1. Requirements

2.1.5.6 Center Director, or designee, shall maintain a reliable list of their Center’s programs and projects containing Class A, B, C, and D software. The list should include: 

a. Project/program name and Work Breakdown Structure (WBS) number.
b. Software name(s) and WBS number(s).
c. Software size estimate (report in Kilo/Thousand Source Lines of Code (KSLOCs)).
d. The phase of development or operations.
e. Software Class or list of the software classes being used on the project.
f. Software safety-critical status.
g. For each Computer Software Configuration Item (CSCI)/Major System containing Class A, B, or C software, provide:

(1) The name of the software development organization.
(2) Title or brief description of the CSCI/Major System.
(3) The estimated total KSLOCs, the CSCI/Major System, represents.
(4) The primary programming languages used.
(5) The life cycle methodology on the software project.
(6) Name of responsible software assurance organization(s).

1.1 Notes

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

1.2 History

2. Rationale

NASA Centers maintain an inventory of software projects worked at their Center to facilitate strategic decisions based on actual data at the Center and Agency levels. The NASA Office of the Chief Engineer (OCE) (in coordination with the Chief of the Safety and Mission Assurance (S&MA) Office) works with the Centers to provide the data needed to address external and internal Agency software inquiries. The rationale and uses of this Software Inventory include:

1. The Center Software Inventory data supports Engineering and S&MA Technical Authorities' duties by cataloging the classification of software on projects and whether it is safety-critical.
2. The Center Software Inventory data support the OCE in helping to determine whether the Centers' software engineering capabilities are commensurate with their responsibilities.
3. The Center Software Inventory data provides an accurate profile of critical software (Class A, B, C, and D) across the Agency to facilitate strategic decisions based on real data.
4. Center S&MA personnel utilize the Center’s Software Inventory data to help identify projects and assure they are covered and have been assessed for safety-critical software and software assurance.
5. The Center Software Inventory data provides NASA with current software data for decision-making.

3. Guidance

3.1 List of Software Development Activities

Each Center is responsible to maintain a current list of software development activities ongoing and in maintenance at their Center. The inventory can be maintained on any system that the Center decides.  The center inventory data should be able to be provided to the OCE if requested in an electronic format. Periodically the Office of the Chief Engineer (OCE) issues requests to the Centers for an update to the inventory of software projects under their purview. Guidance on the information required on projects containing Class A, B, C, and D software is as follows:

1. Project/program name and Work Breakdown Structure (WBS) number – Include the project name and WBS number, the WBS number generally will be the charge code number for the project.
2. Software name(s) and WBS number(s) – Software component names and WBS numbers if multiple names and WBS numbers are used on a project.  The software name may be the same as the project name.
3. Software size estimate (report in Kilo/Thousand Source Lines of Code (KSLOCs)) - Report SLOC estimates until actual SLOC numbers are available.  Use a standard available code counting tool to determine SLOC numbers after the source code is available.  Use a code conversion method if code is being auto-coded or being developed from a model.
4. The phase of development or operations – Phase related to NPR 7120.5 life cycle phases
5. Safety-Critical Software (Yes or No) - use the software safety-critical determination process, defined in NASA-STD-8739.8, to determine if the software is safety-critical.  Multiple software components on a given project may have different criticalities.
6. Software Class or list of the software classes being developed on the project. - use the software classification guidance in Topic 7.02 - Classification and Safety-Criticality to determine the software classification.  Multiple software components on a given project may have different classifications.
7. For each Computer Software Configuration Item (CSCI)/Major System containing Class A, B, or C software, provide:
1. 1. 1. 1. The name of the software development organization – What organization(s) are developing the software component?
         2. Title or brief description of the CSCI/Major System – Name of each software component.
         3. The estimated total KSLOC the CSCI/Major System represents - Report SLOC estimates until actual SLOC numbers are available.  Use a standard available code counting tool to determine SLOC numbers after the source code is available.  Use a code conversion method if code is being auto-coded or being developed from a model.
         4. The primary programming languages used (e.g., C, C++, Java, LabVIEW, others …)
         5. The primary life cycle methodology being used on the software project (e.g., waterfall, agile, spiral, others …)
         6. Name of responsible software assurance organization(s) – Which office is responsible for performing software assurance activities on each software component?

See also Topic 7.04 - Flow Down of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects, 

3.2 Additional Guidance

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

3.3 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

All software developed, acquired, or being maintained by NASA is included in the inventory. The size of the project is not used as a discriminator for the inclusion of project data in the inventory.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

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

6.2 Other Lessons Learned

 As part of its 2003 audit report on IV&V software, the Inspector General (IG) included this recommendation: "The NASA Chief Engineer, in coordination with the Associate Administrator for Safety and Mission Assurance, should establish a process that provides the NASA IV&V Facility, on a recurring basis, a complete and accurate list of the Agency's programs and projects governed by either NASA Procedures and Guidelines 7120.5A ⁰⁸² or NASA Technical Standard 8719.13A ²⁷¹."