# Software Project Plan

<!-- footer: PP -->

| Document No | Software Project Plan | Release, Version, By: | 25690213 V1.0 ApS |
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
| Project Code | 200-WMS-26-001-00 |
| Title | แผนการดำเนินโครงการ |
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 | Project Duration | 232 วัน |
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |

## 1 Manufacture

บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด เป็นบริษัทผู้ประกอบธุรกิจด้านเทคโนโลยีสารสนเทศ ซึ่งมีประสบการณ์ในการส่งมอบผลิตภัณฑ์และบริการด้านเทคโนโลยีให้แก่หน่วยงานภาครัฐและเอกชนอย่างต่อเนื่อง บริษัทประกอบธุรกิจหลัก 3 ด้าน ได้แก่

- พัฒนาซอฟต์แวร์ตามความต้องการของหน่วยงาน (Software Development)
- จำหน่ายผลิตภัณฑ์ซอฟต์แวร์สำเร็จรูป (Software Package) เช่น ระบบบริหารจัดการสินทรัพย์
- ให้บริการบำรุงรักษาระบบ (Service Maintenance: MA) ครอบคลุมโครงสร้างพื้นฐาน เครื่องแม่ข่าย และศูนย์ข้อมูล

## 2 Overview

เพื่อยกระดับการบริหารจัดการคลังสินค้าของบริษัทให้มีความถูกต้อง รวดเร็ว และตรวจสอบย้อนกลับได้ บริษัทมีความประสงค์จะพัฒนา ระบบบริหารจัดการคลังสินค้า (BRN WMS) ขึ้นใหม่ โดยมีวัตถุประสงค์เพื่อ

- รวมศูนย์ข้อมูลคลังสินค้า สินค้าคงคลัง และความเคลื่อนไหวของสินค้าไว้ในระบบเดียว
- เชื่อมโยงงานขาย งานจัดซื้อ งานการเงิน และการบันทึกบัญชีเข้ากับความเคลื่อนไหวของสินค้า
- ควบคุมสิทธิ์การเข้าถึงและแยกข้อมูลระหว่างบริษัทและคลังสินค้าอย่างชัดเจน
- ให้ผู้บริหารเห็นภาพรวมสถานะคลังสินค้าและสถานะทางการเงินได้ตามเวลาจริง

## 3 Goals and Scope

### 3.1 เป้าหมายของโครงการ

**เป้าหมายด้านองค์กร**

- ลดข้อผิดพลาดของยอดสินค้าคงคลังที่เกิดจากการบันทึกด้วยมือ
- เพิ่มความสามารถในการตรวจสอบย้อนกลับของสินค้าตาม Lot, Serial Number และวันหมดอายุ
- ทำให้ข้อมูลคลังสินค้าและข้อมูลบัญชีสอดคล้องกันโดยไม่ต้องบันทึกซ้ำ

**เป้าหมายด้านผู้ใช้งาน**

- ให้พนักงานคลังสินค้าบันทึกรายการรับเข้า จ่ายออก และโอนย้ายได้สะดวกจากอุปกรณ์หน้าคลัง
- ให้ฝ่ายขายและฝ่ายจัดซื้อจัดทำเอกสารและติดตามสถานะได้ในระบบเดียว
- ให้ฝ่ายบัญชีได้ข้อมูลรายการที่ผ่านการตรวจสอบแล้วโดยอัตโนมัติ

### 3.2 ขอบเขตของโครงการ (SOW)

| ลำดับ | ระบบ | ระบบย่อย |
| :---: | --- | --- |
| 1 | ระบบบริหารจัดการผู้ใช้งานและสิทธิ์ | ลงทะเบียนเจ้าของบริษัทและเชิญผู้ใช้งาน (Onboarding) / เข้าสู่ระบบและควบคุมสิทธิ์ตามบทบาท Owner / Admin / Staff / Viewer / กู้คืนรหัสผ่าน, OTP และควบคุม Session / ตั้งค่าบริษัท, SMTP, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน |
| 2 | ระบบข้อมูลหลัก (Master Data) | คลังสินค้า, พื้นที่จัดเก็บ, ช่องจัดเก็บ (Bin) / หมวดสินค้าและสินค้า / ประเภทผู้ติดต่อและผู้ติดต่อ (ลูกค้า/ผู้ขาย) / รองรับโครงสร้างคลังแบบชั้นเดียวและแบบหลายชั้น |
| 3 | ระบบควบคุมสินค้าคงคลัง (Inventory Control) | รับสินค้าเข้า (Stock-in) / จ่ายสินค้าออก (Stock-out) พร้อมตรวจสอบยอดคงเหลือ / โอนย้ายสินค้าระหว่างคลัง/ตำแหน่ง / ติดตาม Lot, Serial Number และวันหมดอายุ / พิมพ์บาร์โค้ดสินค้า/ตำแหน่ง และรองรับการสแกน / แนบไฟล์ประกอบรายการ |
| 4 | ระบบขาย (Sales) | ใบเสนอราคา (Quotation) / ใบสั่งขาย (Sales Order) / ใบแจ้งหนี้ (Invoice) / ใบรับคืน / ใบลดหนี้ (Return / Credit Note) |
| 5 | ระบบจัดซื้อ (Purchasing) | ใบขอซื้อ (Purchase Request) / ใบสั่งซื้อ (Purchase Order) / ใบแจ้งหนี้ซื้อ (Purchase Invoice) / ใบคืนสินค้าผู้ขาย (Supplier Return) |
| 6 | ระบบการเงิน (Finance) | ใบวางบิลรับ / ใบเสร็จรับเงิน / ใบวางบิลจ่าย / ใบสำคัญจ่าย |
| 7 | ระบบบัญชี (Accounting) | ผังบัญชี, แผนก, สูตรบัญชี / สมุดรายวันและบัญชีแยกประเภท (Journal / GL) / รายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม |
| 8 | ระบบรายงานและแดชบอร์ด | แดชบอร์ดคลังสินค้าและบัญชี / รายงานสต๊อก, ความเคลื่อนไหว, ความจุคลัง, สินค้าใกล้หมด, สินค้าหมดอายุ, Lot / กรอง ดู พิมพ์ และส่งออกรายงาน |
| 9 | ระบบควบคุมเอกสาร | ออกเลขที่เอกสารอัตโนมัติตามลำดับที่กำหนด / ควบคุมสถานะและวงจรชีวิตของเอกสาร / บันทึกผู้สร้าง/ผู้แก้ไข/ประวัติรายการ |
| 10 | ระบบแจ้งเตือนและงานตามกำหนดเวลา | แจ้งเตือนแบบ Real-time ผ่าน Node.js / Socket.IO / งานสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมด, ใบแจ้งหนี้ค้างชำระ ตามกำหนดเวลา |
| 11 | ระบบติดตั้งและตั้งค่า | ติดตั้งแบบ Manual ผ่าน setup.php / ติดตั้งแบบ Container ผ่าน Docker Compose (php-apache, mariadb, node/pm2) / สร้างค่าตั้งค่าและความลับของระบบจาก .env โดยไม่เก็บใน Source Control |

### 3.3 สิ่งส่งมอบ (Work Products)

| รหัส | สิ่งส่งมอบ (Work Product) | รายละเอียด |
| --- | --- | --- |
| WP 1.0 | เอกสาร 200-WMS-26-001-00 Software Project Plan (พร้อม Work Schedule) | ส่งเอกสารจำนวน 1 ชุด |
| 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 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 ชุด |
| WP 9.0 | ระบบ BRN WMS ที่ผ่านการทดสอบพร้อมนำไปใช้งานจริง | ส่ง Source Code (Git baseline 6c39700) และติดตั้ง |
| WP 10.0 | เอกสาร 200-WMS-26-001-00 Product Operation Guide | ส่งเอกสารจำนวน 1 ชุด |
| WP 11.0 | เอกสาร 200-WMS-26-001-00 Maintenance Document | ส่งเอกสารจำนวน 1 ชุด |

### 3.4 Delivery Instruction

ในการส่งมอบตามสิ่งส่งมอบ (Work Product) เมื่อแล้วเสร็จและถึงกำหนดเวลา (Due Date) ผู้จัดการโครงการต้องจัดเตรียมเครื่องมือและสถานที่เพื่อให้ลูกค้าทำการทดสอบการยอมรับผู้ใช้ (Validation Result หรือ User Acceptance Test – UAT) โดยทดสอบตามข้อกำหนดในเอกสารความต้องการผู้ใช้ (Customer Requirements) ทีละข้อ และลงนามยืนยันเมื่อผ่านการทดสอบ

- **กรณีสิ่งส่งมอบไม่แล้วเสร็จตามกำหนด (Delay)** ผู้จัดการโครงการต้องนัดประชุมรายงานความคืบหน้าและอธิบายสาเหตุให้ลูกค้าทราบ พร้อมทั้งตกลงกำหนดวันส่งมอบใหม่อย่างเป็นทางการร่วมกัน
- **การปิดโครงการ (Project Closure)** เมื่อสิ่งส่งมอบทั้งหมดผ่านการตรวจรับและได้รับลายเซ็นอนุมัติจากลูกค้าครบทุกชุดแล้ว ผู้จัดการโครงการจัดประชุมปิดโครงการอย่างเป็นทางการ พร้อมจัดทำเอกสารสรุปผลการดำเนินงานเพื่อเก็บเป็นหลักฐาน

### 3.5 เกณฑ์คุณภาพ (Quality Criteria)

**ด้านคุณภาพของระบบ**

| ลำดับ | หัวข้อ | เกณฑ์คุณภาพ | วิธีประเมิน |
| :---: | --- | --- | --- |
| 1.1 | ความถูกต้องของฟังก์ชัน | ฟังก์ชันทั้งหมดทำงานตรงตาม Customer Requirements ครบ 100% | ทดสอบตาม Test Case และ UAT |
| 1.2 | ความถูกต้องของข้อมูลสต๊อกและบัญชี | ไม่พบยอดสต๊อกติดลบหรือรายการ GL ที่ไม่สมดุล | ทดสอบ Transaction และ Rollback (TC-UN08.002) |
| 1.3 | ความปลอดภัยของระบบ | ไม่พบข้อบกพร่องระดับวิกฤตด้านสิทธิ์และการแยกข้อมูล | ทดสอบสิทธิ์เชิงลบ (TC-UN12.001, TC-UN12.002) |
| 1.4 | ประสิทธิภาพการตอบสนอง | งานประจำวันตอบสนองภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | ทดสอบตามปริมาณข้อมูลตัวอย่าง (TC-UN09.001) |
| 1.5 | ความสามารถในการเข้าถึง | ใช้งานได้บน Desktop, Tablet และ Mobile (Responsive) | ทดสอบข้ามอุปกรณ์ |

**ด้านการดูแลหลังส่งมอบ**

| ลำดับ | หัวข้อ | เกณฑ์คุณภาพ | วิธีประเมิน |
| :---: | --- | --- | --- |
| 2.1 | การตอบสนองเหตุขัดข้อง | ตอบรับภายใน 4 ชั่วโมง และแก้ไขตามระดับความรุนแรงที่กำหนดใน SLA | บันทึกการให้บริการ |
| 2.2 | การสำรองข้อมูล | มีระบบสำรองข้อมูลอัตโนมัติรายวันและทดสอบกู้คืนได้จริง | Backup & Restore Test (TC-UN13.004) |
| 2.3 | การเฝ้าระวังระบบ | ตรวจสอบสถานะบริการทุก 5 นาที และแจ้งเตือนเมื่อล้มเหลว 2 ครั้งติดกัน | บันทึกการเฝ้าระวัง |

## 4 Software Development Life Cycle Methodology

โครงการเลือกใช้แนวทาง Incremental / Evolutionary ภายใต้ขั้นตอนหลักของ Waterfall เนื่องจาก

- ขอบเขตและสิ่งส่งมอบกำหนดชัดเจนตั้งแต่ต้นโครงการ จึงวางแผนและตรวจรับเป็นงวดได้
- ระบบมีหลายโมดูลที่ส่งมอบต่อเนื่องกัน จึงพัฒนาและทดสอบทีละส่วนเพื่อลดความเสี่ยง
- เอกสารครบถ้วนตามมาตรฐาน ISO/IEC 29110 ที่เน้น Work Products และ Traceability
- ตรวจสอบย้อนกลับ (Audit) และตรวจรับงานได้อย่างเป็นทางการ

| ขั้นตอน | แนวทางที่ใช้จริงในโครงการ |
| --- | --- |
| Requirements | เก็บความต้องการและตั้ง Baseline ก่อนเริ่มพัฒนา การเปลี่ยนแปลงภายหลังผ่าน Change Report (CH-001–CH-003) |
| Design | ออกแบบสถาปัตยกรรม โครงสร้างฐานข้อมูล และ Software Unit ก่อนพัฒนาแต่ละโมดูล |
| Implementation | พัฒนาเป็นโมดูลต่อเนื่องระหว่าง 19 ก.พ. – 29 พ.ค. 69 พร้อมทบทวนและแก้ไขระหว่างทาง |
| Verification | ตรวจสอบ Work Products 4 รอบ ควบคู่กับการพัฒนา และรอบสุดท้ายก่อนส่งมอบ |
| Validation | ทดสอบระบบและ UAT ระหว่าง 10–14 ส.ค. 69 บนสภาพแวดล้อมที่กำหนด |
| Closure | ตรวจรับ อบรม ปิดงานควบคุมปฏิบัติการ และปิดโครงการภายใน 24 ส.ค. 69 |

## 5 Organization

### 5.1 Role & Responsibility

| ลำดับ | บทบาท | ชื่อ-นามสกุล (ชื่อย่อ) | อีเมล | รายละเอียดหน้าที่ |
| :---: | --- | --- | --- | --- |
| 1 | Project Manager (ApS) | คุณอภิรัชช์ สุภัทรประทีป | apirach.s@brn.co.th | จัดทำ Project Charter และแผนโครงการ / วางแผน Timeline, Resource, Risk, Quality / จัดประชุมและติดตามความคืบหน้า / ควบคุมการเปลี่ยนแปลงและการปิดโครงการ |
| 2 | System Analyst (NoC) | คุณนพพงษ์ เจริญสุข | noppong.c@brn.co.th | เก็บและวิเคราะห์ความต้องการ / จัดทำ SRS และเอกสารออกแบบระบบ / ออกแบบฐานข้อมูลและความสัมพันธ์ของโมดูล / ตรวจสอบความสอดคล้องของงานพัฒนากับความต้องการ |
| 3 | Developer (ThS) | คุณธนกร สถิตวิทยากุล | thanakorn.s@brn.co.th | พัฒนาโมดูลและ API ตามการออกแบบ / จัดการฐานข้อมูลและประสิทธิภาพ / ดูแลความปลอดภัยและการติดตั้ง / แก้ไขข้อบกพร่องที่พบจากการทดสอบ |
| 4 | QA / Tester (PaNg) | คุณปริญ งามขำ | parin.n@brn.co.th | จัดทำ Test Case และ Test Procedures / ทดสอบระบบและบันทึกผล / ติดตามการแก้ไขข้อบกพร่องและทดสอบซ้ำ / สนับสนุนผู้ใช้งานช่วง UAT |
| 5 | Document Control (YaB) | คุณเยาวลักษณ์ บางชมภู | yaowalak.b@brn.co.th | ควบคุมรหัสเอกสารและเวอร์ชัน / จัดเก็บและตรวจสอบความครบถ้วนของเอกสาร / ประสานการทบทวนและอนุมัติ / บันทึกประวัติการเปลี่ยนแปลงเอกสาร |
| 6 | Project Sponsor (SeV) | คุณเสรี วิริยะสกุลธรณ์ | seri.v@brn.co.th | อนุมัติขอบเขต งบประมาณ และการเปลี่ยนแปลง / ตัดสินใจเชิงกลยุทธ์ / ทดสอบการยอมรับและตรวจรับส่งมอบ / อนุมัติปิดโครงการ |

## 6 Project Estimate

### 6.1 Size of the Software Work Products

| ลำดับ | Work Product | ปริมาณ (ประมาณการ) |
| :---: | --- | --- |
| 1 | เอกสารบริหารโครงการ (PM Process) | 10 รายการ |
| 2 | เอกสารกระบวนการพัฒนา (SI Process) | 12 รายการ |
| 3 | ความต้องการลูกค้า (Customer Requirements) | 80 รายการ (CR01–CR14) |
| 4 | ความต้องการซอฟต์แวร์ (SRS) | 49 รายการ (SR01–SR09) |
| 5 | Software Unit | 45 หน่วย (UN01–UN13) |
| 6 | Test Case | 45 รายการ |
| 7 | ตารางฐานข้อมูล | ประมาณ 50 ตาราง ใน 2 ฐานข้อมูล |

### 6.2 Effort Man-Day

| ลำดับ | ตำแหน่ง | หน้าที่หลัก | ระยะเวลา (Man-Day) |
| :---: | --- | --- | ---: |
| 1 | Project Manager | ควบคุมงาน ประสานงาน ติดตามแผน | 120 |
| 2 | System Analyst | วิเคราะห์ความต้องการ ออกแบบระบบ | 60 |
| 3 | Developer | พัฒนาระบบและแก้ไขข้อบกพร่อง | 100 |
| 4 | QA / Tester | วางแผนทดสอบ ทดสอบระบบ UAT | 40 |
| 5 | Document Control | ควบคุมเอกสารและหลักฐานโครงการ | 60 |

## 7 Project Resources

**Human Resource**

| ลำดับ | Team | จำนวน (คน) |
| :---: | --- | ---: |
| 1 | Project Management (PM, Document Control) | 2 |
| 2 | Software Implementation (SA, Developer, QA) | 3 |
| 3 | Project Sponsor / ตัวแทนลูกค้า | 1 |

**Computer Resource**

| ลำดับ | รายการ | จำนวน |
| :---: | --- | --- |
| 1 | Notebook สำหรับทีมพัฒนาและทดสอบ | 5 เครื่อง |
| 2 | Git Server (Repository หลัก) | 1 ระบบ |
| 3 | Internal Testing Server (PHP 8, MariaDB, Node.js) | 1 เครื่อง |
| 4 | Production Server สำหรับใช้งานจริง | 1 เครื่อง |
| 5 | เครื่องอ่านบาร์โค้ดสำหรับทดสอบ | 1 เครื่อง |

## 8 Work Schedule

แผนการดำเนินงานของโครงการ รวม 232 วัน ตั้งแต่ 5 มกราคม 2569 ถึง 24 สิงหาคม 2569 รายละเอียดกิจกรรม ผู้รับผิดชอบ และสิ่งส่งมอบรายกิจกรรม อยู่ในเอกสาร 200-WMS-26-001-00 Work Schedule ซึ่งเป็นส่วนหนึ่งของ Project Plan

| Phase | ช่วงเวลา | ผลลัพธ์หลัก |
| --- | --- | --- |
| Project Initiation | 5 มกราคม 2569 – 23 มกราคม 2569 | Statement of Work, Stakeholder Register, Project Charter |
| Project Planning | 12 มกราคม 2569 – 18 กุมภาพันธ์ 2569 | Customer Requirements, Software Project Plan, Work Schedule |
| Project Execution | 19 กุมภาพันธ์ 2569 – 29 พฤษภาคม 2569 | SRS, Software Design, ระบบที่พัฒนาแล้ว, Software Components |
| 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 |

## 9 Risk Management Plan

วัตถุประสงค์ของแผนบริหารความเสี่ยง คือระบุแนวทางจัดการความเสี่ยงของโครงการ เพื่อให้โครงการบรรลุเป้าหมายภายในเวลา งบประมาณ และคุณภาพที่กำหนด

| ลำดับ | หมวด | รายการ | รายละเอียด |
| :---: | --- | --- | --- |
| 1 | ขอบเขต | ครอบคลุมทุกกิจกรรมของโครงการ | ตั้งแต่ Initiation, Planning, Execution จนถึง Close |
| 2 | บทบาทผู้รับผิดชอบ | Project Manager (Owner), ทีมพัฒนา, Project Sponsor | PM ติดตามและควบคุมความเสี่ยง ทีมพัฒนารายงานความเสี่ยงให้ PM |
| 3 | รอบการทบทวน | ทบทวนทุกงวดรายงานความก้าวหน้า | บันทึกความเสี่ยงใหม่และการเปลี่ยนแปลงระดับความเสี่ยงใน Progress Status Record |

**ตารางระบุความเสี่ยงหลักของโครงการ**

| ลำดับ | ความเสี่ยง (Risk) | ประเภท | โอกาสเกิด | ผลกระทบ | ระดับความเสี่ยง | แนวทางป้องกัน (Mitigation) | แผนรับมือ (Contingency Plan) | ผู้รับผิดชอบ |
| :---: | --- | --- | :---: | :---: | :---: | --- | --- | :---: |
| R1 | ความต้องการเปลี่ยนแปลงระหว่างพัฒนา | กระบวนการ | High | High | High | ตั้ง Baseline ความต้องการและทบทวนทุกงวด | จัดทำ Change Report และจัดลำดับความสำคัญใหม่ | ApS / NoC |
| R2 | ทีมพัฒนาไม่เพียงพอหรือขาดทักษะเฉพาะทาง | บุคลากร | Middle | High | High | ถ่ายทอดความรู้ภายในทีมและจัดทำเอกสารประกอบ | ขออนุมัติจัดหาผู้เชี่ยวชาญเพิ่มเฉพาะงาน | ApS |
| R3 | ยอดสินค้าคงคลังไม่ถูกต้อง | เทคโนโลยี | Middle | High | High | ใช้ Transaction, ตรวจสอบข้อมูลนำเข้า และล็อกรายการ | ตรวจสอบและปรับปรุงยอดพร้อมบันทึก Correction Register | ThS / PaNg |
| R4 | ข้อมูลรั่วไหลข้ามบริษัทหรือสิทธิ์ไม่รัดกุม | ความปลอดภัย | Middle | High | High | บังคับ Role Guard และขอบเขตบริษัทฝั่งเซิร์ฟเวอร์ | ปิดช่องโหว่ทันทีและทดสอบสิทธิ์เชิงลบซ้ำ | ThS / PaNg |
| R5 | ค่าตั้งค่าหรือความลับรั่วไหล | ความปลอดภัย | Middle | High | High | ยกเว้นไฟล์ตั้งค่าจาก Git และสร้างความลับตอนติดตั้ง | เปลี่ยนค่าความลับและตรวจสอบประวัติการเข้าถึง | ThS |
| R6 | ข้อมูลสูญหายระหว่างพัฒนาหรือใช้งาน | เทคโนโลยี | Middle | High | High | สำรอง Git 2 Remote และสำรองฐานข้อมูลรายวัน | กู้คืนจากชุดสำรองตามขั้นตอนในคู่มือ | ThS |
| R7 | หลักฐานการทดสอบและตรวจรับไม่ครบถ้วน | กระบวนการ | Middle | High | High | รักษาการสอบกลับสองทิศทางและบันทึกผลทุกครั้ง | ทดสอบซ้ำและบันทึกหลักฐานก่อนตรวจรับ | PaNg / YaB |
| R8 | ผู้ใช้ไม่ยอมรับระบบ (UAT ไม่ผ่าน) | ผู้ใช้งาน | Middle | High | High | ให้ผู้ใช้ร่วมทบทวนความต้องการและสาธิตระบบระหว่างพัฒนา | ปรับปรุงตาม Feedback และทดสอบการยอมรับใหม่ | ApS / SeV |

## 10 Contingency Actions for Non-Completed Tasks

แผนรองรับสำหรับกรณีงานไม่แล้วเสร็จตามกำหนด (Non-Completed Task)

| ลำดับ | สถานการณ์ | สาเหตุที่พบบ่อย | ผลกระทบที่อาจเกิด | แผนรองรับเมื่อเกิดเหตุ | ผู้รับผิดชอบ |
| :---: | --- | --- | --- | --- | --- |
| 1 | งานไม่เสร็จภายในกำหนด (Due Date) | ประเมินเวลาผิดพลาด หรือทรัพยากรไม่เพียงพอ | กระทบ Timeline และกำหนดส่งมอบ | ประชุมด่วนเพื่อประเมินสถานะ จัดลำดับความสำคัญใหม่ ปรับแผน และแจ้งลูกค้าอย่างเป็นทางการ | ApS |
| 2 | งานล่าช้าเพราะขาดบุคลากร | ลาป่วย ลาออก หรือไม่พร้อมปฏิบัติงาน | งานค้างสะสมและภาระงานกระจุกตัว | จัดทำเอกสารส่งมอบงาน ถ่ายทอดความรู้ให้ผู้ปฏิบัติแทน และขออนุมัติจัดหาผู้ช่วยเฉพาะงาน | ApS / ฝ่ายบุคคล |
| 3 | งานค้างเพราะรอข้อมูลจากผู้ใช้ | ผู้ให้ข้อมูลส่งความต้องการหรือข้อมูลตั้งต้นล่าช้า | ไม่สามารถพัฒนาหรือทดสอบต่อได้ | แจ้งเตือนเป็นลายลักษณ์อักษร แยกงานที่ยังไม่พร้อมออก และนัดยืนยัน Timeline ใหม่ | ApS / SeV |
| 4 | งานไม่เสร็จเพราะพบข้อบกพร่องซ้ำซ้อน | ความซับซ้อนสูงหรือขาดการทดสอบระยะแรก | เกิดความล่าช้าในการพัฒนาและทดสอบ | จัดลำดับข้อบกพร่องตามความรุนแรง แยกงานแก้ไขออกจากงานพัฒนาใหม่ และทดสอบซ้ำ | ThS / PaNg |
| 5 | งานล่าช้าเพราะต้องแก้ความต้องการ | ขอบเขตเปลี่ยนหลังเริ่มงาน | กระทบแผนงานและสิ่งส่งมอบ | จัดทำ Change Report อย่างเป็นทางการ ประเมินผลกระทบ และขออนุมัติก่อนดำเนินการต่อ | ApS / SeV |

## 11 Document and Repository

**รูปแบบไฟล์ (File Format)** การกำหนดชื่อไฟล์ให้ใช้รูปแบบดังนี้

`[Project code] [Document name] [yyyymmdd] V[version] [editor name].[ext.]`

| หัวข้อ | รายละเอียด |
| --- | --- |
| [Project code] | รหัสโครงการตามส่วนงานบัญชี เช่น 200-WMS-26-001-00 |
| [Document name] | ชื่อเอกสาร เช่น Progress Status Record |
| [yyyymmdd] | วันที่ของเอกสารตามปีพุทธศักราช เช่น 25690817 |
| [version] | เวอร์ชันของเอกสาร เช่น 1.0 |
| [editor name] | ตัวย่อของชื่อผู้จัดทำ เช่น ApS |
| [ext.] | นามสกุลไฟล์ เช่น pdf |

**การประกาศเวอร์ชัน (Version Declaration)** เก็บเอกสารแต่ละเวอร์ชันแยกไฟล์เพื่อให้ตรวจสอบย้อนหลังได้ โดยใช้รูปแบบ Major.Minor

| เวอร์ชัน (Version) | รายละเอียด |
| --- | --- |
| 0.1 (Draft) | ร่างเอกสารฉบับแรก |
| 0.2 (Draft) | ปรับปรุงตามผลการทบทวน |
| 1.0 (Release) | อนุมัติใช้เป็นเอกสารทางการ |
| 1.1 (Revision) | ปรับปรุงเอกสารหลังอนุมัติ |

**Project Repository** ใช้ Git Server เป็นศูนย์กลางในการจัดเก็บและควบคุมเวอร์ชันของ Source Code และเอกสารทั้งหมดที่เกี่ยวข้องกับโครงการ

| ลำดับ | หัวข้อ | รายละเอียด |
| :---: | --- | --- |
| 1 | ที่เก็บข้อมูล (Repository Location) | ทีมงานเข้าถึง Repository ผ่าน Git Server โดย Repository ของโครงการนี้เก็บทั้ง Source Code และเอกสาร ISO |
| 2 | สิทธิ์การเข้าถึง (Access Control) | สมาชิกโครงการได้รับสิทธิ์ตามบทบาท โดย Project Manager และ System Analyst มีสิทธิ์อนุมัติการ Merge |
| 3 | การจัดเก็บไฟล์งาน (File Storage Rules) | ไฟล์ที่เกี่ยวข้องกับโครงการต้องจัดเก็บใน Repository และไฟล์ที่สร้างจากเครื่องส่วนบุคคลต้องนำขึ้น Repository ภายในเวลาที่กำหนด |

**Project Repository Backup** เพื่อป้องกันการสูญหายของข้อมูลใน Git Server

| ลำดับ | หัวข้อ | รายละเอียด |
| :---: | --- | --- |
| 1 | ผู้รับผิดชอบ (Responsibility) | มอบหมาย Developer ตรวจสอบความถูกต้องของข้อมูลสำรองอย่างสม่ำเสมอ |
| 2 | วิธีการสำรองข้อมูล (Backup Methods) | ซิงก์ Repository ไปยัง Backup Remote และสำรองฐานข้อมูลด้วยการ Export อัตโนมัติ |
| 3 | รอบการสำรองข้อมูล (Backup Frequency) | ฐานข้อมูลสำรองทุกวันเวลา 02:00 น. และ Repository ซิงก์ทุกครั้งที่มีการส่งมอบ |

## ผู้จัดทำเอกสาร (Secretary)

| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager |  |  |

## ผู้ตรวจสอบเอกสาร (Reviewer)

| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเยาวลักษณ์ บางชมภู | Document Control |  |  |

## ผู้อนุมัติ (Approval)

| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor |  |  |