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