The software assurance and software safety activities provide a level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, that the software functions in an intended manner, and that the software does not function in an unintended manner. The software assurance process is the planned and systematic set of activities that ensure the conformance of software life cycle processes and products to requirements, standards, and procedures. Software assurance assures that the software and its related products meet their specified requirements, conform to standards and regulations, are consistent, complete, correct, safe, secure, and reliable as warranted for the system and operating environment, and satisfy customer needs. The objectives of software assurance and software safety activities include the following:
Ensuring that the processes, procedures, and products used to produce and sustain the software conform to all specified requirements and standards that govern those processes, procedures, and products.
A set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products.
A set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes.
Determining the degree of software quality obtained by the software products.
Ensuring that the software systems are safe and that the software safety-critical requirements are followed.
Ensuring that the software systems are secure.
1.1 Related Activities
SE-Initiation and Planning - Assurance activities are planned. They are dependent on a whole host of other project activities.
SE-Estimation - Estimates are made and tracked for assurance activities. Assurance must be measured and controlled.
SE-Schedules - Assurance Activities are scheduled and tracked to completion.
SE-Training - Assurance tam members are trained in Assurance methods, the use of Assurance tools, and related subjects.
IV&V is a technical discipline of software assurance that employs rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the life cycle. The evaluation of products and processes throughout the life cycle demonstrates whether the software is fit for nominal operations (required functionality, safety, dependability, etc.), and off-nominal conditions (response to faults, responses to hazardous conditions, etc.). The goal of the IV&V effort is to contribute to the assurance conclusions to the project and stakeholders based on evidence found in software development artifacts and risks associated with the intended behaviors of the software.
The IV&V Project Execution Plans (IPEP) documents the activities, methods, level of rigor, environments, tailoring (if any) of the IV&V requirements, and criteria to be used in performing verification and validation of in-scope system/software behaviors (including responsible software components) determined by the planning and scoping effort.
The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software. Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs. IV&V across the project lifecycle increases the likelihood of uncovering high-risk errors early in the life cycle.
IV&V artifacts and products required to perform the IV&V analysis on NASA projects are to be made available in electronic format in the original format. The electronic availability of the IV&V products and artifacts facilitates post-deliveries that might be necessary with software updates. Electronic access to IV&V artifacts and products reduces NASA's IV&V project costs and accommodates the longer-term needs when performing software maintenance.
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.
Typically starts with a quote from the NPR that helps define the activity. Additional descriptive material is meant to help define the activity but not be so detailed that it pulls in all of the guidance from the SWEs in the activity.
Panel
borderColor
blue
title
NPR 7150.2B para 5.3.1
Software peer reviews and inspections are the in-process technical examination of work products by peers to find and eliminate defects early in the life cycle. Software peer reviews and inspections are performed following defined procedures covering the preparation for the review, the review itself is conducted, results are recorded, results are reported, and completion criteria is certified. When planning the composition of a software peer review or inspection team, consider including software testing, system testing, software assurance, software safety, software cybersecurity, and software IV&V personnel.
Examples of Some Documents Going Through Peer Review
Image Added
1.1 Inputs
Note
List of some of the inputs from other activities that are necessary for the activity to begin.
Planning - Peer Reviews are planned activities. They appear in the plans and schedules for the project
Requirements - These are the things that are Peer Reviewed
Architecture Items - These are the things that are Peer Reviewed
Design items - These are the things that are Peer Reviewed
Test Plans and Procedures - These are the things that are Peer Reviewed
1.2 Predecessor Activities
Note
List of some of the other activities that must be started (not necessarily completed) this activity to begin.
Predecessor Activities are performed before Peer Reviews. These activities produce the work products that will be reviewed.
Life Cycle Planning - Peer Reviews are planned activities. They are also used to review and improve all types of plans.
Requirements - Creating the things that are Peer Reviewed
Architecture Items - Creating the things that are Peer Reviewed
Design items - Creating the things that are Peer Reviewed
Test Plans and Procedures - Creating the things that are Peer Reviewed
1.3 Outputs
Note
List of some of the outputs or work products of the activity. These are typically used as inputs by the downstream activity. In some cases there is a supporting SWE associated with the work product.
In the case of Peer Reviews, outputs cycle back to the activity that provided the inputs so that improvements to the work products can be made. The activities that initiated the Peer Review, receive the findings from Peer Reviews, Those activities then use those findings to to fix defects and implement improvements uncovered in the reviews. The improved work products are then used by downstream activities as the project proceeds.
Output Work Product
Used by Downstream Activity
Peer Review Findings
Life Cycle Planning
Software Architecture
Software Design
Software Testing
Configuration Management
Coding
1.4 Successor Activities
Note
Links to Activities which might be started or supported by this activity.
Life Cycle Planning
Software Architecture
Software Design
Software Testing
Configuration Management
Coding
1.5 Repetition
Note
Describe what conditions determine if the activity needs to be repeated.
How much of the activity needs to be repeated
Frequency of repetition
Peer Reviews are planned activities and may be repeated as needed throughout the life cycle.
As Software Requirements, budgets, schedules, and technology changes are factored into the project, additional Peer Reviews of affected work products may be desirable.
1.6 Center Resources From SPAN
Note
Add links to SPAN activity pages that are appropriate for this activity. Use links from the Activity section of the front page. SPAN
Several Centers Process Asset Libraries have materials related to this activity. Related Processes, templates, and other resources may be found in the following Activities in SPAN (available to NASA only).
SWEHBVD:SWE-089 - Software Peer Reviews and Inspections - Basic Measurements
SWEHBVD:SWE-089 - Software Peer Reviews and Inspections - Basic Measurements
nopanel
true
2.2 Topics and other Supporting Materials
Note
This section is for SWEHB pages, other than SWEs, that directly support the activity. This section contains Topics, document content pages, PATs, and other pages.
SWEHBVD:7.10 - Peer Review and Inspections Including Checklists
SWEHBVD:7.10 - Peer Review and Inspections Including Checklists
nopanel
true
2.3 Other Associated SWEs, Topics, etc.
Note
Includes other SWEHB pages that are indirectly associated with the activity. May include SWEs, Topics, document definition pages, PATs, etc. They may have been mentioned in the guidance of another page.
