bannerc
SWE-206 - Auto-Generation Software Inputs

1. Requirements

3.8.2 The project manager shall require the software developers and suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. 

1.1 Notes

The term electronic access includes access to the data from NASA facilities

1.2 HIstory

Click here to view the history of this requirement: SWE-206 History

1.3 Applicability Across Classes

 

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.

2. Rationale

NASA requires electronic access to models and simulation data used as input auto-generation of software developed by either suppliers or software developers to facilitate cases where inputs or models may require changes to produce the desired code results.  This access also accommodates the longer-term needs for performing maintenance, assessing operation or system errors, and addressing hardware and software workarounds.

3. Guidance

Auto-generated software is the result of translating a model of the system behavior into different software languages through the use of a code generator. It is important to capture the approach used for the automatic generation of software because issues can exist with auto-generated software and projects need to be prepared to address them.  “Users not only need to be sure that the code implements the model, but also that the code generator is correctly used and configured, that the target adaptations are correct, that the generated code meets high-level safety requirements, that it is integrated with legacy code, and so on."  193

The approach to auto-generated software is typically captured in project documentation such as the Software Development Plan.  Information can also be captured in project documentation relevant to the topic such as configuration management or verification and validation.

Suppliers and software developers provide electronic access to models and simulation data used as inputs to auto-generation software.

For recommended practices, considerations, and additional guidance related to auto-generated software, see Topic 8.11 – Model-Based Development and Auto-generated Code.

Additional guidance related to software tool accreditation 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 References


5.2 Tools

Unable to render {include} The included page could not be found.

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-206 - Auto-Generation Software Inputs
3.8.2 The project manager shall require the software developers and suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. 

7.1 Tasking for Software Assurance

  1. Confirm that NASA, engineering, project, software assurance, and IV&V have electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. 

7.2 Software Assurance Products

  • None identified at this time.

    Objective Evidence

    • Evidence of confirmation that NASA, engineering, project, software assurance and IV&V have access to the models, simulations and associated data used as inputs for the auto-generated software.
     Definition of objective evidence

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

7.3 Metrics

  • None identified at this time.

7.4 Guidance

The intent of this requirement is to provide the NASA software development team with direct access to the models, simulations, and associated data used as inputs for auto-generation of software. 

All software products acquired for NASA projects are to be made available in electronic format so they can be delivered accurately and used efficiently as part of the project. The electronic availability of the software work products, and associated process information, facilitates post-delivery testing that is necessary for assessing as-built work product quality, and for the porting of products to the appropriate hosts. Electronic access to software projects reduces NASA's project costs.

This access also accommodates the longer-term needs for performing maintenance, including defect repairs and software component augmentations, assessing operation or system errors, addressing hardware and software workarounds, and allowing for the potential reuse of the software on future NASA projects.

Software assurance personnel can determine whether the acquired software products are available in electronic format by checking with the software development managers to see if they are having any difficulties accessing any of the information they need. Some of the items that should be accessible are below. If there are any difficulties with access, these issues should be brought up with the project manager so they can be discussed with the contracting officer.

What Needs To Be Accessible?

  • Auto-generation of software flight and ground software source code
  • Models and simulations used to generate auto-generation of software source code
  • Auto-generation of software prototype software, including prototype architectures/designs source code
  • Auto-generation of software data definitions and data sets
  • Auto-generation of software ground products source code
  • Auto-generation of software build data
  • Auto-generation of software test scripts
  • No labels