2. Rationale

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.

3. Guidance

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.

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, if any, the team needs to repeat 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 that 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.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

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.

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.