Components are implemented so that the software is analysable, testable, verifiable and maintainable, and each is tested. Each component is readable, understandable and testable; the source code conforms to the coding standards, which set out sound programming practice, forbid unsafe language features and describe how code is documented, each component carrying at least its author, configuration history and a short description in a standard form (7.5.4.1-3; Tables A.4 and A.12); source code is placed under configuration control before testing starts (7.5.4.4). Each component is tested against its component test specification, showing that it performs its intended function, and a software component test report states the results, that the component meets its design specification, the coverage achieved showing that all code instructions were executed at least once (or the Table A.21 measure for the SIL), in auditable form with machine-readable cases and results and repeatable automated tests where practicable (7.5.4.5-7; Table A.21). The source code is verified for conformance to the component design specification and the SQAP, including that the coding standards were applied correctly, in the software source code verification report (7.5.4.8 to 7.5.4.10).
This control maps to 1 controls across 1 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 1 it maps to, and the evidence behind each claim, over MCP and REST.