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

SDLC docs feedback and additional adjustment

Browse Source
This commit is contained in:
Thanakorn
2026-08-19 10:02:21 +07:00
parent 6765054950
commit 849158059b
43 changed files with 877 additions and 437 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 → sdlc/1-PM Process (10 Work Product)/2.Project Plan/2-Software Project Plan/200-WMS-26-001-00 Software Project Plan 25690817 V1.1 Final.md
+18 -8
View File
@@ -7,11 +7,21 @@
| Project code | 200-WMS-26-001-00 |
| Title | Warehouse Management System Development Project Plan |
| Project period | 05/01/26–24/08/26 |
| Release | 05/01/26 V1.0 Final |
| Release | 17/08/26 V1.1 Final |
| Original baseline | 05/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Project Manager | Apirach Supattaratpateep |
| Status | Final — ready for review and authorized approval |
## Revision history
| Version | Date | Change | Prepared by |
|---|---|---|---|
| V1.0 | 05/01/26 | Initial project plan issued at project start: scope, lifecycle, organization, resources, risks, quality, configuration and closure approach. | Apirach Supattaratpateep |
| V1.1 | 17/08/26 | Re-issued at closure. Section 6 records the lifecycle actually followed and the implementation commit count; Section 8.5 records the equipment-evidence position; Section 12.2 records achieved quality results; Section 16 records the naming/version conventions and repository state as applied across the controlled file set. Scope, organization and risk content from V1.0 are unchanged. | Apirach Supattaratpateep |
Sections 6, 8.5, 12.2 and 16 describe outcomes as at 17/08/26; the remaining sections are the V1.0 baseline.
## 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.
@@ -89,8 +99,8 @@ BRN WMS is more accurately described as **incremental/evolutionary**, within the
| Stage | How it was actually approached |
|---|---|
| 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" |
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was derived from the as-built architecture, not authored before coding began |
| Implementation | Continuous, feature-by-feature, evidenced by 100 commits across the implementation period (19/02/26–29/05/26; 110 in the repository overall) 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 |
@@ -208,7 +218,7 @@ Progress status includes completed work, planned work, deviations, risks, issues
| ID | Risk | Impact | Planned response / control | Owner |
|---|---|---|---|---|
| R-01 | Pre-development records are | Audit evidence may be weaker than records. | Mark assumptions clearly and obtain review and approval. | Project Manager |
| R-01 | Pre-development planning records were prepared after the fact | Audit evidence may be weaker than the records suggest. | 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 |
@@ -263,9 +273,9 @@ The example reference package states measurable quality thresholds directly in t
| Reliability/integrity | No invalid negative/duplicate stock or GL movement | Failure/rollback and concurrency test | NFR-003, SR09:003, TC-NFR-003 |
| Usability | Responsive UI usable on desktop and warehouse-floor devices | Representative-screen check at agreed viewport sizes | NFR-005, SR02:002, TC-NFR-005 |
| 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 |
| Post-delivery support | Backup and restoration | Restoration check performed manually by the Developer | 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 and 12 of 12 passed (see the Acceptance Report's current-status note).
Actual results belong in the Test Report and Verification/Validation Results, which show 34 of 34 passed and 12 of 12 passed, executed 10/08/26–14/08/26 (see the Acceptance Report's current-status note).
## 13. Verification and validation
@@ -323,7 +333,7 @@ Defects and nonconformities are recorded in the Correction Register, assigned to
### 16.1 File naming convention
BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 42 controlled files, differs deliberately from the example reference project's:
BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 46 controlled files, differs deliberately from the example reference project's:
`[Project code] [Document name] [YYYYMMDD Buddhist] V[version]`, for example `200-WMS-26-001-00 Correction Register 25690817 V1.0`.
@@ -346,7 +356,7 @@ Documents created for BRN WMS are released directly at `V1.0` once content is co
- Documents identify title, date, version, status, preparer, reviewer, and approver as applicable.
- Drafts remain distinguishable from approved baselines.
- The Project Repository contains the current controlled work products and supporting evidence (work product 9).
- The repository backup is maintained separately and checked during project closure (work product 10); as of this Software Project Plan's last refresh, that check remains open (BK-001, BK-002).
- The repository backup is maintained separately and checked during project closure (work product 10); that check was performed manually by the Developer (BK-001, BK-002 closed).
- Superseded records are retained or archived according to organizational control practices.
## 17. Acceptance and closure