During build sprints every code change goes through a pull request that a second engineer reviews against a checklist before it merges, and automated tests must pass first. Problems found along the way go into an anomaly log with a link to risk. A short design review at the end of each sprint confirms that requirements, design documents and tests moved with the code. Training records show each person was trained on the procedures before doing the work.
On the map: Change control and code review. Anomaly log. Design review each sprint. Training records.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Make code review and change control fast enough that engineering uses them every sprint. Anomalies logged when found are cheaper than anomalies reconstructed at verification.
A fixed checklist taken from the development plan: the requirement in the issue is implemented, the change fits the documented architecture, design documents are updated, and any requirement met by the change has a verification protocol. Saved replies in the review tool make the checklist cheap to apply on every pull request.
Senior engineers review changes to the highest safety class software items. A code owners file can force a named reviewer on files that implement risk controls.
Any behavior that deviates from requirements, design documents or user expectations is logged, with its source, safety impact and security impact. Fixed items move to the version history. Open items carry forward to the unresolved anomalies list for the submission.
Light. It confirms the sprint's outputs match its inputs and that documents moved with the code. Formal phase reviews with an independent reviewer stay at the phase gates.
See the open positions and apply.