docs(sdlc): reformat work products to audited reference layout
This commit is contained in:
Thanakorn
+85
@@ -0,0 +1,85 @@
|
||||
# Maintenance Document
|
||||
|
||||
<!-- footer: MD -->
|
||||
|
||||
| Document No | Maintenance Document | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือการบำรุงรักษาระบบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เพื่อกำหนดแนวทางการบำรุงรักษาระบบหลังจากส่งมอบและเปิดใช้งานจริง ครอบคลุมการแก้ไขข้อผิดพลาด การปรับปรุง และการป้องกัน เพื่อให้ระบบมีความเสถียร ปลอดภัย ต่อเนื่อง และสอดคล้องกับความต้องการของผู้ใช้งาน
|
||||
|
||||
## ขอบเขตการบำรุงรักษา (Maintenance Scope)
|
||||
|
||||
| ID | Type |
|
||||
| :---: | --- |
|
||||
| MD-001 | Web Server (PHP 8, Apache, Linux Server) |
|
||||
| MD-002 | Application Modules (11 ระบบงาน) |
|
||||
| MD-003 | Database (MariaDB — ฐานข้อมูล `wms` และ `wms2`) |
|
||||
| MD-004 | Security Layer (HTTPS/TLS, RBAC, bcrypt Password Hashing) |
|
||||
| MD-005 | Real-time & Scheduler Services (Node.js, Socket.IO, pm2) |
|
||||
| MD-006 | Software Components: Git Server (`git@188.166.228.62:nok/wms-app.git`) |
|
||||
| MD-007 | Project Repository (Backup): Git Remote สำรอง (`git@github.com:thanakorninbox-dev/wms-app.git`) และชุดสำรองฐานข้อมูลบนคลาวด์ |
|
||||
|
||||
## ประเภทการบำรุงรักษา
|
||||
|
||||
| ลำดับ | ประเภทการบำรุงรักษา | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Corrective Maintenance | แก้ไขข้อผิดพลาด (Bug Fix) และตรวจสอบ Error Log |
|
||||
| 2 | Adaptive Maintenance | ปรับระบบให้รองรับ Browser หรือระบบปฏิบัติการรุ่นใหม่ |
|
||||
| 3 | Perfective Maintenance | ปรับปรุงประสิทธิภาพและเพิ่มความสามารถตามที่ตกลง |
|
||||
| 4 | Preventive Maintenance | ปรับปรุงความปลอดภัย (Patch Security) และทดสอบการสำรอง/กู้คืนข้อมูล |
|
||||
|
||||
## กิจกรรมการบำรุงรักษา (Maintenance Activities)
|
||||
|
||||
| ลำดับ | กิจกรรม | รายละเอียด | ความถี่ | ผู้รับผิดชอบ |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| 1 | ตรวจสอบ Error Log | วิเคราะห์ Log ของแอปพลิเคชันและบริการ Node.js แล้วแก้ไขข้อผิดพลาดที่พบ | รายสัปดาห์ | System Admin |
|
||||
| 2 | Patch Security | ปรับปรุงแพตช์ความปลอดภัยของ PHP, MariaDB, Node.js และใบรับรอง TLS | รายเดือน หรือเมื่อมี Critical Patch | System Admin |
|
||||
| 3 | Backup & Recovery Test | ตรวจสอบชุดสำรองรายวันและทดสอบกู้คืนสู่สภาพแวดล้อมทดสอบ | สำรองทุกวัน ทดสอบกู้คืนทุกไตรมาส | System Admin |
|
||||
| 4 | Monitor Uptime | ตรวจสอบความพร้อมใช้งานของเว็บ ฐานข้อมูล และบริการ Node.js | ทุก 5 นาที (อัตโนมัติ) | System Admin |
|
||||
| 5 | ตรวจสอบงานตามกำหนดเวลา | ตรวจสอบว่างานสรุปยอดสต๊อก/GL และงานแจ้งเตือนทำงานครบถ้วน | รายวัน | System Admin |
|
||||
| 6 | Support & Training | สนับสนุนผู้ใช้งาน ปรับปรุงคู่มือ และอบรมเมื่อมีการปรับปรุงระบบ | ทุกครั้งที่มี Release ใหม่ | Project Team |
|
||||
|
||||
## ข้อตกลงระดับการให้บริการ (Service Level Agreement)
|
||||
|
||||
| ลำดับ | ระดับปัญหา | คำจำกัดความ | ระยะเวลาแก้ไข |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | Incident Critical | ระบบไม่สามารถใช้งานได้ หรือกระทบความปลอดภัยและความถูกต้องของข้อมูล | แก้ไขภายใน 4 ชั่วโมง |
|
||||
| 2 | Major Issue | ฟังก์ชันสำคัญใช้งานไม่ได้ แต่มีทางเลี่ยงชั่วคราว | แก้ไขภายใน 24 ชั่วโมง |
|
||||
| 3 | Minor Issue | ปัญหาที่กระทบการใช้งานเล็กน้อย | แก้ไขภายใน 3 วันทำการ |
|
||||
| 4 | Feature Request | ความต้องการเพิ่มเติมนอกขอบเขตเดิม | พิจารณาใน Release ถัดไปผ่าน Change Report |
|
||||
|
||||
## แนวทางการแก้ไขและปรับปรุงระบบ
|
||||
|
||||
| ลำดับ | ขั้นตอน | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ระบุส่วนประกอบที่เกี่ยวข้อง | ค้นหา Manager Class ที่รับผิดชอบจากเอกสาร Software Components ก่อนแก้ไขหน้าจอโดยตรง |
|
||||
| 2 | ตรวจสอบประวัติข้อบกพร่อง | ตรวจสอบ Correction Register (28 รายการ) เพื่อไม่ให้การแก้ไขย้อนกลับผลการแก้ไขเดิม |
|
||||
| 3 | ควบคุมการเปลี่ยนแปลง | หากกระทบขอบเขตหรือ Baseline ที่ส่งมอบแล้ว ต้องจัดทำ Change Report ก่อนดำเนินการ |
|
||||
| 4 | ปรับปรุงฐานข้อมูล | สะท้อนการเปลี่ยนแปลงโครงสร้างใน `setup.php` และตาราง `schema_migrations` เสมอ |
|
||||
| 5 | ทดสอบและบันทึกผล | ทดสอบด้วย Test Case ที่เกี่ยวข้อง แล้วบันทึกผลใน Correction Register |
|
||||
| 6 | ปรับปรุงชุดสำรอง | ซิงก์การเปลี่ยนแปลงไปยัง Remote สำรอง `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-79
@@ -1,79 +0,0 @@
|
||||
# Maintenance Documentation
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Maintenance Documentation |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | System Maintenance Manual Document |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — reflects the implemented architecture at project baseline |
|
||||
|
||||
Note: the example reference package filed the same content twice under Product Operation Guide and Maintenance Documentation. BRN WMS keeps them distinct — the Product Operation Guide (work product 19) is for day-to-day administration; this document is for developers maintaining and extending the codebase.
|
||||
|
||||
## Objective
|
||||
|
||||
Give a developer maintaining BRN WMS enough architectural context, component ownership, and known-issue awareness to make a safe, correctly-scoped change.
|
||||
|
||||
## 1. Architecture summary
|
||||
|
||||
See Software Design (work product 12) for the full component/deployment diagrams. In summary: PHP presentation + business-logic manager classes → two MariaDB databases (`wms` identity/company, `wms2` WMS/accounting), plus a Node.js real-time/scheduler tier reached only through a secret-protected internal endpoint.
|
||||
|
||||
## 2. Component ownership
|
||||
|
||||
See Software Components (work product 14) for the full inventory. When changing behavior, locate the owning manager class first (e.g., stock behavior → `StockManager`/`StockSourceManager`/`StockTablesTrait`; posting/GL behavior → `PostingManager`; document numbering → `DocumentNumberManager`) rather than editing page-level code directly, consistent with NFR-007 (maintainability).
|
||||
|
||||
## 3. Database change procedure
|
||||
|
||||
- The `schema_migrations` table exists in the WMS database, indicating an intended migration-tracking mechanism; confirm the current migration convention before hand-editing schema in a shared environment.
|
||||
- `setup.php` is the authoritative one-shot schema definition for a fresh environment; any schema change should be reflected there so a new environment matches production.
|
||||
- Prefer additive, backward-compatible schema changes; coordinate destructive schema changes through the Change Report.
|
||||
|
||||
## 4. Configuration points
|
||||
|
||||
| Area | File(s) | Notes |
|
||||
|---|---|---|
|
||||
| Database/app config | `app/config.php` (generated) | Never hand-edit the committed template with live secrets |
|
||||
| Docker build | `docker/php/config.php.template`, `docker/php/entrypoint.sh` | Change here to affect all container deployments |
|
||||
| Node.js services | `nodejs/server.js`, `nodejs/scheduler.js`, `nodejs/ecosystem.config.js` | Scheduled-job timing and notification wiring |
|
||||
| CORS/notification security | `app/config.php` (`NODE_EMIT_SECRET`), Node.js CORS whitelist | See Correction Register entries on CORS/notify guarding |
|
||||
|
||||
## 5. Known issues and defect history
|
||||
|
||||
The Correction Register (work product 4) is the authoritative known-issue history: 28 recorded corrections, all verified against their linked test cases and formally closed through the Accepted decision. Before changing an area, check the Correction Register so a verified fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-016, CoR-017, CoR-026), onboarding (CoR-007, CoR-008, CoR-013, CoR-018), and master-data/document-lifecycle review (CoR-019, CoR-020).
|
||||
|
||||
## 6. Release procedure
|
||||
|
||||
1. Implement and locally verify the change.
|
||||
2. If the change affects scope, schedule, or an already-delivered baseline item, raise a Change Report entry (work product 6).
|
||||
3. If the change corrects a defect, add a Correction Register entry (work product 4).
|
||||
4. Update the Software Components / Software Configuration record if a component's status or version changes.
|
||||
5. Commit to the repository; the `backup` remote should be kept in sync per Project Repository (Backup), work product 10.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
Reference in New Issue
Block a user