QuartzWare Logo








 

 

 

 

Subscribe To The Newsletter
"Timeless Software Solutions"
Team Planning Tracking Technical Deliverables Contact

Software Inspection Procedure

1. Work Product - The state of the source code is one of general maintenance(completed with need of review). Most of the major foundation classes are present as well as several of the secondary functions. There appears to be a slight presence of bugs scattered throughout the code however. In an inspection there should be about 250 lines of code inspected or about a few modules.
2. Participants - Quality Assurance will be there, Integration Manager, Configuration Manager and Tester will all be present.
3. Preparing for Inspection - As preparation each participant will get familiar with all the classes that are involved in each of the modules that will be inspected upon. In that sense everyone will know how each module interacts and hopefully give everyone a springboard into finding more bugs related to integration as well as coding bugs. Each member will be assigned some module and will be responsible in making a particular checklist for that module.
4. Refernce materials - None
5. Meeting - Any member who wants to appear may. However the QA, Integration and Tester must come and are crucial to Software Inspection. The time limit is about 3 hours. The purpose of the meeting is to inspect the overall quality, integration and functionality of the code. Each member of the inspection meeting will make a quick, concise report of the state of the code they reviewed and comment on any changes that need to be made. They will then put it on the web for all to behold. All changes are to be made within a week of the proposed changes.
6. Rework - Rework is done by whoever made the piece of code. Communication between the inspector of the code and the creator are mandatory at his own time. The code should then be reviewed by the code and the inspector.
7. Follow-up - The tester, integration, design and QA should all take a look at the code at some point after revision to see if it breaks.

8. Check-list:

1. Specification
Is the functionality described in the specification fully implemented by the code?
Is there any excess functionality implemented by the code but not described in the specification?
Is the program interface implemented as described in the speci cation?

2. Initialisation and Declarations
Are all local and global variables initialised before use?
Are variables and class members i) required, ii) of the appropriate type and iii) correctly scoped?

3. Function Calls
Are parameters presented in the correct order?
Are pointers and & used correctly?
Is the correct function being called, or should it be a di erent function with a similar name?

4. Arrays
Are there any o -by-one errors in array indexing?
Can array indexes ever go out-of-bounds?

5. Pointers and Strings
Check that pointers are initialised to NULL
Check that pointers are never unexpectedly NULL
Check that all strings are identi ed by pointers and are NULL-terminated at all points in the program

6. Dynamic Storage Allocation
Is too much/too little space allocated?

7. Output Format
Are there any spelling or grammatical errors in displayed output?
Is the output formatted correctly in terms of line stepping and spacing?

8. Computation, Comparisons and Assignments
Check order of computation/evaluation, operator precedence and parenthesising
Can the denominator of a division ever be zero?
Is integer arithmetic, especially division, ever used inappropriately, causing unexpected truncation/rounding?
Are the comparison and boolean operators correct?
If the test is an error-check, can the error condition actually be legitimate in some cases? Does the code rely on any implicit type conversions?

9. Flow of Control
In a switch statement, is any case not terminated by break or return?
Do all switch statements have adefault branch?
Are all loops correctly formed, with the appropriate initialisation, increment and termination expressions?

10. Files Are all les properly declared and opened? Is a le not closed in the case of an error? Are EOF conditions detected and handled correctly?

Version History:
2/1/01 - Document Created - Albert Lee

 

 

 

| home | team | planning | tracking | technical | deliverables | contact |

Copyright (c) 2000 QuartzWare. All rights reserved.
Site created by Anthony Tomarchio of Teknokratz, Inc.