1. Requirements

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 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, and 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

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 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 lifecycle 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 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?

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