See edit history of this section
Post feedback on this section
- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
1. Requirements
3.6.5 If software IV&V is performed on a project, the project manager shall provide responses to IV&V submitted issues and risks and track these issues and risks to closure.
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
Class A B C D E F Applicable?
Key: - Applicable | - Not Applicable
2. Rationale
If the project manager does not address the issues and risks found by IV&V and track them to closure, these unaddressed risks and issues could cause the project to fail to meet its objectives (e.g. schedule, planned quality, functionality, etc.) Since IV&V personnel have generally worked across many projects, they are often likely to recognize risks and issues to the project that the project manager may not recognize.
3. Guidance
3.1 Risk Mitigation
If software-independent validation and verification (IV&V) are performed on a project, the project manager provides responses to IV&V submitted issues and risks and tracks these issues and risks to closure. See also SWE-080 - Track and Evaluate Changes
IV&V is a part of Software Assurance playing a role in the NASA software risk mitigation strategy. IV&V is an objective examination of safety and mission-critical software processes and products. The key parameters for independence are technical independence, managerial independence, and financial independence. The goal of IV&V is to determine if the right system has been built and that it has been built correctly. From that perspective IV&V strives to answer the questions: will the system’s software do what it is supposed to do, will the system’s software not do what it is not supposed to do and will the system’s software respond as expected under adverse conditions. See also SWE-086 - Continuous Risk Management.
IV&V leads to higher quality products, reduced risk, greater insight, reduced cost, and knowledge transfer. IV&V also facilitates the transfer of system and software engineering best practices. IV&V status reports provide another status indicator and performance report to decision-makers (program managers). The scope of IV&V services is determined by the IV&V provider, documented in the IV&V Project Execution Plan (IPEP) 028, and approved by the NASA IV&V Program. The IPEP is developed by the IV&V provider and serves as the operational document that will be shared with the project receiving IV&V support. See also 8.53 - IV&V Project Execution Plan and SWE-178 - IV&V Artifacts.
Once a risk or issue is submitted by IV&V, use the following considerations:
Considerations for evaluating the change and suggested solution
- Project impact analysis.
- Include the appropriate set of stakeholders, such as procurement, quality assurance, risk management, relevant experts, and management (e.g., change requested by high visibility customer may result in a business decision to implement a change as opposed to volumes of end-users not seeing the problem), etc.
- Evaluate the impact on schedule and cost, including making and testing the change and regression testing the software.
- Evaluate the impact on other groups and resources, as applicable.
- Evaluate the impact on functions and features, interfaces, and system resource requirements.
- Evaluate the impact on other baseline products, such as design, tests, and documentation (traceability matrices are helpful here).
- Evaluate the risk of making the change vs. not making it.
- Evaluate the size, complexity, the criticality of the change.
- Evaluate whether a change request is within the scope of the project.
- Evaluate whether a change request is needed to meet project requirements.
- Evaluate the impact on performance, reliability, quality, etc.
- Evaluate alternatives to making the change.
- Software safety impact analysis (NASA-STD-8739.8 278, NASA Software Assurance, and Software Safety Standard )
- Include software quality assurance and safety personnel in this review.
- Look for the potential creation of new hazard contributions and impacts.
- Look for potential modifications of existing hazard controls or mitigations.
- Look for a detrimental effect on safety-critical software or hardware.
- Determine the effect on software safety.
- Determine the effect on system safety.
- Capture evaluation/analysis results and related decisions, including action items.
Considerations for tracking the change
- Use a change control system that is compatible with the project environment and capable of tracking change until completed.
- Trace safety-critical problems back to the related system-level hazard.
- Include in the tracking records the actual change request/problem reports, impact analysis, notes from evaluation/approval boards and meetings, etc.
- Track the software products and versions changed as part of implementing the change (requirements, code, specifications, etc.)
- Close change requests only after verification and approval of the implemented change and all associated documentation revisions.
Once the evaluation of issues and risks have been evaluated, responses are submitted to IV&V. The risks and issues are tracked until closure. The project will continue to work with IV&V collaboratively to achieve consensus on issues and risks as both are dispositioned to closure.
3.2 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
Related Links |
---|
3.3 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).
SPAN Links |
---|
4. Small Projects
No additional guidance is available for small projects.
5. Resources
5.1 References
- (SWEREF-028) T2103, NASA Independent Verification and Validation Program, 2011.
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-271) NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07
- (SWEREF-278) NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
5.2 Tools
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
7.1 Tasking for Software Assurance
7.2 Software Assurance Products
- Records of IV&V issues and risks with status (e.g., accepted, in work, closed)
Objective Evidence
- Evidence that the confirmation of IV&V involvement is occurring, if applicable.
7.3 Metrics
- # of software work product Non-Conformances identified by life cycle phase over time
- # of Risks identified in each life cycle phase (Open, Closed)
- # of Risks by Severity (e.g., red, yellow, green) over time
- # of Risks with mitigation plans vs. total # of Risks
- # of Risks trending up over time
- # of Risks trending down over time
- # of IV&V Non-Conformances/issues/risks (# Open, Closed, accepted by the project, severity, category of Non-Conformance (e.g., requirements, design, code, testing, security, etc.))
- The trend of open/closed Non-Conformances
See also Topic 8.18 - SA Suggested Metrics.
7.4 Guidance
- Confirm if IV&V is required on the project, see section 4.4 of NASA-STD-8739.8 278 for the IV&V requirements.- See SWE-141 - Software Independent Verification and Validation
- Develop, if IV&V is required on the project, IV&V findings, issues, concerns, and risks. -
- Assure that the IV&V findings, issues, concerns, and risks are tracked and addressed by the project and engineering. Track findings to closure. The IV&V personnel deliver their findings, concerns, and risks to the project periodically, and generally provide a summary status at milestone reviews. SA should have access to the IV&V findings and be able to review them to assure that they are being closed out in a timely fashion. If the findings and issues are not being addressed by the project, that should be elevated up through the assurance chain of command.
- Identify software risks from the IV&V issues, concerns, and risks if needed. SA documents any software risks they identify from their review of the IV&V issues, concerns, and risks
- Assess why the IV&V issues, concerns, and risks were not found during the SA assessment processes. SA reviews the IV&V issues, concerns, and findings and compares them to the SA findings to identify any findings that were not also identified by the SA team. Those IV&V findings not also identified by SA should be assessed to determine why they were not discovered. Assess SA processes as appropriate to enable the discovery of more of these missed findings.
7.5 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
0 Comments