bannerd


SWE-083 - Status Accounting

1. Requirements

5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. 

1.1 Notes

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

1.2 History

SWE-083 - Last used in rev NPR 7150.2D

RevSWE Statement
A

4.1.5 The project shall prepare and maintain records of the configuration status of configuration items.

Difference between A and B

No change

B

5.1.6 The project manager shall prepare and maintain records of the configuration status of configuration items.

Difference between B and C

No change

C

5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. 

Difference between C and DNo change
D

5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. 



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


2. Rationale

Configuration status accounting (CSA) provides a way for a project to determine the content of configuration items (CIs) throughout the life cycle by capturing the status of submitted products such as data, models, scripts, code, and their associated change requests. It also allows project managers to monitor the developing software and know, based on status accounting reports, the contents of versions and releases of software. See also SWE-063 - Release Version Description.

3. Guidance

NASA-GB-8719.13, NASA Software Safety Guidebook

4.5.3 Status Accounting
"While the status information can be compiled by hand, it can be a tedious process. Many tools exist that provide an integrated configuration management system for all kinds of documents, including source code, and that can generate the status reports when requested. Some of these tools are free or low-priced."
276

3.1 Configuration Status Accounting

Configuration status accounting generates and/or maintains records of the status and contents of the software throughout the life cycle. This function keeps track of the changes and the contents of versions and releases.  Both the acquirer and the provider need to have a status accounting system. See also SWE-063 - Release Version Description, SWE-080 - Track and Evaluate Changes, SWE-084 - Configuration Audits, SWE-085 - Release Management

When preparing status accounting records, consider the intended audience for those records and prepare them so that the receiver can obtain the information they need quickly and clearly. Consider the following information for CSA records:

  • Stages of incompleteness, correctness, and obsoleteness for each CI.
  • Identify each stage (e.g., draft, under review, ready for integration/delivery, operational, superseded).
  • Status of each CI (version, whether it is checked-out when it was last updated, who made the changes, and what was changed).
  • Status of change requests/problem reports. See also Topic 5.01 - CR-PR - Software Change Request - Problem Report

The SMA (Safety and Mission Assurance) Technical Excellence Program (STEP) Level 2 Software Configuration Management and Data Management course 343  provide a set of questions useful for determining the type of status accounting data that is important to a project. If the answers are important, then the appropriate data needs to be collected and reported as part of CSA. A few of those questions are shown below:

Which versions of which products are installed at which sites?

What are the differences between versions?

What is the version history of each CI in each version of each product?

What documents support each version of each product?

What hardware configuration is required to operate a specific version of each product?

When will the next version of a given CI for a given product be available?

Which versions of which products are affected by a given configuration item revision?

Which revisions of which CIs make up a specific version of a product?

How many errors were reported and/or fixed in each version of each product in a given time period?

Which product versions are affected by a specific problem report?

3.2 Data Management

When establishing status accounting activities, consider coordinating or applying the same concepts as part of data management activities.  A basic description of data management is provided in SWE-079 - Develop CM Plan.

Once the information to be captured, collected, and reported has been defined, it is captured in the CM plan (see SWE-079 - Develop CM Plan and 5.06 - SCMP - Software Configuration Management Plan).

3.3 Additional Guidance

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

3.4 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

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

4. Small Projects

Projects with limited personnel and access to an automated CM tool that has reporting features may find that those features are helpful in fulfilling this requirement.

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

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-083 - Status Accounting
5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. 

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that the project maintains records of the configuration status of the configuration items.

7.2 Software Assurance Products

  • None at this time


    Objective Evidence

    • Software Problem reporting or defect tracking data
    • Software configuration management system data
    • Software assurance audit results of the change management processes.
    • Software version description document(s).

    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

  • None identified at this time.

7.4 Guidance

The software engineering guidance in SWE-083 (this requirement) provides guidance on the types of configuration records that should be kept. Particularly important are the records of the items and their versions in each baseline, and the records of the configurations that are being delivered and described in the version description documents that accompany a delivery. Confirm that all the configuration management records are being kept and that they are accurate.

7.5 Additional Guidance

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



  • No labels