Software Inspections, Reviews & Walkthroughs Marcus Ciolkowski University of Kaiserslautern & Fraunhofer IESE Kaiserslautern, Germany Oliver Laitenberger Fraunhofer IESE, Kaiserslautern, Germany Dieter Rombach Forrest Shull Dewayne Perry University of Fraunhofer Center University of Texas, Kaiserslautern & Maryland, Austin, Tx, Fraunhofer IESE, College Park, MD, USA Kaiserslautern, USA Germany 1. INTRODUCTION While software has become one of the most valuable products of the past decades, its growing complexity and size is responsible for making it one of the most challenging ones to build and maintain. The challenge stems from the fact that software development belongs to the most labor- and, at the same time, knowledge-intensive processes of today's world. The heavy dependence on knowledgeable human beings may be one reason why software development is often compared to an art or craft rather than to an engineering discipline. However, it has almost become impossible nowadays for a craftsman to produce large software systems according to a given schedule, to a limited budget, and to the quality requirements of a customer at delivery. Hence, researchers as well as practitioners are increasingly obliged to address the question of how to integrate engineering principles into software development. An important one is to perform quality-enhancing activities as early as possible. Despite the simplicity of this principle one can observe in the software industry that the activity of detecting and correcting software problems is often deferred until late in the project. To address this issue, engineering-orientedsoftware organizations have started to implement rigorous inspections, reviews and/or walkthroughs (in this paper all referred to as "inspections"). But still, a large number of organizations do not take full advantage of these approaches, which prevents them to base their software development approach on engineering grounds. The main objective of the IMPACT project in the area of software inspection is to collect demonstrated success cases, perform root cause analyses as to what contributed to the success cases in terms of research and transfer activities in software engineering, and derive lessons learned to maximize the success in other interested organizations. The research results in the inspection context include both new techniques, methods and tools as well as sound empirical evidence regarding the effectiveness and context dependency of inspections. The results show the importance of methodological and empirical software engineering research. Permissionto make digital or hard copies of all or part of this work for personal or classroomuse is grantedwithout fee providedthat copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the flail citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to fists, requires prior specificpermission and/ora fee. 1CSE'02, May 19-25,2002, Orlando,Florida,USA. Copyright2002 ACM 1-58113-472-X/02/0005...$5.00. Empirical software engineering has lead to overcome the ,factoid' that testing is the most effective defect finding technique, and helped maturing software development in practice one step further towards an engineering discipline. This abstract first presents some of the history of inspections, walkthroughs and reviews. An example is briefly described to illustrate how research impacted industrial software development practice in this area. Finally, challenges and questions as well as areas for further work are outlined. 2. HISTORY This historical overview is based on material of Tom Gilb. He therefore earns the credit for this part. Walkthroughs were widely practiced before inspection at IBM. They were conducted by someone presenting the entire logic of an artifact and paraphrasing it aloud, while others listened or asked questions. Walkthroughs primarily aim at training and only secondarily detecting or measuring defects. In a direct comparison a British IBM Lab showed that inspection was an order of magnitude better at finding defects than structured walkthrough. As the 1960s drew to a close, it became apparent that delivering defect free software on time was difficult. IBM was one of the largest software houses in the world. There were a number of streams of development of better quality control methods for software, at about the same time. The major players were Michael Fagan, Harlan Mills and Ronald Radice [2], with Watts Humphrey supporting Fagan and Radice in their developments. Mills was in the Federal Systems Division, outside of Humphrey's domain. But Mike Fagan worked directly with Mills for a few years. Mills also was one of the first working on reading techniques Mills and his associates packaged inspection into a larger attack on the software quality and time problem known as the Cleanroom method [4]. There were a number of components to that such as structured programming, user profile testing, evolutionary project management, design reviews, and code inspections including "reading by stepwise abstraction". In parallel with Fagan, Ronald Radice, at Kingston Labs used the inspection process in 1975 for levels of specification above pseudocode. Some of his ideas went into the development of the Capability Maturity Model (CMM). Level Three of that model was called 'Peer Reviews'. Many other elements from the practice of inspections would influence other levels of the CMM. 641