bannerd


SWE-147 - Specify Reusability Requirements

1. Requirements

3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.

1.1 Notes

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

1.2 History

SWE-147 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

NEW

B

3.14.2 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including models used to generate the software.

Difference between B and CChanged "used to generate the software" to "simulations, and associated data used as inputs for auto-generation of software, for United States Government purposes."
C

3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for United States Government purposes. 

Difference between C and DEditorial fix: 'United State' became 'U. S.'
D

3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


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 a 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

3.1 Reusing Code

“’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.

30 Pitfalls for Real-Time Software Developers

#25 Reusing code not designed for reuse
Code that is not designed for reuse will not be in the form of an abstract data type or object. The code may have interdependencies with other code, such that if all of it is taken, there is more code than needed. If only part is taken, it must be thoroughly dissected, which increases the risk of unknowingly cutting out something that is needed, or unexpectedly changing the functionality. If code isn’t designed for reuse, it’s better to analyze what the existing code does, then redesign and re-implement the code as well-structured reusable software components. From there on, the code can be reused. Rewriting this module will take less time than the development and debugging time needed to reuse the original code.
481

3.2 Planning For Reuse

With the focus on software reuse increasing, projects need to plan for future reuse of developed software by specifying requirements that facilitate 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 - Use of Commercial, Government, and Legacy Software 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 is 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.

See also SWE-219 - Code Coverage for Safety Critical Software

3.3 Software Catalog of Reusable Code

If the goal is to reuse a product that will exist in the government inventory, such as the Agency Software Catalog (see also, SWE-148 - Contribute to Agency Software Catalog. )  accessible via the NASA Technology Transfer Portal, the following are key items to address in reusability requirements 041 :

  • Technical information to support the 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 is needed to support future requests for acquiring the product from Government sources.
NASA Software Safety Standard - NASA STD 8719.13 (Rev C )

“Use of ... reused software that is not developed specifically for the safety-critical system can be risky.  The 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.” 271

3.4 Reusability Requirements

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, reusability requirements need 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:

  • The capture of hazard analyses performed on reused software for assessing the safety aspects of that software for use in safety-critical systems. 276
  • Information is needed to integrate the software into a system, such as an interface documentation, industry standards conformance, and how the software interacts within itself (between modules) and with the outside world (its application program interface (API)). 276
  • Availability of source to allow future safety analyses to be performed and to better understand how the software works. 276
  • 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. 276
  • 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 projects gauge the thoroughness of the testing. 276
  • Information on defects, including known bugs and unresolved problems, is important to help future users make decisions about reusing the software. 276
  • Future use or need for analyses performed on the software. 276
  • 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. 276
  • 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. 276
  • 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. 276
  • Information on to help developers understand what happens to their developed system if an unneeded function in the reused component is accidentally invoked. 276
  • Information on any “back doors” (that could be exploited to create a security problem.) 276 See also SWE-156 - Evaluate Systems for Security Risks

Reusability requirements should address the availability of the following documents for future development projects: 276

  • 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.

For auto-generated code see Topic 8.11 - Auto-Generated Code

3.5 Additional Guidance

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

3.6 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

NASA-specific acquisition process information and resources are available in Software Processes Across NASA (SPAN).

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

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

  • Reuse of Analysis Software. Lesson Number 2158 592: “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 526: ” By designing maintainable software products we can update and enhance fielded software much faster and at a lower cost. The 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.”

6.2 Other Lessons Learned

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

7. Software Assurance

SWE-147 - Specify Reusability Requirements
3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that the project has considered reusability for its software development activities.

7.2 Software Assurance Products

  • None at this time.


Objective Evidence

  • None at this time.

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 products submitted for reuse.
  • # of developed products submitted for reuse vs. total # of developed products.
  •   # of developed products entered in NASA Internal Sharing & Reuse System vs. total # of developed products.
  •   # of products submitted for reuse vs. # of products entered into NASA Internal Sharing & Reuse Systems

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

Determine if: 

  1. the project has considered reusability for its software development activities,  and if so,
  2. reusability considerations are part of the software planning process, software processes, and software requirements (if needed). 

Assess during the software life cycle development process if any of the software products should or could be provided to other software development activities.

Check to see if the identified software reusable products are listed on the Internal Software Reuse List 386  site.  If any products are identified as reusable, they are put on the list.

Determine if NASA has the proper ownership rights.  All contributors to the software product should be listed with the product. Also, make sure that the Civil Servant point of contact (POC) knows if the software component or software product uses and or contains any commercial software components or any open source software components. Before any software can be shared, the Civil Servant POC has to have a list of all contributors to the software product (SWE-217 - List of All Contributors and Disclaimer Notice ).

If NASA Civil Servants developed the software and the software does not include any open source or commercial software, the software can be shared.

If a contractor helped develop the software, then contact your legal office about the rights to the software.

Ensure that Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights have been addressed for the software components being shared. (see SWE-027 - Use of Commercial, Government, and Legacy Software ).

To avoid software license issues associated with sharing software, make sure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third-party owners before providing the software for internal NASA software sharing or reuse.

If in doubt, contact your Center’s Legal office.

Reusability requirements should address the availability of the following documents for future development projects: 276

  • 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.

For any third party or re-used software, assess the software plans to ensure the conditions regarding the disclosure,  identification, and use of the software have been identified.  This includes the identification of the SLOCs for the re-used software in the software development plan. 

7.5 Additional Guidance

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

  • No labels