SDLC docs

2026-08-17 17:09:27 +07:00
parent 6c39700d74
commit a71366ec9f
49 changed files with 4763 additions and 2 deletions
@@ -0,0 +1,80 @@
+# Maintenance Documentation
+
+| Document field | Value |
+|---|---|
+| Document | Maintenance Documentation |
+| Project | BRN WMS |
+| Project code | 200-WMS-26-001-00 |
+| Title | เอกสารคู่มือการบำรุงรักษาระบบ |
+| Project period | 05/01/26–24/08/26 |
+| Preparation date | 17/08/26 |
+| Release | 17/08/26 V1.0 |
+| Standard | ISO/IEC 29110 Basic Profile |
+| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
+| Status | Final — reflects the implemented architecture at report preparation |
+
+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: 29 recorded corrections, all currently "Implemented; verification pending." Before changing an area, check whether it has an open Correction Register entry so a fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-017, CoR-018, CoR-027), onboarding (CoR-007, CoR-008, CoR-014, CoR-019), and master-data/document-lifecycle review (CoR-020, CoR-021).
+
+## 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: ธนกร สถิตวิทยากุล  
+Role: Developer / System Analyst  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed by
+
+Name: คุณอภิรัชต์ สุภัทรประทีป  
+Role: Project Manager  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed and authorized by
+
+Name: คุณเสรี วิริยะสกุลธรณ์  
+Project roles: Project Sponsor / Customer Representative / Authorized Approver  
+Position: กรรมการผู้จัดการ  
+Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด  
+Signature: ______________________________________________  
+Date: ___________________________________________________