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 6dc8444139
commit 155cf783ae
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/1-Work Schedule/200-WMS-26-001-00 Work Schedule 25690105 V1.0 Final.md → sdlc/1-PM Process (10 Work Product)/2.Project Plan/1-Work Schedule/200-WMS-26-001-00 Work Schedule 25690817 V1.1 Final.md
+14 -4
View File
@@ -7,10 +7,20 @@
| Project code | 200-WMS-26-001-00 |
| Project period | 05/01/26–24/08/26 |
| Project end date | 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 |
| Status | Final — ready for authorized approval |
## Revision history
| Version | Date | Change | Prepared by |
|---|---|---|---|
| V1.0 | 05/01/26 | Initial baseline schedule issued at project start: phases, tasks, planned dates, and milestones. | Apirach Supattaratpateep |
| V1.1 | 17/08/26 | Re-issued at closure. Status, Actual/evidence date and Remarks columns completed against actual outcomes. Planned dates, project end date and task breakdown from V1.0 are unchanged. | Apirach Supattaratpateep |
The Status, Actual/evidence date and Remarks columns below record outcomes as at 17/08/26. The Start, Finish and Duration columns remain the V1.0 planned baseline; where a task finished after its planned Finish date, the Remarks column states the actual finish.
## Schedule basis
| No. | Phase | Task | Details / basis | Responsible role | Start | Finish | Duration | Deliverable / evidence | Status | Remarks |
@@ -33,12 +43,12 @@
| 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Development baseline | Completed |
| 4.1 | Control | Maintain progress and control records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 24/08/26 | 170 days | Progress Status and Correction Register | Completed |
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 24/08/26 | 137 days | Git repository and Software Configuration | Completed | Git repository evidenced |
| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Overdue / not completed — scheduled period elapsed | Traceability Record complete (34/34 requirements linked); Verification Results is a Round 1 self-review by the document preparer only — independent verification not yet performed |
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed — execution | All 34 test cases and 12 validation scenarios were confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees were not separately recorded |
| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Completed | Actual finish 17/08/26, after the scheduled finish of 31/07/26. Traceability Record complete (34/34 requirements linked and verified); Round 2 independent verification performed by Yaowalak Bangchomphoo (Document Control) on 17/08/26 |
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed | Actual finish 14/08/26, after the scheduled finish of 07/08/26. All 34 test cases and 12 validation scenarios were executed and passed over 10/08/26–14/08/26, confirmed by the project user on 17/08/26; per-case execution dates within that window were not separately recorded |
| 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | documentation period |
| 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Configuration and login correction | Completed |
| 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Demonstration data | Completed |
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Independent verification and review completion confirmed by the project user on 17/08/26 |
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Round 2 independent verification performed by Document Control on 17/08/26 |
| 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report and closure record | Completed | Project Sponsor authorization confirmed by the project user on 17/08/26; signature capture remains administrative follow-up |
## Milestones
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
sdlc/1-PM Process (10 Work Product)/2.Project Plan/3-Customer Requirement/200-WMS-26-001-00 Customer Requirements 25690112 V1.0 Final.md
+2 -2
View File
@@ -43,8 +43,8 @@ The expected business outcomes are:
| Apirach Supattaratpateep | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
| Noppong Chareunsook | System Analyst | Analyze customer needs, specify system behavior, and maintain technical traceability. |
| Thanakorn Sathitwitayakul | Developer | Design and implement the solution. |
| Parin Ngamkham | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26. |
| Yaowalak Bangchomphoo | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; added to the project 17/08/26, same role as the example reference project for the same company. |
| Parin Ngamkham | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer. |
| Yaowalak Bangchomphoo | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; same role as the example reference project for the same company. |
| Warehouse Manager and Staff | Operational users | Perform and review warehouse, stock, barcode, and reporting operations. |
| Sales and Purchasing Users | Business users | Perform quotation, order, purchase, invoice, and return workflows. |
| Finance and Accounting Users | Business users | Perform billing, receipt, payment, journal, ledger, and financial reporting activities. |