Aim: split the development into defined phases and activities and keep a record of all pertinent information through the software's life. A lifecycle model is chosen and described in the quality assurance plan required by 6.5, allowing for iteration inside and across phases (C.1 guides iterative models, C.2 modelling). Quality assurance runs alongside the lifecycle with shared terminology. The quality assurance, verification, validation and configuration management plans exist from project start and are kept current. Each phase's activities are defined and planned before the phase begins. Documents are built to grow with the development; each carries a unique reference and a documented link to the others; terms, acronyms and item names mean the same thing everywhere (historic differences listed); each document takes in and does not contradict the one above it in the hierarchy (pre-existing software documents excepted); content is kept in a form suited to processing and storage. Where documents from independent roles are merged, each role's part stays traceable. Documents may be merged or split, and steps merged, split or, with justification, dropped, by the Project Manager with the Validator's agreement; documents generated from databases or modelling tools keep version traceability to the database. Any lifecycle or document structure adopted is shown to meet every objective and requirement of the standard. Table A.1 lists the lifecycle documents by integrity level.
This control maps to 8 controls across 4 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 8 it maps to, and the evidence behind each claim, over MCP and REST.