1. Requirements

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

2. Rationale

Standards and processes are documented in the SDP-SMP - Software Development - Management Plan or in a separate 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, standards, and processes for the applicable software classification are defined in the Software Development/Management Plan (see Topic 7.18) to be used throughout the software lifecycle. The software is maintained using the defined and documented processes and standards throughout the maintenance phase.

Software Lifecycle

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

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

1. Perform audits on the standards and processes used throughout maintenance based on the software classification.

7.2 Software Assurance Products

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

  
  

  Note
  title Objective Evidence
  Software assurance process audit results

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

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

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.