docs(sdlc): finalize ISO 29110 evidence package

2026-08-26 12:35:57 +07:00
parent c7821b9d2d
commit 45b2415beb
53 changed files with 195 additions and 27 deletions
@@ -25,6 +25,37 @@ Sections 6, 8.5, 12.2 and 16 describe outcomes as at 17/08/26; the remaining sec

 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.

+### 1.1 Standards basis and applicability
+
+BRN WMS applies the ISO/IEC 29110 software engineering Generic Basic Profile for one non-safety-critical software product developed by one project team under a customer project agreement. The standards basis for this project is:
+
+- **ISO/IEC 29110-4-1:2018** — Software engineering profile specifications for the Generic profile group, including the Basic profile.
+- **ISO/IEC 29110-5-1-2:2025** — Software engineering management and engineering guidelines for the Generic Basic profile.
+
+| Applicability item | BRN WMS application |
+|---|---|
+| Profile group | Generic profile group |
+| Profile | Basic profile |
+| Engineering discipline | Software engineering |
+| Project organization | One project team with assigned management, analysis, development, testing, document-control, and customer-approval roles |
+| Product scope | One browser-based warehouse management software product and its supporting deployment/service components |
+| Agreement | Customer project agreement controlled through the Statement of Work and Customer Requirements |
+| Safety criticality | Non-safety-critical software |
+| Management process | Project Management |
+| Engineering process | Software Implementation |
+| Lifecycle | Incremental/evolutionary implementation with controlled requirements, configuration baselines, verification, validation, and acceptance |
+| Tailoring principle | Work-product structure and detail are scaled to BRN WMS size and complexity while retaining controlled content, responsibility, review, and traceability |
+
+### 1.2 Work-product tailoring
+
+- Project Plan content is controlled across the Work Schedule, this Software Project Plan, and Customer Requirements.
+- The Software work product is the Git-controlled application baseline; work product 17 is its controlled identification and repository pointer record.
+- The Traceability Record (work product 13) is the master requirements matrix. The additional Traceability Record Table is a summary/pointer and does not create a second competing baseline.
+- Test Cases and Test Procedures defines the tests and records their execution status; the separate Test Report consolidates the results and disclosed evidence limitations.
+- The Project Charter Report, Stakeholder Register, List of Evidence, Traceability Record Table, and Training Report supplement the Basic-profile work products without replacing them.
+- Markdown files under `sdlc/` are the controlled editable document sources. PDFs under `sdlc-delivery/` are generated delivery/printing outputs and are not edited independently.
+- No Project Management or Software Implementation process is declared excluded. Content granularity is scaled where documented, including requirement-level traceability for the 34 controlled requirements.
+
 ## 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.
@@ -100,7 +131,7 @@ BRN WMS is more accurately described as **incremental/evolutionary**, within the
 | 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 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) |
+| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal Round 2A document-control and Round 2B technical work-product verification was completed on 17/08/26 and recorded in work product 21 |
 | Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |

 ## 7. Organization and responsibilities
@@ -12,6 +12,7 @@
 | Project Manager | Apirach Supattaratpateep |
 | System Analyst | Noppong Chareunsook |
 | Developer | Thanakorn Sathitwitayakul |
+| QA / Tester | Parin Ngamkham |
 | Project Sponsor / Customer Representative | Seri Viriyasakultorn |
 | Status | Final — all 28 corrections verified against linked test cases and formally closed through the Accepted decision |

@@ -25,6 +26,15 @@ Each entry records the date the issue was detected and the date the correction w
 | Verified | Objective verification evidence has been linked and reviewed. |
 | Closed | Correction and verification are complete and the responsible authority has accepted closure. |

+### 1.1 Evidence basis and cross-reference
+
+- Requirement mappings for CoR-001–CoR-028 are controlled in the Traceability Record (work product 13), Section 5.
+- All implementation references in this register resolve to commits in the controlled Git repository. Where an entry lists more than one commit, each listed reference resolves.
+- Every correction entry links to at least one verification test case. Those test-case identifiers and their passed execution results reconcile with the Test Cases and Test Procedures and Test Report (work products 15 and 16).
+- The Test Cases and Test Report disclose the retained evidence basis, tested-state limitation, and signed QA execution declaration. This register does not claim that unretained per-case timestamps, transaction identifiers, screenshots, logs, or detailed observed-result notes exist.
+- Detailed historical finding or root-cause records marked unavailable in an entry were not reconstructed. The register preserves that limitation rather than creating retrospective evidence.
+- No correction remains in Implemented; verification pending status. Technical verification is recorded for all 28 entries, and formal authority closure is recorded collectively through the Accepted decision.
+
 ## 2. Correction entries

 | ID | Detected | Corrected | Severity | Problem or finding | Cause record | Corrective action / result | Owner | Implementation reference | Verification | Status |
@@ -76,7 +86,7 @@ The entry rows retain `Verified` as their technical evidence status. Formal auth

 ## 4. Verification and closure procedure

-For each entry:
+The intended correction verification and closure procedure is:

 1. Link the applicable requirement ID and affected component.
 2. Identify or create the verifying Test Case ID.
@@ -86,7 +96,18 @@ For each entry:
 6. Change status to Verified only after evidence review.
 7. Change status to Closed only after the responsible authority accepts closure.

-## 5. Approval
+For this historical register, the signed manual execution records in work products 15 and 16 substantiate the linked passed results. Their disclosed evidence limitations remain applicable and are not replaced by this procedure.
+
+## 5. Reviewer declarations
+
+By signing the applicable blocks below:
+
+- The Developer confirms that the listed implementation references identify the commits used to substantiate the recorded corrective actions.
+- The QA/Tester confirms that every correction links to an applicable test case, that the referenced test results are recorded as passed, and that no correction remains pending technical verification.
+- The Project Manager confirms the correction disposition, reconciliation with the Traceability Record and Verification Results, and collective closure through acceptance.
+- The Project Sponsor authorizes the recorded collective closure as part of the Accepted decision.
+
+## 6. Approval

 ### Prepared and technically substantiated by

@@ -95,7 +116,14 @@ Role: Developer
 Signature: ______________________________________________  
 Date: ___________________________________________________

-### Reviewed by
+### Verification results confirmed by
+
+Name: Parin Ngamkham  
+Role: QA / Tester  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Disposition and closure reviewed by

 Name: Apirach Supattaratpateep  
 Role: Project Manager