Code inspection techniques comp.software-eng archive file "inspect" last changed 30 Jul 1993 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 2 Code Inspections 1 Code Inspections : Summary 2 Fagan's formal inspection methodology? 1 Software Inspections 5 What factors impact code inspection product 1 bibliography on software inspections 1 code inspection tool info 1 need info on code inspection tools ------------------------------------------------------------------------ ------------------------------------------------------------------------ Date: Thu, 11 Feb 93 08:17:33 EST From: bryk@ida.org (Bill Brykczynski) Subject: bibliography on software inspections (Note: An earlier version of this bibliography was published in ACM Software Engineering Notes, Jan. 1993, Vol. 18, No. 1, pp 81-88. I'll periodically update this archive, so if you are aware of additional references on inspection, please email them to me. bill, 2/11/93) An Annotated Bibliography on Software Inspections Bill Brykczynski David A. Wheeler Institute for Defense Analyses 1801 N. Beauregard St. Alexandria, VA 22311-1772 bryk@ida.org wheeler@ida.org 703-845-6641 703-845-6662 The technique of formal software inspection has existed for over fifteen years. The productivity and quality benefits that result from an effective inspection process are impressive. However, software inspections are not yet practiced routinely in industry. There is a variety of information relating to software inspections available in the literature, but to our knowledge a comprehensive bibliography on the subject has not yet been published. Below is the authors' bibliography of inspection-related references. Abstracts are provided verbatim for some of the references. The bibliography is separated into three parts. Part I contains references focusing on the subject of software inspection. Part II provides additional references relating to software reviews and walkthroughs. Part III identifies software engineering textbooks that have chapters discussing inspection techniques. Software inspections are a detailed examination of a work product, such as requirements, design, code, and test cases. Inspections follow a defined process, involving steps such as work product overview, preparation, inspection, rework, and follow-up. The inspected work product is small, for example, four to five pages of code. The inspection meeting is attended by a small number (e.g., four to five) of coworkers and lasts less than two hours. A role (e.g., moderator, author, reader, tester) is assigned to each inspector, and the primary objective of the inspection is to detect defects. The work product author is responsible for defect removal, and corrections or suggested improvements are not allowed during the inspection meeting. The reader paraphrases the work product during the inspection meeting. Error-cause analysis is usually performed after an inspection to identify process improvements that would prevent future occurrences of the same type of defect. If you want to quickly learn about inspections and their productivity and quality benefits, the authors recommend reading the following three papers: [Fagan 1986], [Kelly 1992], and [Russell 1991]. If references of particular significance have been omitted, the authors would appreciate hearing about them. Part I - Inspection References [Ackerman 1982] Ackerman, A. Frank, Amy S. Ackerman, and Robert G. Ebenau. "A Software Inspections Training Program," COMPSAC `82: 1982 Computer Software and Applications Conference, Chicago, IL Nov. 8-12, pp. 443-444. IEEE Computer Society Press. [Ackerman 1984] Ackerman, A. Frank, Priscilla J. Fowler, and Robert G. Ebenau. 1984. "Software Inspections and the Industrial Production of Software," Software Validation, H.L. Hausen, ed., pp. 13-40, Elsevier, Amsterdam. Abstract: Software inspections were first defined by M.E. Fagan in 1976. Since that time they have been used within IBM and other organizations. This paper provides a description of software inspections as they are being utilized within Bell Laboratories and the technology transfer program that is being used for their effective implementation. It also describes the placement of software inspections within the overall development process, and discusses their use in conjunction with other verification and validation techniques. [Ackerman 1989] Ackerman, A. Frank, Lynne S. Buchwald, and Frank H. Lewski. "Software Inspections: An Effective Verification Process," IEEE Software, Vol. 6, No. 3, May 1989, pp. 31-36. Abbreviated Introduction: This article is an attempt to clarify what software inspections are, to explain how you can use them to improve both your process and your product, and to summarize what is known about their effectiveness. [Ascoly 1976] Ascoly, J., M.J. Cafferty, S.J. Gruen, and O.R. Kohli. "Code Inspection Specification," IBM Corp., Kingston, NY, Technical Report TR 21.630, 1976. [Bisant 1989] Bisant, David B., and James R. Lyle. "A Two-Person Inspection Method to Improve Programming Productivity," IEEE Transactions on Software Engineering, Vol. 15, No. 10, Oct. 1989, pp. 1294- 1304. Abstract: This paper reviews current research and investigates the effect of a two-person inspection method on programmer productivity. This method is similar to the current larger team method in stressing fault detection, but does not use a moderator. The experiment used a Pretest-Posttest Control Group design. An experimental and control group of novices each completed two programming assignments. The amount of time taken to complete each program. (Time1, Time2) was recorded for each subject. The subjects of the experimental group did either a design inspection, a code inspection, or both during the development of the second program. An analysis of variance was performed and the relationship between Time1 and Time2 was modeled for both groups. A comparison of the models revealed the experimental group improved significantly in programming speed as a result of using the two-person inspection. It also appeared as though this method was more effective at improving the performance of the slower programmers. This two-person method could have its application in those environments where access to larger team resources is not available. If further research establishes consistency with this method then it might be useful as a transition to the larger team method. [Blakely 1991] Blakely, Frank W. and Mark E. Boles. "A Case Study of Code Inspections," Hewlett-Packard Journal, Vol. 42, No. 4, Oct. 1991, pp. 58-63. Abstract: Code inspections have become an integral part of the software development life cycle in many organizations. Because it takes some project time and because engineers initially feel intimidated by the process, code inspections have not always been readily accepted. Additionally, there has not always been enough evidence (metrics) to provide that for the time and effort invested, the process has any value in reducing defects and improving overall software quality. Since the early days, the process has become better understood and documented, and recent articles have provided concrete metrics and other evidence to justify the value of the process. This paper describes our experiences in bringing the code inspection process to HP's Application Support Division (ASD). We describe both the positive and negative findings related to using code inspections. Although we only have metrics for one project, out main goal here is to present how we implemented the inspection process and to illustrate the type of data to collect and what might be done with the data. [Bollinger 1992] Bollinger, Donald E., Frank P. Lemmon, and Dawn L. Yamine. "Providing HP-UX kernel Functionality on a New PA-RISC Architecture." Hewlett-Packard Journal, Vol. 43, No. 3, Jun. 1992, pp. 11-15. Abstract: Hewlett-Packard Co's HP 9000 Series 700 workstation development goals required that the HP- UX kernel laboratory change the normal software development process, the number of product features and the management structure. The laboratory wanted to change or add the minimum number of HP-UX kernel functions that meet customer needs and its own performance goals while also adapting to a new I/O system. The resulting HP-UX kernel code is called minimum core functionality (MCF). The management structure was changed to allow small teams of individual developers and first-level managers to make important program decisions quickly and directly. The performance team included members from hardware, kernel, languages, graphics and performance measurement groups; the team's goal was to maximize system performance in computation, graphics and I/O. The quality control plan, certification process, design and code reviews, branch and source management and test setup process are described. [Britcher 1988] Britcher, Robert N. "Using Inspections to Investigate Program Correctness," IEEE Computer, Vol. 21, No. 11, Nov. 1988, pp. 38-44. Conclusion: As we develop better tools for recording and compiling software designs and code, those who think about and practice programming will take greater interest in the more obscure aspects of a program: its intent, meaning, resilience, and developmental history. Although the problem of writing correct programs, especially those embedded within large systems or products, remains largely unsolved in practice, the situation is improving. We can use inspections to further the investigation into how correct programs are constructed. Several such inspections will be carried out to determine their usefulness and refine their practice. The purpose of incorporating correctness arguments into inspections is not to improve inspections, but to improve programming. This is not a modest objective. Steps will necessarily be small. [Brothers 1990] Brothers, L., V. Sembugamoorthy, and M. Muller. "ICICLE: Groupware for Code Inspection," CSCW 90: Proceedings of the ACM Conference on Computer Supported Cooperative Work, Oct. 1990, pp. 169-181. [Brykczynski 1993] Brykczynski, Bill, and David A. Wheeler. "An Annotated Bibliography on Software Inspections," ACM Software Engineering Notes, Jan. 1993, Vol. 18, No. 1, pp 81-88. [Buck 1981] Buck, F.O. "Indicators of Quality Inspections," IBM Corp., Technical Report TR21.802, Sep. 1981. [Buck 1984] Buck, Robert D. and James H. Dobbins. 1984. "Application of Software Inspection Methodology in Design and Code," Software Validation, H.L. Hausen, ed., Elsevier, Amsterdam, pp. 41-56. [Bush 1990] Bush, Marilyn. "Improving Software Quality: The Use of Formal Inspections at the Jet Propulsion Laboratory," 12th International Conference on Software Engineering, 1990, pp. 196-199, IEEE Computer Society Press. Abstract: Finding and fixing defects early in the software development life cycle is much cheaper than finding and fixing the same defects later on. After surveying detection practices in the best of industry, JPL Software Product Assurance decided that the most cost-effective early defect detection technique was the "Fagan inspection" procedure. This paper will describe this technique, how it was introduced to JPL, some of the difficulties involved in "transferring technology" and the first provisional set of results. [Chaar 1992] Chaar, J.K., M.J. Halliday, I.S. Bhandari, and R. Chillarege. "In-process Metrics for Software Inspection and Test Evaluations," IBM Corp., Technical Report 80725, 1992. [Christenson 1987] Christenson, Dennis A. and Steel T. Huang. "Code Inspection Management Using Statistical Control Limits," National Communications Forum, Vol. 41, No. 2, Chicago, IL, 1987, pp. 1095-1100. [Christenson 1988] Christenson, Dennis A. and Steel T. Huang. "A Code Inspection Model for Software Quality Management and Prediction," GLOBECOM `88. IEEE Global Telecommunications Conference and Exhibition, Hollywood, FL, 1988, pp. 468-472. [Christenson 1990] Christenson, Dennis A., Steel. T. Huang, and Alfred J. Lamperez. "Statistical Quality Control Applied to Code Inspections," IEEE Journal on Selected Areas in Communications, Vol. 8, No. 2, Feb. 1990, pp. 196- 200. Abstract: Code inspections have been used on the 5ESS Switch project since 1983. Beginning wit ha training program for all the developers involved in the project, code inspections have improved with each new 5ESS Switch generic. The improvement in code inspections has been the result of hard work and innovation on the part of the 5ESS Switch software developers, and the use of some "Statistical Quality Control" (SQC) techniques. Variations on a standard SQC technique, the control chart, have been used to track the metrics indicative of the effectiveness of code inspections. Parameters used in the computation of these metrics include the preparation effort, inspection time, number of inspectors, the size of the inspected unit of code, and the number of errors found at the inspection. The exact form that these "control charts" have taken has evolved and improved with experience. [Collofello 1987] Collofello, James S. "Teaching Technical Reviews in a One-Semester Software Engineering Course," ACM SIGCSE Bulletin, Vol. 19, No. 1, Feb. 1987, pp. 222- 227. Abstract: Software technical reviews are essential to the development and maintenance of high quality software. These review processes are complex group activities for which there exist an abundance of basic concepts evolved over years of practical experience. In a typical one-semester software engineering course very little of this information is adequately conveyed to students. Texts supporting this course are also very weak in this area. This paper provides a practical approach for teaching about software technical reviews in a one-semester software engineering course. The contents for two to three lectures on this topic are described as well as suggested exercises and an approach for integrating technical reviews with the usual team project. An extensive annotated bibliography is also provided to assist instructors and students. [Collofello 1988] Collofello, James S. "The Software Technical Review Process," Curriculum Module SEI-CM-3-1.5, The Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA, Jun. 1988. Capsule Description: This module consists of a comprehensive examination of the technical review process in the software development and maintenance life cycle. Formal review methodologies are analyzed in detail from the perspective of the review participants, project management and software quality assurance. Sample review agendas are also presented for common types of reviews. The objective of the module is to provide the student with the information necessary to plan and execute highly efficient and cost effective technical reviews. [Cross 1988] Cross, John A., ed. "Support Materials for the Software Technical Review Process," Support Materials SEI-SM-3-1.0, Software Engineering Institute, Pittsburgh, PA, Apr. 1988. [Crossman 1977] Crossman, Trevor D. "Some Experiences in the Use of Inspection Teams," 15th Annual ACM Computer Personnel Research Conference, Aug. 1977, p. 143. [Crossman 1979] Crossman, Trevor D. "Some Experiences in the Use of Inspection Teams in Application Development," Applications Development Symposium, Monterey, CA, Oct. 1979. pp. 163-168. [Crossman 1982] Crossman, Trevor D. "Inspection Teams, Are They Worth It?" Proceedings 2nd National Symposium on EDP Quality Assurance, Chicago, IL, Mar. 24-26, 1982. [Deimel 1991] Deimel, L.E. "Scenes of Software Inspections. Video Dramatizations for the Classroom," Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA, CMU/SEI-91-EM-5, May 1991. Abstract: This report describes the videotape "Scenes of Software Inspections," which contains brief dramatizations that demonstrate appropriate and inappropriate conduct of software inspections. The tape also includes scenes that show other kinds of group interactions. Any of these scenes can be incorporated into lectures, self-study materials, or other educational delivery mechanisms, to illustrate how to perform inspections, an important software engineering technique. [Dichter 1992] Dichter, C.R. "Two Sets of Eyes: How Code Inspections Improve Software Quality and Save Money," Unix Review, Vol. 10, No. 2, Feb. 1992, pp. 173-182. Abstract: Programmers can detect a large percentage of software bugs by inspecting code to supplement testing. Testing alone will not determine if code will work on different platforms, if it is written efficiently and whether it adheres to particular coding guidelines or standards. Inspections and walkthroughs are two kinds of software reviews. Programmers perform inspections by sequential reading of code to search for bugs by using an inspection checklist. In walkthroughs, inspectors play the role of the computer by searching the code for logical errors. Programmers can start improving code by using advanced linter tools and then inspecting code for errors the linter will not catch. Code-counting tools are also helpful. Programmers may find that inspections on code of more than 1,000 lines will help find bugs that testing would not turn up and which would be more expensive to correct later. [Dobbins 1987] Dobbins, J.H. 1987. "Inspections as an Up-Front Quality Technique," Handbook of Software Quality Assurance, G.G. Schulmeyer and J.I. McManus, eds., pp. 137-177, NY: Van Nostrand Reinhold. [Doolan 1992] Doolan, E. P. "Experience with Fagan's Inspection Method," Software-Practice and Experience, Vol. 22, No. 2, Feb. 1992, pp. 173-182. Abstract: Fagan's inspection method was used by a software development group to validate requirements specifications for software functions. The experiences of that group are described in this paper. In general, they have proved to be favourable. Because the costs of fixing errors in software were known, the payback for every hour invested in inspection was shown to be a factor 30. There are also other benefits that are much more difficult to quantify directly but whose effect is significant in terms of the overall quality of the software. Some pointers are given at the end of this paper for those who want to introduce Fagan's inspection method into their own development environment. [Ebenau 1981] Ebenau, R.G. "Inspecting for Software Quality," Second National Symposium in EDP Quality Assurance, 1981. DPMA Educational Foundation, U.S. Professional Development Institute, Inc., 12611 Davon Drive, Silver Spring, MD 20904. [Fagan 1976a] Fagan, Michael E. "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, Vol. 15, No. 3, 1976, pp. 182-211. Abstract: Substantial net improvements in programming quality and productivity have been obtained through the use of formal inspections of design and of code. Improvements are made possible by a systematic and efficient design and code verification process, with well-defined roles for inspection participants. The manner in which inspection data is categorized and made suitable for process analysis is an important factor in attaining the improvements. It is shown that by using inspection results, a mechanism for initial error reduction followed by ever-improving error rates can be achieved. [Fagan 1976b] Fagan, M.E. "Design and Code Inspections and Process Control in the Development of Programs," IBM Corp., Poughkeepsie, NY, Technical Report TR 00.2763, Jun. 10, 1976. This report is a revision of "Design and Code Inspections and Process Control in the Development of Programs," IBM Corp., Kingston, NY, Technical Report TR 21.572, Dec. 17, 1974. [Fagan 1977] Fagan, Michael E. "Inspecting Software Design and Code," Datamation, Oct. 1977, pp. 133-144. [Fagan 1986] Fagan, Michael E. "Advances In Software Inspections," IEEE Transactions on Software Engineering, Vol. 12, No. 7, Jul. 1986, pp. 744-751. Abstract: This paper presents new studies and experiences that enhance the use of the inspection process and improve its contribution to development of defect-free software on time and at lower costs. Examples of benefits are cited followed by descriptions of the process and some methods of obtaining the enhanced results. Software inspection is a method of static testing to verify that software meets its requirements. It engages the developers and others in a formal process of investigation that usually detects more defects in the product-at and lower cost-than does machine testing. Users of the method report very significant improvements in quality that are accompanied by lower development costs and greatly reduced maintenance efforts. Excellent results have been obtained by small and large organizations in all aspects of new development as well as in maintenance. There is some evidence that developers who participate in the inspection of their own product actually create fewer defects in future work. Because inspections formalize the development process, productivity and quality enhancing tools can be adopted more easily and rapidly. [Fowler 1986] Fowler, Priscilla J. "In-Process Inspections of Workproducts at AT&T," AT&T Technical Journal, Vol. 65, No. 2, Mar./Apr. 1986, pp. 102-112. Abstract: In-process inspections are examination meetings held to find defects in design and development work products, including intermediate versions of the product or system in requirements and design documents. Because these inspections delimit the phases of design and development processes, they can prevent the passage of defects from one phase to the next and significantly reduce the number of defects released to customers. Software development projects within AT&T's research and development community have been using in-process inspections effectively for several years to reduce defects, and hardware projects began using them one and a half years ago. In addition, the experience of installing in-process inspections in project organizations has yielded a wealth of information on technology transfer. This article defines inspections, describes the installation process, and discussed some uses for inspection data. [Freedman 1982] Freedman, Daniel P. and Gerald M. Weinberg. 1982. Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products. 3rd ed. Boston, MA: Little, Brown and Company. [Gilb 1991] Gilb, Tom. "Advanced Defect Prevention Using Inspection, Testing, and Field Data as a Base," American Programmer, May 1991, pp. 38-45. [Graden 1986] Graden, Mark E. and Palma S. Horsley. "The Effects of Software Inspections on a Major Telecommunications Project," AT&T Technical Journal, Vol. 65, No. 3, May/Jun. 1986, pp. 32-40. Introduction: Software inspections are a highly formalized and rigorous technique used for the identification and removal of errors in software products. Faithfully applied, they have beneficial impact on the productivity and quality of a project. As a result, software inspections were selected as a critical ingredient in the overall Software Quality Assurance Plan to guide the development and evolution of a major, real time telecommunications software project. This paper describes how the results of software inspections have been sued to explain differences in end-product quality and identifies useful techniques for applying the results of software inspections to manage the software development process. [Hale 1978] Hale, R. M. "Inspections in Application Development-Introduction and Implementation Guidelines," IBM Corp., Form GC20-2000-0 (Jul. 1977) updated by TNL GN20-3814 (Aug. 1978). [Hollocker 1990] Hollocker, Charles P. 1990. Software Reviews and Audits Handbook, NY: John Wiley & Sons. [IBM 1976] IBM. "Code Reading, Structured Walkthroughs, and Inspections," IBM Corp., Report GE-19-5200, Zoetermeer, Netherlands, 1976. [Kelly 1992] Kelly, John C., Joseph S. Sherif, and Jonathan Hops. "An Analysis of Defect Densities Found During Software Inspections," Journal of Systems and Software, Vol. 17, No. 2, Feb. 1992, pp. 111-117. Abstract: Software inspection is a technical evaluation process for finding and removing defects in requirements, design, code, and tests. The Jet Propulsion Laboratory (JPL), California Institute of Technology, tailored Fagan's original process of software inspections to conform to its software development environment in 1987. Detailed data collected from 203 inspections during the first three years of experience at JPL included averages of staff time expended, pages covered, major and minor defects found, and inspection team size. The data were tested for homogeneity. Randomized samples belonging to the various phases or treatments were analyzed using the completely randomized block design analysis of variance (a = 0.05). The results showed a significantly higher density of defects during requirements inspections. The number of defect densities decreased exponentially as the work products approached the coding phase because defects were fixed when detected and did not migrate to subsequent phases. This resulted in a relatively flat profile for cost to fix. Increasing the pace of the inspection meeting decreased the density of defects found. This relationship held for major and minor defect densities, although it was more pronounced for minor defects. [Kitchenham 1986] Kitchenham, B.A., Kitchenham, A.P., and J.P. Fellows. "Effects of Inspections on Software Quality and Productivity," ICL Technical Journal, Vol. 5, No. 1, May 1986, pop. 112-122. [Knight 1991] Knight, John C. and Ethella Ann Myers. "Phased Inspections and their Implementation," University of Virginia, Computer Science Report No. TR-91-10. May 12, 1991. Also published in ACM Software Engineering Notes, Vol. 16, No. 3, Jul. 1991, pp. 29- 35. Abstract: Since the 1970s, non-mechanical review methods have become very popular as verification tools for software products. Examples of existing review methods are formal reviews, walkthroughs, and inspections. Another example is Fagan Inspections, developed in 1976 by Michael Fagan in an effort to improve software quality and increase programmer productivity. Fagan Inspections and other existing methods have been empirically shown to benefit the software development process, mainly by lowering the number of defects in software early in the development process. Despite this success, existing methods are limited. They are not rigorous, therefore, they are not dependable. A product that has been reviewed with an existing method has no quantitative qualities that are ensured by the method used. This thesis presents a new review method, Phased Inspection, that was developed to be rigorous, reliable, tailorable, heavily computer supported, and cost effective. Phased Inspection consists of a series of partial inspections termed phases. Each phase is intended to ensure a single or small set of related properties. Phases are designed to be as rigorous as possible so that compliance with associated properties is ensured, at least informally, with a high degree of confidence. A detailed description of Phased Inspection, and evaluation framework and preliminary evaluation, and a prototype toolset for support of Phased Inspection is presented. [Kohli 1975] Kohli, Robert O. "High-Level Design Inspection Specification," IBM Corp., Kingston, NY, Technical Report TR 21.601, Jul. 21, 1975. [Kohli 1976] Kohli, Robert O. and R.A. Radice. "Low-Level Design Inspection Specification," IBM Corp., Kingston, NY, Technical Report TR 21.629, 1976. [Koontz 1986] Koontz, W.L.G. "Experience with Software Inspections in the Development of Firmware for a Digital Loop Carrier System," IEEE International Conference on Communications, 1986 Conference Record, pp. 1188-1189. [Larson 1975] Larson, R.R. "Test Plan and Test Case Inspection Specification," IBM Corp., Kingston, NY, Technical Report TR21.585, Apr. 4, 1975. [Martin 1990] Martin, Johnny, and W.T. Tsai. "N-fold Inspection: A Requirements Analysis Technique," Communications of the ACM, Vol. 33, No. 2, Feb. 1990, pp. 225-232. Abstract: N-fold inspection used traditional inspections of the user requirements document (URD) but replicates the inspection activities using N independent teams. A pilot study was conducted to explore the usefulness of N-fold inspection during requirements analysis. A comparison of N-fold inspection with other development techniques reveals that N-fold inspection is a cost-effective method for finding faults in the URD and may be a valid technique in the development of mission-critical software systems. [McCormick 1981] McCormick, K.K. "The Results of Using a Structured Methodology, Software Inspections, and a New Hardware/Software Configuration on Application Systems," Second National Symposium in EDP Quality Assurance, 1981. DPMA Educational Foundation, U.S. Professional Development Institute, Inc., 12611 Davon Drive, Silver Spring, MD 20904. [McKissick 1984] McKissick, John Jr., Mark J. Somers, and Wilhelmina Marsh. "Software Design Inspection for Preliminary Design," COMPSAC `84: 1984 Computer Software and Applications Conference, Las Vegas, NV, Jul. 1984, pp. 273-281. Abstract: The continuing need for improved computer software demands improved software development techniques. A technique for the inspection of preliminary software designs is described in this paper. Experience and results from the application of this technique are presented. [Myers 1978] Myers, Glenford J. "A Controlled Experiment in Program Testing and Code Walkthroughs- Inspections," Communications of the ACM, Vol. 21, No. 9, Sep. 1978, pp. 760-768. Abstract: This paper describes an experiment in program testing, employing 59 highly experienced data processing professionals using seven methods to test a small PL/1 program. The results show that the popular code walkthrough/inspection method was as effective as other computer-based methods in finding errors and that the most effective methods (in terms of errors found and cost) employed pairs of subjects who tested the program independently and then pooled their findings. The study also shows that there is a tremendous amount of variability among subjects and that the ability to detect certain types of errors varies from method to method. [O'Neill 1991] O`Neill, Don. "What is the Standard of Excellence?" IEEE Software, May 1991, pp. 109-111. [Peele 1982a] Peele, R. "Code Inspections at First Union Corporation," COMPSAC `82: 1982 Computer Software and Applications Conference, Chicago, IL Nov. 8-12, 1982, pp. 445-446, IEEE Computer Society Press. Abbreviated Introduction: During 1980, a task force was formed within the Systems Development Division of First Computer Services to examine the coding and testing functions and to recommend ways to increase productivity and improve the quality of these functions while maintaining high staff morale. The task force evaluated the Design and Code Inspection process developed by Mike Fagan of IBM and concluded that this approach offered [several] potential quality assurance benefits. [Peele 1982b] Peele, R. "Code Inspection Pilot Project Evaluation," Second National Symposium in EDP Quality Assurance, DPMA Educational Foundation, U.S. Professional Development Institute, Inc., 12611 Davon Dr., Silver Spring, MD 20904. Abstract: At First Computer, a code inspection is conducted after the coding of a program or module is complete as indicated by a clean compilation of the program and prior to unit testing of the program. The completed program specifications and a clean compilation are the entry criteria for the inspection process. An inspection team at First Computer consists of four members: one moderator and three inspections. The moderator is the key person in the process with the responsibility to ensure the best possible review of the program. The moderator approves the team members for the inspection and makes the necessary decisions related to scheduling and conducting the sessions. The moderator is the facilitator of the inspection meetings but is also an active participant charged with finding defects. The moderator must log all defects found during the sessions, ensure that all defects found are corrected by the author, and decide whether or not to reinspect the code. [Reeve 1991] Reeve, J.T. "Applying the Fagan Inspection Technique," Quality Forum, Vol. 17, No. 1, Mar. 1991, pp. 40-47. Abstract: This paper asks and briefly explains what Fagan inspection is, and how it differs from more established techniques. It proposes how the technique may be used as an integral part of the product appraisal process from initial proposal to release to customer. A proven plan of action for establishment of the technique is also proposed, together with evidence of its success. [Remus 1984] Remus, Horst. 1984. "Integrated Software Validation in the View of Inspections/Reviews," Software Validation, H.L. Hausen, ed., pp. 57-64, Elsevier, Amsterdam. Abstract: The Software Development Process is being looked at as to the specific contribution of inspections/reviews to the discovery of wrong design directions or implementations. The benefits are evaluated under the aspects of quality/productivity improvement and/or cost savings. [Runge 1982] Runge, B. "The Inspection Method Applied to Small Projects," 6th International Conference on Software Engineering, 1982, pp. 416-417. Abstract: The Inspection Method is a quality-control for written material. It is used on large projects and takes 3 to 8 persons for correct use. This excludes small projects with less than three persons from proper inspection. This paper shows how the personnel restriction may be circumvented in small projects. An example of inspection in a small project (writing a report) is given. [Russell 1991] Russell, Glen W. "Experience with Inspection in Ultralarge-Scale Developments," IEEE Software, Vol. 8, No. 1, Jan. 1991, pp. 25-31. Abbreviated Introduction: inspections can be very cost-effective and highly beneficial, even when scaled up for ultralarge projects. Here I present quantitative results based on a 1988 study of inspection of 2.5 million lines of high-level code at Bell-Northern Research. The data represent one of the largest published studies in the industry and confirm that code inspection is still one of the most efficient ways to remove software defects. In the box on pp. 28-29, I describe how to successfully introduce inspections in large-scale production environments. [Schneider 1992] Schneider, G. Michael, Johnny Martin, and W.T. Tsai "An Experimental Study of Fault Detection in User Requirements Documents," ACM Transactions on Software Engineering and Methodology, Vol. 1, No. 2, Apr. 1992, pp. 188-204. Abstract: This paper describes a software engineering experiment designed to confirm results from an earlier project which measured fault detection rates in user requirements documents (URD). The experiment described in this paper involves the creation of a standardized URD with a known number of injected faults of specific type. Nine independent inspection teams were given this URD with instructions to locate as many faults as possible using the N-fold requirements inspection technique developed by the authors. Results obtained from this experiment confirm earlier conclusions about the low rate of fault detection in requirements documents using formal inspections and the advantages to be gained using the N-fold inspection method. The experiment also provides new results concerning variability in inspection team performance and the relative difficult of locating different classes of URD faults. [Sherif 1992] Sherif, Joseph S. and John C. Kelly. "Improving Software Quality Through Formal Inspections," Microelectronics and Reliability, Vol. 32, No. 3, Mar. 1992, pp. 423-431. Abstract: The software inspection process was created for the dual purpose of improving software quality and increasing programmers' productivity. This paper puts forward formal inspections as an alternative to and a better method than technical walkthroughs in the software lifecycle reviewing process. Examples of benefits gained in the development of defect-free software by utilizing formal inspections are cited. [Shirey 1992] Shirey, Glen C. "How Inspections Fail," 9th International Conference on Testing Computer Software, Jun 15-18, 1992, Washington DC, pp. 151-159. Abstract: This paper discusses an experience in the application of inspections in software development and how a concentration on the mechanics of the technology rather than acting on the information it provides failed to improve product quality. In this paper practitioners will find a comprehensive inspection model used to audit the inspection practices of the group studied. Managers will find examples of how to integrate the information provided by inspections into their Software Development Process. [Weinberg 1984] Weinberg, Gerald M. and Daniel P. Freedman. "Reviews, Walkthroughs, and Inspections," IEEE Transactions on Software Engineering, Vol. 12, No. 1, Jan. 1984, pp. 68-72. Abstract: Formal technical reviews supply the quality measurement to the "cost effectiveness" equation in a project management system. There are several unique formal technical review procedures, each applicable to particular types of technical material and to the particular mix of the Review Committee. All formal technical reviews produce reports on the overall quality for project management, and specific technical information for the producers. These reports also serve as an historic account of the systems development process. Historic origins and future trends of formal and informal technical reviews are discussed. [Weller 1992a] Weller, Edward F. "Experiences with Inspections at Bull HN Information Systems," 4th Annual Software Quality Workshop, Aug. 2-6, 1992, Alexandria Bay, NY. Abstract: Bull's experiences with the inspection process over the last two years will be discussed by using four case studies. Several successes as well as one "failure" are included. Data for requirements, design, and code inspections, and how it has been used outside the inspection process, are also presented. [Weller 1992b] Weller, Edward F. "Lessons Learned from Two Years of Inspection Data," 3rd International Conference on Applications of Software Measurement, Nov. 15-19, 1992, La Jolla, CA, pp. 2.57-2.69. Also published in Crosstalk: The Journal of Defense Software Engineering, No. 39, Dec. 1992, pp. 23-28. Abstract: Bull HN Information System's Major Systems Division in Phoenix initiated an inspection program in April 1990. Data collection was crucial to early buy-in to the inspection process. During the last 2 years, this data has been used to highlight potential direction for continuing process improvement. The data is also the basis for continuing development staff and management commitment to the program. Various metrics and the conclusions we have drawn from them will be discussed. A "case study" approach will highlight both the "good" and "bad" uses of inspection data for software process management. [Wenneson 1985] Wenneson, G. "Quality Assurance Software Inspections at NASA Ames: Metrics for Feedback and Modification," Tenth Annual Software Engineering Workshop, December 10, 1985, Goddard Space Flight Center. Part II - Review/Walkthrough-related References [Bias 1991] Bias, Randolph. "Walkthroughs: Efficient Collaborative Testing," IEEE Software, Vol. 8, No. 5, Sep. 1991, pp. 94-95. [Hart 1982] Hart, J. "The Effectiveness of Design and Code Walkthroughs," COMPSAC `82: 1982 Computer Software and Applications Conference, Chicago, IL Nov. 8-12, 1982, pp. 515-522, IEEE Computer Society Press. [IEEE 1988] "IEEE Standard for Software Reviews and Audits," ANSI/IEEE STD 1028-1988, IEEE Computer Society, Jun. 30, 1989. [Lehman 1976] Lehman, John H. "Software Engineering Techniques in Computer Systems Development," Department of the Air Force, Report No.: SM-ALC/ACD-76-04. 15 Dec. 1976. [Lemos 1979] Lemos, Ronald S. "An Implementation of Structured Walkthroughs in Teaching COBOL Programming," CACA, Vol. 22, No. 6, Jun. 1979, pp. 335-340. [MILS 1985] Military Standard for Technical Reviews and Audits for Systems, Equipments, and Computer Software. United States Department of Defense. 1985 MIL- STD-1521B. [Myers 1988] Myers, Ware. "Shuttle Code Achieves Very Low Error Rate," IEEE Software, Vol. 5, No. 5, Sep. 1988, pp. 93-95. [Parnas 1987] Parnas, David L. and David M. Weiss. "Active Design Reviews: Principles and Practices," Journal of Systems and Software, No. 7, 1987, pp. 259-265. [Remus 1979] Remus, Horst, and S. Zilles. "Prediction and Management of Program Quality," 4th International Conference on Software Engineering, Sep. 1979, pp. 341-350, IEEE Computer Society Press. Abstract: Techniques such as design reviews, code inspections, and system testing are commonly being used to remove defects from programs as early as possible in the development process. The objective of the authors is to demonstrate that predictors can be devised which tell us how well defects are being removed during the defect removal process. [Shelly 1982] Shelly, Gary B. and Thomas J. Cashman. 1982. "Implementation of Structured Walkthroughs in the Classroom," Section 12 of Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products, 3rd ed., pp. 425-434. Boston, MA: Little, Brown and Company. [Waldstein 1976] Waldstein, N.S. "The Walk-Thru-A Method of Specification, Design, and Review," IBM Corp., Poughkeepsie, NY, Technical Report TR 00.2436, 1976. [Weinberg 1971] Weinberg, Gerald M. 1971. The Psychology of Computer Programming. NY: Van Nostrand Reinhold. Part III - Software Engineering Textbooks Discussing Reviews, Walkthroughs and Inspections [Dunn 1984] Dunn, Robert H. 1984. Software Defect Removal. NY: McGraw-Hill Book Co. pp. 102-125. [Dyer 1992] Dyer, Michael. 1992. The Cleanroom Approach to Quality Software Development. NY: John Wiley & Sons. pp. 96-99. [Gilb 1987] Gilb, Tom. 1987. Principles of Software Engineering Management. Reading, MA: Addison-Wesley Publishing Co. pp 205-226, pp. 403-422. [Humphrey 1989] Humphrey, Watts. 1989. Managing the Software Process. Reading, MA: Addison-Wesley Publishing Co. pp. 463-486. [Jones 1986] Jones, Capers. 1986. Programming Productivity. NY: McGraw-Hill Book Co. [Jones 1991] Jones, Capers. 1991. Applied Software Measurement. NY: McGraw-Hill Book Co. [Myers 1976] Myers, Glenford J. 1976. Software Reliability: Principles and Practices, NY: John Wiley & Sons. pp. 17-25. [Pressman 1992] Pressman, Roger S. 1992. Software Engineering: A Practitioner's Approach. 3rd Edition. NY: McGraw- Hill Book Co. pp. 558-570. [Yourdon 1989] Yourdon, Edward. 1989. Structured Walkthroughs, 4th Edition. Englewood Cliffs, NJ: Yourdon Press. ------------------------------------------------------------------------ From: collier@enuxha.eas.asu.edu (Ken Collier) Subject: Re: Fagan's formal inspection methodology? Date: 31 Oct 91 02:57:17 GMT Organization: Arizona State University, Tempe Fagan's original paper was published in 1976 here is the reference. M.E. Fagan "Design and Code Inspections to Reduce Errors in Program Development" IBM Systems Journal, March 1976, vol.15, no.3, pp.105-211 A later paper on inspections by Fagan was published in 1986: M.E. Fagan "Advances in Software Inspections" IEEE Transactions on Software Engineering, vol. SE-12,no.7,pp.744-751, 1986 Anyone studying inspections should read both papers. The first is long and contains a description of an experiment to validate the inspection process. However, all other work on inspections that I have read refer to Fagan's original paper so it is a must. His second paper reflects the seasoning of Fagan's views on the inspection process. It is useful in bringing us up to date on the principals of the Fagan inspection process. I won't suggest that Fagan's method is the best or only inspection method discussed in literature. However, understanding Fagan's work is fundamental to evaluating other variations on the inspection theme. ------------------------------------------------------------------------ From: jck@neptune.cs.Virginia.EDU (John Knight) Subject: Re: Fagan's formal inspection methodology? Date: 1 Nov 91 14:05:00 GMT Reply-To: jck@neptune.cs.Virginia.EDU (John Knight) Organization: University of Virginia In article <31600003@hpsmtc1.cup.hp.com>, debram@hpsmtc1.cup.hp.com (Debra Mallette) writes: |> |> Fagan has been improving his methodology since both of the references |> mentioned. His most recent article is in a recent issue of SIGSOFT. I think Debra might have been referring to my article in the July 1991 issue of Software Engineering Notes. The article is entitled "Phased Inspections and Their Implementation". The goals of Phased Inspections are (1) to make the inspection process rigorous and repeatable, and (2) to support inspections with computer tools. We have developed a toolset called InspeQ that provides many facilities to engineers engaged in Phased Inspections. We hope to make a version of InspeQ available for distribution shortly. Phased Inspections are a lot different from Fagan's inspections although they obviously benefit from Fagan's work. Phased Inspections were also influenced heavily by the Active Review work of Parnas and Weiss. ------------------------------------------------------------------------ From: tonyg@tc.fluke.COM (Tony Garland) Subject: Re: Code Inspections Date: 18 Nov 91 16:11:35 GMT Organization: John Fluke Mfg. Co., Inc., Everett, WA michali@infinet.UUCP (Paul Michali) writes: >Over the past few months I have read several messages about the pros >and cons of code inspections. I am interested in trying code inspections >at where I work but I need more information. Can anyone recommend some >texts that talk about the code inspection process/procedure? I would like >to know more about code inspections before trying it out on a project at >work. I'm hoping that people will become enthusiastic about inspections, >provided the process is presented to them properly. While not specific to *code* inspections, the following articles shed considerable light on the inspection process, regardless of the target of its application. "Design and Code Inspections to reduce Errors in Program Development" M.E. Fagan IBM Systems Journal, Vol. 15, No. 3, 1976, pp. 182-211 "Reviews, Walkthroughs, and Inspections" Gerald M. Weinberg and Daniel P. Freedman, IEEE Transactions on Software Engineering, VOL. SE-10, No. 1, Jan '84 Experience with Inspection in Ultralarge-Scale Developments Glen W. Russell IEEE Software, Jan 1991 Phased Inspections and Their Implementation John C. Knight and E. Ann Myers ACM Sigsoft, Software Engineering Notes, vol. 16 no. 3, Jul 1991, p. 29 Software Inspections: An Effective Verification Process A. Frank Ackerman, Lynne S. Buchwald, Frank H. Lewski IEEE Software, May 1989 ------------------------------------------------------------------------ From: wright@tc.fluke.COM (Dave Wright) Subject: Re: Code Inspections Date: 18 Nov 91 17:56:52 GMT Organization: John Fluke Mfg. Co., Inc., Everett, WA Fagan, Michael E., "Advances in Software Inspections", IEEE Transactions on Software Engineering, Vol. SE-12, No. 7, July, 1986, pp. 744-751. Fowler, Priscilla J., "In-Process Inspections of Workproducts at AT&T", AT&T Technical Journal, Vol. 65, No. 2., March/April, 1986, pp. 102-111. Prell, Edward M., and Sheng, Alan P., "Building Quality and Productivity into a Large Software System", IEEE Software, July, 1984, pp. 47-54. Fagan's article updates his original 1976 paper. Fowler's article (and Russell's article cited by Tony) discuss the application of inspections to real-time switching system implementation, and are helpful in understanding how to introduce inspection into an organization, and the benefits and costs you can expect. The Prell/Sheng article discusses inspection as part of the larger 5ESS project management strategy. ------------------------------------------------------------------------ From: led@sei.cmu.edu (Lionel Deimel) Subject: Software Inspections Date: 18 Nov 91 21:31:15 GMT Organization: The Software Engineering Institute In light of the recent discussion about software inspections, some readers will no doubt be interested in an "Education Materials" package issued recently by the Software Engineering Institute (SEI). The package is Scenes of Software Inspections: Video Dramatizations for the Classroom by Lionel E. Deimel, Software Engineering Institute May 1991 CMU/SEI-91-EM-5 and consists of a 20-page report and a 17-minute VHS videotape. The package is reasonably well described by the abstract of the report: This report describes the videotape "Scenes of Software Inspections," which contains brief dramatizations that demonstrate appropriate and inappropriate conduct of software inspections. The tape also includes scenes that show other kinds of group interactions. Any of these scenes can be incorporated into lectures, self-study materials, or other educational delivery mechanisms, to illustrate how to perform inspections, an important software engineering technique. There are, in fact, 11 scenes, 7 of which are directly related to inspections. The scenes are acted by professional actors. The beauty of the videotape, of course, is that it shows how inspections work, which can be more meaningful than just reading about them. The report makes specific suggestions as to how the scenes can be used to teach the inspection process. Successful use of the tape has been reported both from industry and universities. The report contains a highly selective annotated bibliography for those who may not be very familiar with inspections, by the way. Although most SEI materials are distributed without charge, there is a modest charge for CMU/SEI-91-EM-5 to cover duplication and distribution (but certainly not production) costs. It is available to U.S. government agencies and to U.S. colleges and universities for $25. The cost to others is $50. Orders should be addressed to: Education Program Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Inquiries about ordering may be sent to Lucy Piccolino, lpiccoli@sei.cmu.edu. Technical questions should be addressed to me (see below). ------------------------------------------------------------------------ From: michali@infinet.UUCP (Paul Michali) Subject: Code Inspections : Summary Date: 20 Nov 91 17:59:29 GMT Organization: Infinet, Inc. Here is a quick summary of the replies that I have received, regarding code inspections. ========== From: Bill Hahn bhahn@bogus.sw.stratus.com "Handbook of Walkthroughs, Inspections and Technical Reviews" by Daniel Freedman and Gerald Weinberg (Third Edition) ISBN: 0-932633-19-6 ========== From: Sue Hamilton sriley@bbn.com We don't follow a formal method. This is new for all of us and we didn;t want to wrap a lot of procedure around the task. There are a few different conditions under which we request a review (the coder requests a review) - 1. Design is complete, want review before starting developlment. 2. Have a nasty ol' bug and want some help finding it 3. Think some code is done and want to put it on the shelf The process I follow is: * I decide that I have reached a point where I want a review * I contact the other people in my group and coordinate a time for us to meet - hopefully that same day or very soon after. If I want a review, I've reached a breakpoint. * I make hard copies of the code I want reviewed, and all necessary supporting code and annotate it enough so the reviewers can read and understand without me there. * Distribute the code to the reviewers some time before the review. Their commitment to the review process is that they will spend time reading the code before the actual review. * At the review, a number of different things can happen. Sometimes I walk through my code line by line. Sometimes I just let people make their comments after having read the code. I note any suggestions and try to summarize them via email after the review. Each review has been different, and each one has produced some valuable suggestions. Bugs have been found. Design changes have been suggested. I think the key is to use common sense. We follow a few unwritten rules: - Be nice. Constructive criticism is the point. - Be open minded. Don't redesign the code unless it is necessary. We all have different programming styles. - Stay on track. Try to focus on the task at hand. Group dynamics are important. We have a small group that basically get along well. Choosing the right reviewers is important. I think I read somewhere that you should never have more that 5 or 6 people at a review. We usually have 3. ========== From: Rick Dostal via phone call "Best Current Practices, Code Inspections", Issue 1, AT&T Bell Labs AVAILABLE ONLY TO AT&T EMPLOYEES Costs $10.00, available from AT&T Customer Info Center, Order Entry Dept. use Select Code # 700263. Phone 1-800-432-6600 ========== From: Debra Mallette hpsmtc1.cup.hp.com Fagan, Michael E. and colleagues: "Design and Code Inspections to Reduce Errors in Program Development," IBM System Journal, Vol. 15, No. 3, 1976 Fagan, Michael E. and colleagues: "Advances in Software Inspections," IEEE Transactions on Software Engineering, Vol. SE-12 No. 7, July 1986 Jones, C.L.: "A Process-Integrated Approach to Defect Prevention," IBM System Journal, Vol. 24 No. 2, 1985 Mays, R.G., C.L. Jones, G.J.Holloway, D.P. Studinski: "Experiences with Defect Prevention," IBM System Journal, Vol. 29 No. 1, 1990 Gilb, Tom, "Principles of Software Engineering Management", Addison- Wesley, (Chapts 12 and 21) Freedman, Daniel P. and Weinberg, Gerald M. "Handbook of Walkthroughs, Inspections, and Technical Reviews Evaluating Programs, Projects, and Products," Third edition, Dorset House Publishing, New York, 1990 There have also been articles published in IEEE Software, May 1989; IEEE Computer, 1988, IEEE Transactions, 1990 for which I don't have the specific references. Yourdon's book on Structured Walkthroughs (4th edition, Yourdon Press, Prentice Hall, 1989) has some excellent discusion on the psychology and implementation/marketing challenges that apply to inspections just as well as they apply to structured walkthroughs. ------------------------------------------------------------------------ From: naga@devnull.mpd.tandem.com (S Nagarajan) Subject: Re: need info on code inspection tools To: sophatsa@enuxha.eas.asu.edu (Peraphon Sophatsathit) Date: Tue, 28 Jan 92 14:07:06 CST One doucument that comes to my mind immediately is the IEEE Software Engineering Standard 1028-1988 for Software Reviews and Audits(ANSI). I shall forward some of the earlier USENET summaries on this for your reference. I am also interested to know what you got. Will you please mail me a summary of what you received, when you are done? Thank you very much. Warm Regards. -nagarajan. ------------------------------------------------------------------------ Date: Sat, 6 Jun 92 11:00:16 -0700 From: Peraphon Subject: code inspection tool info In response to your request for inspection tool functionality that I posted on the net, I have gathered the following information from two individuals, namely, Mr. Nagarajan and Miss Anne Anderson. I would like to take this opportunity to thank both of them for their courtesy and generosity for sharing their knowledge. In addition to the invaluable information that I obtained from the aforementioned sources and what I posted, I have collected a few facts and ideas from my colleagues and professors to enhance my research. Here are a couple more of code inspection tool functionalities that I found: 1) Note-taking, and 2) Checklist. Note-taking is essential due to the fact that code inspector may want to comment on a particular section of code. The developer(s), on the other hand, has the option of by-passing or invoking (click) the notes to uncover his shortcomings of that piece of code. Thus, this functionality allows inspector to inform the developer of his opinion on the spot. Checklist informs the developer, from the outset, to where he should pay close attention. Thus, the inspector can freely mark any section of code that he thinks will be potential source of error. Other artifacts suggested were Data Dictionary, Cross-referencing facility, etc. have been incorporated into the static code analyser that I mentioned in my posting (but did not elaborate them). From: goodsenj@ajpo.sei.cmu.edu (John Goodsen) Subject: Re: What factors impact code inspection product Organization: Ada Joint Program Office Date: Wed, 10 Jun 1992 04:07:25 GMT > >>Again, I will have to disagree. Document can and should be inspected >>(ie VERIFIED). Documents and code should also go through at LEAST 1 >>review cycle BEFORE inspection, where such items as approach, method, >>etc are discussed, problems mentioned and discussed, etc. > 1) Expand the "document and code" to the more general term artifact. 2) In a well defined software process, artifacts must meet entry criteria before they are inspected. They must also pass exit criteria before they get "passed" along from one activity to another activity. (activities = req analysis, design, coding, etc..) If your entry criteria for the inspection is a review, then so be it, but to make a blanket statement that it should go through "at LEAST 1" review cycle is clearly an organization dependent decision. one can think of other entrance criteria that might be just as efeective. From: dwwx@cbnewsk.ATT.COM (david.w.wood) Subject: Re: What factors impact code inspection product Date: 11 Jun 92 03:15:25 GMT Organization: AT&T Bell Laboratories dickey@saifr00.cfsat.honeywell.com (Bill Dickey) wrote about reviews vs inspections You're right about 20 people being a waste of time at an inspection. 8 appears to be the upper limit. > So what happens different in a code review than a code inspection?? > > I get the feeling that we are just talking semantics...we talk reviews > for documents, indicating a long lead in time to prepare, followed by > a follow-up meeting to deal with these issues. > > In reality, we do not have inspections here, we have reviews...But > inspections are much different than reviews, I think. (I'm sure > someone will correct me if I'm wrong :-) ) Inspections are a much more > formal review. > > I think we don't disagree as much as you think... I will agree with you that reviews and inspections are different beasts, though most managers use them interchangably, with inspection becoming the more popular term, though are still doing reviews. I would define the diffenece between a review and an inspection as follows: reviews are for raising issues/problems and discussing them providing feedback on an approach, or style mixed with problem solving inspections are solely for detecting and recording problems no discussions, no problem solving That's why my earlier posting said that there should be at least 1 review before an inspection. The review is where the thinking gets refined and hammered out. The inspection is for when you think you have a completed product (document, code, whatever). Think of inspections as testing. You are testing the workproduct against its spec (architecture against the requirement, design against the arch, code against the design). From your posting I now understand that your earlier posting was discribing how your organization works with respect to reviews and inspections, not a statement about the world in general. You're right, we aren't very far apart. From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) Subject: Re: What factors impact code inspection product Date: 18 Jun 92 20:13:02 GMT In article <1992Jun17.161040.1118@saifr00.cfsat.honeywell.com>, dickey@saifr00.cfsat.honeywell.com (Bill Dickey) writes: >>> I wonder if some mention of >>> 'tracability' to the preceeding document/software/deliverable should be >>> mentioned also? >>How about defining lack of traceability as an error? > > Sounds a bit extreme. Definitely needs to be addressed in some manner. Alternate approach. If lack of traceability allows for the potential to miss a requirement (don't know where it is) or inability to find a part of a design that requires modification, then I submit that it is an error. From: dickey@saifr00.cfsat.honeywell.com (Bill Dickey) Subject: Re: What factors impact code inspection product Date: 19 Jun 92 20:21:11 GMT Organization: Honeywell Air Transport Systems Division In article <1992Jun18.151302.8338@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes: >Alternate approach. If lack of traceability allows for the potential to miss >a requirement (don't know where it is) or inability to find a part of a design >that requires modification, then I submit that it is an error. I still am not convinced that lack of traceability is an error...traceability just provides a mapping between steps. Without it we may or may not find errors. It's an error in the process, but not really an error, since the deliverables still may be correct without it. I.E. we could have perfect software (ha.) without traceability, correct? From: claird@NeoSoft.com (Cameron Laird) Subject: Re: What factors impact code inspection product Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Tue, 23 Jun 1992 14:25:48 GMT My vote is with Mr. Kambic, that [lack of traceability] *is* an error, and for a reason perhaps interesting enough to elevate this follow-up from mere dead-horse flogging. If we were "just programmers", there'd be no error. In fact, I suspect that the majority of our co-pro- fessionals see no error in an accounting package that melts down in the year 2000, 'cause they'll be gone by then, and, ipso facto, no problem. As software engineers, though, our responsibility is higher. Even if we satisfy the customer (and I know how rare that is!), we still haven't done our job until we've integrated the PROCESS which produced that customer's application into the ORGANIZATION which owns it. We deliver a binary object, and it certainly has to exhibit QUALITY; but we don't manage our work at the bit level. It's useful to understand what makes a product deliverable, as an earlier poster certainly does; we can't stop there, though. Incidentally, traceability doesn't seem like a big deal to me, personally, but that largely reflects on the types of applications for which I've had responsibility.