2. Rationale

Software systems are often designed using existing components from other systems. It is recognized that reusing existing software components can help achieve the resulting system more quickly and at lower cost. However, for software components to be truly reusable, reusability needs to be part of the planned initial development of those components.

3. Guidance

“’30 Pitfalls for Real-Time Software Developers,’ by David B. Stewart discusses problems faced by real-time developers. Of the problems he considers, the following are especially applicable to safety and reliability: ...Reusing code not designed for reuse. If the code was not designed for reuse, it may have interdependencies with other components. Usually, it will not use abstract data types (if object-oriented) or have a well-defined interface.” ²⁷⁶

With the focus on software reuse increasing, projects need to plan for future reuse of developed software by specifying requirements that facilitate the software reuse in the future.  These requirements enhance the benefits of reuse and address the known pitfalls of reuse where that is possible.  These requirements, which should be captured as early in the life cycle as possible, address development processes as well as project technical requirements and are captured in project documentation such as the software development/management plan for processes, project coding standards, and the requirements document or repository for technical requirements.  The software reuse related requirements are included as a part of the normal software requirements review process and verification & validation process.

Key focus areas of project reusability requirements support SWE-027 and a general strategy for future product reuse, including:

• Documentation associated with the software’s fulfillment of its purpose (e.g., usage instructions).
• Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights.
• Future support for the software.
• Any documentation to allow the software component to be verified and validated to the same level required to accept a similar developed software component for its intended use.
• Ability to perform periodic assessments of developer-reported defects to ensure the defects do not impact the reused software components.

If the goal is to reuse a product that will exist in the government inventory, such as the Agency Software Catalog accessible via the NASA Technology Transfer Portal, the following are key items to address in reusability requirements ⁴⁸⁶ :

• Technical information to support determination of whether the product meets the technical requirements of future projects.
• Supporting documentation and user manuals’ for future projects.
• Products to enable test, operations, and maintenance support and disposal services.
• Assistance or documentation needed to support future requests for acquiring the product from Government sources.

“Use of ... reused software that is not developed specifically for the safety critical system can be risky.  Software in this category includes ... previously created software (e.g., from a past project).  It is important to evaluate the differences between how the ... reused software will be used within the new system, and how it was used in previous systems.  The differences in operational constraints or configuration of the software may affect the operation of the ... reused software, sometimes in unexpected ways.” ²⁷¹ For this reason, reusability requirements should address documentation, code comments, design documentation, manuals, drawings, etc. to make this reuse assessment easier for future projects.

Given that reused software will likely require software to integrate it into the system under development, it is important for reusability requirements to address any aspects of the developed software that will facilitate or reduce the effort to integrate the reused software components with other parts of the developed system.

Additional considerations when generating reusability requirements include:

• Capture of hazard analyses performed on reused software for assessing the safety aspects of that software for use in safety-critical systems. ²⁷⁶
• Information needed to integrate the software into a system, such as interface documentation, industry standards conformance, and how the software interacts within itself (between modules) and with the outside world (its application program interface (API)). ²⁷⁶
• Availability of source to allow future safety analyses to be performed and to better understand how the software actually works. ²⁷⁶
• Information about the software development process used to create the software, including meeting any specific development standards, development tools used to create and test the software. ²⁷⁶
• Information about the testing process used to verify the software, including types of tests performed, availability of test reports and any additional information to help future project gauge the thoroughness of the testing. ²⁷⁶
• Information on defects, including known bugs and unresolved problems, important to help future users make decisions about reusing the software. ²⁷⁶
• Future use or need for analyses performed on the software. ²⁷⁶
• Documentation of error codes returned by the software, how it can fail (return error code, throw an exception, etc.), and information regarding function checks on input variables for proper range. ²⁷⁶
• Information on the internals of the software, such as the complexity of the various software modules or the interfaces between the modules to support future analyses to be performed on the OTS software. ²⁷⁶
• Information regarding “turning off” any of the functionality in the software component, such as recompiling the source code with defined switches or stubs to remove the extra functionality. ²⁷⁶
• Information on to help developers understand what happens to their developed system if an unneeded function in the reused component is accidentally invoked. ²⁷⁶
• Information on any “back doors” (that could be exploited to create a security problem.) ²⁷⁶

Reusability requirements should address the availability of the following documents for future development projects: ²⁷⁶

• Design documentation.
• Source code.
• Development tools.
• Configuration files, setup files, etc. needed to configure the development tools.
• User documentation.
• Simulators or models developed for use with the operational software.
• Test software, procedures, reports.
• SA reports.
• Formal inspection reports.

Additional guidance related to reusability may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects. 

5. Resources

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.

6. Lessons Learned

The NASA Lessons Learned database contains the following lesson learned related to bidirectional traceability:

• Reuse of Analysis Software. Lesson Number 2158: “When a project plans to reuse existing metrology software for a new application, a thorough independent review of the software and its new interfaces should be conducted." ⁵⁹²
• Software Design for Maintainability. Lesson Number 838:” By designing software products that are maintainable we can update and enhance fielded software much faster and at lower cost. Software can be reused, thus alleviating costly update time. Also, any faults found in the software can be easily diagnosed and corrected, reducing downtime and meeting delivery schedules. Software maintainability ensures system availability by reducing system downtime.” ⁵²⁶