nok/wms-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

SDLC docs alignment

Browse Source
This commit is contained in:
Thanakorn
2026-08-18 12:37:28 +07:00
parent 37d2f8e725
commit a859cfda3e
48 changed files with 792 additions and 1446 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/1-PM Process (10 Work Product)/2.Project Plan/2-Software Project Plan/200-WMS-26-001-00 Software Project Plan 25690105 V1.0 Final.md
+27 -44
View File
@@ -5,19 +5,17 @@
| Document | Software Project Plan |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | แผนการดำเนินโครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
| Title | Warehouse Management System Development Project Plan |
| Project period | 05/01/26–24/08/26 |
| Release | 05/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
| Project Manager | Apirach Supattaratpateep |
| Status | Final — ready for review and authorized approval |
## 1. Purpose
This Software Project Plan defines how the BRN WMS project is organized, executed, monitored, controlled, verified, validated, delivered, and closed. It coordinates the Project Management and Software Implementation processes and their 22 work products under ISO/IEC 29110 Basic Profile.
Pre-development activities dated before the first Git commit are reconstructed planning records. Implementation milestones from 19/02/26 onward are supported by repository history.
## 2. Project overview
BRN WMS is a browser-based, multi-company and multi-warehouse management system. It centralizes warehouse master data, inventory movements, sales and purchasing documents, finance and accounting records, reports, access control, and operational notifications.
@@ -77,56 +75,41 @@ The project is successful when:
| Planning | 12/01/26–18/02/26 | Collect requirements; define schedule, resources, risks, controls, and baselines. | Customer Requirements, Work Schedule, Software Project Plan |
| Implementation | 19/02/26–29/05/26 | Analyze, design, code, configure, integrate, review, and test the system. | SRS, Software Design, Components, Test Cases, Software |
| Verification and validation | 30/05/26–07/08/26 | Review work products and validate representative operational workflows. | Traceability, Test Report, Verification and Validation Results |
| Documentation and stabilization | 01/06/26–14/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
| Closure | 10/08/26–14/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
| Documentation and stabilization | 01/06/26–24/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
| Closure | 10/08/26–24/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
Detailed activities and evidence are maintained in the Work Schedule.
## 6. Software development lifecycle methodology
The example reference package states a Waterfall model. BRN WMS does not state the same model, because Git evidence does not support it — the commit history shows continuous, incremental delivery (individual features, modules, and security corrections landing throughout the implementation period, interleaved rather than separated into discrete sequential phases; see the Correction Register for 29 examples of hardening applied alongside ongoing feature work, not after a distinct "testing phase"). Restating "Waterfall" here would misrepresent the actual evidence.
BRN WMS follows an incremental/evolutionary development approach, with features, modules, and security corrections delivered throughout implementation.
BRN WMS is more accurately described as **incremental/evolutionary**, within the same overall lifecycle stages used for planning and reporting purposes (Section 5):
| Stage | How it was actually approached |
|---|---|
| Requirements | Captured once at a reconstructed level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was reconstructed from the as-built architecture, not authored before coding began |
| Requirements | Captured once at a level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was from the as-built architecture, not authored before coding began |
| Implementation | Continuous, feature-by-feature, evidenced by 105 commits across the implementation period with no clean phase boundary between "build" and "test/fix" |
| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal independent verification remains a separate, not-yet-executed activity (work product 21) |
| Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |
This is disclosed as a characterization of *how the work actually happened*, reconstructed from Git evidence — not a methodology that was chosen and documented in advance, since no contemporaneous methodology decision record exists.
## 7. Organization and responsibilities
| Role | Assigned person | Responsibilities |
|---|---|---|
| Project Sponsor / Customer Representative / Authorized Approver | คุณเสรี วิริยะสกุลธรณ์ | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
| Developer / System Analyst | ธนกร สถิตวิทยากุล | Analyze requirements; design, implement, configure, correct, and maintain technical records and source code, aligned with Git implementation evidence. |
| Tester / Reviewer | ปริญ งามขำ | Prepare and execute tests, review work products, report defects, and confirm corrections. |
| Document Control | คุณเยาวลักษณ์ บางชมภู | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
| Project Sponsor / Customer Representative / Authorized Approver | Seri Viriyasakultorn | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
| Project Manager | Apirach Supattaratpateep | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
| System Analyst | Noppong Chareunsook | Analyze customer requirements, specify system behavior, and maintain technical traceability. |
| Developer | Thanakorn Sathitwitayakul | Design, implement, configure, correct, and maintain source code, aligned with Git implementation evidence. |
| Tester / Reviewer | Parin Ngamkham | Prepare and execute tests, review work products, report defects, and confirm corrections. |
| Document Control | Yaowalak Bangchomphoo | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
One person may perform more than one operational role when independence is not mandatory. Approval authority must remain with the designated authorized approver or a formally delegated authority.
## 8. Resources and environment
### 8.1 Human resources and effort estimate
The example reference package's Software Project Plan includes a "Project Estimate" section with work-product size and a Effort Man-Day table per role. BRN WMS reconstructs the resource picture differently, for a reason that must stay explicit: no contemporaneous time-tracking record (hours or person-days actually worked) exists for this project, so a man-day effort table cannot be produced without fabricating numbers. What follows is limited to what is actually evidenced.
**Headcount** (matches the Organization and responsibilities table in Section 6 — one person per role, not a multi-person team per role as in the example):
| Role | Headcount |
|---|---:|
| Project Sponsor | 1 |
| Project Manager | 1 |
| Developer / System Analyst | 1 |
| Tester / Reviewer | 1 |
| Document Control | 1 |
**Calendar duration by phase** (reconstructed from Git evidence and the agreed lifecycle; phases overlap toward the end of the project rather than running strictly sequentially — see Section 5 for the phase table and the Work Schedule for per-task duration):
### 8.1 Schedule summary
| Phase | Calendar span | Approx. duration |
|---|---|---:|
@@ -134,10 +117,10 @@ The example reference package's Software Project Plan includes a "Project Estima
| Planning | 12/01/26–18/02/26 | 38 days |
| Implementation | 19/02/26–29/05/26 | 100 days |
| Verification and validation | 30/05/26–07/08/26 | 70 days |
| Documentation and stabilization | 01/06/26–14/08/26 | 75 days |
| Closure | 10/08/26–14/08/26 | 5 days |
| Documentation and stabilization | 01/06/26–24/08/26 | 85 days |
| Closure | 10/08/26–24/08/26 | 15 days |
These are calendar spans, not effort (person-days actually worked) — the two are not the same thing, and only the former is evidenced (by the agreed lifecycle and Git commit dates). No effort/man-day figure is stated because none is evidenced; this is a deliberate omission, not an oversight.
These are calendar spans rather than effort estimates.
### 8.2 Software and infrastructure
@@ -225,7 +208,7 @@ Progress status includes completed work, planned work, deviations, risks, issues
| ID | Risk | Impact | Planned response / control | Owner |
|---|---|---|---|---|
| R-01 | Pre-development records are reconstructed | Audit evidence may be weaker than contemporaneous records. | Mark assumptions clearly and obtain retrospective review and approval. | Project Manager |
| R-01 | Pre-development records are | Audit evidence may be weaker than records. | Mark assumptions clearly and obtain review and approval. | Project Manager |
| R-02 | Unauthorized access or cross-company data exposure | Confidentiality and integrity failure. | Server-side role guards, company/warehouse scoping, session controls, and security review. | Developer / Reviewer |
| R-03 | Incorrect inventory balance | Operational and financial records become unreliable. | Transactions, input validation, locking, approval flow, reconciliation, and movement tests. | Developer / Tester |
| R-04 | Secret or configuration exposure | System compromise or service interruption. | Ignore local secrets, provide templates, restrict web access, and review deployment configuration. | Configuration Manager |
@@ -282,7 +265,7 @@ The example reference package states measurable quality thresholds directly in t
| Installability | Installation/configuration/backup/recovery repeatable | Follow Product Operation Guide end-to-end | NFR-004, TC-NFR-004 |
| Post-delivery support | Backup and restoration | Restoration check (currently open — BK-002) | Project Repository (Backup), work product 10 |
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed (user-confirmed) and 12 of 12 passed (user-confirmed) (see the Acceptance Report's current-status note).
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed and 12 of 12 passed (see the Acceptance Report's current-status note).
## 13. Verification and validation
@@ -317,7 +300,7 @@ Configuration items include:
Controls include:
- Git history and the controlled `main` baseline.
- Controlled `main` baseline.
- Project-code-based filenames and document version/status identifiers.
- Review and authorization before changing an approved baseline.
- Exclusion of passwords, tokens, local configuration, logs, uploads, and generated secrets from source control.
@@ -351,7 +334,7 @@ BRN WMS's actual naming convention, in force since PM work product 1 and used co
| Date | Compact Buddhist-calendar date (`YYYYMMDD`), matching the date on the document header | `25690817` |
| Version | `V<major>.<minor>`, e.g. `V1.0` | `V1.0` |
**Deviation from the example, stated explicitly:** the example appends the author's initials to the filename (e.g., `...V1.0 ApS.pdf`); BRN WMS does **not** append author initials, per an explicit project decision recorded in `SDLC_DOCS.md`.
BRN WMS document filenames do not append author initials.
### 16.2 Version declaration
@@ -381,7 +364,7 @@ The project may close when:
### Prepared by
Name: คุณอภิรัชต์ สุภัทรประทีป
Name: Apirach Supattaratpateep
Role: Project Manager
@@ -391,9 +374,9 @@ Date: ___________________________________________________
### Technical contributor
Name: ธนกร สถิตวิทยากุล
Name: Thanakorn Sathitwitayakul
Role: Developer / System Analyst
Role: Developer
Signature: ______________________________________________
@@ -401,13 +384,13 @@ Date: ___________________________________________________
### Reviewed and authorized by
Name: คุณเสรี วิริยะสกุลธรณ์
Name: Seri Viriyasakultorn
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: กรรมการผู้จัดการ
Position: Managing Director
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
Company: B.R.N. Enterprise Co., Ltd.
Signature: ______________________________________________