- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
4.6.5 The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
Click here to view the history of this requirement: SWE-195 History
1.3 Applicability Across Classes
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.
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.
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.
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 actually 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 a period of 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 changes are made. Basically 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.
No references have been currently identified for this SWE. If you wish to suggest a reference, please leave a comment below.
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
- 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.)
Definition of 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 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.
- # 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
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.