Does every inspection need a meeting?

ABSTRACT

At each step in large software development, reviewers carry out inspections to detect faults. These inspections are usually followed by a meeting to collect the faults that have been discovered. However, we have found that these inspection meetings are not as beneficial as managers and developers think they are. Even worse, they cost much more in terms of products development interval and developer's time than anyone realizes.Analysis of the inspection and collection process leads us to make the following suggestions. First, at the least, the number of participants required at each inspection meeting should be minimized. Second, we propose two alternative fault collection methods, either of which would eliminate the inspection meetings altogether: (a) collect faults by deposition (small face-to-face meetings of two or three persons), or (b) collect faults using verbal or written media (telephone, electronic mail, or notes).We believe that such a change in procedure would increase efficiency by reducing production times without sacrificing product quality.

REFERENCES

• 1: Mark G. Bradac , Dewayne E. Perry , Lawrence G. Votta, Prototyping a process monitoring experiment, Proceedings of the 15th international conference on Software Engineering, p.155-165, May 17-21, 1993, Baltimore, Maryland, United States
• 2: Watts S. Humphrey, Managing the software process, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1989
• 3: G. Stalk, Jr. and T. M. Hout, Competing Against Time: How Time-Based Competition Is Reshaping Global Markets, Free Press, New York, 1990.
• 4: G. M. Weinberg, The psychology of computer programming, Van Nostrand Reinhold Co., New York, NY, 1988
• 5: W. E. Dernming, Ouf of the Crisis, Massachusetts Institute of Technology, Center for advanced Engineering Study, Cambridge, Mass., 1982.
• 6: Priscilla J Fowler, In-process inspections of workproducts at AT&T, AT&T Technical Journal, v.65 n.2, p.102-112, March 1986
• 7: J.F. Keane, M. Keane, and M. Teagan, Productivity Management in the Development of Computer Applications, Prentice-Hall Inc., Englewood Cliffs, New Jersey, 1984.
• 8: M.E. Fagan, "Design and Code Inspections to Reduce Errors in Program Development," IBM Syst. J., vol. 15, no. 3, 1976, pp. 182-211.
• 9: Edward Yourdon, Structured walkthroughs: 4th edition, Yourdon Press, Upper Saddle River, NJ, 1989
• 10: David L. Parnas , David M. Weiss, Active design reviews: principles and practices, Proceedings of the 8th international conference on Software engineering, p.132-136, August 28-30, 1985, London, England
• 11: IEEE Standard for Software Reviews and Audits, IEEE Std 1028-1988, Soft. Eng. Tech. Comm. of the IEEE Computer Society, June 1989.
• 12: C. Lafferty, The Subarctic Survival Situation, Human Synergistic, Plymouth, Michigan, June 1975.
• 13: Stephen G. Eick , Clive R. Loader , M. David Long , Lawrence G. Votta , Scott Vander Wiel, Estimating software fault content before coding, Proceedings of the 14th international conference on Software engineering, p.59-65, May 11-15, 1992, Melbourne, Australia [doi>10.1145/143062.143090]
• 14: B.Y. Auger, How to Run Better Business Meetings, Amacom Visual Products, 1972.

INDEX TERMS

Primary Classification:
  K. Computing Milieux
  K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
      K.6.3 Software Management
          Subjects: Software development

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING

General Terms:
Design, Human Factors, Management, Measurement, Performance, Theory