1. Purpose

This document addresses guidance for projects that desire to transition software from a lower to a higher classification. This guidance is provided for Technical Authorities to use in determining:

• If the transition activity is within acceptable risk boundaries, e.g., intended use, resource constraints.
• And, if so,what strategy is needed to complete the transition to the higher classification.

1.1 Roles

1.2 Transition Categories

• Non-flight to non-flight (Class E -> Class D).
• Non-flight to flight (Class E -> Class C, Class B, or Class A; Class D -> Class C, Class B, or Class A).
• Flight to flight (Class C -> Class B or Class A; Class B -> Class A)

The greatest risk exists for software that crosses the flight boundary and for software making large transitions, so those projects should be analyzed with the greatest care.

2. Preparation

Before transition risk or a strategy can be determined, the Software Project Lead should work with the original author (if available) of the software to obtain the information, e.g., documentation, classification, upon which that determination will be based and make it available to the Technical Authority. Such information includes:

• Original software proposed for transition.
• Artifacts of original software development.
• Description of new environment/project where transitioned software will be used.

3. Process Overview

This process diagram includes the roles with primary responsibility for carrying out each activity or decision. While the named roles have primary responsibility for the activity, the actual completion of the activity will involve other roles as needed or in compliance with Center standards.

4. Determine Preliminary Transition Risk

Before choosing a transition strategy, it is important for the Technical Authority to determine if the transition effort is within acceptable risk boundaries or if new development is a less risky solution. The following questions should be considered when evaluating transition versus new development solutions. Some of these topics are addressed in more detail in later analysis steps.

1. Is this a new project, midstream change of an existing project, or transition of an older, completed project?
2. What was the classification and safety criticality of the software to be transitioned? What is the higher classification and safety criticality?
   1. A larger gap, e.g., non-safety-critical Class E to safety-critical Class B, means a larger number of new requirements to fulfill.
   2. The larger the gap, the more likely that the new requirements will need to be met, as opposed to being tailored or waived.
   3. If the gap is too large, e.g., non-safety-critical Class E to safety-critical Class A, the amount of work to close the gap may simply be too large to consider, and transitioning is not a viable option.
3. Will the software operate in a different environment at the higher classification? If so, is the software appropriate to be used in the new environment? If so, what changes are needed to support this environment (hardware and software interfaces, etc.)?
4. Do software artifacts/documentation exist, and can they be built upon for the transitioned software or must artifacts/documentation be created from scratch?
5. Do personnel have sufficient knowledge and skills related to the prior development to support a transition effort? What additional training is needed?
6. What are the tradeoffs of coding from scratch versus transitioning the existing work?
7. Does this preliminary assessment cause the transition to fall outside the bounds of acceptable risk, which would result in abandonment of the transition?

5. Determine Requirements Gap

Once the Technical Authority has deemed that the transition effort is within acceptable risk boundaries, the Software Project Lead has the following primary responsibilities:

• To ensure the project begins to adhere to the requirements for the higher classification and safety criticality, as this will begin to reduce the existing requirements gap.
• To determine the NPR 7150.2 requirements gap between the original software classification and safety criticality and the higher classification and safety criticality.

The requirements gap is input to the transition strategy activity described below.

To determine the requirements gap, use the NPR 7150.2 compliance matrix to determine:

1. Which requirements were met by the software when it was developed.
2. Which requirements must be met for the higher classification and safety criticality.
3. Which requirements that were met in the original software must be met at a more rigorous level at the higher classification.

6. Determine Transition Strategy

Once the NPR 7150.2 requirements gap has been determined, a strategy for accomplishing the transition needs to be developed and documented. The Software Project Lead should develop this strategy with input from the Software Assurance organization that will be part of the group responsible for ensuring the transition strategy is carried out. Development of the transition strategy may involve a requirement by requirement review. Additionally, review and approval of the strategy and the associated risk are the responsibilities of the Technical Authority.

During this process, new information may be identified that shows the transition risk is no longer acceptable. In that case, the Technical Authority can determine that transition is no longer within the acceptable risk boundaries and stop the transition attempt.

The questions below should be considered when establishing the transition strategy.

6.1 Evaluation of Additional Requirements

1. Which requirements become more significant at the higher classification? Consider:
   1. Safety requirements.
   2. Risk reduction requirements.
   3. Software assurance requirements.
   4. Requirements for reaction to adverse conditions (data, system, environmental, etc.).
   5. Requirements for required functionality.
   6. Other.
2. Which requirements are candidates to be waived?
   1. What are the tradeoffs of not doing the higher level requirement(s)?
   2. What are the risks of doing/not doing the higher level requirement(s)?
   3. What requirements do not make sense to retroactively fulfill or provide little added value, e.g., related to phase of project development?
3. Which requirements will be tailored?
   1. Which requirements must be retroactively applied, e.g., peer reviews, and which requirements will be applied only to remaining work, e.g., cost estimates? 
4. Process-related requirements, e.g., configuration management and planning, should already be met but should be checked to confirm completeness for higher level classification requirements.
   1. Are there products that need to be placed under configuration management that were not for the lower class?
   2. Is the schedule and cost estimate up to date and detailed enough for the higher level classification?
   3. What new metrics need to be collected to meet requirements as well as to benefit future transition efforts?
   4. What processes need to be updated to meet the higher classification requirements, e.g., peer reviews, stakeholder reviews, audits?
5. Does this effort cause the transition to fall outside the bounds of acceptable risk?

6.2 Documentation Needed

1. What is state/status of existing documentation?
   1. Review documents as well as existing change requests, inspection/peer review reports, etc., to determine state and quality of documentation.
   2. What new material/content and revisions will be necessary to meet the higher requirements?
   3. To what depth will the new content need to go to meet the higher level requirements?
2. What new documentation will be required to meet all of the higher requirements and to what depth/rigor?
3. Does this effort cause the transition to fall outside the bounds of acceptable risk?

6.3 Software Modifications Needed

1. What is the status of the software? Can it be used "as is," or do parts of the software require modification?
   1. Review existing change requests, inspection/peer review reports, test reports, etc., to determine state and quality of software.
   2. What code (to meet new requirements such as redundancy) or documentation (design, comments, etc.) must be added to fulfill the higher requirements? What is the size of anticipated code modifications versus original code size? Note: If size of modifications is significantly greater than size of original code, risk could be higher than coding from scratch.
   3. What new standards, e.g., coding standards, must be implemented/met by the code to fulfill the higher requirements?
   4. What non-essential code ("bells and whistles," test hooks, "dead" code, etc.,) should be removed to conform to higher level requirements?
   5. If not already performed or data is not current, conduct static analysis to identify existing errors in the code, identify missing pieces of the code, generate complexity data, etc.
2. What is the status of the verification and validation (V&V) activities?
   1. Has V&V been performed on the software to be transitioned?
   2. Are existing V&V results invalidated by the new environment or application?
   3. What new or revised/more rigorous V&V activities (analysis, tests, results documentation, etc.) will be needed to fulfill the higher requirements?
   4. Are there areas of the project that are more safety critical or higher risk and that will require focused V&V effort at the higher level classification?
   5. If code modifications are needed, what V&V activities are required for those modifications?
3. Does this effort cause the transition to fall outside the bounds of acceptable risk?

6.4 Resources Needed

1. What resources (people, time, budget, etc.) are available for the transition effort?
   1. Are there tools and/or methods/techniques that could reduce the required effort and still provide the appropriate level of documentation? Some examples are:
      1. Doxygen ⁴⁵⁶ to document design of existing code.
      2. Model-based tools to check requirements completeness.
      3. Model-based tools to check design completeness.
   2. In-house personnel or contractors, i.e., are new or renegotiated contracts or internal agreements needed to support the transition effort?
2. What additional resources are needed?
   1. What additional personnel are needed, e.g., software assurance, IV&V, etc.?
   2. What new tools and/or equipment are needed, e.g., for V&V?
   3. Are any new skills needed, e.g., new tools or coding techniques, to meet higher level requirements?
3. Do the resource needs cause the transition to fall outside the bounds of acceptable risk?

7. Resources

7.1 Reference Documentation Table

This table provides guidance on what documentation a project will need to develop for software that will be reused, in whole or in part, from a previous development effort. The documentation to be developed depends on the classification of the project that will be using the software and on decisions made by the project as to which documents are necessary, based on NASA Center procedures.

7.2 Reference Code Size Decision Chart

Decision making for software transition involves detailed investigation of the subject code and of the resources available to apply to its modification or rebuilding. The following chart provides some guidance with respect to code size, noting that Modification Size should only reflect modification within the original code, not any code to which the original software will be linked. This table should be tailored even further, depending on the nature of the code's language, local experience with the programming languages involved, and availability of alternate language development resources.

7.3 Resources

7.4 Tools