@(#)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.
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).
Figure 1. Inspection Process
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.
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.
|Analysis Report||Analysis Report Inspection||Analysis Report Standard|
|Implementation Report||Implementation Inspection||Coding Standards, Unit Test Standard, and TCL Style Guide|
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.
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|
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.
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.
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:
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:
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
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:
|Assemble items to be inspected||Author|
|Select moderator from SQA group||PC|
|Review inspection items for completeness||Moderator|
|Select and notify inspection team||PC|
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.
|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|
*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.
|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|
*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.
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.
|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|
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.
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
The following material should be provided to inspectors (if applicable):
A3.2 Implementation Inspection Checklist
The following material should be provided to inspectors (if applicable):
Loops and Branches
Adapted from [FREE] and [WIEG95].