ASSISTing Exit Decisions in Software Inspection James Miller, Fraser Macdonald Dept. Computer Science, University of Strathclyde, Livingstone Tower, Richmond Street, Glasgow G1 1XH, Scotland E-mail: james@cs.ac.strath.uk Abstract Software inspection is a valuable technique for detect- ing defects in the products of software development. One avenue of research within inspection concerns the develop- ment of computer support. It is hoped that such support will provide even greater benefits when applying inspection. A number of prototype systems have been developed by re- searchers, yet these suffer from some fundamental limita- tions. One of the most serious of these concerns is the lack of facilities to monitor the process, and to provide the mod- erator with quantitative information on the performance of the process. This paper begins by briefly outlining the mea- surement component that has been introduced into the sys- tem, and especially discusses an approach to estimating the effectiveness of the current process. 1. Introduction Software inspection is a method for statically verifying documents. Unfortunately many organisations are failing to reap the significant benefits, due to their failure to imple- ment a full and rigorous inspection process. One solution to the problem of rigour lies in providing computer support for inspection, and to this end a number of prototype tools have been developed. Although existing systems present innovative approaches to supporting software inspection, in general they suffer from a number of shortcomings. Given the limitations of existing tool support, the authors have been working to design and implement a second genera- tion inspection support tool which embodies the important lessons learned from first generation tools, as well as tack- ling perceived weaknesses (ASSIST). This paper provides an overview of the measurement component that has been introduced into the system, and especially discusses an ap- proach to estimating the effectiveness (in terms of defect removal) of the current inspection process. 2. Measurement in ASSIST Despite having existed for twenty years, little is known about the software inspection process and its variations. This process has many variations including the method, team size, inspection rate, etc. Those issues, and many oth- ers, must be empirically explored to provide an understand- ing of optimal setting and their interactions. Further, organ- isations using an inspection process is interested in optimis- ing their inspection process — the collection of data on the performance of the previous inspections is the best way to achieve this. The measurement and instrumentation com- ponent of ASSIST can be subdivided into 3 distinct compo- nents: Measurement of the Process: This is perhaps the best known of the three measurement components, the measures here are like those found in standard process improvement programs. A full collection of relevant measures is desir- able, but extremely time consuming when attempted man- ually, and the literature suggests that many organisations either only collect a basic set of measures or collect no data. Gilb and Graham[5] list nearly one hundred differ- ent measures which should be collected during the various components of the inspection process. The collection of these measures are simple, efficient and effective using a computer-support system. Further, collection of the mea- sures is not in its self sufficient, the measures must be stored and analysed to allow process understanding and improve- ment. Again this task is easily accomplished by a computer- support system, but is a lengthy, and error-prone undertak- ing when executed manually. Monitor individual inspector's behaviour patterns: This set of measures seeks to capture the inspectors inter- action with the system and hence with the documents(s). These measures are important to researchers conducting ethnographic investigations about the behaviour of the in- spectors under various circumstances. e.g. the system could be used to record how an inspector attempts to build-up an understanding of a program, possibly of a specific type, for example an object-oriented program. Such a system can