bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

The license could not be verified: License Certificate has expired! Administrators, please check your license details here.

SWE-020 - Software Classification
Unknown macro: {div3}

1. Requirements

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

1.1 Notes">1.1 Notes

The applicability of requirements in this NPR to specific systems and subsystems containing software is determined through the use of the NASA-wide definitions for software classes in Appendix E and the designation of the software as safety-critical or non safety-critical in conjunction with the Requirements Mapping Matrix in Appendix D. 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. The NPR allows software written to support development activities (e.g., verification software, simulations) to be classified separately from the system under development; however, such support software is usually developed in conjunction with the system and not as a separate project. Projects may decide to reuse processes and work products established for the development of the system to satisfy the NPR 7150.2 requirements for the support software. The software assurance organization will perform an independent classification assessment and the results will be compared as per NASA-STD-8739.8, Software Assurance Standard. 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. The classification decision is documented in the Software Development or Management Plan as defined in Chapter 5.

1.2 Applicability Across Classes

Appendix D of NPR 7150.2 does not include any notes for this requirement.

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

   

   

   

Key:    A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

2. Rationale

The definitions of the different classes of software which are defined in NPR 7150.2 Appendix E, along with the Requirements Mapping Matrix in NPR 7150.2 Appendix D, provide a built-in method of tailoring software requirements.  Classifying software essentially provides 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 (Class A), not every requirement will be applicable to lower level classifications.

Unknown macro: {div3}

3. Guidance

Complete classifying software as soon as it has been determined that a project includes software.  Both the project 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. The classification decision is documented in the Software Development or Management Plan ..."

When classifying software be sure to consider:

  • All software for the system or subsystem (classification may need to be assessed separately2)
  • How the software is intended to be used
  • Relevance to major programs and projects
  • Interaction with humans
  • Safety criticality (see "Safety-Critical Software Determination" in the NASA Software Safety Standard)
  • Complexity (developmental and operational complexity is woven into the class definitions)
  • Investment

A no-cost classification tool is available to help organizations classify software.  Section 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.  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. Care should be taken to properly classify software, since mis-classification will result in missed requirements that will eventually be discovered (at reviews, during testing, etc.), resulting in greater cost and/or the submission of waivers to the Engineering Technical Authority.

As a project progresses the software classification is revisited since design and usage decisions may be revised which alter the original classification (see [SWE-021]). 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 the associated engineering, safety, and assurance requirements needed to fulfill the increased level of rigor and ensure delivery of a safe, quality product.   

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

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to classifying software.

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

[SWE-021]

Transition to a Higher Class

[SWE-132]

Independent Software Classification Assessment

[SWE-133]

Software Safety Determination

Topic 7.2

Classification Tool and Safety Criticality Assessment Tool


Unknown macro: {div3}

4. Small Projects

There is currently no guidance for this requirement specific to small projects.

Unknown macro: {div3}

5. Resources

  1. NASA Technical Standard, "NASA Software Safety Standard", NASA-STD-8719.13B, 2004.
  2. NASA Technical Standard, "NASA Software Assurance Standard", NASA-STD-8739.8, 2004.
  3. Software Engineering Process Group, Glenn Research Center, "Software Project Planning", GRC-SW-7150.3, Revision C, 2011.
  • (SWEREF-083) NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
  • (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
  • (SWEREF-271) NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07
  • (SWEREF-278) NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
  • (SWEREF-332) Software Project Planning, GRC-SW-7150.3, Revision C, Software Engineering Process Group, NASA Glenn Research Center, 2011. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook. Note: Revision Mark-up visible on this version.

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.

Unknown macro: {div3}

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.

  • No labels

0 Comments