bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

7.13 - Transitioning to a Higher Class

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

Role

Responsibility

Technical Authority

Reviews and approves transition strategy, waivers.

Software Project Lead

Reviews requirements gap, documents transition strategy, writes waiver requests, carries out transition strategy.

Lead Software Author

Provides documentation, code, other artifacts, and insights into software considered for transition.

Project Manager

Decides budget and schedule resources associated with transition.

Software Assurance

Ensures transition strategy is carried out.

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 456 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.

Software Documentation

Class A
OR
Class A Safety Critical

Class B
OR
Class B and Safety Critical

Classes C through E and Safety Critical

Class C and NOT Safety Critical

Class D and NOT Safety Critical

Class F
(In-house)

Class G
(In-house)

Software Management Plan

1

1

1

1

1

1

1

Software Configuration Management Plan

1

1

1

1

1

1

1

Software Test Plan

1

1

1

1

1

1

1

Software Maintenance Plan

1

1

1



1

1

Software Assurance Plan

1

1

1

1


1

1

Software Safety Plan

1

1

1

1

1

1

1

Software Requirements Specification

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

Software Data Dictionary

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4


2, 3, or 4

2, 3, or 4

Software Design Description

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

Interface Design Description

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4


2, 3, or 4

2, 3, or 4

Software Change Request/ Problem Report

1

1

1

1

1

1

1

Software Test Procedures

2

2

2

2


2

2

Software Users Manual

2, 3, or 4

2, 3, or 4

2, 3, or 4



2, 3, or 4

2, 3, or 4

Software Version Description

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

2, 3, or 4

Software Metrics Report

1

1

1

1


1

1

Software Test Report

2

2

2

2


2

2

Software Inspection/Peer Review Report

1

1

1

1


1

1

Key:
1. Project already responsible for developing this document; it needs to address integration of the transitioning software.
2. Develop the document if it does not exist.
3. Modify the project/document to accommodate the transitioning software.
4. Incorporate existing document into the project.

Note: A blank cell indicates that the document does not need to be developed.

Classes E and H do not appear in the table since they are the lowest classifications. It is not possible to transition up to either of them. Documents with multiple keys allow for decisions to be made in the best interest of the project. A block with 2, 3 or 4 in it gives the project three options. For instance, a requirements document can be developed as a stand-alone document if it does not exist or the requirements can be included in another of the project's requirements documents or, if the requirements document exists, it can be directly incorporated into the project.

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.


Size of Existing Code


Size of Modifications

Small

Big

Small

Determine size of original code plus the modifications.

If the determined size is big, then:
Write new code from scratch, following Center procedures and project plans. Exit this process.

If the size is small, then:
1. Analyze and determine risk based on:
• Relative size of original code to mod size.
• Comparison of specialized resources needed/available.
• Reuse: reduced effort, but older language skills/maintenance required.
• Re-code: increased effort, but newer language skills/capabilities available.
• State of the original code: less of these items requires more resources to validate original code and assure to higher control level.
• Documentation available.
• Known reliability/applicability/readability.
2.Evaluate the risk.
• If the risk is acceptable, reuse original code. Perform mods if needed. Follow Center procedures and project plans. Continue with this process.
• If the risk is not acceptable, write new code from scratch, following Center procedures and project plans. Exit this process.

Reuse original code. Perform mods if needed. Follow Center implementations of NPR 7150.2 and project plans. Continue with this process.

Big

Write new code from scratch following Center procedures and project plans. Exit this process.

1. Analyze and determine risk based on:
• Relative size of original code to mod size.
• Comparison of specialized resources needed/available.
• Reuse: reduced effort, but older language skills/maintenance required.
• Re-code: increased effort, but newer language skills/capabilities are available.
• State of the original code.
(If few of these items exist, more resources are required to validate original code and assure to higher classification level.)
• Documentation available.
• Known reliability/applicability/readability.
2. Evaluate the risk.
• If the risk is acceptable, reuse original code. Perform mods if needed. Follow Center procedures and project plans. Continue with this process.
• If the risk is not acceptable, write new code from scratch. Exit this process.

7.3 Resources

  • (SWEREF-456)

    Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL, Tcl, and to some extent D.

7.4 Tools

Tools relative to this Topic 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.

No tools have been currently identified for this Topic. If you wish to suggest a tool, please leave a comment below.

  • No labels