Page History
...
| 0 | 1. The Requirement |
|---|---|
| 1 | 2. Rationale |
| 2 | 3. Guidance |
| 3 | 4. Project Tasks |
| 4 | 5. Resources |
| 5 | 6. Lessons Learned |
| 6 | 7. Software Assurance |
...
| id | tabs-1 |
|---|
1. Requirements
| Excerpt |
|---|
5.3.2 The project manager shall perform and report the results of software peer reviews or software inspections for: a. Software requirements. |
1.1 Notes
Software peer reviews or software inspections are recommended best practices for all safety and mission-success related software components. Recommended best practices and guidelines for software formal inspections are contained in NASA-STD-8739.9, Software Formal Inspection Standard.
| Swerefn | ||
|---|---|---|
|
1.2 History
...
| title | Click here to view the history of this requirement: SWE-087 History |
|---|
...
1.3 Applicability Across Classes
| Applicable c | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Div | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
2. RationaleSoftware peer reviews or inspections are performed to ensure product and process quality, add value, and reduce risk through expert knowledge infusion, confirmation of approach, identification of defects, and specific suggestions for product improvements.
|
...
| id | tabs-3 |
|---|
3. Guidance
| Note |
|---|
In this version of SWE-087, tab 3 has been revised to include subheadings for clarity. |
3.1 What are Peer Reviews?
Peer reviews are one of the most efficient and effective ways to find and remove defects.
NASA-STD-8709.22 provides two definitions for peer reviews:
| Swerefn | ||
|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
[1] A review of a software work product, following defined procedures, by peers of the product producers to identify defects and improvements. [2] Independent evaluation by internal or external subject matter experts who do not have a vested interest in the work product under review. Projects can plan peer reviews, and focused reviews conducted on selected work products by the producer’s peers to identify defects and issues before that work product moves into a milestone review or approval cycle. |
Peer reviews can also be described as “planned, focused reviews by technical team peers on a single work product with the intent of identifying issues before that work product moves on to the next step. A peer review includes planning, preparing, conducting, analyzing outcomes, and identifying and implementing corrective actions.”
| Swerefn | ||
|---|---|---|
|
A key rationale for using software peer reviews or software inspections is that they are a few verification and validation (V&V) approaches that can be applied in the early stages of software development, long before there is any code that can be run and tested. Moreover, when defects are found and fixed in these early stages rather than slipping into later phases, it can have a huge impact on the project budget. For this reason, software peer reviews and software inspections of requirements documents are explicitly required.
| Panel | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
|
3.2 Advantages of Peer Reviews
3.2.1 Stakeholder Buy in
Software plans are another key artifact on which software peer reviews or software inspections can be applied with the best return on investment. Since well-developed and appropriate plans that have buy-in from key stakeholders are important elements of critical software success, peer review or inspections are applied to improve the quality of such plans.
3.2.2 Improving Quality
Software testing represents a substantial part of assuring software quality for most projects, so it is important to ensure that test cases are focused on the appropriate functional areas, cover all important usage scenarios, and specify the expected system behavior adequately and accurately. The best way to ensure these factors is via peer review/inspection, the application of human judgment, and analysis.
Code and design artifacts also benefit from peer review or inspection. However, although important, inspections of such artifacts are less crucial than those of other life cycle activities because there are other effective Verification and Validation (V&V) options available for code and design (such as testing or simulation). A project needs to identify the most crucial design and code segments and deploy inspections to improve their quality. Projects also need to focus inspections of code and design on issues that cannot be verified using automated tools; i.e., projects need to be sure that human judgment is applied on appropriate issues and rely on automation where it is best suited.
3.2.3 Additional Benefits from Peer Reviews
Peer reviews/inspections provide the following additional benefits:
...
Useful for many types of products: documentation, requirements, designs, code
...
Simple to understand
...
Provide a way for sharing/learning good product development techniques
...
Serve to bring together human judgment and analysis from diverse stakeholders in a constructive way
...
This can result in a very efficient method of identifying defects early in the product’s life cycle
...
Use a straightforward, organized approach for evaluating a work product
- To detect potential defects in a product
To methodically evaluate each defect to identify solutions and track the incorporation of these solutions into the product
3.3 Required Peer Reviews
Projects are required to conduct peer reviews/inspections for the following documentation based on software classification:
...
Software Documentation
...
A
...
B
...
C
...
D
...
E
...
Software Requirements
...
X
...
X
...
X
...
X (SC only)
...
...
Software Plans
...
X
...
X
...
X
...
X (SC only)
...
...
Software Design Identified in Plans
...
X
...
X
...
X
...
X (SC only)
...
...
Software Code identified in Plans
...
X
...
X
...
X
...
X (SC only)
...
...
Test Procedures
...
X
...
X
...
X
...
X (SC only)
...
3.4 Preparing for a Peer Review
3.4.1 Peer Review Process Elements
When conducting a peer review/inspection, be sure the following are part of the process to have an effective software peer review/inspection:
- Keep the review focused on the technical integrity and quality of the product.
- Keep the review simple and informal, and manage time effectively.
- Keep the review short and simple.
- Concentrate on the review of the documentation and minimize presentations.
- Don't pass your opinion off as fact and don't ask judgmental; questions.
- Don't use emojis to point out issues and don't ghost people (let the reviewers know what you did with the comments)
- Use a round-table format rather than a stand-up presentation.
- Give a full technical picture of the items being reviewed.
- Automate when possible.
- Take advantage of the talent.
- Plan the review/inspection, use checklists, and include readiness and completion criteria.
- Capture action items, and monitor defects, results, and effort.
- The project's static analysis tools have been run on any source code under review before the software code review.
- Make sure that the code changes implement the software requirement and that the software requirement is up-to-date.
- Use the code reviews and inspections as a teaching opportunity.
3.4.2 Peer Review Members and Roles
When putting a software peer review team together, use the following best practices:
- The team consists of a minimum of four inspectors.
- Diverse viewpoints and objectivity are required.
- Inspection team members are based on the analysis of key stakeholders in the item under inspection.
- The author should not be the reader, recorder, or moderator.
- The moderator should not be a manager.
- At a minimum, the moderator should be formally trained in the process, but all participants may be trained.
- Management presence/participation discouraged.
- Each role has a specific responsibility, as shown in the table below:
...
Role
...
Responsibility
...
Moderator
...
Conducts and controls the inspection
...
Author
...
The producer of the product under inspection, answers technical questions
...
Reader
...
Presents (reads, paraphrases) the inspection product to the inspection team
...
Recorder
...
Documents defects identified during the inspection as well as open issues and action items
...
Software Peers
...
Look for software and software coding defects in the product under inspection.
...
3.4.3 Entrance and Exit Criteria
The table below is from the NASA System Engineering Processes and Requirements, NPR 7123.1, and shows the entrance criteria and success criteria for a peer review activity.
Table G-19 - Peer Review Entrance and Success Criteria
...
Peer Review
...
Entrance Criteria
...
Success Criteria
...
- The product to be reviewed (e.g., document, process, model, design details) has been identified and made available to the review team.
- Peer reviewers independent from the project have been selected for their technical background related to the product being reviewed.
- A preliminary agenda, success criteria, and instructions for the review team have been agreed to by the technical team and project manager.
- Rules have been established to ensure consistency among the team members involved in the peer-review process.
- *Spectrum (radio frequency) considerations addressed.
...
- Peer review has thoroughly evaluated the technical integrity and quality of the product.
- Any defects have been identified and characterized.
- The results of the peer review are communicated to the appropriate project personnel.
- Spectrum-related aspects have been concurred on by the responsible Center spectrum manager.
- A code peer review checks to verify that the code meets the software requirements
*Required per NPD 2570.5.
3.4.4 Peer Review Process Steps
Software peer reviews are conducted using the following steps:
...
Step
...
Description
...
Planning
...
Organize inspection, inspection package contents, required support, and schedule.
...
Overview
...
Educational briefing at the time of package distribution to explain materials at a high level
...
Preparation
...
Inspectors individually look for and document defects and develop questions
...
Inspection Meeting
...
Inspectors examine the product as a group to classify and record defects and capture open issues and action items.
...
Third Hour
...
Optional informal meeting to resolve open issues and discuss solutions
...
Rework
...
The author corrects major defects (others when cost and schedule allow)
...
Follow-up
...
Moderator verifies all major and other dispositioned defects have been corrected; no new defects introduced; all action items/open issues are closed.
3.4.5 Peer Review Best Practices
When conducting the software peer review, incorporate the following best practices to ensure an effective outcome:
- Defects found during inspections are never used to evaluate the author – the goal is to improve the product.
- Use checklists relevant to each inspector’s perspective.
- Verify that the product being reviewed meets the requirements
- Use readiness and completion criteria.
- Limit inspection meeting to 2 hours.
- Track action items until they are resolved.
- Collect and use inspection data:
- The effort, number of participants, and areas of expertise.
- Defects - list, total, type.
- Inspection outcome (pass/fail).
- The item being inspected and type (requirements, code, etc.).
- Date and time.
- Meeting length, and the preparation time of participants.
NASA-STD-8739.9, Software Formal Inspection Standard
| Swerefn | ||
|---|---|---|
|
- Requirements.
- Design documents.
- Source code.
- Software plans.
- Software test procedures.
The design and code segments selected for peer review or inspection should be the most critical, complex, have key interfaces, or otherwise represent areas where the concerns of multiple stakeholders overlap.
The presence and participation of project management in peer review or inspection meetings are usually not recommended due to the potential negative impact on the effectiveness of the inspections. Typically, management only receives summary-level information on peer reviews/inspections. However, since the project manager for both the software and the system is often the stakeholder of the work products examined (especially in the context of software plans), they may be included as participants in the inspections only when necessary.
Both management and the inspectors must be aware that defects found during inspections are never used to evaluate the authors. Everyone involved in an inspection needs to have a vested interest in improving the product that is being inspected. This requires that everyone be willing to identify defects (including the author) and help identify potential solutions.
3.4.6 Additional Guidance
In Maryland, the Fraunhofer Center maintains a public website that collects checklists found from NASA and other contexts, which can be applied to the types of work products mentioned in these requirements.
| Note |
|---|
NASA users should consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources, such as templates, related to peer reviews and inspections. |
...
Additional guidance related to peer reviews and inspections may be found in the following topic and related requirements in this handbook:
...
| Div | ||
|---|---|---|
| ||
4. Project Tasks
While small projects are required to use peer reviews and inspection processes to evaluate key artifact types, they could make the task more manageable by varying the size of the inspection team, as long as key stakeholders are still represented. When it isn't possible to find all of the needed expertise from within the project team itself, consider whether the peer review/inspection team can leverage personnel from:
Small teams also determine whether quality assurance personnel from the Center participate, for example, by providing a trained moderator to oversee the inspection logistics. 4.1 Tasking for Software DevelopmentGuidance for each task is available in tab 3.
4.2 Software Development Work Products
4.3 MetricsSuggested metrics are listed below. Items in bold are strongly recommended for implementation in order to provide benefit for tracking and assessing completion of the work.
|
...
| id | tabs-5 |
|---|
5. Resources
5.1 References
...
| group | confluence-users |
|---|
...
| titleColor | red |
|---|---|
| title | Visible to editors only |
Enter the necessary modifications to be made in the table below:
...
SWEREFs called out in text: 041, 197, 274, 276, 277, 319, 421, 521, 685
SWEREFs NOT called out in text but listed as germane: none
...
| Div | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
6. Lessons Learned6.1 NASA Lessons LearnedA documented lesson from the NASA Lessons Learned database notes the following:
6.2 Other Lessons Learned
|
...
| id | tabs-7 |
|---|
7. Software Assurance
...
7.1 Tasking for Software Assurance
...
| borderColor | blue |
|---|---|
| title | From NASA-STD-8739.8B |
...
7.2 Software Assurance Products
- SA peer review records (Including findings for software assurance and software safety plans.)
| Note | ||
|---|---|---|
| ||
|
...
| title | Definition of objective evidence |
|---|
...
7.3 Metrics
- # of software work product Non-Conformances identified by life cycle phase over time
- # of Peer Review Audits planned vs. # of Peer Review Audits performed
- Time required to close review Non-Conformances
- Total # of peer review Non-Conformances (Open, Closed)
- # of Non-Conformances identified by software assurance during each peer-review
- # of Non-Conformances identified in each peer review
- # of peer reviews performed vs. # of peer reviews planned
- # of Non-Conformances and risks open vs. # of Non-Conformances, risks identified with test procedures
- Software cyclomatic complexity # for safety-critical components
- # of safety-related non-conformances identified by life cycle phase over time
- # of safety-related requirement issues (Open, Closed) over time
- # of Non-Conformances from reviews (Open vs. Closed; # of days Open)
- # of Non-Conformances (activities not being performed)
- # of Non-Conformances accepted by the project
- # of Non-Conformances (Open, Closed, Total)
- Trends of overtime
- % of Total Source Code for each Software Classification (*organizational measure)
7.4 Guidance
Confirm that peer reviews are planned and are being executed on the items listed in SWE-087. Early in the project (e.g., before SRR or PDR), assurance confirms that peer reviews are planned for the requirements, the software plan, and the test procedures. In addition to these peer reviews, confirm that the project has considered whether other products need to be reviewed and have included a list of those in their software management/development plan.
Generally, the additional peer-reviewed items are design and code products for any software design or code intended to address requirements for critical software or for any of the areas of the code or design that are particularly complex. Software assurance may also choose other areas to peer review independently if they feel a particular area or product needs review.
Plan to attend any scheduled reviews listed in this requirement and any identified in the software plan. Other software assurance responsibilities associated with peer reviews are addressed in SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking. This includes confirming that all issues and defects from the peer reviews are recorded and addressed before the review is closed out. Software assurance tracks all actions (issues, defects) from the peer reviews and verifies their closure before the reviews are closed.
Software assurance products such as the SA Plan and the requirement assessments done by SA will also be peer-reviewed. In addition to addressing any issues, or defects resulting from the SA product reviews, the software assurance team tracks its review metrics, including those listed in section 7.3 above. Software assurance confirms that the software team is collecting metrics on their peer reviews. It is beneficial for software assurance to collect the metrics on any issues and defects found by software assurance in software peer reviews to show that their attendance was valuable.
Ensure peer review participation by key stakeholders including Systems Engineering, and all affected Responsible Engineers.
Ensure that peer reviews perform requirements check as part of any code peer review activity and process.
Assure that all code peer reviews have verified that the code or code changes meet the software requirements.
See SWE-134 - Safety-Critical Software Design Requirements for additional guidance associated with cyclomatic complexity assessments.
