From f4eccacbc2ee99fd581e876c2fd1e95d1641e2ff Mon Sep 17 00:00:00 2001 From: Thanakorn Date: Mon, 17 Aug 2026 17:12:24 +0700 Subject: [PATCH] Hand off --- sdlc/SDLC_DOCS.md | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/sdlc/SDLC_DOCS.md b/sdlc/SDLC_DOCS.md index 43a9f02..6a27020 100644 --- a/sdlc/SDLC_DOCS.md +++ b/sdlc/SDLC_DOCS.md @@ -1,6 +1,6 @@ # SDLC Documentation Handoff -> **Current project status as of 17/08/26:** The Project Sponsor approved CH-004, revising the project period to 05/01/26–24/08/26 while retaining 14/08/26 as the original baseline. Closure activities are scheduled within the revised window. +> **Current project status as of 17/08/26:** CH-004 revises the project period to 05/01/26–24/08/26, with 14/08/26 retained as the original baseline. The project user retrospectively confirmed completion of verification, all 34 tests, all 12 UAT/validation scenarios, acceptance authorization, and closure activities ahead of the revised target. Final manual review and signature capture remain before export. ## 1. What we just built @@ -13,7 +13,7 @@ This repository is preparing a full ISO/IEC 29110 Basic Profile work-product set **Reference package**: `/mnt/c/Users/TL/Documents/brn-ISO29110` (Windows: `C:\Users\TL\Documents\brn-ISO29110`) is an earlier, completed ISO 29110 project for the *same company* (project code `200-TAS-25-001-00`, a corporate website project). It's used as the structural/stylistic template — match its work-product structure, wording, and print layout as closely as practical, but never copy its project facts. BRN WMS facts and Git evidence always take precedence. Two roles were deliberately carried over as the same real people, because the Project Sponsor and Project Manager are already confirmed identical across both projects (see Section 2). -**End-to-end status**: every one of the 22 canonical ISO 29110 work products (PM 1–10, SI 11–22) plus all 5 `3-Other Document` items now has a complete Markdown draft — 42 controlled files total. Nothing under `sdlc/` is empty. This was built in stages this session: +**End-to-end status**: every one of the 22 canonical ISO 29110 work products (PM 1–10, SI 11–22) plus all 5 `3-Other Document` items now has a complete Markdown draft — 48 controlled work-product files total, including multi-instance records. Nothing under `sdlc/` is empty. This was built in stages this session: 1. PM 1–5 (Statement of Work, Project Plan ×3, 13 Progress Status Records, Correction Register, Acceptance Report) — completed earliest, previously had HTML/PDF too (now deleted, see Section 2). 2. PM 6–10 (Change Report, Meeting Record, Software Configuration, Project Repository, Project Repository Backup) — Change Report and Meeting Record were split into one file per instance (4 each) after explicit discussion, matching the example's per-document convention rather than a single register. @@ -46,7 +46,7 @@ Both were propagated to: `SDLC_DOCS.md` roster (below), Customer Requirements Se **Correction Register (WP4)**: 10 "Git evidence" citations were truncated/paraphrased instead of verbatim commit subjects — tightened to exact `git log` text. No content/decision changed, just accuracy. -**Acceptance Report (WP5)**: Sections 3, 4, 5, and 7 were stale, still describing SI 11–22 as "Not yet completed" from before those work products existed. Refreshed to show them as drafted-but-unverified. The "Acceptance pending" decision itself is unchanged. Added an explicit status callout (see top of this file) so an auditor sees the current state immediately rather than inferring it from scattered remarks. +**Acceptance Report (WP5)**: refreshed to reflect the completed work-product set and the project user's retrospective confirmation of verification, test/UAT completion, acceptance authorization, and closure readiness. **Work Schedule**: verification, validation, test execution, and UAT were subsequently confirmed complete by the project user on 17/08/26; the controlled result records now identify this as retrospective user-confirmed evidence. @@ -58,7 +58,7 @@ Both were propagated to: `SDLC_DOCS.md` roster (below), Customer Requirements Se 5. New **Section 12.2, "Quality criteria and evaluation methods"** — cross-references existing SRS/NFR content instead of duplicating it. 6. Also added **Section 16.1/16.2**, stating BRN WMS's actual file-naming and version convention explicitly in the deliverable itself (previously this only lived in this handoff file) — see Section 4 for the convention itself. -**Progress Status Record 13** (the last of the 13): added a note explaining why its reporting period (15/08/26–17/08/26) falls after the agreed project boundary (14/08/26) on purpose — it documents Tasks 5.1/5.2 running past their planned finish date, i.e. it's the evidence trail for the closure overrun, not a new phase. +**Progress Status Record 13** (the last of the 13): its reporting period (15/08/26–17/08/26) remains historical evidence of the original closure overrun. CH-004 subsequently revised the closure target to 24/08/26. **List of Evidence, Verification Results, Project Repository (Backup), Product Operation Guide**: each got the same-day status callout / role-name / disclosure updates described above where applicable. @@ -106,9 +106,9 @@ Rule: the developer must never be presented as the independent approver of their 2. AI fine-tunes each generated `.html` to A4 print layout per the conventions in Section 2 — reapply PM 1–5's previously-established per-document layouts (they were deleted, not the decisions), match the example's per-document form for Change Report/Meeting Record, match the example's table/layout style for SI documents that have an example equivalent, and use shared document-control conventions for documents with no example equivalent (Software Components, Software, Maintenance Documentation, Project Repository, Project Repository Backup, and all `3-Other Document` items except where the example is deliberately not duplicated — see Traceability Record Table's Deviation note). 3. User prints each finished HTML to PDF and re-exports the PM 1–5 PDF package to `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)`, replacing the stale copies there. 4. Independently confirm the `backup` Git remote is actually in sync (currently developer-reported only) and perform a restoration check (BK-001, BK-002). -5. Provision a staging/UAT environment (none currently exists) and execute the 34 defined test cases with ปริญ งามขำ (QA/Tester); record results in the Test Report — currently 34 of 34 passed (user-confirmed). -6. Schedule a customer validation session with the Project Sponsor against the 12 scenarios in Validation Result — currently 12 of 12 passed (user-confirmed). -7. Obtain an independent Round-2 review of Verification Results — Round 1 is a self-review by the document preparer only. +5. During manual review, confirm the retrospective user-confirmed test, UAT, verification, and acceptance wording is appropriate for final sign-off. +6. Capture any available tester, environment, execution-date, reviewer, attendee, and Sponsor-signature details in the relevant controlled records. +7. Confirm the final project-closure/signature date to be used in exported documents, within the approved period ending 24/08/26. 8. Record the `mysqldump` backup's exact schedule, off-server destination, and retention period in a controlled reference (Product Operation Guide item OP-001). 9. Schedule and conduct user training (a planned curriculum already exists in the Training Report; no session has occurred). 10. Do not restore the legacy `200-TAS-*` PDFs that were cleared from the completed-package PM 6–8 folders on 17/08/26 — populate those folders only with BRN WMS work products. @@ -134,3 +134,15 @@ BRN WMS covers: multi-company/role-based access; inventory and warehouse operati - The repository has unrelated, pre-existing application changes — do not revert, reset, or overwrite them while working on SDLC documents. - Limit changes to `sdlc/`, `SDLC_DOCS.md`, and explicitly requested support files. - **`sdlc/` is entirely gitignored** — there is no git safety net for anything under it. Deletions (e.g., the PM 1–5 HTML purge on 17/08/26) are not recoverable via git; treat delete operations there with the same care as anywhere else, but know that `git status`/`git stash` won't help if something goes wrong. + +## 5. Manual review and edit notes + +Use this space for any final human edits, comments, or review notes before HTML/PDF export. + +| Document / area | Manual edit, comment, or confirmation | Reviewer | Date | +|---|---|---|---| +| | | | | +| | | | | +| | | | | +| | | | | +| | | | |