The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to https://swehb.nasa.gov/display/SWEHBVC/7.08+-+Maturity+of+Life-Cycle+Products+at+Milestone+Reviews. If you do not get there in 2 seconds, click the link to go there.
See edit history of this section
Post feedback on this section
1. Introduction and Chart
This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life-cycle products and their maturity level at the various software project life cycle reviews. This chart serves as guidance only and NASA Center procedures should take precedence for projects at those Centers.
The chart was constructed using the software engineering products from NPR 7150.2, the project life-cycle reviews from NPR 7123.1 041, previous work from the NASA Software Working Group to map products to life -cycle reviews, and additional information gathered from these NPRs, NPR 7120.5 082, and individual NASA Center procedures. Draft versions of the chart were reviewed by the NASA Software Working Group resulting in this chart which represents the current consensus guidance from this collection, collation, and review process.
The following maturity definitions from NPR 7120.5 082 are used in this table:
a. "Preliminary" is the documentation of information as it stabilizes but before it goes under configuration control. It is the initial development leading to a baseline.
Some products will remain in a preliminary state for multiple life cycle reviews. The initial preliminary version is likely to be updated at subsequent life cycle reviews but remains preliminary until baselined.
b. "Baseline" indicates putting the product under configuration control so that changes can be tracked, approved, and communicated to the team and any relevant stakeholders. The expectation on products labeled "baseline" is that they will be at least final drafts going into the designated life cycle review and baselined coming out of the life cycle review. Updates to baselined documents require the same formal approval process as the original baseline.
c. "Update" is applied to products that are expected to evolve as the formulation and implementation processes evolve. Only expected updates are indicated.
However, any document may be updated, as needed. Updates to baselined documents require the same formal approval process as the original baseline.
NPR 7150.2 does include life-cycle products that are not included in the chart and there are life-cycle reviews that are also not represented in the chart. Insufficient information currently exists or consensus was not reached for those elements which will all be considered for future updates to this chart.
7150.2 Software Life-Cycle Products | MCR | SRR | MDR | SDR | PDR | CDR | SIR | TRR | SAR | ORR |
---|---|---|---|---|---|---|---|---|---|---|
Software Development Plan (SDP) / Software Management Plan (SMP) |
| P | P | B |
| U | ||||
Software Schedule | D | P | U | U | B | U | ||||
Software Cost Estimate | D | P | U | U | B | U | ||||
Software Configuration Management Plan (SCMP) | P | P |
| B | U | |||||
Software Test Plans | P | B | U | U | ||||||
Software Test Procedures | P |
| B | |||||||
Software Test Reports | F | |||||||||
Software Maintenance Plan |
| D | P | P | B | U | ||||
Software Requirements Specification (SRS) |
| P |
|
| B | U |
| U | ||
Requirements on OTS s/w |
| P |
|
| B | U | ||||
Software Data Dictionary |
| P | B | |||||||
Software Design Description (Architectural Design) |
| B | U |
| U | |||||
Software Design Description (Detailed Design) |
| P | B |
| U | |||||
Interface Design Description |
| P | B |
| U | |||||
Software User's Manual (SUM) | B | |||||||||
Records of Continuous Risk Management | P | U | U | U | U | U |
| U | U | |
Measurement Analysis Results |
| X | X | |||||||
Operational Concepts (part of "Mission Operations Concept" or separate) |
| P | U | U | B | U | ||||
Record of trade-off criteria & assessment (make/buy decision) |
| X | X | |||||||
Acceptance Criteria and Conditions |
|
| P | B |
Software Assurance and Software Safety | MCR | SRR | MDR | SDR | PDR | CDR | SIR | TRR | SAR | ORR |
---|---|---|---|---|---|---|---|---|---|---|
Software Assurance and Software Safety Plan(s) | P | P | P | B | U | |||||
Software Process Root cause analysis results | U | U | U | U | U | U | ||||
SA analysis showing uncovered software code percentage | P | U | U | U | U | |||||
SA audit and status reports | U | U | U | U | U | U | U | U | U | |
SA schedule | D | P | U | U | B | U | ||||
Requirements mapping table for the SA requirements. | P | B | U | U | U | |||||
Cost estimate for the project’s SA support. | D | P | U | U | B | U | ||||
Analysis showing software requirement and hazard control coverage | D | P | B | U | U | U | U | |||
SA Product Acceptance Criteria and Conditions | P | B | ||||||||
The defined SA processes for the SA activities on the project per the requirements in the Software Assurance and Safety standard. | P | U | U | B | U | |||||
The software training records for SA personnel on a project. | P | U | U | B | U | |||||
The list of all software safety-critical components that have been identified by the system hazard analysis. | P | U | U | U | B | U | ||||
The results of SA independent static code analysis results for cybersecurity vulnerabilities and weaknesses. | P | B | ||||||||
The results of SA independent static code analysis, on the source code, showing that the source code follows the defined secure coding practices. | P | B | ||||||||
SA metric analysis procedures. | P | U | U | B | U | |||||
Preliminary Hazard Analysis and software controls and mitigations (FHA / Hazard Reports / Hazard Analysis Tracking Index) | P | U | U | U | B | U | ||||
Software Safety Analysis | P | U | U | B | U | |||||
IV&V Project Execution Plan (IPEP) | B | U | U | U | U | U | U | U | U |
F = Final, D = Draft, P = Preliminary, B = Baseline, U = Updated/Updated as required, X = assume complete (final), not explicit in NPRs
MCR = Mission Concept Review, SRR = System Requirements Review, MDR = Mission Definition Review, SDR = System Definition Review, PDR = Preliminary Design Review, CDR = Critical Design Review, SIR = System Integration Review, TRR = Test Readiness Review, SAR = System Acceptance Review, ORR = Operational Readiness Review
2. References
2.1 References
- (SWEREF-041) NPR 7123.1D, Office of the Chief Engineer, Effective Date: July 05, 2023, Expiration Date: July 05, 2028
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-083) NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
2.2 Tools
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
3. Lessons Learned
3.1 NASA Lessons Learned
No Lessons Learned have currently been identified for this requirement.
3.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.