bannerb

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed / removed references to Classification Tool

...

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Div
idtabs-1

1. Requirements

3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, F, G, and H software in Appendix D.

1.1 Notes

The expected applicability of requirements in this directive to specific systems and subsystems containing software is determined through the use of the NASA-wide definitions for software classes in Appendix D and the designation of the software as safety critical or non-safety critical in conjunction with the Requirements Mapping and Compliance Matrix in Appendix C. These definitions are based on: (1) usage of the software with or within a NASA system, (2) criticality of the system to NASA’s major programs and projects, (3) extent to which humans depend upon the system, (4) developmental and operational complexity, and (5) extent of the Agency’s investment. Software classification tool details are defined in NASA-HDBK-2203.

1.2 Applicability Across Classes

Applicable b
a1
b1
csc1
c1
d1
dsc1
e1
f1
g1
h1

Div
idtabs-2

2. Rationale

Classifying software provides essentially pre-tailoring of software engineering requirements, software safety requirements, software assurance requirements and other software requirements for different types and levels of software.  While every requirement may be applicable to the highest classification, not every requirement will be applicable to lower level classifications.

Div
idtabs-3

3. Guidance

Some projects may contain multiple systems and subsystems having different software classes. Appendix C in the NPR defines the default applicability of the requirements based on software classification and safety criticality. The applicability of NPR 7150.2 requirements is determined using the Requirements Mapping and Compliance Matrix in Appendix C of the NPR using the software class definitions in Appendix D of the NPR and the software’s safety criticality designation. Important to classification are the usage of the software with or within a NASA system, criticality of the system to NASA’s major programs and projects, extent to which humans depend upon the system, developmental and operational complexity, and extent of the Agency’s investment.

Complete the classification of software as soon as it has been determined that a project includes software. Both the software development organization in conjunction with the project office and software assurance independently classify software and, as stated in the NPR 7150.2 note for this requirement, “Software management and software assurance must reach agreement on classification of systems and subsystems. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.”

When classifying software be sure to consider:

  • All software for the system or subsystem (classification may need to be assessed separately).
    Swerefn
    refnum278
  • Purpose for the software.
  • How the software is intended to be used.
  • Relevance to major programs and projects.
  • Hardware controls.
  • Operations.
  • Interaction with humans.
  • Complexity (developmental and operational complexity is woven into the class definitions).
  • Risk to the project, Center and Agency
  • Investment.

If a software component is determined to be safety critical software, then the software component classification must be Software Class D or higher.

“Projects utilizing commercial, government, legacy, heritage, and MOTS software components typically take into consideration the importance of planning and managing the inclusion of those components into the project software... When software components use COTS applications (e.g., spreadsheet programs, database programs) within a NASA system/subsystem application, the software components typically are assessed and classified as part of the software subsystem in which they reside. Note that commercial, government, legacy, heritage, and MOTS software also have to meet the applicable requirements for each class of software.”

Swerefn
refnum039
 The commercial, government, legacy, heritage, and MOTS software components are verified and validated to the same level required to accept a similar developed software component for its intended use. The project needs to ensure that the COTS, MOTS, government off the shelf (GOTS), reused, and auto generated code software components and data meet the applicable requirements in this directive and as assigned to its software classification as shown in Appendix C
Swerefn
refnum039
.  

A no-cost classification tool is available to help organizations classify software. Section See Classification Guidance in Topic 7.2 - Classification Tool and Safety Critical Assessment Tool of this handbook contains an introduction to the tool and its current Web address. This tool is just a first step in classifying software, but can be useful when starting the process because the results from the tool and the supporting rationale can be printed and included in classification documentation-Criticality for determining the classification of software. Final classification of software occurs through project agreement with the independent check performed by the Software Assurance organization (see SWE-132). In the event of a conflict, the designated Software Engineering Technical Authority facilitates a resolution between the project and the Center Safety and Mission Assurance Organization, if possible. Note that software is not to be mis-classified to reduce requirements on small or higher risk missions. In these instances, a waiver request for reduced requirements submitted to the Engineering Technical Authority is the recommended course of action.

As a project progresses the software classification is revisited since design and usage decisions may be made which alter the original classification. The software classification should be reviewed and validated at each major project review or major change to determine if the existing classification is appropriate for the proposed use of the software in the system. For example, a research project may be so successful during development and testing that a decision is made to take the system out of the research laboratory and directly to the field for use in a real-world environment. This decision alters the software classification and, therefore, the engineering, safety, and assurance requirements associated with it.

Panel

When questions arise regarding software classification, consult the Engineering Technical Authority (TA).

Note

NASA users should consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to classifying software.

NASA-specific software classification information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.

 Additional guidance related to classifying software may be found in the following related requirement in this Handbook:


Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects.

Div
idtabs-5

5. Resources

 
refstable

toolstable

Div
idtabs-6

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.