GENERIC

SOFTWARE QUALITY ASSURANCE PLAN

@(#)sqa.htm 3.5 - 03/08/02


The Generic UWF Maintenance Process (GUMP ++) 1994-2000 The University of West Florida. All rights reserved.

Permission is granted to reproduce and adapt this document provided credit is given to the University of West Florida. This documentation is provided "as is" and no warranty of fitness for any particular purpose is made or implied.


ABSTRACT

This document describes the Software Quality Assurance (SQA) plan for the generic software maintenance process used in the Software Engineering graduate program at the University of West Florida (UWF).


TABLE OF CONTENTS

ABSTRACT
LIST OF FIGURES
LIST OF TABLES
1.0 PURPOSE
2.0 DOCUMENTATION
3.0 STANDARDS, PRACTICES, AND CONVENTIONS
4.0 TISK PROCESS CHECKLIST
5.0 TRAINING
6.0 INFORMAL WALK-THROUGHS
7.0 INSPECTION PROCESS
7.1 Planning Phase
7.2 Preparation Phase
7.3 Inspection Meeting
7.4 Follow-up
APPENDIX A INSPECTION PROCESS REFERENCES
A1.0 Inspection Roles
A2.0 Rules for Inspections
A3.0 Inspection Checklists
A3.1 Analysis Report Inspection Checklist
A3.2 Implementation Inspection Checklist
REVISION HISTORY
BIBLIOGRAPHY
GLOSSARY


LIST OF FIGURES

Figure 1. Inspection Process


LIST OF TABLES

Table 1. Governing Documentation
Table 2. Process Standards
Table 3. Inspection Phases
Table 4. Planning Phase
Table 5. Preparation Phase
Table 6. Inspection Meeting
Table 7. Follow-up


1.0 PURPOSE

The purpose of this plan is to specify how Software Quality Assurance (SQA) will be performed during the process. SQA personnel will both ensure that software maintenance is performed according to the process described in the Generic Process Architecture document and help to improve and refine the process. By doing so, SQA personnel will help to improve the overall quality of software products. This plan describes the SQA activities to be performed and defines a set of standardized techniques for performing those activities.


2.0 DOCUMENTATION

The documents identified in Table 1 are generated during the software maintenance process. The table specifies both the inspection procedures, during which a document will be checked for accuracy, and the criteria against which the document will be checked.

Documents Inspection Criteria
Analysis Report Analysis Report Inspection Analysis Report Standard
Implementation Report Implementation Inspection Coding Standards, Unit Test Standard, and TCL Style Guide

Table 1. Governing Documentation


Note: In the case of a "Buy-in" of software, the Analysis Report may simply point to a Software Requirements Specification (SRS) document for inspection.


3.0 STANDARDS, PRACTICES, AND CONVENTIONS

The following table lists all standards, practices, and conventions used in the process and identifies when SQA personnel will apply them:

Standard, Practice, or Convention Inspection Type Cell
Analysis Report Standard Analysis Report Inspection 303
Coding Standard Implementation Inspection 505
Unit Test Standard Implementation Inspection 505
TCL Style Guide Implementation Inspection 505

Table 2. Process Standards


4.0 TISK PROCESS CHECKLIST

It is the responsibility of SQA to ensure that the TISK Process Checklist is properly updated. SQA will inform the responsible parties if they have neglected to complete the appropriate sections of the checklist.


5.0 TRAINING

Initial SQA training may be conducted by SQA personnel early in each project cycle. This training will consist of a lecture that describes SQA activities and an inspection simulation. Follow on SQA training will be conducted prior to each inspection as needed. This training will consist of a review of inspection procedures by the SQA inspection moderator with inspection team members.


6.0 INFORMAL WALK-THROUGHS

The objective of the walk-through is to evaluate the product and eliminate as many defects, omissions, and deviations from standards as possible before proceeding to a formal inspection. A walk-through is an informal procedure performed by a software engineer other than the author. All of the review procedures for a walk-through may be done via E-mail.

The following actions occur during a walk-through:


7.0 INSPECTION PROCESS

Inspections are used to increase software quality and improve productivity and manageability of the development process. The inspection process follows a specific set of steps which define what will be inspected, when it will be inspected, who will do the inspection, what data will be collected, and what follow-up actions must be taken.

Inspections are conducted for Analysis Reports and Implementation. Implementation inspections may be done incrementally as development progresses and need not be delayed until the product is finished. The overall inspection process is as follows:


Figure 1. Inspection Process

The purpose of the Inspection Process is to formally review the product and identify defects. The author of the product to be inspected notifies the Project Coordinator (PC) that the product is complete and ready for inspection.

Actions Responsibility
Planning Author/Moderator
Preparation Moderator
Inspection Moderator
Follow-up Moderator/Author

Table 3. Inspection Phases



Once the inspection is complete, the appropriate Inspection Checklist (Appendix A) will be used to validate the inspection. The moderator certifies that all necessary actions of the inspection are complete. The Inspection Report and combined Defect Log are created and filed in the TISK directory as a result of the inspection process.


7.1 Planning Phase

The purpose of the Planning Phase is to ensure that the product to be inspected is properly prepared. The author assembles all software elements necessary for the inspection in the TISK directory to allow easy access for the entire inspection team. The author then notifies the Project Coordinator (PC) that the TISK is ready for inspection. Notification may be in the form of an E-mail message or phone call to the PC. Minimum criteria, if applicable, shall include:

Actions Responsibility
Assemble items to be inspected Author
Select moderator from SQA group PC
Review inspection items for completeness Moderator
Select and notify inspection team PC
Assign roles PC
Schedule inspection Moderator

Table 4. Planning Phase


Note: It is strongly recommended that all of the Software Engineer Leads participate in each inspection. This will allow team members to be kept informed as to changes that could affect other groups.

The moderator certifies that the product to be inspected is complete, the team is selected and notified, and all scheduling actions are accomplished. The outputs for this phase include the assembled product to be inspected, the Defect Log form and the appropriate inspection checklist (Appendix A), if applicable. Inspection forms may be downloaded from the Forms directory.


7.2 Preparation Phase

The purpose of the Preparation Phase is to ensure that the team conducting the inspection is properly prepared. Each member of the inspection team is provided access to the product to be inspected.

Actions Responsibility
Review all items to be inspected Inspectors
Record identified defects on individual Defect Log Inspectors
Record inspection preparation times on individual Defect Log Inspectors
Send copy of individual Defect Log to moderator 48 hours prior to inspection meeting Inspectors
One day prior to the inspection, notify PC and Client (by E-mail) of any Inspectors who failed to provide a Defect Log * Moderator
Combine all individual Defect Logs in a logical order to present during the inspection meeting ** Moderator
Disperse the combined Defect Log to all inspection participants for review 24 hours prior to the meeting Moderator

Table 5. Preparation Phase


Notes:

*The moderator may reschedule the inspection to provide all participants an additional opportunity to prepare adequately for the inspection.

**After reviewing the combined list of defects, the moderator will decide whether the inspection can be completed in a reasonable time. If the moderator feels that the inspection could take excessive time (based on the number of defects reported), the moderator may consult with the author in order to determine if the TISK is really ready to be inspected. If not, the author has the responsibility of making all changes necessary to allow for an inspection to occur. The scheduled inspection is canceled.


Each inspector uses the appropriate checklist (Appendix A) and standards (Section 2.0) to review the inspection items and documents his/her findings on an individual defect log. The individual findings are consolidated into a combined Defect Log prior to, or at the Inspection meeting.

Notes: If more than a few spelling and/or grammatical mistakes are found, then the inspector may make a general comment to the author to check spelling and grammar rather than trying to record each on the Defect Log. A redlined copy of the inspection item may also be given to the author at the end of the inspection to aid in defect location.

7.3 Inspection Meeting

The purpose of the Inspection Meeting is to formally review the product and the identified defects.

Actions Responsibility
Review rules for inspections (Appendix A) Moderator
Confirm and record inspection preparation times Moderator
Systematically review the product being inspected* Reader
Present and clarify defects identified Inspectors
Note the status of each defect as agreed upon by the inspection team and categorize valid defects Recorder
Determine results of the inspection Moderator
Determine estimated rework effort and completion date Author
Notify PC of inspection results Moderator

Table 6. Inspection Meeting


Note:

*A systematic review normally involves checking each identified defect. The moderator may choose, if appropriate, to read the product line by line.

The moderator, with input from the inspection team, determines the inspection disposition (Accepted, Conditional, or Re-inspect, as defined below). The PC approves all re-inspections and rework efforts recommended by the inspection team. The combined list of defects is created as a result of the Inspection meeting.

Accepted - The product is complete, without any further verification of rework. No defects were found that caused the product to deviate from its specifications and there are only a very few trivial defects that can be left to the author to correct.

Conditional - Conditionally accept the product, with verification of the rework by the moderator. In this case there are some major defects, but they are few, and rework is not expected to create any substantial changes in the major design of the product.

Re-inspect - Re-inspect the authorís rework. The moderator will inform the PC if a re-inspection is required. This disposition requires that the rework be examined by the moderator, the author, and at least one other member of the inspection team in a reiteration of the inspection meeting. For this case, there are either a substantial number of major defects, or rework that will change the original design of the product. The re-inspection may or may not comprise the entire original product. The moderator will determine if the product needs to be reinspected in its entirety. In this case the inspection process for this product will commence at the beginning.

7.4 Follow-up

The purpose of the Follow-up is to ensure that any previous inspection defects have been corrected or resolved and that the inspection is accurately documented in the inspection report. All inspectors should agree that the list of defects is resolved or additional corrective actions identified to resolve concerns.

Actions Responsibility
Correct or resolve all noted defects Author
Validate corrections made by author (conditional disposition) Moderator
Complete the Inspection Report Moderator/Recorder
Post the Inspection Report to the TISK directory IAW SCM file naming conventions Moderator
Record metrics in the appropriate section of the TISK Process Checklist Moderator

Table 7. Follow-up



The moderator is responsible for certifying that any inspection discrepancies have been satisfactorily corrected or resolved and the Inspection Report and associated forms have been accurately completed.


APPENDIX A

INSPECTION PROCESS REFERENCES

This appendix provides additional information and checklists to be used in support of the inspection process. The included checklists may be tailored by projects as needed. Blank inspection forms are available from the Forms Directory. The following data will be collected for all inspections:

A1.0 Inspection Roles

The following paragraphs provide information as to the roles and responsibilities of the various inspection participants. The minimum roles required for an inspection are moderator/recorder, author/reader, and inspector (3 participants).

Author - The authorís role is to address specific questions that the reader is not able to answer, and to detect defects based upon their special understanding of the product. The author must not serve as moderator or recorder.

Moderator - The moderator ensures that the inspection procedures are followed, and that the other inspectors perform their responsibilities for each step of the inspection process. The Moderator may also serve as the Recorder and/or Reader.

Reader - The reader leads the team through the product in a comprehensive and logical manner. The reader shall be prepared to describe the various parts and functions of the product.

Recorder - The role of the recorder is to record and classify all of the defects detected at the inspection meeting, and to assist the moderator in preparing the inspection reports.

Inspector - All of the inspection team members are inspectors, including the author, regardless of their other roles.

A2.0 Rules for Inspections

A3.0 Inspection Checklists

The following checklists are provided to aid in inspections. These checklists are not only useful to the formal inspectors, but to the SEs that must be both author and peer reviewer during walk-throughs. The checklists are not intended to be all-inclusive, but only a starting point for inspections. Not all questions are pertinent to each inspection.

A3.1 Analysis Report Inspection Checklist

Support Material:

The following material should be provided to inspectors (if applicable):

Inspection Issues:

A3.2 Implementation Inspection Checklist

Support Material:

The following material should be provided to inspectors (if applicable):

Inspection Issues:

Structure

Variables

Loops and Branches

Defensive Programming

Documentation

Adapted from [FREE] and [WIEG95].


REVISION HISTORY


February 2001
Clark Reid
Editorial Changes

July 2000
Eischelle Krueger and Darsi Ewing
Clarified Inspection Procedures
Revised Walk-through Procedures
Removed Walk-through comment sheet
Added Analysis Report Inspection Checklist

July 1999
Tracie McCoy
Process Improvement Updates
Added Walk-through Procedures and Tisk Process Checklist section

Jan 1998
Donna Karlek
Updates per CR 3

June 1997
Tom Cothern, Diana Stallworth
HTM Updates

April 1996
Pete Tully, Orlando Figuero
Generic Process Update

Summer 1995
Scott Brown
Generic Process Update

January 25, 1994
Suzanne Nagy
Tisk 4 Update

August 2, 1994
T Stone, J Suarez-Beard
Final Document Revision

July 22, 1994
T Stone, J Suarez-Beard
Walk-through Document Revision

July 20, 1994
T Stone, J Suarez-Beard
Preliminary Document Revision

July 12, 1994
T Stone, J Suarez-Beard
Preliminary Document Revision

June 28, 1994
T Stone, J Suarez-Beard
Preliminary Document


BIBLIOGRAPHY

FREE
Freedman, D. & Weinberg, G. Handbook of Walkthroughs, Inspections, and Technical Reviews.
IEEE90
IEEE Std 610.12-1990, Standard Glossary of Software Engineering Terminology (ANSI)
WIEG95
Wiegers, K. "Improving Quality with Software Inspections." Software Development, April 1995.


GLOSSARY

Author
The producer of the software element(s) that are inspected.
Defect
A defect is either a deviation from standards and specifications; a non-conformance to applicable standards; or an instance of an unmet specification.
Inspection
"A statistical analysis technique that relies on visual examination of development products to detect errors, violation of development standards and other problems." [IEEE90]
Moderator
The chief planner and meeting manager of an inspection.
PC
Project Coordinator
Reader
During an inspection, the person who leads an inspection team through the software element(s) being inspected.
Recorder
The person who records defects identified during an inspection.
SE
Software Engineer
Software element
"A deliverable or in-process document." [IEEE90]
SQA
Software Quality Assurance