1. Requirements

4.6.5 The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.

1.1 Notes

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

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Standards and processes are documented in the 5.08 - SDP-SMP - Software Development - Management Plan or in a separate 5.04 - Maint - Software Maintenance Plan.  Each software classification has a defined set of requirements and all software at that classification must meet those requirements for its lifetime or until its classification changes, therefore, the software is maintained according to processes and standards defined for its software classification.

3. Guidance

Once the software classification is determined as defined in SWE-020 - Software Classification, standards, and processes for the applicable software classification are defined in the Software Development/Management Plan (see 7.18 - Documentation Guidance) to be used throughout the software life cycle. The software is maintained using the defined and documented processes and standards throughout the maintenance phase.

3.1 Software Life Cycle

The Software development life cycle model includes the following phases.

1) Requirement gathering and analysis:  Business requirements are gathered in this phase. After requirement gathering, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be developed is also studied. A Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

2)  Design:  In this phase, the system and software design are prepared from the requirement specifications which were studied in the first phase. System Design helps in specifying hardware and system/software requirements and also helps in defining overall system architecture. The software design specifications serve as input for the next phase of the model.

3)  Implementation / Coding:  On receiving system/software design documents, the work is divided into modules/units and actual coding is started. Since, in this phase, the code is produced so it is the main focus for the developer. This is the longest phase of the software development life cycle.

4)  Testing:  After the code is developed it is tested against the requirements to make sure that the product is solving the needs addressed and gathered during the requirements phase. During this phase, all types of functional testing like unit testing, integration testing,  system testing,  acceptance testing are done as well as non-functional testing are also done.

5)  Deployment/Release: After successful testing, the product is delivered/deployed to the customer for their use.

6) Maintenance: Once when the customers start using the developed system then the actual problems come up and need to be solved from time to time. This process where the care is taken for the developed product is known as maintenance.

The Maintenance Phase is the last phase of the life cycle and occurs once the system is released to the customer and operational. It includes implementation of changes that software might undergo over some time, or implementation of new requirements after the software is deployed at the customer location. The maintenance phase also includes handling the residual errors that may exist in the software even after the testing phase. This phase also monitors system performance, rectifies bugs, and requested for changes to be made. Maintenance is what happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform, and more.

During the maintenance phase the previous phases in the software life cycle may need to be revisited as applicable.  Software changes should be analyzed to determine the level of regression testing to be performed. 

See also SWE-075 - Plan Operations, Maintenance, Retirement, 

3.2 Additional Guidance

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

3.3 Center Process Asset Libraries

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

4. Small Projects

No additional guidance is available for small projects.

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

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

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Standards and Processes Audit Report (Results of audits on processes and standards used during maintenance, including any findings, issues.)

  
  

  Objective Evidence

  • Software assurance process audit results
   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 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 Non-Conformances identified in the software after delivery
• # of process Non-Conformances (e.g., activities not performed) identified by SA vs. # accepted by the project
• Trends of # Open vs. # Closed over time
• # of Non-Conformances per audit (including findings from process and compliance audits, process maturity)
• Trends of # of Non-Conformances from audits over time (Include counts from process and standards audits and work product audits.)
• # of Open vs. Closed Audit Non-Conformances over time
• # of Compliance Audits planned vs. # of Compliance Audits performed
• # of software process Non-Conformances by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

Software assurance will perform audits of the maintenance processes and procedures in use during this phase. Some of the processes and procedures to audit include the configuration management processes, change management processes, the process to transition changed software into the operational environment, and the testing procedures, particularly those associated with testing safety-critical functions and regression testing. 

Findings from the audit all need to be recorded and tracked to closure.

Every task that involves performing an audit should also clarify that all audit findings are promptly shared with the project will be addressed in the handbook guidance.

7.5 Additional Guidance

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