2.4.4 The project shall record, address, and track to closure the results of software validation activities.
NPR 7150.2A does not include any notes for this requirement.
NPR 7150.2A does not include any notes for this requirement.
This requirement applies to all classes and safety criticalities except:
- Class E and not Safety Critical
- Class H
Class G is labeled with "P(Center). This means that an approved Center-defined process that meets a non-empty subset of the full requirement can be used to achieve this requirement.
Simply performing validation is not sufficient to ensure the software will perform as intended in the customer environment. The project team must capture the results of validation activities to prove the validation was conducted and to document the findings from those activities. Identified issues should be analyzed to determine the cause. The team should then identify associated resolutions, and track to closure the work to implement those resolutions. This completes the cycle and provides the best assurance that the software will be of high quality and perform as intended.
Where resolution involves revision to the validation process, environment, etc., tracking such issues helps to document process improvements and improve process quality resulting in more accurate validation results in the future.
The basic validation process is shown below with the steps addressed by this requirement highlighted:
Results and the validation activities and validated products that generated them can be recorded in the following ways, as appropriate for the validation method used:
- Validation reports
- Review meeting minutes / reports
- Review Item Dispositions (RIDs)
- As-run test logs
- Demonstration results
- Analysis reports
- Beta test reports
- User group reports
- Issue tracking system
- Change requests / change request system
When analyzing validation results to determine whether those results support a conclusion that the software will perform as intended in the operational environment, consider the following steps:
- Compare actual to expected results
- Identify discrepancies or mismatches in behavior
- Document discrepancies individually for ease of tracking through the resolution process
- Determine cause of the issue, including problems with the validation methods, criteria, or environment
- Identify the changes required to address discrepancies
- Evaluate and record the impact of changes needed to correct issues / discrepancies
- Rework and test
- Obtain and record approval for changes to be made versus those to be addressed at a different time
- Measure and predict quality of the software based on the validation results (typically, a software assurance activity)
When tracking discrepancies to closure, consider the following activities:
- Capture the changes to be made (change requests, corrective actions, RIDs, etc.) with or with reference to the original validation results
- Carry out the approved changes to be made
- Follow chosen solution to completion, including any re-validation necessary to confirm the issue has been resolved
- Obtain and record approval for issue close-out
The following is a list of information typically captured in the validation results, analysis results, or in the post-analysis documentation of those results. This is not a complete list. Center procedures may call for additional information, or additional information may be needed to document fully the result or identified issue. Note that problem tracking or corrective action tools may capture some of this information automatically.
- Specific reference (name, identification number, version, etc.) to the item or product (requirement, document, function, system, etc.) being validated
- Where appropriate, the specific validation activity applied (test identifier, demonstration step(s), etc.)
- Include sequence of events leading to problem, if appropriate
- Description of the validation result(s)
- Description of identified issue or problem
- Root cause of issue or problem, including problems with the validation environment, process, etc.
- Criticality of issue or problem, including impact on the item under validation or software system
- Recommended correction or change to address the issue
- Impact of recommended correction or change
- Justification for the chosen resolution, including choices to postpone a change
- Approval to implement the chosen resolution
- Tracking information such as validator (person, team, etc.) identification, date of activity (validation date, analysis or review date, correction date, follow-up validation activity date, etc.), etc.
- Approval of issue close-out
Center or project procedures may require additional documentation not described above.
Additional documents which may be produced
Validation summary report
The team should report the results of validation activities to one or more of the following:
- Project management
- Software assurance, if not involved in the validation activities
- Customer, as appropriate
- Other stakeholders, as appropriate
Potential problems when recording, analyzing and tracking validation results include, but are not limited to:
- Assuming all issues are problems in the software (issues may be caused by the validation procedures, criteria, or environment)
- Failing to involve knowledgeable or "expert" personnel in the analysis process
- Not reviewing validation results at lifecycle product milestone, or other relevant, reviews (waiting to review such results can potentially result in carrying issues into later lifecycle phases)
NASA Centers typically have templates and tools for capturing and tracking validation results. The tools for each particular center should be used for projects developed at those centers.
See also related requirements in this handbook:
SWE-055 - Requirements Validation
- The CMMi easy button presentation of CMMi – Validation (VAL) (SP 2.2 Analyze Validation Results), Software Quality Assurance.org
- Reference Information for the Software Verification and Validation Process, NIST Special Publication 500-234, 1996
- Software Development Process Description Document, EI32-OI-001, Revision R, 2010, (Hosted on NEN)
There are no tools currently identified for this requirement.
The NASA Lessons Learned website offers a few lessons learned related to validating results from flights of "Off the Shelf" Aviation Navigation Units on the Space Shuttle, GPS.