bannerc
SWE-176 - Software Records

1. Requirements

3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessment for the life of the project. 

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

SWE-176 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

N/A

B


Difference between B and C

NEW

C

3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessment for the life of the project. 

Difference between C and DNo change
D

3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project. 



1.3 Applicability Across Classes

 

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable

2. Rationale

The project manager is required to maintain the following records for the life of the project.

(1) Each software classification determination performed by the project manager,
(2) Each project software requirements mapping matrix
(3) The results of each software-independent classification assessment by S&MA.

It is important to maintain the records of the software classification and the resulting logic for the classification since the NPR 7150.2 requirements that need to be satisfied for the software are dependent on the software classification. The software requirements mapping matrix will contain the records of any approved tailoring of the requirements. The combination of these records determines exactly what requirements the project will need to satisfy and that information needs to be communicated to everyone on the project.

The records of the logic for the software classification are important so they can be reviewed as the project requirements change and used to help determine whether there has been sufficient change to merit a change in software classification.

Records maintained by the project manager can also be used during the Office of the Chief Engineer (OCE) survey activity (see SWE-129 ) for evaluating compliance and software classification assessments. 

3. Guidance

The following records are maintained throughout the life of the project.

(1) Each software classification determination performed by the project manager,

The project completes the determination of software classification (see SWE-020 ). 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.

(2) Each project software requirements mapping matrix

A requirements mapping matrix typically lists all of the NPR 7150.2, NASA Software Engineering Requirements, requirements applicable to a project's software, along with the planned approach for demonstrating compliance. As projects can contain multiple classes of software, a project software requirements matrix with this NPR is created for each software class.

(3) The results of software classification determination by S&MA.

If an independent assessment is needed by S&MA, S&MA will complete the assessment and compare the results to the engineering assessment and work with the TAs to resolve any differences.

These records can be used in the OCE survey of a Center's processes and directives and thorough examinations of a project's official records. These surveys are one of the tools used by the OCE to provide oversight, maintain internal control, and review its operations. 

The software classification and safety criticality should be reexamined periodically, for example, whenever there are major requirement changes, and at major milestone review points.

The location of the records above should be listed on the project's data management list along with the record of the software safety criticality. The Software Management/Development Plan may list the initial determinations of the software classification and safety-critical and then point to the location of the data management list or the most up-to-date information.

When classifying software be sure to consider:

  • All software for the system or subsystem (classification may need to be assessed separately).
  • The purpose of 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).
  • The risk to the project, Center, and Agency
  • Investment.

If a software component is traceable to a hazard and is determined to be safety-critical software, per the software safety-critical determination process defined in NASA-STD-8739.8, then the software component classification must be Software Class D or higher.

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 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

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

SWE-176 - Software Records
3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessment for the life of the project. 

7.1 Tasking for Software Assurance

  1. Confirm that records of the software Requirements Mapping Matrix and each software classification are maintained and updated for the life of the project.

7.2 Software Assurance Products

  • Software Classification Determination 
  • Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric)


    Objective Evidence

    • NPR 7150.2 and NASA-STD-8739.8 requirements mapping matrices signed by the engineering and SMA technical authorities for each development organization.

    Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

    • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
    • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
    • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
    • Signatures on SA reviewed or witnessed products or activities, or
    • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
      • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
      • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
    • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  •   % of Total Source Code for each Software Classification (*organizational measure)
  • Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational measure)

7.4 Guidance

An independent software assurance classification assessment is not required but can be done if needed by your center processes. Software engineering and software assurance must reach an agreement on the classification of systems and subsystems.  Software assurance can just concur with the software engineering classification if they agree with the classification. If an independent software assurance classification is done, that record along with the rationale for the classification should be kept.

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 is the usage of the software with or within a NASA system, the criticality of the system to NASA’s major programs and projects, the extent to which humans depend upon the system, developmental and operational complexity, and the 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 classify software and, as stated in the NPR 7150.2 note for this requirement, Software engineering and software assurance must reach an agreement on the classification of systems and subsystems. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.

Guidance: When classifying software be sure to consider:

  • All software for the system or subsystem (classification may need to be assessed separately).   
  • Purpose of 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).
  • The risk to the project, Center, and Agency Investment.

If a software component is traceable to a hazard and is determined to be safety-critical software, per the software safety-critical determination process defined in NASA-STD-8739.8 278,  then the software component classification must be Software Class D or higher. When classifying software be sure to consider:




  • No labels