This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
3.5.4 If a system or subsystem evolves to a higher or lower software classification as defined in Appendix D, or there is a change in the safety criticality of the software, then the project manager shall update their plan to fulfill the applicable requirements per the Requirements Mapping and Compliance Matrix in Appendix C and any approved tailoring.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.
Software projects that start out at a low classification, such as a Class E research project, but at some point after project start are reclassified to a higher classification, need to adhere to the NPR 7150.2 software engineering requirements for the higher classification. Valid transition situations include a lower engineering class (Class E) to a higher engineering class (Class C), a lower business class (Class H) to a higher business class (Class F); an invalid transition would be a business class (Class F) to an engineering class (Class D) transition. This requirement is to ensure that the resulting product does not present safety or other critical issues when delivered and operated.
In some instances, transitions may only involve the software engineering classification "A" through "H" (i.e., unchanged safety criticality). Even when safety criticality and hazards are not a factor, transitioning to higher engineering classes needs careful attention. Usually this will involve one or more of the following aspects: (1) Change in usage of the software; (2) extent to which humans depend upon the systems; (3) increases in the Agency's investment related to the software; or (4) increases in complexity. Examples include moving software from use in a laboratory environment to a spaceflight vehicle; from a robotics spacecraft to a human-rated space vehicle; or from a local general purpose computer application to one supporting multiple Centers or Agency-wide. It's important to note that not only does the coverage of additional NPR 7150.2 requirements need to be assessed via the project's original compliance matrix, but other considerations also need to be addressed as part of the transition strategy:
- Evaluate whether the rigor applied in meeting NPR requirements for software under the lower classification is still adequate for the new setting. This is particularly important with respect to NPR 7150.2's reviews and testing requirements.
- Revisit any waivers/deviations granted to the original software application. A new or modified waiver may need to be approved.
- Establish a gaps list to determine what was performed vs. what would have been performed if the increased classification was known from the start.
- Determine if the transition activity is within acceptable risk boundaries. This may include a formal risk and hazards analysis conducted by a software assurance and safety professional.
- Revisit and update the Software Development/Management Plan if there are major gaps and changes. If relatively minor, revisit and update the Software Maintenance Plan.
- Assess the value of repeating completed work so that it meets the requirements of the higher classification versus the risk to the overall project of not repeating some or all of that work.
- Determining whether additional resources (people, time, budget, etc.) are needed to carry out the transition.
For significant changes in software engineering classification, it is not unusual to need the help of the Center Engineering Technical Authority, or even the Headquarters' Engineering Technical Authority. In addition to NPR 7150.2 requirements, it's also likely that Technology Readiness Levels (TRLs) in NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, Appendix J (software description), will need special attention.
The Technical Authority (TA):
- Reviews and assesses the project's evaluation of risk and hazards.
- Reviews and assesses the project's strategy to transition to a higher classification.
The TA, Software Project Lead, original software author(s), and software assurance personnel work together, where appropriate, to:
- Obtain information upon which the transition risk and strategy can be determined.
- Evaluate transitioning the software vs. developing a new solution.
- If transitioning, determine the NPR 7150.2 requirements gap between the original classification and safety criticality (see SWE-020 for a discussion of the relationship between classification and safety criticality) and the higher classification and safety criticality.
- Determine the transition strategy.
Guidance for each of these activities is described in this section of the Handbook: 7.13 - Transitioning to a Higher Class.
The guidance topic noted above addresses risk considerations when transitioning a project, but the project plans all need to be updated appropriately based on the chosen transition strategy. Keeping plans current with the project's classification ensures proper management visibility as well as project accountability for the effects of the classification change.
When a necessary plan forward is established, it needs to be funded and carried to completion to ensure the resulting software is sufficiently robust for use in the context of the increased classification.
Additional information and resources regarding classification transitions to a higher class are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
4. Small Projects
This requirement applies to projects, regardless of size, unless a waiver is granted by the appropriate TA.
Projects with limited financial or personnel resources need to carefully analyze what work the team needs to perform for a transitioned project. For example, if a project has completed the design phase and then the decision is made to transition that project to a higher classification, all completed work through the design phase needs to be assessed to determine how much of that work fails to meet the requirements of the higher classification. A small project with limited personnel or financial resources needs to weigh the value of repeating or performing work to meet the higher classification requirements against the risk to the overall project of having requirements and design that does not meet the requirements of the higher classification. The result of this analysis may provide the basis for the project to reduce or eliminate some of the transition effort. Keep in mind, however, that all projects, regardless of size, will require waivers for any unmet requirements.
Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.
POC: Matt Sharpe, Alex Eiser, Bill Van Dalsem (all from Ames)
Objective: System to enable Ames' software management processes. Notes: "Living" and historical databases of all of Ames' software projects; enables online recommendation, review, and approval of software classifications (engineering and S&MA assurance/safety); repository for detailed software project data needed to support the Ames software engineering management processes. NPR 7150.2A records retention requirements and NASA Software Inventory. For more information, see the presentation given by Ames at the March, 2011, NASA SWG Face-to-Face (slides 9-13), available from the NSCKN site (Click the link to the left and log into NSCKN)
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.