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:

• The Author of the product or the lead software engineer selects a software engineer/reviewer to perform the walk-through.
• The SE/Reviewer will review the product for completeness, accuracy, and compliance with standards and good practice.
• The SE/Reviewer will report any defects found to the author.
• The Author will correct and resolve all noted defects.
• The SE/Reviewer will update the TISK Process Checklist to confirm completion of the walk-through.
• The Author will notify SQA when the walk-through is complete.
• SQA will verify that the TISK Process Checklist has been updated.

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:

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.

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:

• Spelling and grammar checked
• Compliant with standards (see Section 2.0)
• Ensure inspection item is line numbered for easy reference by inspectors, if possible
• Code should compile clean

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.

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.

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.

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:

• Size of materials inspected
• Defects by severity, class, and type
• Preparation times prior to inspection
• Estimates of rework effort

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

• The maximum time scheduled for an inspection meeting should be about 2 hours.
• Start the meeting on time and move it along so that it finishes on schedule.
• Defer arguments over style or technique.
• Solutions or alternatives may be mentioned, but avoid spending too much time on group rework.
• Bring to the inspection meeting any references not already provided team members that may be useful (standards and reference documents).
• Address the product directly, do not attack the author.

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):

• Analysis Report (including any documents referenced by the Analysis Report)
• Set of deficiencies that make up the tisk
• Analysis Report Standard

• Is the Analysis Report in the required format?
• Is the Analysis Report compliant with the Analysis Report Standards or a written variance provided?
• Does the requirement specification portion of the Analysis Report capture all of the requirements identified by the set of deficiencies?
• Does the design solution meet the specified requirements?
• Is the time and resource estimation realistic?
• Have all source and documentation files that need to be changed been identified?

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

• All source code pertaining to the TISK, including code listings before and after changes were made (in line-numbered listings) and difference files as appropriate
• All documentation pertaining to the TISK before and after changes were made (in line-numbered listings) and difference files as appropriate
• The Analysis Report containing specifications and design for the TISK
• Standards and Guidelines referenced in Section 2.0

• Do all documents and code conform to the applicable standards and guidelines or a variance provided?
• Are all products, including documentation, necessary to implement the TISK complete and correct?
• Have the SEs certified that Unit Testing was performed in accordance with standards?
• Have all items passed the walk-through process?
• Does the proposed change do what it is supposed to do? That is, is it Correct?
• Does the proposed change ONLY do what is supposed to? That is, is it Consolidated? Review potential for changed code to cause undesirable side effects (ways in which a change can cause affect existing code and documentation).
• Does the proposed change keep the code from looking patched? That is, is it Clean? Use a generalized look at the new code in context, or review the new code against standards.

• File Opening/Closing: Will proposed changes cause files to be opened and/or closed at different points and/or with different attributes?
• Data Value Change: Will changes to data values within the scope of the proposed changes cause problems elsewhere?
• Parameter Change: Will proposed changes affect the specification of parameters to subroutines?
• File Position Change: Will proposed changes affect the files sensitive to record positioning?
• Invalid Pointer: Will proposed changes affect existing linked data structures, possibly causing pointer problems?
• Record Layout Change: Will proposed changes affect record layouts? If so, have all references to the records be reviewed and changed in kind?
• Does the code properly implement all requirements of the analysis report?
• Are there any unneeded or uncalled procedures (dead code)?
• Do processes occur in the correct sequence?
• Are user error messages meaningful and easy to understand?
• Is the code well-structured, consistent in style?
• Are there any blocks of repeated code that could be condensed into a single function?
• Are symbolics used rather than "magic numbers" constants or string constants?
• Is storage use efficient?

• Are the variables properly defined and given meaningful, clear, and consistent names?
• Did all assigned variables have proper type consistency and casting?
• Are there any redundant or unused variables?
• Are all array references in bounds?

• Are all loops, branches, and logic constructions complete, correct, and properly nested?
• Are all cases covered in an IF-THEN-ELSE or CASE block, including ELSE or DEFAULT clauses?
• Does the normal case flow follow the IF, not the ELSE?
• Does each case in a CASE statement have a break?
• Does every switch statement have a default?
• Are loop termination conditions obvious and invariably achievable?
• Are indexes or subscripts properly initialized just prior to the loop?
• Does the code in the loop avoid manipulating the index variable or using it upon termination of the loop?

• Are indexes, pointers, and subscripts tested against array, record, or file bounds?
• Are input arguments tested for validity and completeness?
• Are divisors tested for zero and noise?
• Are all output variables assigned?
• Are the correct data being operated on in each statement?
• Is every memory allocation being deallocated?
• Are files checked for existence before attempting to access them?
• Are cleanup routines used to make sure all files and devices are left in the correct state upon program termination?

• New Name: New data name, file name, and/or labels documented?
• Old Name Deleted: Are all documentation references to deleted names resolved?
• New Error Message: Are any new error messages included in their proper place in the documentation?
• Deleted Error Message: Are references to deleted error messages deleted?
• Accepts New Data/Rejects Old Data: How are changes in input to the program communicated to operators and users?
• New Data Interpretation: Question a design which changes the interpretation of existing inputs to the system.
• Is the code clearly and adequately documented?
• Are there any inconsistencies between code and comments?
• Is the commenting style easy to maintain?

Adapted from [FREE] and [WIEG95].

REVISION HISTORY

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