docs(sdlc): update work products for 23/09 review feedback
This commit is contained in:
Thanakorn
+1
-1
@@ -62,7 +62,7 @@
|
||||
| WP 2.0 | เอกสาร 200-WMS-26-001-00 Customer Requirements | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 3.0 | เอกสาร 200-WMS-26-001-00 Software Requirements Specification | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 4.0 | เอกสาร 200-WMS-26-001-00 Software Design | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 3 ฉบับ (CH-001–CH-003) |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 1 ชุด (ทะเบียนการควบคุมการเปลี่ยนแปลง) |
|
||||
| WP 6.0 | เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 7.0 | เอกสาร 200-WMS-26-001-00 Validation Results | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 8.0 | เอกสาร 200-WMS-26-001-00 Software User Document | ส่งเอกสารจำนวน 1 ชุด |
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@
|
||||
| 4.1 | Project Control | Progress & Meeting Records | ติดตามความก้าวหน้า ประเด็นปัญหา มติ และการแก้ไขตลอดโครงการ | ApS, YaB | 5 ม.ค. 69 | 24 ส.ค. 69 | 232 | Progress Status, Meeting Record | Completed | บันทึกรายงวดตลอดโครงการ |
|
||||
| 4.2 | Project Control | Configuration & Repository Control | ควบคุม Source Code, Baseline, เวอร์ชันเอกสาร และการสำรองข้อมูล | ThS, YaB | 19 ก.พ. 69 | 24 ส.ค. 69 | 187 | Software Configuration | Completed | Git origin + backup remote |
|
||||
| 4.3 | Verification | Verify Work Products | ตรวจสอบความต้องการ ออกแบบ ส่วนประกอบ และการสอบกลับ | PaNg, NoC | 30 พ.ค. 69 | 17 ส.ค. 69 | 80 | Verification Results | Completed | ตรวจสอบ 4 รอบ รอบสุดท้าย 17 ส.ค. 69 |
|
||||
| 4.4 | Validation | System Test & UAT | ทดสอบระบบตาม Test Case และทดสอบการยอมรับโดยผู้ใช้ | PaNg, SeV | 10 ส.ค. 69 | 14 ส.ค. 69 | 5 | Test Report, Validation Results | Completed | ทดสอบ 45 Test Case และ 12 สถานการณ์ UAT |
|
||||
| 4.4 | Validation | System Test & UAT | ทดสอบระบบตาม Test Case และทดสอบการยอมรับโดยผู้ใช้ | PaNg, SeV | 10 ส.ค. 69 | 14 ส.ค. 69 | 5 | Test Report, Validation Results | Completed | ทดสอบ 45 Test Case และ UAT ครบ 14 หมวดความต้องการ (80 รายการ) |
|
||||
| 4.5 | Documentation | Operational Documentation | จัดทำคู่มือผู้ใช้ คู่มือผู้ดูแลระบบ และคู่มือบำรุงรักษา | ThS, YaB | 1 มิ.ย. 69 | 17 ส.ค. 69 | 78 | User / Operation / Maintenance docs | Completed | จัดทำครบ 3 ฉบับ |
|
||||
| 4.6 | Stabilization | Post-baseline Corrections | แก้ไขปัญหาการเข้าสู่ระบบและค่าตั้งค่าหลัง Baseline | ThS | 3 ส.ค. 69 | 3 ส.ค. 69 | 1 | Correction Register | Completed | Git b2c4374 |
|
||||
| 4.7 | Stabilization | Demonstration Data & Delivery Package | เตรียมข้อมูลสาธิต ปรับแบรนด์ และชุดติดตั้ง Docker Compose | ThS | 14 ส.ค. 69 | 17 ส.ค. 69 | 4 | Demo data, Docker stack | Completed | Git dd48a8b–6c39700 |
|
||||
@@ -51,7 +51,7 @@
|
||||
| ตั้ง Baseline ความต้องการและแผนงาน | 18 กุมภาพันธ์ 2569 | อนุมัติ Customer Requirements และ Work Schedule |
|
||||
| เริ่มพัฒนาระบบ | 19 กุมภาพันธ์ 2569 | เริ่ม Task 3.1 ตามแผน |
|
||||
| Baseline การพัฒนา | 29 พฤษภาคม 2569 | พัฒนาครบทุกโมดูล (Git a0677d6) |
|
||||
| ทดสอบระบบและ UAT | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 | ทดสอบ 45 Test Case และ 12 สถานการณ์ UAT ผ่านทั้งหมด |
|
||||
| ทดสอบระบบและ UAT | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 | ทดสอบ 45 Test Case และ UAT ครบ 14 หมวดความต้องการ (80 รายการ) ผ่านทั้งหมด |
|
||||
| ตรวจรับส่งมอบระบบ | 17 สิงหาคม 2569 | ผลการตรวจรับ Accepted |
|
||||
| อบรมผู้ใช้งาน | 22 สิงหาคม 2569 | อบรมผู้ใช้งาน 6 คน |
|
||||
| ปิดโครงการ | 24 สิงหาคม 2569 | ปิดโครงการอย่างเป็นทางการ |
|
||||
|
||||
+30
-4
@@ -67,7 +67,7 @@
|
||||
| WP 2.0 | เอกสาร 200-WMS-26-001-00 Customer Requirements | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 3.0 | เอกสาร 200-WMS-26-001-00 Software Requirements Specification | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 4.0 | เอกสาร 200-WMS-26-001-00 Software Design | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 3 ฉบับ (CH-001–CH-003) |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 1 ชุด (ทะเบียนการควบคุมการเปลี่ยนแปลง) |
|
||||
| WP 6.0 | เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 7.0 | เอกสาร 200-WMS-26-001-00 Validation Results | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 8.0 | เอกสาร 200-WMS-26-001-00 Software User Document | ส่งเอกสารจำนวน 1 ชุด |
|
||||
@@ -113,11 +113,11 @@
|
||||
|
||||
| ขั้นตอน | แนวทางที่ใช้จริงในโครงการ |
|
||||
| --- | --- |
|
||||
| Requirements | เก็บความต้องการและตั้ง Baseline ก่อนเริ่มพัฒนา การเปลี่ยนแปลงภายหลังผ่าน Change Report (CH-001–CH-003) |
|
||||
| Requirements | เก็บความต้องการและตั้ง Baseline ก่อนเริ่มพัฒนา การเปลี่ยนแปลงภายหลังต้องพิจารณาตามเกณฑ์ใน Change Report ก่อนดำเนินการ |
|
||||
| Design | ออกแบบสถาปัตยกรรม โครงสร้างฐานข้อมูล และ Software Unit ก่อนพัฒนาแต่ละโมดูล |
|
||||
| Implementation | พัฒนาเป็นโมดูลต่อเนื่องระหว่าง 19 ก.พ. – 29 พ.ค. 69 พร้อมทบทวนและแก้ไขระหว่างทาง |
|
||||
| Verification | ตรวจสอบ Work Products 4 รอบ ควบคู่กับการพัฒนา และรอบสุดท้ายก่อนส่งมอบ |
|
||||
| Validation | ทดสอบระบบและ UAT ระหว่าง 10–14 ส.ค. 69 บนสภาพแวดล้อมที่กำหนด |
|
||||
| Verification | ตรวจสอบ Work Products 4 รอบ ประมาณทุก 2 เดือน และรอบสุดท้ายก่อนส่งมอบ ตามแผนในหัวข้อ 8.1 |
|
||||
| Validation | ทดสอบระบบและ UAT ระหว่าง 10–14 ส.ค. 69 บนสภาพแวดล้อมที่กำหนด โดยใช้ Customer Requirements ทุกรายการเป็นตัวตั้ง |
|
||||
| Closure | ตรวจรับ อบรม ปิดงานควบคุมปฏิบัติการ และปิดโครงการภายใน 24 ส.ค. 69 |
|
||||
|
||||
## 5 Organization
|
||||
@@ -189,6 +189,32 @@
|
||||
| Verification & Validation | 30 พฤษภาคม 2569 – 17 สิงหาคม 2569 | Test Case, Test Report, Verification Results, Validation Results |
|
||||
| Project Close | 10 สิงหาคม 2569 – 24 สิงหาคม 2569 | Acceptance Report, Training Report, List of Evidence |
|
||||
|
||||
### 8.1 แผนการตรวจสอบ (Verification Plan)
|
||||
|
||||
โครงการมีระยะเวลา 232 วัน จึงกำหนดให้ตรวจสอบ Work Products ทั้งหมด 4 ครั้ง ประมาณทุก 2 เดือน (ทุก 60–75 วัน) ครั้งละ 3 ชั่วโมง และรอบสุดท้ายก่อนส่งมอบระบบ 6 ชั่วโมง เพื่อให้พบประเด็นตั้งแต่เนิ่น ๆ และแก้ไขได้ก่อนเริ่มงานขั้นถัดไป ผลการตรวจสอบแต่ละรอบบันทึกใน Verification Results และประเด็นที่พบบันทึกใน Correction Register
|
||||
|
||||
| รอบ | วันที่ตรวจสอบ | เวลา | ชั่วโมง | หัวข้อการตรวจสอบ | Deliverables under Review |
|
||||
| :---: | --- | :---: | ---: | --- | --- |
|
||||
| 1 | 17 มีนาคม 2569 | 09:00 – 12:00 น. | 3 | ตรวจสอบเอกสารวางแผนโครงการและความต้องการ | WP 1.0, WP 2.0 |
|
||||
| 2 | 29 พฤษภาคม 2569 | 09:00 – 12:00 น. | 3 | ตรวจสอบเอกสารความต้องการซอฟต์แวร์และการออกแบบ | WP 3.0, WP 4.0, WP 5.0 |
|
||||
| 3 | 31 กรกฎาคม 2569 | 09:00 – 12:00 น. | 3 | ตรวจสอบชุดทดสอบและการสอบกลับ | WP 6.0 |
|
||||
| 4 | 17 สิงหาคม 2569 | 09:00 – 16:00 น. | 6 | User Acceptance Test (UAT) และตรวจสอบเอกสารส่งมอบทั้งหมด | WP 1.0, WP 2.0, WP 3.0, WP 4.0, WP 5.0, WP 6.0, WP 7.0, WP 8.0, WP 9.0, WP 10.0, WP 11.0 |
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ผู้ตรวจสอบ | คุณปริญ งามขำ (QA/Tester) ร่วมกับ คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
| ผู้เข้าร่วมรับฟังผล | ผู้จัดทำ Work Product ที่ตรวจในรอบนั้น เพื่อแก้ไขได้ทันทีเมื่อพบประเด็น |
|
||||
| ผู้อนุมัติผลการตรวจสอบ | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor) |
|
||||
| รวมเวลาตรวจสอบตลอดโครงการ | 15 ชั่วโมง |
|
||||
| บันทึกผล | Verification Results แยกฉบับตามรอบ (V0.1–V1.0) และ Correction Register |
|
||||
|
||||
**Risk & Constraints Note**
|
||||
|
||||
1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
|
||||
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
|
||||
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
|
||||
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย
|
||||
|
||||
## 9 Risk Management Plan
|
||||
|
||||
วัตถุประสงค์ของแผนบริหารความเสี่ยง คือระบุแนวทางจัดการความเสี่ยงของโครงการ เพื่อให้โครงการบรรลุเป้าหมายภายในเวลา งบประมาณ และคุณภาพที่กำหนด
|
||||
|
||||
+96
-96
@@ -27,102 +27,102 @@
|
||||
|
||||
## ความต้องการเชิงหน้าที่และไม่ใช่หน้าที่ (Functional and Non-Functional Requirements)
|
||||
|
||||
| ID | Topic | Result* | Remark |
|
||||
| --- | --- | :---: | --- |
|
||||
| CR01: Feature & Functional Characteristics | | | |
|
||||
| CR01:001 | ระบบต้องรองรับการลงทะเบียนเจ้าของบริษัทและการเชิญผู้ใช้งานเข้าร่วมบริษัท (Onboarding) | A | FR-001 |
|
||||
| CR01:002 | ระบบต้องยืนยันตัวตนผู้ใช้และบังคับสิทธิ์ตามบทบาท Owner, Admin, Staff และ Viewer | A | FR-002 |
|
||||
| CR01:003 | ระบบต้องรองรับการกู้คืนรหัสผ่าน การควบคุม Session และการยืนยัน OTP ตามที่กำหนด | A | FR-003 |
|
||||
| CR01:004 | ระบบต้องให้ผู้ดูแลจัดการข้อมูลบริษัท, SMTP, การตั้งค่าระบบ, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน | A | FR-004 |
|
||||
| CR01:005 | ระบบต้องจัดการข้อมูลคลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ประเภทผู้ติดต่อ และผู้ติดต่อ | A | FR-005 |
|
||||
| CR01:006 | ระบบต้องรองรับโครงสร้างตำแหน่งจัดเก็บทั้งแบบคลังเดียวและแบบหลายชั้น (คลัง/พื้นที่/ช่อง) | A | FR-006 |
|
||||
| CR01:007 | ระบบต้องบันทึกการรับสินค้าเข้า (Stock-in) ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง และข้อมูลติดตาม | A | FR-007 |
|
||||
| CR01:008 | ระบบต้องบันทึกการจ่ายสินค้าออก (Stock-out) โดยตรวจสอบสิทธิ์และยอดคงเหลือก่อนจ่าย | A | FR-008 |
|
||||
| CR01:009 | ระบบต้องโอนย้ายสินค้าระหว่างตำแหน่งจัดเก็บที่ได้รับอนุญาตโดยยอดต้นทาง/ปลายทางสมดุลกัน | A | FR-009 |
|
||||
| CR01:010 | ระบบต้องติดตาม Lot, Serial Number และวันหมดอายุของสินค้าที่เกี่ยวข้อง | A | FR-010 |
|
||||
| CR01:011 | ระบบต้องแสดงภาพรวมสต๊อก, ประวัติความเคลื่อนไหว, ความจุ/การใช้พื้นที่, สินค้าใกล้หมด, สินค้าหมดอายุ และข้อมูล Lot | A | FR-011 |
|
||||
| CR01:012 | ระบบต้องพิมพ์บาร์โค้ดสินค้า (SKU) และตำแหน่งจัดเก็บ และรองรับการสแกนในหน้าจอที่กำหนด | A | FR-012 |
|
||||
| CR01:013 | ระบบต้องสร้างและจัดการใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน และใบลดหนี้ | A | FR-013 |
|
||||
| CR01:014 | ระบบต้องสร้างและจัดการใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ และใบคืนสินค้าผู้ขาย | A | FR-014 |
|
||||
| CR01:015 | ระบบต้องสร้างและจัดการใบวางบิลรับ, ใบเสร็จรับเงิน, ใบวางบิลจ่าย และใบสำคัญจ่าย | A | FR-015 |
|
||||
| CR01:016 | ระบบต้องจัดการผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน และบัญชีแยกประเภท | A | FR-016 |
|
||||
| CR01:017 | ระบบต้องจัดทำรายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม, สมุดรายวัน และความเคลื่อนไหว GL | A | FR-017 |
|
||||
| CR01:018 | ระบบต้องออกเลขที่เอกสารอัตโนมัติและควบคุมสถานะ/วงจรชีวิตของเอกสาร | A | FR-018 |
|
||||
| CR01:019 | ระบบต้องรองรับการแนบไฟล์ที่อนุญาตกับรายการที่กำหนด | A | FR-019 |
|
||||
| CR01:020 | ระบบต้องให้ผู้ใช้กรอง ดู พิมพ์ และส่งออกรายงานปฏิบัติการและรายงานผู้บริหาร | A | FR-020 |
|
||||
| CR01:021 | ระบบต้องแจ้งเตือนผู้ใช้ที่เกี่ยวข้องเมื่อสถานะเอกสารเปลี่ยนหรือมีเหตุการณ์ปฏิบัติการ | A | FR-021 |
|
||||
| CR01:022 | ระบบต้องสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระตามกำหนดเวลา | A | FR-022 |
|
||||
| CR01:023 | ระบบต้องเก็บผู้สร้าง ผู้แก้ไข สถานะ และประวัติรายการเพื่อการตรวจสอบ | A | FR-023 |
|
||||
| CR01:024 | ระบบต้องจำกัดข้อมูลบริษัทและคลังสินค้าให้เฉพาะผู้ใช้ที่ได้รับอนุญาตในบริบทปัจจุบัน | A | FR-024 |
|
||||
| CR02: Performance Considerations | | | |
|
||||
| CR02:001 | ระบบต้องตอบสนองงานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | A | NFR-006 |
|
||||
| CR02:002 | ระบบต้องมีตารางสรุปยอด (Aggregate) เพื่อให้แดชบอร์ดและรายงานแสดงผลได้โดยไม่ต้องคำนวณใหม่ทุกครั้ง | A | NFR-006 |
|
||||
| CR02:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันในระดับที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | A | NFR-006 |
|
||||
| CR03: Interface Considerations | | | |
|
||||
| CR03:001 | ระบบต้องเชื่อมต่อฐานข้อมูล MySQL/MariaDB 2 ฐาน (wms สำหรับผู้ใช้/บริษัท และ wms2 สำหรับคลัง/บัญชี) | A | Operational context |
|
||||
| CR03:002 | ระบบต้องใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ได้ | A | NFR-008 |
|
||||
| CR03:003 | ระบบต้องส่งเหตุการณ์ไปยังบริการ Node.js ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret | A | NFR-002 |
|
||||
| CR03:004 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint สาธารณะเพื่อรับการแจ้งเตือนแบบ Real-time | A | FR-021 |
|
||||
| CR03:005 | ระบบต้องส่งอีเมล Onboarding, กู้คืนรหัสผ่าน และแจ้งเตือนผ่าน SMTP ที่ตั้งค่าต่อบริษัท | A | FR-004 |
|
||||
| CR04: Required System Characteristics | | | |
|
||||
| CR04:001 | ระบบต้องพัฒนาบนสถาปัตยกรรม Web-based Application | A | Operational context |
|
||||
| CR04:002 | ระบบต้องเก็บข้อมูลแบบ Relational Database และรักษา Referential Integrity | A | Data requirements |
|
||||
| CR04:003 | ระบบต้องรองรับการเข้าสู่ระบบด้วย Username/Password และกำหนดบทบาทผู้ใช้ | A | FR-002 |
|
||||
| CR04:004 | ระบบต้องทำงานบน PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js | A | NFR-008 |
|
||||
| CR05: Human Engineering Considerations | | | |
|
||||
| CR05:001 | UI ต้องเป็น Responsive ใช้งานได้ทั้งบน Desktop และอุปกรณ์หน้าคลังสินค้า (Tablet/Mobile) | A | NFR-005 |
|
||||
| CR05:002 | เมนูและปุ่มคำสั่งต้องแสดงตามบทบาทและสิทธิ์การเข้าถึงของผู้ใช้ | A | Interface requirements |
|
||||
| CR05:003 | ระบบต้องแสดงผลการตรวจสอบข้อมูล สถานะ ความสำเร็จ และข้อผิดพลาดอย่างชัดเจน | A | Interface requirements |
|
||||
| CR05:004 | ระบบต้องมีขั้นตอนยืนยันก่อนลบ ยกเลิก หรือทำรายการที่ย้อนกลับไม่ได้ | A | Usability practice |
|
||||
| CR05:005 | ระบบต้องพิมพ์เอกสารธุรกิจและฉลากบาร์โค้ดในรูปแบบที่ใช้งานได้ | A | Interface requirements |
|
||||
| CR06: Security Considerations | | | |
|
||||
| CR06:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องเข้ารหัสด้วย HTTPS/TLS | A | NFR-001 |
|
||||
| CR06:002 | ค่าตั้งค่าและความลับของระบบต้องไม่ถูกเก็บใน Source Control และไม่เข้าถึงได้จากเว็บสาธารณะ | A | NFR-001 |
|
||||
| CR06:003 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | A | NFR-002 |
|
||||
| CR06:004 | ระบบต้องจำกัดสิทธิ์การเข้าถึงตามบทบาท (Role-based Access Control) ทั้งใน UI และฝั่งเซิร์ฟเวอร์ | A | FR-002 |
|
||||
| CR06:005 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting | A | NFR-002 |
|
||||
| CR06:006 | ระบบต้องบล็อกการเข้าสู่ระบบซ้ำซ้อน (Concurrent Login) ของบัญชีเดียวกัน | A | FR-003 |
|
||||
| CR07: Environmental Considerations | | | |
|
||||
| CR07:001 | ระบบต้องทำงานบน Linux Server ในรูปแบบติดตั้งเอง (LAMP) หรือ Docker Compose | A | NFR-004 |
|
||||
| CR07:002 | ระบบต้องใช้เขตเวลา Asia/Bangkok อย่างสม่ำเสมอทั้งแอปพลิเคชันและงานตามกำหนดเวลา | A | NFR-010 |
|
||||
| CR07:003 | ระบบต้องใช้งานได้บนอุปกรณ์ Desktop และอุปกรณ์พกพาผ่าน Web Browser | A | NFR-005 |
|
||||
| CR07:004 | ระบบต้องแยกข้อมูลสาธิต/ทดสอบออกจากข้อมูลใช้งานจริงได้ | A | Data requirements |
|
||||
| CR08: Operational Considerations | | | |
|
||||
| CR08:001 | ระบบต้องมีการสำรองฐานข้อมูลอัตโนมัติรายวัน | A | NFR-004 |
|
||||
| CR08:002 | ระบบต้องกู้คืนข้อมูลจากชุดสำรองได้ตามขั้นตอนที่จัดทำเป็นเอกสาร | A | NFR-004 |
|
||||
| CR08:003 | ระบบต้องมีการเฝ้าระวังสถานะบริการ Web, Database และ Node.js พร้อมแจ้งเตือนเมื่อขัดข้อง | A | NFR-004 |
|
||||
| CR08:004 | ระบบต้องรองรับหลายบริษัท (Multi-company) และหลายคลังสินค้าภายใต้การแยกข้อมูล | A | FR-024 |
|
||||
| CR08:005 | งานตามกำหนดเวลาต้องทำงานสำเร็จโดยไม่สร้างผลลัพธ์ซ้ำหรือเกินสิทธิ์ | A | FR-022 |
|
||||
| CR09: Maintenance Considerations | | | |
|
||||
| CR09:001 | ซอฟต์แวร์ต้องมีโครงสร้างแบบโมดูล (Manager Classes / API) เพื่อให้แก้ไขได้โดยไม่กระทบส่วนอื่น | A | NFR-007 |
|
||||
| CR09:002 | ระบบต้องมีแม่แบบค่าตั้งค่า (Configuration Template) และควบคุมเวอร์ชันด้วย Git | A | NFR-007 |
|
||||
| CR09:003 | ระบบต้องมีเอกสารคู่มือการบำรุงรักษาและประวัติข้อบกพร่องที่แก้ไขแล้ว | A | NFR-004 |
|
||||
| CR09:004 | การเปลี่ยนแปลงโครงสร้างฐานข้อมูลต้องสะท้อนใน setup.php และตาราง schema_migrations | A | NFR-007 |
|
||||
| CR10: Installation Considerations | | | |
|
||||
| CR10:001 | ระบบต้องติดตั้งฐานข้อมูลได้ในขั้นตอนเดียวผ่าน setup.php | A | NFR-004 |
|
||||
| CR10:002 | ระบบต้องติดตั้งแบบ Container ได้ด้วยคำสั่ง docker compose up -d --build | A | NFR-004 |
|
||||
| CR10:003 | ระบบต้องมีสคริปต์สร้างไฟล์ .env และค่าความลับอัตโนมัติ (docker/init-env.sh) | A | NFR-001 |
|
||||
| CR10:004 | ระบบต้องมีเอกสารขั้นตอนการติดตั้งและตั้งค่า | A | NFR-004 |
|
||||
| CR11: Support Considerations | | | |
|
||||
| CR11:001 | ต้องมีคู่มือผู้ใช้งาน (Software User Document) | A | Documentation |
|
||||
| CR11:002 | ต้องมีคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ (Product Operation Guide) | A | Documentation |
|
||||
| CR11:003 | ต้องมีการอบรมผู้ใช้งานก่อนเปิดใช้งานจริง | A | Training |
|
||||
| CR11:004 | ต้องมีช่องทางสนับสนุนและระดับการให้บริการ (SLA) หลังส่งมอบ | A | Maintenance |
|
||||
| CR12: Design Constraints | | | |
|
||||
| CR12:001 | ระบบต้องพัฒนาด้วย PHP, MariaDB และ Node.js ตามที่องค์กรอนุมัติ | A | NFR-008 |
|
||||
| CR12:002 | ระบบต้องควบคุม Source Code ด้วย Git โดยมี main เป็น Baseline หลัก | A | Configuration |
|
||||
| CR12:003 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | A | NFR-002 |
|
||||
| CR12:004 | โครงการต้องจัดทำ Work Products ตามมาตรฐาน ISO/IEC 29110 Basic Profile | A | NFR-009 |
|
||||
| CR13: Safety and Reliability Considerations | | | |
|
||||
| CR13:001 | การเปลี่ยนแปลงฐานข้อมูลที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction เดียวกัน | A | NFR-003 |
|
||||
| CR13:002 | ระบบต้องป้องกันยอดสต๊อกติดลบและความเคลื่อนไหวซ้ำซ้อน | A | NFR-003 |
|
||||
| CR13:003 | ระบบต้องรองรับการสำรองและกู้คืน (Backup & Recovery) ทั้ง Source Code และฐานข้อมูล | A | NFR-004 |
|
||||
| CR13:004 | ระบบต้องจัดการข้อผิดพลาดโดยแสดงข้อความที่เข้าใจได้แทน Fatal Error | A | NFR-006 |
|
||||
| CR14: Quality Expectations | | | |
|
||||
| CR14:001 | ระบบต้องผ่านการทดสอบตาม Test Case ที่กำหนดก่อนส่งมอบ | A | Acceptance |
|
||||
| CR14:002 | ทุกความต้องการต้องสอบกลับได้ถึงการออกแบบ ส่วนประกอบ และหลักฐานการทดสอบ | A | NFR-009 |
|
||||
| CR14:003 | ระบบต้องผ่านการทดสอบการยอมรับ (UAT) โดยตัวแทนลูกค้าบนสภาพแวดล้อมใช้งานจริง | A | Acceptance |
|
||||
| CR14:004 | ต้องไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ในด้านความปลอดภัย การแยกข้อมูล และความถูกต้องของสต๊อก/บัญชี | A | Acceptance |
|
||||
| ID | Topic | Result* |
|
||||
| --- | --- | :---: |
|
||||
| CR01: Feature & Functional Characteristics | | |
|
||||
| CR01:001 | ระบบต้องรองรับการลงทะเบียนเจ้าของบริษัทและการเชิญผู้ใช้งานเข้าร่วมบริษัท (Onboarding) | A |
|
||||
| CR01:002 | ระบบต้องยืนยันตัวตนผู้ใช้และบังคับสิทธิ์ตามบทบาท Owner, Admin, Staff และ Viewer | A |
|
||||
| CR01:003 | ระบบต้องรองรับการกู้คืนรหัสผ่าน การควบคุม Session และการยืนยัน OTP ตามที่กำหนด | A |
|
||||
| CR01:004 | ระบบต้องให้ผู้ดูแลจัดการข้อมูลบริษัท, SMTP, การตั้งค่าระบบ, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน | A |
|
||||
| CR01:005 | ระบบต้องจัดการข้อมูลคลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ประเภทผู้ติดต่อ และผู้ติดต่อ | A |
|
||||
| CR01:006 | ระบบต้องรองรับโครงสร้างตำแหน่งจัดเก็บทั้งแบบคลังเดียวและแบบหลายชั้น (คลัง/พื้นที่/ช่อง) | A |
|
||||
| CR01:007 | ระบบต้องบันทึกการรับสินค้าเข้า (Stock-in) ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง และข้อมูลติดตาม | A |
|
||||
| CR01:008 | ระบบต้องบันทึกการจ่ายสินค้าออก (Stock-out) โดยตรวจสอบสิทธิ์และยอดคงเหลือก่อนจ่าย | A |
|
||||
| CR01:009 | ระบบต้องโอนย้ายสินค้าระหว่างตำแหน่งจัดเก็บที่ได้รับอนุญาตโดยยอดต้นทาง/ปลายทางสมดุลกัน | A |
|
||||
| CR01:010 | ระบบต้องติดตาม Lot, Serial Number และวันหมดอายุของสินค้าที่เกี่ยวข้อง | A |
|
||||
| CR01:011 | ระบบต้องแสดงภาพรวมสต๊อก, ประวัติความเคลื่อนไหว, ความจุ/การใช้พื้นที่, สินค้าใกล้หมด, สินค้าหมดอายุ และข้อมูล Lot | A |
|
||||
| CR01:012 | ระบบต้องพิมพ์บาร์โค้ดสินค้า (SKU) และตำแหน่งจัดเก็บ และรองรับการสแกนในหน้าจอที่กำหนด | A |
|
||||
| CR01:013 | ระบบต้องสร้างและจัดการใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน และใบลดหนี้ | A |
|
||||
| CR01:014 | ระบบต้องสร้างและจัดการใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ และใบคืนสินค้าผู้ขาย | A |
|
||||
| CR01:015 | ระบบต้องสร้างและจัดการใบวางบิลรับ, ใบเสร็จรับเงิน, ใบวางบิลจ่าย และใบสำคัญจ่าย | A |
|
||||
| CR01:016 | ระบบต้องจัดการผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน และบัญชีแยกประเภท | A |
|
||||
| CR01:017 | ระบบต้องจัดทำรายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม, สมุดรายวัน และความเคลื่อนไหว GL | A |
|
||||
| CR01:018 | ระบบต้องออกเลขที่เอกสารอัตโนมัติและควบคุมสถานะ/วงจรชีวิตของเอกสาร | A |
|
||||
| CR01:019 | ระบบต้องรองรับการแนบไฟล์ที่อนุญาตกับรายการที่กำหนด | A |
|
||||
| CR01:020 | ระบบต้องให้ผู้ใช้กรอง ดู พิมพ์ และส่งออกรายงานปฏิบัติการและรายงานผู้บริหาร | A |
|
||||
| CR01:021 | ระบบต้องแจ้งเตือนผู้ใช้ที่เกี่ยวข้องเมื่อสถานะเอกสารเปลี่ยนหรือมีเหตุการณ์ปฏิบัติการ | A |
|
||||
| CR01:022 | ระบบต้องสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระตามกำหนดเวลา | A |
|
||||
| CR01:023 | ระบบต้องเก็บผู้สร้าง ผู้แก้ไข สถานะ และประวัติรายการเพื่อการตรวจสอบ | A |
|
||||
| CR01:024 | ระบบต้องจำกัดข้อมูลบริษัทและคลังสินค้าให้เฉพาะผู้ใช้ที่ได้รับอนุญาตในบริบทปัจจุบัน | A |
|
||||
| CR02: Performance Considerations | | |
|
||||
| CR02:001 | ระบบต้องตอบสนองงานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | A |
|
||||
| CR02:002 | ระบบต้องมีตารางสรุปยอด (Aggregate) เพื่อให้แดชบอร์ดและรายงานแสดงผลได้โดยไม่ต้องคำนวณใหม่ทุกครั้ง | A |
|
||||
| CR02:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันในระดับที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | A |
|
||||
| CR03: Interface Considerations | | |
|
||||
| CR03:001 | ระบบต้องเชื่อมต่อฐานข้อมูล MySQL/MariaDB 2 ฐาน (wms สำหรับผู้ใช้/บริษัท และ wms2 สำหรับคลัง/บัญชี) | A |
|
||||
| CR03:002 | ระบบต้องใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ได้ | A |
|
||||
| CR03:003 | ระบบต้องส่งเหตุการณ์ไปยังบริการ Node.js ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret | A |
|
||||
| CR03:004 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint สาธารณะเพื่อรับการแจ้งเตือนแบบ Real-time | A |
|
||||
| CR03:005 | ระบบต้องส่งอีเมล Onboarding, กู้คืนรหัสผ่าน และแจ้งเตือนผ่าน SMTP ที่ตั้งค่าต่อบริษัท | A |
|
||||
| CR04: Required System Characteristics | | |
|
||||
| CR04:001 | ระบบต้องพัฒนาบนสถาปัตยกรรม Web-based Application | A |
|
||||
| CR04:002 | ระบบต้องเก็บข้อมูลแบบ Relational Database และรักษา Referential Integrity | A |
|
||||
| CR04:003 | ระบบต้องรองรับการเข้าสู่ระบบด้วย Username/Password และกำหนดบทบาทผู้ใช้ | A |
|
||||
| CR04:004 | ระบบต้องทำงานบน PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js | A |
|
||||
| CR05: Human Engineering Considerations | | |
|
||||
| CR05:001 | UI ต้องเป็น Responsive ใช้งานได้ทั้งบน Desktop และอุปกรณ์หน้าคลังสินค้า (Tablet/Mobile) | A |
|
||||
| CR05:002 | เมนูและปุ่มคำสั่งต้องแสดงตามบทบาทและสิทธิ์การเข้าถึงของผู้ใช้ | A |
|
||||
| CR05:003 | ระบบต้องแสดงผลการตรวจสอบข้อมูล สถานะ ความสำเร็จ และข้อผิดพลาดอย่างชัดเจน | A |
|
||||
| CR05:004 | ระบบต้องมีขั้นตอนยืนยันก่อนลบ ยกเลิก หรือทำรายการที่ย้อนกลับไม่ได้ | A |
|
||||
| CR05:005 | ระบบต้องพิมพ์เอกสารธุรกิจและฉลากบาร์โค้ดในรูปแบบที่ใช้งานได้ | A |
|
||||
| CR06: Security Considerations | | |
|
||||
| CR06:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องเข้ารหัสด้วย HTTPS/TLS | A |
|
||||
| CR06:002 | ค่าตั้งค่าและความลับของระบบต้องไม่ถูกเก็บใน Source Control และไม่เข้าถึงได้จากเว็บสาธารณะ | A |
|
||||
| CR06:003 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | A |
|
||||
| CR06:004 | ระบบต้องจำกัดสิทธิ์การเข้าถึงตามบทบาท (Role-based Access Control) ทั้งใน UI และฝั่งเซิร์ฟเวอร์ | A |
|
||||
| CR06:005 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting | A |
|
||||
| CR06:006 | ระบบต้องบล็อกการเข้าสู่ระบบซ้ำซ้อน (Concurrent Login) ของบัญชีเดียวกัน | A |
|
||||
| CR07: Environmental Considerations | | |
|
||||
| CR07:001 | ระบบต้องทำงานบน Linux Server ในรูปแบบติดตั้งเอง (LAMP) หรือ Docker Compose | A |
|
||||
| CR07:002 | ระบบต้องใช้เขตเวลา Asia/Bangkok อย่างสม่ำเสมอทั้งแอปพลิเคชันและงานตามกำหนดเวลา | A |
|
||||
| CR07:003 | ระบบต้องใช้งานได้บนอุปกรณ์ Desktop และอุปกรณ์พกพาผ่าน Web Browser | A |
|
||||
| CR07:004 | ระบบต้องแยกข้อมูลสาธิต/ทดสอบออกจากข้อมูลใช้งานจริงได้ | A |
|
||||
| CR08: Operational Considerations | | |
|
||||
| CR08:001 | ระบบต้องมีการสำรองฐานข้อมูลอัตโนมัติรายวัน | A |
|
||||
| CR08:002 | ระบบต้องกู้คืนข้อมูลจากชุดสำรองได้ตามขั้นตอนที่จัดทำเป็นเอกสาร | A |
|
||||
| CR08:003 | ระบบต้องมีการเฝ้าระวังสถานะบริการ Web, Database และ Node.js พร้อมแจ้งเตือนเมื่อขัดข้อง | A |
|
||||
| CR08:004 | ระบบต้องรองรับหลายบริษัท (Multi-company) และหลายคลังสินค้าภายใต้การแยกข้อมูล | A |
|
||||
| CR08:005 | งานตามกำหนดเวลาต้องทำงานสำเร็จโดยไม่สร้างผลลัพธ์ซ้ำหรือเกินสิทธิ์ | A |
|
||||
| CR09: Maintenance Considerations | | |
|
||||
| CR09:001 | ซอฟต์แวร์ต้องมีโครงสร้างแบบโมดูล (Manager Classes / API) เพื่อให้แก้ไขได้โดยไม่กระทบส่วนอื่น | A |
|
||||
| CR09:002 | ระบบต้องมีแม่แบบค่าตั้งค่า (Configuration Template) และควบคุมเวอร์ชันด้วย Git | A |
|
||||
| CR09:003 | ระบบต้องมีเอกสารคู่มือการบำรุงรักษาและประวัติข้อบกพร่องที่แก้ไขแล้ว | A |
|
||||
| CR09:004 | การเปลี่ยนแปลงโครงสร้างฐานข้อมูลต้องสะท้อนใน setup.php และตาราง schema_migrations | A |
|
||||
| CR10: Installation Considerations | | |
|
||||
| CR10:001 | ระบบต้องติดตั้งฐานข้อมูลได้ในขั้นตอนเดียวผ่าน setup.php | A |
|
||||
| CR10:002 | ระบบต้องติดตั้งแบบ Container ได้ด้วยคำสั่ง docker compose up -d --build | A |
|
||||
| CR10:003 | ระบบต้องมีสคริปต์สร้างไฟล์ .env และค่าความลับอัตโนมัติ (docker/init-env.sh) | A |
|
||||
| CR10:004 | ระบบต้องมีเอกสารขั้นตอนการติดตั้งและตั้งค่า | A |
|
||||
| CR11: Support Considerations | | |
|
||||
| CR11:001 | ต้องมีคู่มือผู้ใช้งาน (Software User Document) | A |
|
||||
| CR11:002 | ต้องมีคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ (Product Operation Guide) | A |
|
||||
| CR11:003 | ต้องมีการอบรมผู้ใช้งานก่อนเปิดใช้งานจริง | A |
|
||||
| CR11:004 | ต้องมีช่องทางสนับสนุนและระดับการให้บริการ (SLA) หลังส่งมอบ | A |
|
||||
| CR12: Design Constraints | | |
|
||||
| CR12:001 | ระบบต้องพัฒนาด้วย PHP, MariaDB และ Node.js ตามที่องค์กรอนุมัติ | A |
|
||||
| CR12:002 | ระบบต้องควบคุม Source Code ด้วย Git โดยมี main เป็น Baseline หลัก | A |
|
||||
| CR12:003 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | A |
|
||||
| CR12:004 | โครงการต้องจัดทำ Work Products ตามมาตรฐาน ISO/IEC 29110 Basic Profile | A |
|
||||
| CR13: Safety and Reliability Considerations | | |
|
||||
| CR13:001 | การเปลี่ยนแปลงฐานข้อมูลที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction เดียวกัน | A |
|
||||
| CR13:002 | ระบบต้องป้องกันยอดสต๊อกติดลบและความเคลื่อนไหวซ้ำซ้อน | A |
|
||||
| CR13:003 | ระบบต้องรองรับการสำรองและกู้คืน (Backup & Recovery) ทั้ง Source Code และฐานข้อมูล | A |
|
||||
| CR13:004 | ระบบต้องจัดการข้อผิดพลาดโดยแสดงข้อความที่เข้าใจได้แทน Fatal Error | A |
|
||||
| CR14: Quality Expectations | | |
|
||||
| CR14:001 | ระบบต้องผ่านการทดสอบตาม Test Case ที่กำหนดก่อนส่งมอบ | A |
|
||||
| CR14:002 | ทุกความต้องการต้องสอบกลับได้ถึงการออกแบบ ส่วนประกอบ และหลักฐานการทดสอบ | A |
|
||||
| CR14:003 | ระบบต้องผ่านการทดสอบการยอมรับ (UAT) โดยตัวแทนลูกค้าบนสภาพแวดล้อมใช้งานจริง | A |
|
||||
| CR14:004 | ต้องไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ในด้านความปลอดภัย การแยกข้อมูล และความถูกต้องของสต๊อก/บัญชี | A |
|
||||
|
||||
## Remark
|
||||
|
||||
|
||||
+1
-1
@@ -39,7 +39,7 @@
|
||||
|
||||
| CR ID | หัวข้อ | สถานะ | ผลกระทบ |
|
||||
| :---: | --- | :---: | --- |
|
||||
| CH-001 | เปลี่ยนคำเรียกตำแหน่งจัดเก็บจาก Rack เป็น Bin | อนุมัติ | แก้ไข 14 ไฟล์ ประมาณ 1,000 บรรทัด ครอบคลุมคลาสจัดการ 8 คลาสและเครื่องมือบาร์โค้ด ไม่มีการเพิ่มฟังก์ชันใหม่ |
|
||||
| - | ไม่มีคำขอเปลี่ยนแปลงในงวดนี้ | - | - |
|
||||
|
||||
## Next Meeting
|
||||
|
||||
|
||||
+2
-2
@@ -14,7 +14,7 @@
|
||||
|
||||
| Task ID | Task Name | Period | Responsible | Status | Progress (%) | Remarks |
|
||||
| :---: | --- | :---: | :---: | :---: | ---: | --- |
|
||||
| 4.4 | System Test & UAT | 10–14 ส.ค. 69 | PaNg, SeV | Completed | 100 | ทดสอบระบบ 45 Test Case และ UAT 12 สถานการณ์ ผ่านทั้งหมดระหว่าง 10–14 ส.ค. 69 |
|
||||
| 4.4 | System Test & UAT | 10–14 ส.ค. 69 | PaNg, SeV | Completed | 100 | ทดสอบระบบ 45 Test Case และ UAT ครบ 14 หมวดความต้องการ (80 รายการ) ผ่านทั้งหมดระหว่าง 10–14 ส.ค. 69 |
|
||||
| 4.7 | Demonstration Data & Delivery Package | 14–17 ส.ค. 69 | ThS | In Progress | 60 | จัดทำข้อมูลสาธิตเสร็จ อยู่ระหว่างปรับแบรนด์และชุดติดตั้ง Docker Compose |
|
||||
| 5.1 | Final Work-product Review | 10–17 ส.ค. 69 | ApS, YaB | In Progress | 70 | ตรวจสอบความครบถ้วนของ Work Products |
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
| CR ID | หัวข้อ | สถานะ | ผลกระทบ |
|
||||
| :---: | --- | :---: | --- |
|
||||
| CH-002 | เพิ่มชุดข้อมูลสาธิตสำหรับการตรวจรับและสาธิตระบบ | อนุมัติ | แก้ไข 9 ไฟล์ เพิ่มประมาณ 2,900 บรรทัด เป็นสคริปต์สร้างข้อมูลใหม่ ไม่แก้ตรรกะหลักของระบบ |
|
||||
| - | ไม่มีคำขอเปลี่ยนแปลงในงวดนี้ | - | - |
|
||||
|
||||
## Next Meeting
|
||||
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@
|
||||
|
||||
| CR ID | หัวข้อ | สถานะ | ผลกระทบ |
|
||||
| :---: | --- | :---: | --- |
|
||||
| CH-003 | ปรับอัตลักษณ์องค์กรและเพิ่มชุดติดตั้ง Docker Compose | อนุมัติ | ปรับแบรนด์ 23 ไฟล์ (ภาพและไฟล์ PHP/CSS 11 ไฟล์) และเพิ่มไฟล์ติดตั้ง 10 ไฟล์ |
|
||||
| - | ไม่มีคำขอเปลี่ยนแปลงในงวดนี้ | - | - |
|
||||
|
||||
## Next Meeting
|
||||
|
||||
|
||||
+12
@@ -56,6 +56,18 @@
|
||||
|
||||
ปัญหาทุกรายการได้รับการแก้ไขและตรวจสอบผลด้วย Test Case ที่เกี่ยวข้อง โดยผลการทดสอบผ่านทั้งหมดในรอบทดสอบระหว่าง 10 สิงหาคม 2569 – 14 สิงหาคม 2569 ไม่มีข้อบกพร่องระดับวิกฤตคงค้าง ณ วันตรวจรับ
|
||||
|
||||
## บทเรียนและแนวทางป้องกันสำหรับโครงการถัดไป (Lessons Learned)
|
||||
|
||||
เมื่อปิดโครงการ ทีมงานทบทวนปัญหาทั้งหมดในทะเบียนนี้ จัดกลุ่มตามสาเหตุ และกำหนดแนวทางป้องกันเพื่อไม่ให้ปัญหาลักษณะเดียวกันเกิดซ้ำในโครงการถัดไป
|
||||
|
||||
| ลำดับ | กลุ่มปัญหา | เลขที่ปัญหา | จำนวน | สิ่งที่เกิดขึ้น | แนวทางป้องกัน (Preventive Action) |
|
||||
| :---: | --- | --- | ---: | --- | --- |
|
||||
| 1 | ความปลอดภัยและการควบคุมสิทธิ์ | ISS-001, ISS-003, ISS-004, ISS-006, ISS-009, ISS-011, ISS-015, ISS-016, ISS-017, ISS-018, ISS-024, ISS-026 | 12 | ข้อบกพร่องกลุ่มใหญ่ที่สุดเกิดจากการเพิ่ม Role Guard การตรวจสิทธิ์ และการจำกัด Session ทีละส่วนระหว่างพัฒนา | กำหนด Secure Coding Checklist และรูปแบบการตรวจสิทธิ์กลางตั้งแต่ช่วงออกแบบ และทบทวนโค้ดด้านความปลอดภัยทุกโมดูลก่อนรวมเข้า Baseline |
|
||||
| 2 | ขั้นตอน Onboarding และการลงทะเบียน | ISS-007, ISS-008, ISS-013 | 3 | เส้นทางการรับคำเชิญมีหลายเงื่อนไขที่ไม่ได้ระบุครบในการออกแบบ | เขียน Test Case ครบทุกเส้นทางของขั้นตอนหลายสถานะก่อนพัฒนา และทดสอบซ้ำทุกครั้งที่แก้ไข |
|
||||
| 3 | ความสอดคล้องระหว่างข้อกำหนดกับการพัฒนา | ISS-019, ISS-020, ISS-022 | 3 | ข้อกำหนดและเอกสารถูกปรับระหว่างพัฒนา ทำให้เกิดช่องว่างกับโค้ด | ปรับข้อกำหนดและ Traceability Record ในรอบเดียวกับการแก้โค้ด และตรวจความสอดคล้องในทุกรอบ Verification |
|
||||
| 4 | ความถูกต้องของข้อมูลสต๊อกและบัญชี | ISS-002, ISS-012 | 2 | การแปลงชนิดข้อมูลและการตรวจสอบความสัมพันธ์ของข้อมูลไม่ครอบคลุม | ตรวจสอบข้อมูลนำเข้าและความสัมพันธ์ฝั่งเซิร์ฟเวอร์ทุกคำสั่งที่เปลี่ยนสต๊อกหรือ GL และเพิ่มชุดทดสอบวงจรเอกสาร |
|
||||
| 5 | มาตรฐานโค้ดและการตั้งค่าสภาพแวดล้อม | ISS-005, ISS-010, ISS-014, ISS-021, ISS-023, ISS-025, ISS-027, ISS-028 | 8 | พัฒนาหลายโมดูลคู่ขนานโดยไม่มีมาตรฐานการตั้งชื่อ เส้นทางไฟล์ และค่าตั้งค่ากลาง | กำหนด Coding Standard และแม่แบบค่าตั้งค่าตั้งแต่ต้นโครงการ และทดสอบการติดตั้งบนสภาพแวดล้อมใหม่ทุกครั้งก่อนตั้ง Baseline |
|
||||
|
||||
## การเชื่อมโยงกับหลักฐานการทดสอบ
|
||||
|
||||
| เลขที่ | การแก้ไขอ้างอิง (Commit) | Test Case ที่ใช้ตรวจสอบ | ผลการทดสอบ |
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@
|
||||
| 2 | WP 2.0 | เอกสาร 200-WMS-26-001-00 Customer Requirements | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
| 3 | WP 3.0 | เอกสาร 200-WMS-26-001-00 Software Requirements Specification | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
| 4 | WP 4.0 | เอกสาร 200-WMS-26-001-00 Software Design | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
| 5 | WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 3 ฉบับ (CH-001–CH-003) | Accepted |
|
||||
| 5 | WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 1 ชุด (ทะเบียนการควบคุมการเปลี่ยนแปลง) | Accepted |
|
||||
| 6 | WP 6.0 | เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
| 7 | WP 7.0 | เอกสาร 200-WMS-26-001-00 Validation Results | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
| 8 | WP 8.0 | เอกสาร 200-WMS-26-001-00 Software User Document | ส่งเอกสารจำนวน 1 ชุด | Accepted |
|
||||
@@ -33,7 +33,7 @@
|
||||
| :---: | --- | --- | :---: |
|
||||
| 1 | ฟังก์ชันในขอบเขตทำงานตรงตาม Customer Requirements ครบทุกรายการ | Traceability Record, Test Report | ผ่าน |
|
||||
| 2 | ทดสอบระบบตาม Test Case ครบถ้วน | Test Report 45 Test Case ผ่านทั้งหมด (10 สิงหาคม 2569 – 14 สิงหาคม 2569) | ผ่าน |
|
||||
| 3 | ทดสอบการยอมรับโดยผู้ใช้ (UAT) | Validation Results 12 สถานการณ์ ผ่านทั้งหมด | ผ่าน |
|
||||
| 3 | ทดสอบการยอมรับโดยผู้ใช้ (UAT) | Validation Results ครบ 14 หมวดความต้องการ (80 รายการ) ผ่านทั้งหมด | ผ่าน |
|
||||
| 4 | ไม่มีข้อบกพร่องระดับวิกฤตคงค้าง | Correction Register 28 รายการ แก้ไขและตรวจสอบครบ | ผ่าน |
|
||||
| 5 | เอกสารคู่มือผู้ใช้ ผู้ดูแลระบบ และการบำรุงรักษาครบถ้วน | Software User Document, Product Operation Guide, Maintenance Document | ผ่าน |
|
||||
| 6 | Source Code และเอกสารจัดเก็บใน Repository พร้อมชุดสำรอง | Project Repository, Project Repository (Backup) | ผ่าน |
|
||||
|
||||
-89
@@ -1,89 +0,0 @@
|
||||
# Change Report
|
||||
|
||||
<!-- footer: CR -->
|
||||
|
||||
| Document No | Change Report | Release, Version, By: | 25690521 V1.0 NoC |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Change ID | CH-001 | วันที่ร้องขอ | 21 พฤษภาคม 2569 |
|
||||
| ผู้ร้องขอ (Requester) | คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| หน่วยงาน/ฝ่าย | ฝ่ายวิเคราะห์ระบบ / ตัวแทนผู้ใช้งานคลังสินค้า |
|
||||
| ประเภทการเปลี่ยนแปลง | ☒ Scope ☒ Quality ☐ Schedule ☐ Cost ☐ Resource ☐ Other |
|
||||
| ความเร่งด่วน (Priority) | ☐ High ☒ Medium ☐ Low |
|
||||
|
||||
## ส่วนที่ 1 : ข้อมูลทั่วไป
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ชื่อการเปลี่ยนแปลง | เปลี่ยนคำเรียกตำแหน่งจัดเก็บจาก Rack เป็น Bin |
|
||||
| โครงการ | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| ระยะที่เกิดการเปลี่ยนแปลง | ช่วงดำเนินโครงการ (21 พฤษภาคม 2569) |
|
||||
| เอกสารที่เกี่ยวข้อง | Customer Requirements, Software Project Plan, Traceability Record |
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description) | เปลี่ยนคำเรียกตำแหน่งจัดเก็บสินค้าจาก "Rack" เป็น "Bin" ทั้งระบบ ครอบคลุมป้ายกำกับหน้าจอ, custom.js, เครื่องมือบาร์โค้ด (BarcodeManager.php, location_barcode_label.php, retrieve_rack.php) และคลาสจัดการคลังสินค้า สต๊อก ใบสั่งขาย รายงาน ใบรับคืน ใบคืนผู้ขาย สินค้า และการตั้งค่าบริษัท |
|
||||
| 2 | เหตุผลของการเปลี่ยนแปลง (Justification) | ให้คำที่ใช้ในระบบตรงกับคำที่พนักงานคลังสินค้าใช้จริงในการปฏิบัติงาน ลดความสับสนระหว่างการใช้งานและการอบรม |
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ผลกระทบต่อ Scope | แก้ไข 14 ไฟล์ ประมาณ 1,000 บรรทัด ครอบคลุมคลาสจัดการ 8 คลาสและเครื่องมือบาร์โค้ด ไม่มีการเพิ่มฟังก์ชันใหม่ |
|
||||
| 2 | ผลกระทบต่อ Schedule | ดำเนินการภายในช่วงพัฒนาปัจจุบัน ไม่กระทบกำหนดส่งมอบ |
|
||||
| 3 | ผลกระทบต่อ Budget/Cost | ไม่มีค่าใช้จ่ายเพิ่ม ใช้ทรัพยากรทีมพัฒนาเดิม |
|
||||
| 4 | ผลกระทบต่อ Resource | ผู้พัฒนา 1 คน |
|
||||
| 5 | ผลกระทบต่อ Quality/Deliverables | เป็นการเปลี่ยนคำเรียกเท่านั้น ไม่เปลี่ยนพฤติกรรมของระบบ ข้อบกพร่องที่เกิดจากการเปลี่ยนไม่ครบให้บันทึกใน Correction Register (ISS-023) |
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | คุณอภิรัชช์ สุภัทรประทีป | Project Manager | เห็นควรอนุมัติ ผลกระทบอยู่ในวิสัยที่ควบคุมได้ |
|
||||
| 2 | คุณนพพงษ์ เจริญสุข | System Analyst | สอดคล้องกับความต้องการและการออกแบบ |
|
||||
| 3 | คุณปริญ งามขำ | QA / Tester | ต้องทดสอบซ้ำในส่วนที่ได้รับผลกระทบ |
|
||||
| 4 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | อนุมัติ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| สถานะ | ☒ อนุมัติ (Approved) ☐ ไม่อนุมัติ (Rejected) |
|
||||
| การอ้างอิงการดำเนินการ | Commit `8f57ab5` |
|
||||
| ผลการดำเนินการ | ดำเนินการแล้วเสร็จ และตรวจสอบผลด้วย TC-UN03.001 ผ่านเมื่อ 10–14 ส.ค. 69 |
|
||||
|
||||
## ภาคผนวก A : เกณฑ์การประเมินระดับความรุนแรงของการเปลี่ยนแปลง (Change Criteria)
|
||||
|
||||
ตารางนี้ใช้เป็นแนวทางประเมินระดับความรุนแรง (Priority Level) ของการเปลี่ยนแปลง เพื่อให้คณะพิจารณา (Change Advisory Board – CAB) กำหนดระดับผลกระทบและความเร่งด่วนได้ชัดเจนตามมาตรฐาน ISO/IEC 29110
|
||||
|
||||
| ระดับ (Level) | คำจำกัดความ (Definition) | ตัวอย่างสถานการณ์ (Examples) | ผลกระทบ (Impact Scope) |
|
||||
| --- | --- | --- | --- |
|
||||
| High | การเปลี่ยนแปลงที่มีผลกระทบอย่างมีนัยสำคัญต่อระบบหลัก งบประมาณ หรือแผนโครงการ ซึ่งต้องได้รับอนุมัติจาก Project Manager และ Project Sponsor | ปรับสถาปัตยกรรมหลักของระบบ / เพิ่มฟังก์ชันหลักใหม่ / ต้องปรับงบประมาณหรือระยะเวลาโครงการ | กระทบ Scope, Schedule และ Cost โดยตรง |
|
||||
| Medium | การเปลี่ยนแปลงที่มีผลกระทบต่อส่วนติดต่อผู้ใช้งานหรือฟังก์ชันย่อยบางส่วน แต่ไม่กระทบโครงสร้างหลัก | ปรับปรุงหน้าจอ / ปรับข้อความหรือตรรกะบางส่วน / เพิ่มการตรวจสอบข้อมูล | กระทบ Quality หรือ Deliverables บางส่วน |
|
||||
| Low | การเปลี่ยนแปลงขนาดเล็กที่ไม่ส่งผลต่อการทำงานหลักของระบบ | แก้ไขคำสะกดหรือข้อความแสดงผล / เปลี่ยนโลโก้หรือรูปภาพ / ปรับฟอนต์หรือสี | ผลกระทบเล็กน้อยต่อ Deliverables |
|
||||
|
||||
**แนวทางการใช้งาน**
|
||||
|
||||
- ผู้ร้องขอ (Requester) ระบุระดับความรุนแรงตามตารางนี้ในส่วน "ความเร่งด่วน (Priority)"
|
||||
- คณะพิจารณา (CAB) ใช้ตารางนี้ประกอบการพิจารณาในส่วน "การประเมินผลกระทบ (Impact Analysis)"
|
||||
- หากมีข้อสงสัยในระดับผลกระทบ ให้ใช้ระดับที่สูงกว่าเพื่อความปลอดภัยของโครงการ
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-89
@@ -1,89 +0,0 @@
|
||||
# Change Report
|
||||
|
||||
<!-- footer: CR -->
|
||||
|
||||
| Document No | Change Report | Release, Version, By: | 25690808 V1.0 ApS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Change ID | CH-002 | วันที่ร้องขอ | 8 สิงหาคม 2569 |
|
||||
| ผู้ร้องขอ (Requester) | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| หน่วยงาน/ฝ่าย | ฝ่ายบริหารโครงการ / เตรียมการส่งมอบ |
|
||||
| ประเภทการเปลี่ยนแปลง | ☒ Scope ☒ Quality ☐ Schedule ☐ Cost ☐ Resource ☐ Other |
|
||||
| ความเร่งด่วน (Priority) | ☐ High ☒ Medium ☐ Low |
|
||||
|
||||
## ส่วนที่ 1 : ข้อมูลทั่วไป
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ชื่อการเปลี่ยนแปลง | เพิ่มชุดข้อมูลสาธิตสำหรับการตรวจรับและสาธิตระบบ |
|
||||
| โครงการ | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| ระยะที่เกิดการเปลี่ยนแปลง | ช่วงดำเนินโครงการ (8 สิงหาคม 2569) |
|
||||
| เอกสารที่เกี่ยวข้อง | Customer Requirements, Software Project Plan, Traceability Record |
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description) | เพิ่มสคริปต์สร้างข้อมูลสาธิต 3 ไฟล์ (demo_seed.php, demo_seed_more_orders.php, demo_seed_transactions.php) สำหรับใบสั่งขาย รูปแบบคำสั่งซื้อเพิ่มเติม และประวัติรายการเคลื่อนไหว พร้อมตั้งค่าไดเรกทอรี Log ของบริการ Node.js ที่ใช้ระหว่างสร้างข้อมูล |
|
||||
| 2 | เหตุผลของการเปลี่ยนแปลง (Justification) | ระบบที่ติดตั้งใหม่ไม่มีประวัติรายการ ทำให้ตรวจรับรายงานและขั้นตอนการทำงานไม่ได้ จึงต้องมีข้อมูลตัวอย่างที่ใกล้เคียงการใช้งานจริงสำหรับการตรวจรับและการสาธิต |
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ผลกระทบต่อ Scope | แก้ไข 9 ไฟล์ เพิ่มประมาณ 2,900 บรรทัด เป็นสคริปต์สร้างข้อมูลใหม่ ไม่แก้ตรรกะหลักของระบบ |
|
||||
| 2 | ผลกระทบต่อ Schedule | ดำเนินการภายในช่วงเตรียมส่งมอบตามแผน |
|
||||
| 3 | ผลกระทบต่อ Budget/Cost | ไม่มีค่าใช้จ่ายเพิ่ม |
|
||||
| 4 | ผลกระทบต่อ Resource | ผู้พัฒนา 1 คน |
|
||||
| 5 | ผลกระทบต่อ Quality/Deliverables | เป็นการเพิ่มข้อมูลสาธิตเท่านั้น ข้อมูลสาธิตต้องแยกจากข้อมูลใช้งานจริงตาม CR07:004 |
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | คุณอภิรัชช์ สุภัทรประทีป | Project Manager | เห็นควรอนุมัติ ผลกระทบอยู่ในวิสัยที่ควบคุมได้ |
|
||||
| 2 | คุณนพพงษ์ เจริญสุข | System Analyst | สอดคล้องกับความต้องการและการออกแบบ |
|
||||
| 3 | คุณปริญ งามขำ | QA / Tester | ต้องทดสอบซ้ำในส่วนที่ได้รับผลกระทบ |
|
||||
| 4 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | อนุมัติ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| สถานะ | ☒ อนุมัติ (Approved) ☐ ไม่อนุมัติ (Rejected) |
|
||||
| การอ้างอิงการดำเนินการ | Commit `dd48a8b` |
|
||||
| ผลการดำเนินการ | ดำเนินการแล้วเสร็จเมื่อ 14 ส.ค. 69 และใช้เป็นข้อมูลตั้งต้นของการทดสอบและ UAT |
|
||||
|
||||
## ภาคผนวก A : เกณฑ์การประเมินระดับความรุนแรงของการเปลี่ยนแปลง (Change Criteria)
|
||||
|
||||
ตารางนี้ใช้เป็นแนวทางประเมินระดับความรุนแรง (Priority Level) ของการเปลี่ยนแปลง เพื่อให้คณะพิจารณา (Change Advisory Board – CAB) กำหนดระดับผลกระทบและความเร่งด่วนได้ชัดเจนตามมาตรฐาน ISO/IEC 29110
|
||||
|
||||
| ระดับ (Level) | คำจำกัดความ (Definition) | ตัวอย่างสถานการณ์ (Examples) | ผลกระทบ (Impact Scope) |
|
||||
| --- | --- | --- | --- |
|
||||
| High | การเปลี่ยนแปลงที่มีผลกระทบอย่างมีนัยสำคัญต่อระบบหลัก งบประมาณ หรือแผนโครงการ ซึ่งต้องได้รับอนุมัติจาก Project Manager และ Project Sponsor | ปรับสถาปัตยกรรมหลักของระบบ / เพิ่มฟังก์ชันหลักใหม่ / ต้องปรับงบประมาณหรือระยะเวลาโครงการ | กระทบ Scope, Schedule และ Cost โดยตรง |
|
||||
| Medium | การเปลี่ยนแปลงที่มีผลกระทบต่อส่วนติดต่อผู้ใช้งานหรือฟังก์ชันย่อยบางส่วน แต่ไม่กระทบโครงสร้างหลัก | ปรับปรุงหน้าจอ / ปรับข้อความหรือตรรกะบางส่วน / เพิ่มการตรวจสอบข้อมูล | กระทบ Quality หรือ Deliverables บางส่วน |
|
||||
| Low | การเปลี่ยนแปลงขนาดเล็กที่ไม่ส่งผลต่อการทำงานหลักของระบบ | แก้ไขคำสะกดหรือข้อความแสดงผล / เปลี่ยนโลโก้หรือรูปภาพ / ปรับฟอนต์หรือสี | ผลกระทบเล็กน้อยต่อ Deliverables |
|
||||
|
||||
**แนวทางการใช้งาน**
|
||||
|
||||
- ผู้ร้องขอ (Requester) ระบุระดับความรุนแรงตามตารางนี้ในส่วน "ความเร่งด่วน (Priority)"
|
||||
- คณะพิจารณา (CAB) ใช้ตารางนี้ประกอบการพิจารณาในส่วน "การประเมินผลกระทบ (Impact Analysis)"
|
||||
- หากมีข้อสงสัยในระดับผลกระทบ ให้ใช้ระดับที่สูงกว่าเพื่อความปลอดภัยของโครงการ
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-89
@@ -1,89 +0,0 @@
|
||||
# Change Report
|
||||
|
||||
<!-- footer: CR -->
|
||||
|
||||
| Document No | Change Report | Release, Version, By: | 25690810 V1.0 SeV |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Change ID | CH-003 | วันที่ร้องขอ | 10 สิงหาคม 2569 |
|
||||
| ผู้ร้องขอ (Requester) | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor) |
|
||||
| หน่วยงาน/ฝ่าย | ผู้บริหาร / ฝ่ายพัฒนา |
|
||||
| ประเภทการเปลี่ยนแปลง | ☒ Scope ☒ Quality ☐ Schedule ☐ Cost ☐ Resource ☐ Other |
|
||||
| ความเร่งด่วน (Priority) | ☐ High ☒ Medium ☐ Low |
|
||||
|
||||
## ส่วนที่ 1 : ข้อมูลทั่วไป
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ชื่อการเปลี่ยนแปลง | ปรับอัตลักษณ์องค์กรและเพิ่มชุดติดตั้ง Docker Compose |
|
||||
| โครงการ | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| ระยะที่เกิดการเปลี่ยนแปลง | ช่วงดำเนินโครงการ (10 สิงหาคม 2569) |
|
||||
| เอกสารที่เกี่ยวข้อง | Customer Requirements, Software Project Plan, Traceability Record |
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description) | รวมการเปลี่ยนแปลงเพื่อเตรียมส่งมอบ 2 รายการ: (1) เปลี่ยนชุดอัตลักษณ์องค์กร ได้แก่ โลโก้ (logo.png, logo.svg), Favicon และภาพหัวเอกสาร พร้อมปรับไฟล์ UI ที่อ้างอิง และ (2) เพิ่มชุดติดตั้ง Docker Compose สำหรับใช้งานจริง ประกอบด้วย Compose file, Dockerfile, แม่แบบค่าตั้งค่า, Entrypoint, SQL เริ่มต้น, .env.example และสคริปต์สร้าง .env แบบโต้ตอบ |
|
||||
| 2 | เหตุผลของการเปลี่ยนแปลง (Justification) | ให้ชุดส่งมอบใช้อัตลักษณ์องค์กรของลูกค้าอย่างถูกต้อง และมีเส้นทางการติดตั้งที่ทำซ้ำได้ โดยไม่นำค่าความลับเข้า Source Control หรือฝังไว้ใน Image |
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| ลำดับ | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ผลกระทบต่อ Scope | ปรับแบรนด์ 23 ไฟล์ (ภาพและไฟล์ PHP/CSS 11 ไฟล์) และเพิ่มไฟล์ติดตั้ง 10 ไฟล์ |
|
||||
| 2 | ผลกระทบต่อ Schedule | ดำเนินการภายในช่วงเตรียมส่งมอบ 15–17 ส.ค. 69 |
|
||||
| 3 | ผลกระทบต่อ Budget/Cost | ไม่มีค่าใช้จ่ายเพิ่ม |
|
||||
| 4 | ผลกระทบต่อ Resource | ผู้พัฒนา 1 คน |
|
||||
| 5 | ผลกระทบต่อ Quality/Deliverables | ภาพหัวเอกสารถูกใช้ในเอกสารส่งมอบ ชุด Docker Compose สร้างค่าความลับจาก .env ขณะเริ่ม Container ตาม CR10:003 |
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | คุณอภิรัชช์ สุภัทรประทีป | Project Manager | เห็นควรอนุมัติ ผลกระทบอยู่ในวิสัยที่ควบคุมได้ |
|
||||
| 2 | คุณนพพงษ์ เจริญสุข | System Analyst | สอดคล้องกับความต้องการและการออกแบบ |
|
||||
| 3 | คุณปริญ งามขำ | QA / Tester | ต้องทดสอบซ้ำในส่วนที่ได้รับผลกระทบ |
|
||||
| 4 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | อนุมัติ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| สถานะ | ☒ อนุมัติ (Approved) ☐ ไม่อนุมัติ (Rejected) |
|
||||
| การอ้างอิงการดำเนินการ | Commit `63cea23, 136084f, 6c39700` |
|
||||
| ผลการดำเนินการ | ดำเนินการแล้วเสร็จเมื่อ 17 ส.ค. 69 และตรวจสอบผลด้วย TC-UN13.002 และ TC-UN13.003 |
|
||||
|
||||
## ภาคผนวก A : เกณฑ์การประเมินระดับความรุนแรงของการเปลี่ยนแปลง (Change Criteria)
|
||||
|
||||
ตารางนี้ใช้เป็นแนวทางประเมินระดับความรุนแรง (Priority Level) ของการเปลี่ยนแปลง เพื่อให้คณะพิจารณา (Change Advisory Board – CAB) กำหนดระดับผลกระทบและความเร่งด่วนได้ชัดเจนตามมาตรฐาน ISO/IEC 29110
|
||||
|
||||
| ระดับ (Level) | คำจำกัดความ (Definition) | ตัวอย่างสถานการณ์ (Examples) | ผลกระทบ (Impact Scope) |
|
||||
| --- | --- | --- | --- |
|
||||
| High | การเปลี่ยนแปลงที่มีผลกระทบอย่างมีนัยสำคัญต่อระบบหลัก งบประมาณ หรือแผนโครงการ ซึ่งต้องได้รับอนุมัติจาก Project Manager และ Project Sponsor | ปรับสถาปัตยกรรมหลักของระบบ / เพิ่มฟังก์ชันหลักใหม่ / ต้องปรับงบประมาณหรือระยะเวลาโครงการ | กระทบ Scope, Schedule และ Cost โดยตรง |
|
||||
| Medium | การเปลี่ยนแปลงที่มีผลกระทบต่อส่วนติดต่อผู้ใช้งานหรือฟังก์ชันย่อยบางส่วน แต่ไม่กระทบโครงสร้างหลัก | ปรับปรุงหน้าจอ / ปรับข้อความหรือตรรกะบางส่วน / เพิ่มการตรวจสอบข้อมูล | กระทบ Quality หรือ Deliverables บางส่วน |
|
||||
| Low | การเปลี่ยนแปลงขนาดเล็กที่ไม่ส่งผลต่อการทำงานหลักของระบบ | แก้ไขคำสะกดหรือข้อความแสดงผล / เปลี่ยนโลโก้หรือรูปภาพ / ปรับฟอนต์หรือสี | ผลกระทบเล็กน้อยต่อ Deliverables |
|
||||
|
||||
**แนวทางการใช้งาน**
|
||||
|
||||
- ผู้ร้องขอ (Requester) ระบุระดับความรุนแรงตามตารางนี้ในส่วน "ความเร่งด่วน (Priority)"
|
||||
- คณะพิจารณา (CAB) ใช้ตารางนี้ประกอบการพิจารณาในส่วน "การประเมินผลกระทบ (Impact Analysis)"
|
||||
- หากมีข้อสงสัยในระดับผลกระทบ ให้ใช้ระดับที่สูงกว่าเพื่อความปลอดภัยของโครงการ
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
# Change Report
|
||||
|
||||
<!-- footer: CR -->
|
||||
|
||||
| Document No | Change Report | Release, Version, By: | 25690817 V1.0 ApS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | ทะเบียนการควบคุมการเปลี่ยนแปลง (Change Control Register) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เอกสารนี้บันทึกการควบคุมการเปลี่ยนแปลงของโครงการ ตั้งแต่ตั้ง Baseline ความต้องการเมื่อ 18 กุมภาพันธ์ 2569 จนถึงการตรวจรับส่งมอบ โดยพิจารณาทุกรายการปรับปรุงที่มีการเสนอตามเกณฑ์ในส่วนที่ 1 รายการที่เข้าเกณฑ์ต้องจัดทำคำขอเปลี่ยนแปลง ประเมินผลกระทบ และขออนุมัติก่อนดำเนินการ ส่วนรายการที่ไม่เข้าเกณฑ์ดำเนินการเป็นมติที่ประชุมหรืองานในแผน
|
||||
|
||||
## ส่วนที่ 1 : เกณฑ์การพิจารณาคำขอเปลี่ยนแปลง (Change Criteria)
|
||||
|
||||
รายการใดจะถือเป็นคำขอเปลี่ยนแปลงเมื่อเข้าเกณฑ์ทั้ง 3 ข้อ หากตัดรายการนั้นออกแล้วยังส่งมอบงานได้ตามที่ตกลงไว้ จะไม่ถือเป็นคำขอเปลี่ยนแปลง
|
||||
|
||||
| ลำดับ | เกณฑ์ | คำอธิบาย |
|
||||
| :---: | --- | --- |
|
||||
| 1 | เป็นสิ่งจำเป็นต่อการส่งมอบ | หากไม่ดำเนินการ จะส่งมอบสิ่งส่งมอบ (Work Product) หรือความต้องการที่ตกลงไว้ไม่ได้ |
|
||||
| 2 | เปลี่ยนแปลงขอบเขตหรือสิ่งส่งมอบ | เพิ่ม ลด หรือแก้ไขความต้องการ (CR) หรือสิ่งส่งมอบที่ตั้ง Baseline แล้ว เช่น เพิ่มโมดูล หรือรองรับ 2 ภาษา |
|
||||
| 3 | กระทบทรัพยากรของโครงการ | กระทบ Man-day กำหนดส่งมอบ หรือค่าใช้จ่าย จึงต้องประเมินผลกระทบและขออนุมัติก่อนดำเนินการ |
|
||||
|
||||
## ส่วนที่ 2 : ทะเบียนคำขอเปลี่ยนแปลง (Change Request Log)
|
||||
|
||||
| Change ID | หัวข้อ | ผู้ร้องขอ | ผลกระทบ | สถานะ |
|
||||
| :---: | --- | :---: | --- | :---: |
|
||||
| - | ไม่มีคำขอเปลี่ยนแปลงที่เข้าเกณฑ์ตลอดโครงการ | - | - | - |
|
||||
|
||||
## ส่วนที่ 3 : รายการปรับปรุงที่พิจารณาแล้วไม่เข้าเกณฑ์
|
||||
|
||||
| ลำดับ | วันที่พิจารณา | รายการ | ผู้เสนอ | ผลการพิจารณา | การดำเนินการ | อ้างอิง |
|
||||
| :---: | :---: | --- | :---: | --- | --- | --- |
|
||||
| 1 | 23 พ.ค. 69 | ปรับคำเรียกตำแหน่งจัดเก็บจาก Rack เป็น Bin ทั้งระบบ | NoC | ไม่เข้าเกณฑ์ — เป็นการปรับคำเรียกบนหน้าจอให้ตรงกับการปฏิบัติงานจริง ไม่เพิ่มหรือลดฟังก์ชัน ไม่กระทบ Man-day และส่งมอบได้แม้ไม่ปรับ | มติที่ประชุม ดำเนินการภายใน Task 3.9 | Meeting Record 23 พ.ค. 69, Correction Register ISS-023 |
|
||||
| 2 | 3 ส.ค. 69 | เตรียมข้อมูลสาธิตสำหรับการตรวจรับและการสาธิตระบบ | ApS | ไม่เข้าเกณฑ์ — เป็นข้อมูลตั้งต้นสำหรับตรวจรับ ไม่ใช่สิ่งส่งมอบ และต้องแยกจากข้อมูลใช้งานจริงตาม CR07:004 | งานเตรียมการส่งมอบ Task 4.7 | Meeting Record 3 ส.ค. 69, 14 ส.ค. 69 |
|
||||
| 3 | 14 ส.ค. 69 | ปรับอัตลักษณ์องค์กรและจัดทำชุดติดตั้ง Docker Compose | SeV | ไม่เข้าเกณฑ์ — ชุดติดตั้ง Docker Compose อยู่ในความต้องการ CR10:002 ตั้งแต่ Baseline และการปรับอัตลักษณ์องค์กรไม่เปลี่ยนแปลงฟังก์ชันหรือสิ่งส่งมอบ | งานเตรียมการส่งมอบ Task 4.7 | Meeting Record 14 ส.ค. 69, 17 ส.ค. 69 |
|
||||
|
||||
## ส่วนที่ 4 : สรุปผลการควบคุมการเปลี่ยนแปลง
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| รายการปรับปรุงที่เสนอและพิจารณา | 3 |
|
||||
| คำขอเปลี่ยนแปลงที่เข้าเกณฑ์ | 0 |
|
||||
| คำขอเปลี่ยนแปลงที่อนุมัติ | 0 |
|
||||
| ผลกระทบต่อ Man-day กำหนดส่งมอบ และค่าใช้จ่าย | ไม่มี |
|
||||
|
||||
ขอบเขตงาน สิ่งส่งมอบ และ Customer Requirements ที่ตั้ง Baseline ไม่มีการเปลี่ยนแปลงตลอดโครงการ รายการปรับปรุงที่พิจารณาทั้งหมดดำเนินการภายในแผนงานเดิมโดยไม่กระทบ Man-day และกำหนดส่งมอบ
|
||||
|
||||
## ภาคผนวก A : เกณฑ์การประเมินระดับความรุนแรงของการเปลี่ยนแปลง
|
||||
|
||||
ใช้ประเมินระดับความรุนแรง (Priority Level) เมื่อมีคำขอเปลี่ยนแปลงที่เข้าเกณฑ์ในส่วนที่ 1
|
||||
|
||||
| ระดับ (Level) | คำจำกัดความ (Definition) | ตัวอย่างสถานการณ์ (Examples) |
|
||||
| --- | --- | --- |
|
||||
| High | กระทบระบบหลัก งบประมาณ หรือแผนงานอย่างมีนัยสำคัญ | เพิ่มโมดูลใหม่ เปลี่ยนโครงสร้างฐานข้อมูลหลัก |
|
||||
| Medium | กระทบฟังก์ชันย่อยหรือส่วนติดต่อผู้ใช้งานบางส่วน และกระทบ Man-day | รองรับ 2 ภาษา เพิ่มรายงานใหม่ |
|
||||
| Low | กระทบเล็กน้อยต่อ Man-day ไม่เปลี่ยนการทำงานหลัก | เพิ่มฟิลด์ในเอกสาร |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
+4
-4
@@ -9,7 +9,7 @@
|
||||
| Task ID / Task Name | 3.7 Accounting & Finance Workflows |
|
||||
| Work Period of Task | 13 พฤษภาคม 2569 – 23 พฤษภาคม 2569 |
|
||||
| Meeting Date | 23 พฤษภาคม 2569 | Time | 09:00 – 11:00 น. |
|
||||
| สิ่งแนบ | Progress Status Record 23 พ.ค. 69, Change Report CH-001 |
|
||||
| สิ่งแนบ | Progress Status Record 23 พ.ค. 69 |
|
||||
| Location | ห้องประชุม บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
@@ -38,7 +38,7 @@
|
||||
| ลำดับ | หัวข้อการประชุม | วัตถุประสงค์ |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ผลการพัฒนาบัญชีและการเงิน | ตรวจสอบความครบถ้วนตาม CR01:015–CR01:017 |
|
||||
| 2 | พิจารณาคำขอเปลี่ยนแปลง CH-001 (Rack เป็น Bin) | ประเมินผลกระทบและอนุมัติ |
|
||||
| 2 | คำเรียกตำแหน่งจัดเก็บ (Rack / Bin) | กำหนดคำเรียกที่ใช้ในหน้าจอให้ตรงกับการปฏิบัติงานจริง |
|
||||
| 3 | แผนงานก่อนตั้ง Baseline การพัฒนา | ยืนยันงานที่ต้องเสร็จภายใน 29 พ.ค. 69 |
|
||||
|
||||
## สรุปรายงานการประชุม (Discussion Summary)
|
||||
@@ -46,14 +46,14 @@
|
||||
| ลำดับ | ประเด็น | รายละเอียด / มติที่ได้ | ผู้รับผิดชอบ | สถานะ |
|
||||
| :---: | --- | --- | :---: | :---: |
|
||||
| 1 | บัญชีและการเงิน | พัฒนาผังบัญชี GL สมุดรายวัน รายงานบัญชี ใบวางบิลและใบเสร็จครบตามความต้องการ | ThS, NoC | เสร็จสิ้น |
|
||||
| 2 | คำขอเปลี่ยนแปลง CH-001 | เปลี่ยนคำเรียกตำแหน่งจัดเก็บจาก Rack เป็น Bin ให้ตรงกับคำที่พนักงานคลังใช้จริง ประเมินผลกระทบระดับ Medium ไม่กระทบกำหนดส่งมอบ | SeV, ApS, NoC | อนุมัติ |
|
||||
| 2 | คำเรียกตำแหน่งจัดเก็บ | ที่ประชุมมีมติให้ใช้คำว่า Bin แทน Rack ทั้งระบบให้ตรงกับคำที่พนักงานคลังใช้จริง เป็นการปรับคำเรียกบนหน้าจอ ไม่เพิ่มหรือลดฟังก์ชันและไม่กระทบ Man-day จึงไม่ถือเป็นคำขอเปลี่ยนแปลง | SeV, ApS, NoC | มติที่ประชุม |
|
||||
| 3 | ความปลอดภัยและโควตารายการ | เพิ่มการควบคุมสิทธิ์แอปพลิเคชันและโควตารายการต่อบริษัท | ThS | ดำเนินการ |
|
||||
|
||||
## งานที่ต้องติดตาม (Action Item)
|
||||
|
||||
| ลำดับ | งาน | ผู้รับผิดชอบ | วันครบกำหนด | สถานะ |
|
||||
| :---: | --- | :---: | :---: | :---: |
|
||||
| 1 | ดำเนินการเปลี่ยนคำเรียกตามคำขอ CH-001 | ThS | 27 พฤษภาคม 2569 | Scheduled |
|
||||
| 1 | ปรับคำเรียก Rack เป็น Bin ตามมติที่ประชุม | ThS | 27 พฤษภาคม 2569 | Scheduled |
|
||||
| 2 | ทบทวนความปลอดภัยและวงจรเอกสารก่อนตั้ง Baseline (Task 3.9) | ThS, PaNg | 28 พฤษภาคม 2569 | Scheduled |
|
||||
| 3 | บันทึกการแก้ไข ISS-010 ถึง ISS-015 ใน Correction Register | YaB | 25 พฤษภาคม 2569 | Scheduled |
|
||||
|
||||
|
||||
+7
-7
@@ -9,7 +9,7 @@
|
||||
| Task ID / Task Name | 4.4 System Test & UAT |
|
||||
| Work Period of Task | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| Meeting Date | 14 สิงหาคม 2569 | Time | 09:00 – 11:00 น. |
|
||||
| สิ่งแนบ | Test Report, Validation Results, Change Report CH-002 |
|
||||
| สิ่งแนบ | Test Report, Validation Results |
|
||||
| Location | ห้องประชุม บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
@@ -30,7 +30,7 @@
|
||||
|
||||
| หมวดงาน | สถานะ | ความคืบหน้า (%) | รายละเอียด |
|
||||
| --- | :---: | ---: | --- |
|
||||
| Phase 4: Verification & Validation | เสร็จสมบูรณ์ | 100 | ทดสอบ 45 Test Case และ UAT 12 สถานการณ์ ผ่านทั้งหมด |
|
||||
| Phase 4: Verification & Validation | เสร็จสมบูรณ์ | 100 | ทดสอบ 45 Test Case และ UAT ครบ 14 หมวดความต้องการ (80 รายการ) ผ่านทั้งหมด |
|
||||
| Phase 5: Project Close | กำลังดำเนินการ | 60 | อยู่ระหว่างตรวจสอบ Work Products และเตรียมชุดส่งมอบ |
|
||||
| รวมความคืบหน้าทั้งโครงการ | ตามแผน | 92 | เตรียมตรวจรับและปิดโครงการ |
|
||||
|
||||
@@ -39,8 +39,8 @@
|
||||
| ลำดับ | หัวข้อการประชุม | วัตถุประสงค์ |
|
||||
| :---: | --- | --- |
|
||||
| 1 | สรุปผลการทดสอบระบบ 45 Test Case | ยืนยันผลการทดสอบและข้อบกพร่องคงค้าง |
|
||||
| 2 | สรุปผลการทดสอบการยอมรับ (UAT) 12 สถานการณ์ | ยืนยันความพร้อมใช้งานจริง |
|
||||
| 3 | พิจารณาคำขอเปลี่ยนแปลง CH-002 (ข้อมูลสาธิต) | ประเมินผลกระทบและอนุมัติ |
|
||||
| 2 | สรุปผลการทดสอบการยอมรับ (UAT) ตาม Customer Requirements CR01–CR14 | ยืนยันความพร้อมใช้งานจริง |
|
||||
| 3 | ข้อมูลสาธิตสำหรับการตรวจรับ (Task 4.7) | ยืนยันความพร้อมของข้อมูลตั้งต้น |
|
||||
| 4 | แผนงานปิดโครงการ | ยืนยันงานที่เหลือถึง 24 ส.ค. 69 |
|
||||
|
||||
## สรุปรายงานการประชุม (Discussion Summary)
|
||||
@@ -48,8 +48,8 @@
|
||||
| ลำดับ | ประเด็น | รายละเอียด / มติที่ได้ | ผู้รับผิดชอบ | สถานะ |
|
||||
| :---: | --- | --- | :---: | :---: |
|
||||
| 1 | ผลการทดสอบระบบ | ทดสอบ 45 Test Case บน Internal Testing Server ผ่านทั้งหมด ไม่พบข้อบกพร่องคงค้าง | PaNg | ผ่าน |
|
||||
| 2 | ผลการทดสอบการยอมรับ | ตัวแทนลูกค้าทดสอบ 12 สถานการณ์บนสภาพแวดล้อมใช้งานจริง ผ่านทั้งหมด | SeV | ผ่าน |
|
||||
| 3 | คำขอเปลี่ยนแปลง CH-002 | เพิ่มชุดข้อมูลสาธิตเพื่อใช้ตรวจรับรายงานและขั้นตอนการทำงาน ประเมินผลกระทบระดับ Medium | ApS, SeV | อนุมัติ |
|
||||
| 2 | ผลการทดสอบการยอมรับ | ตัวแทนลูกค้าทดสอบการยอมรับครบ 14 หมวดความต้องการ (80 รายการ) บนสภาพแวดล้อมใช้งานจริง ผ่านทั้งหมด | SeV | ผ่าน |
|
||||
| 3 | ข้อมูลสาธิต | จัดเตรียมข้อมูลสาธิตสำหรับการตรวจรับรายงานและขั้นตอนการทำงานเสร็จแล้ว เป็นงานเตรียมการส่งมอบตาม Task 4.7 ไม่เปลี่ยนแปลงขอบเขตหรือสิ่งส่งมอบ | ApS, SeV | เสร็จสิ้น |
|
||||
| 4 | งานที่เหลือ | ตรวจสอบ Work Products รอบสุดท้าย เตรียมชุดติดตั้ง ตรวจรับ อบรม และปิดโครงการ | ApS, YaB | ดำเนินการ |
|
||||
|
||||
## งานที่ต้องติดตาม (Action Item)
|
||||
@@ -57,7 +57,7 @@
|
||||
| ลำดับ | งาน | ผู้รับผิดชอบ | วันครบกำหนด | สถานะ |
|
||||
| :---: | --- | :---: | :---: | :---: |
|
||||
| 1 | ตรวจสอบ Work Products รอบที่ 4 และจัดทำ List of Evidence | YaB, ApS | 17 สิงหาคม 2569 | Scheduled |
|
||||
| 2 | จัดทำชุดติดตั้ง Docker Compose และปรับแบรนด์ (CH-003) | ThS | 17 สิงหาคม 2569 | Scheduled |
|
||||
| 2 | จัดทำชุดติดตั้ง Docker Compose (CR10:002) และปรับแบรนด์ (Task 4.7) | ThS | 17 สิงหาคม 2569 | Scheduled |
|
||||
| 3 | นัดตรวจรับส่งมอบระบบกับ Project Sponsor | ApS | 17 สิงหาคม 2569 | Scheduled |
|
||||
|
||||
## งานประชุมครั้งถัดไป (Next Meeting)
|
||||
|
||||
+3
-3
@@ -9,7 +9,7 @@
|
||||
| Task ID / Task Name | 5.3 Acceptance & Project Closure |
|
||||
| Work Period of Task | 17 สิงหาคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Meeting Date | 17 สิงหาคม 2569 | Time | 09:00 – 11:00 น. |
|
||||
| สิ่งแนบ | Acceptance Report, List of Evidence, Verification Results, Change Report CH-003 |
|
||||
| สิ่งแนบ | Acceptance Report, List of Evidence, Verification Results |
|
||||
| Location | ห้องประชุม บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
@@ -41,7 +41,7 @@
|
||||
| :---: | --- | --- |
|
||||
| 1 | นำเสนอผลการดำเนินโครงการและสิ่งส่งมอบ | สรุปผลงานทั้งหมดเทียบกับแผนและผลลัพธ์จริง |
|
||||
| 2 | ตรวจสอบความครบถ้วนของเอกสารและหลักฐาน | ยืนยันเอกสารครบตามมาตรฐาน ISO/IEC 29110 |
|
||||
| 3 | พิจารณาคำขอเปลี่ยนแปลง CH-003 | ประเมินผลกระทบและอนุมัติ |
|
||||
| 3 | ชุดติดตั้งและอัตลักษณ์องค์กร (Task 4.7) | ยืนยันความพร้อมของชุดส่งมอบ |
|
||||
| 4 | พิจารณาตรวจรับส่งมอบระบบ | ลงมติผลการตรวจรับ |
|
||||
|
||||
## สรุปรายงานการประชุม (Discussion Summary)
|
||||
@@ -50,7 +50,7 @@
|
||||
| :---: | --- | --- | :---: | :---: |
|
||||
| 1 | ผลการดำเนินโครงการ | พัฒนาระบบครบตามขอบเขต 11 ระบบงาน ทดสอบและ UAT ผ่านทั้งหมด ไม่มีข้อบกพร่องระดับวิกฤตคงค้าง | ApS, SeV | ผ่านการรับรอง |
|
||||
| 2 | ความครบถ้วนของเอกสาร | ตรวจสอบ Work Products รอบที่ 4 ครบทุกรายการ ผลผ่านทั้งหมด และจัดทำ List of Evidence เรียบร้อย | YaB, PaNg | สมบูรณ์ |
|
||||
| 3 | คำขอเปลี่ยนแปลง CH-003 | ปรับอัตลักษณ์องค์กรและเพิ่มชุดติดตั้ง Docker Compose ประเมินผลกระทบระดับ Medium | SeV, ApS | อนุมัติ |
|
||||
| 3 | ชุดติดตั้งและอัตลักษณ์องค์กร | จัดทำชุดติดตั้ง Docker Compose ตามความต้องการ CR10:002 และปรับอัตลักษณ์องค์กรในหน้าจอและเอกสารเสร็จแล้ว เป็นงานเตรียมการส่งมอบตาม Task 4.7 ไม่เปลี่ยนแปลงขอบเขตหรือสิ่งส่งมอบ | SeV, ApS | เสร็จสิ้น |
|
||||
| 4 | ผลการตรวจรับ | Project Sponsor ตรวจรับสิ่งส่งมอบทั้งหมด ผลการตรวจรับ Accepted | SeV | ตรวจรับแล้ว |
|
||||
|
||||
## งานที่ต้องติดตาม (Action Item)
|
||||
|
||||
+2
-2
@@ -20,7 +20,7 @@
|
||||
| **เอกสารส่งมอบครั้งที่ 2 (พัฒนาและทดสอบ)** | | |
|
||||
| WP 3.0 | เอกสาร 200-WMS-26-001-00 Software Requirements Specification | 1.0 |
|
||||
| WP 4.0 | เอกสาร 200-WMS-26-001-00 Software Design | 1.0 |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report (CH-001–CH-003) | 1.0 |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | 1.0 |
|
||||
| WP 6.0 | เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures | 1.0 |
|
||||
| WP 7.0 | เอกสาร 200-WMS-26-001-00 Validation Results | 1.0 |
|
||||
| WP 8.0 | เอกสาร 200-WMS-26-001-00 Software User Document | 1.0 |
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
## การเชื่อมโยงกับการเปลี่ยนแปลง
|
||||
|
||||
การเปลี่ยนแปลง Configuration Item ต้องผ่าน Change Report (CH-001–CH-003) และการแก้ไขข้อบกพร่องต้องบันทึกใน Correction Register (ISS-001–ISS-028) โดยทุกรายการเชื่อมโยงกับ Commit ที่ตรวจสอบได้ใน Repository
|
||||
การเปลี่ยนแปลง Configuration Item ต้องพิจารณาตามเกณฑ์ใน Change Report และการแก้ไขข้อบกพร่องต้องบันทึกใน Correction Register (ISS-001–ISS-028) โดยทุกรายการเชื่อมโยงกับ Commit ที่ตรวจสอบได้ใน Repository
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user