5.4 KiB
Executable File
5.4 KiB
Executable File
BRN WMS (200-WMS-26-001-00) — ISO/IEC 29110 audit preparation
1. Questions auditors usually ask
Project Management (PM)
| Usual question | Where to point |
|---|---|
| What was agreed with the customer: scope, deliverables, acceptance criteria? | Statement of Work, Software Project Plan §3 |
| How did you plan: tasks, people, effort, schedule? | Work Schedule, Software Project Plan §5–8 |
| How did you track progress, and what did you do when something slipped? | Progress Status Records (15 periods), Minutes of Meeting |
| What risks did you identify, and were they reviewed? | Software Project Plan §9 (R1–R8); expect "show me a risk that changed during the project" |
| How were changes requested, assessed and approved? | Change Report |
| How were defects recorded and closed? | Correction Register ISS-001–028, each linked to a commit and a test case |
| How is the repository controlled and backed up? | Project Repository, Project Repository (Backup), Software Configuration (main, baseline 6c39700) |
| Did the customer formally accept the product? | Acceptance Report, Validation Results |
Software Implementation (SI)
| Usual question | Where to point |
|---|---|
| Were requirements reviewed and baselined before development? | Customer Requirements (CR01–CR14), SRS (SR01–SR09), requirements baseline 18 Feb 2569 |
| Pick one requirement and show its design, code, test and result | Traceability Record — most common test; rehearse 2–3 requirements end to end |
| Show the design and how it maps to the code | Software Design (units UN01–UN13 with file paths) |
| Who reviewed which documents, what was found, and how was it fixed? | Verification Results V0.1–V1.0 (4 rounds) |
| Show the test cases and test results, including a failure and its retest | Test Case and Test Procedures (45), Test Report, Correction Register |
| What exactly was delivered, and can you rebuild it? | Software, Software Components, Product Operation Guide |
| Are user, operation and maintenance documents available? | Software User Document, Product Operation Guide, Maintenance Document |
Weak points likely to be probed
| Point | How to prepare |
|---|---|
| No change requests in 8 months | Explain why the evaluated items did not meet the change criteria |
| All 45 test cases passed in one run | Point to the Correction Register: defects were found and fixed during development |
| Risks never re-rated | Be ready to show where risks were reviewed in Progress Status Records |
| Interviews must match the documents | Developer and QA rehearse: how a defect is logged; how TC-UN08.002 was run |
2. Response to the 23/09/2569 advisor feedback
Feedback paraphrased from the review meeting (original was a screenshot).
| # | Feedback | What was decided / changed | Where to point | Risk if asked |
|---|---|---|---|---|
| 1 | Trace everything back to Customer Requirements | All 80 CRs traced: 68 to unit and test case; 12 to proving documents (manuals, Training Report, SLA, Test Report) in a new "หลักฐานอื่น (Document)" column | Traceability Record summary | Low |
| 2 | Hold meeting minutes for document changes | Not done — documents changed without new minutes | — | High — asked for directly; write a short review record on its real date or be ready to explain |
| 3 | Remark "FR-002" in Customer Requirements | Remark column removed; FR-/NFR- IDs came from an August draft with no customer source | Customer Requirements | Medium — confirm with P'Nok before the audit |
| 4 | Issue table | Accepted by advisor, no change | Correction Register | Low |
| 5 | Link test evidence to corrections | Issues already linked to test cases; Lessons Learned added (28 issues, 5 causes, preventive actions) | Correction Register | Low |
| 6 | Change criteria — "if you remove it, can you still deliver? If yes, it's not a change" | CH-001–003 reclassified: one register with criteria, no request met them; items recorded as meeting decision (Rack → Bin) and Task 4.7 delivery preparation | Change Report §1–2 | Medium — be ready to apply the advisor's test to each of the three items |
| 7 | Software Design needs high-level diagram and wireframes | 4 diagrams (architecture, use case, component, deployment) + 6 wireframes | Software Design figures 1–10 | Low |
| 8 | Verification plan with dates, frequency, hours (232 days → ~4 rounds, every 2 months) | Plan §8.1: 17 Mar, 29 May, 31 Jul, 17 Aug; 3 + 3 + 3 + 6 = 15 hours | Software Project Plan §8.1, Verification Results V0.1–V1.0 | Low |
| 9 | Validate against Customer Requirements, not test cases (14 groups; UAT incomplete) | Rebuilt: 80 requirements in 14 groups, each with method, evidence and Passed 10–14 Aug | Validation Results per-group table | Medium — explain how the extra items were validated; CR11:003 cites the training plan (training 22 Aug, after UAT) |
| — | Next time PM and SI walk through the program end to end with Document Control | No document change | — | Say it will be done on the next project |
Changes made after the review (not requested by the advisor)
| Change | If asked |
|---|---|
| Each document states only what was known on its own date | Documents aligned so each reflects the project state at its date |
| Perfective Maintenance removed; 3 maintenance types | Maintenance Document; Verification Results "3 ประเภท" |
Only branch main named; no commit after 24 Aug 2569 |
Software Configuration: baseline 6c39700 on main |