1 6 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E

Researchers have responded to these prob-lems by studying methods of formal correct-ness verification for programs. In theory, wenow know how to prove programs correctwith the same degree of rigor that we apply tomathematical theorems. In reality, this israrely practical and even more rarely done.Most research papers on verification makesimplifying assumptions (for example, a 1:1correspondence between variables and vari-able names) that aren’t valid for real pro-grams. Proofs of realistic programs involvelong, complex expressions and require pa-tience, time, and diligence that developersdon’t think they have. (Interestingly enough,they never have time to verify a program be-fore release, but they must take time to re-spond to complaints after release.) Inspectionmethods can be more effective than informalreviews and require less effort than formal

focusInspection’s Role inSoftware QualityAssurance

Despite more than 30 years’ effort to improve software quality,companies still release programs containing numerous errors.Many major products have thousands of bugs. It’s not for lack oftrying; all major software developers stress software quality as-

surance and try to remove bugs before release. The problem is the code’scomplexity. It’s easy to review code but fail to notice significant errors.

guest editors’ introduction

David L. Parnas, University of Limerick

Mark Lawford, McMaster University

proofs, but their success depends on having asound, systematic procedure. Tools that sup-port this procedure are also important.

The Workshop on Inspection in SoftwareEngineering (WISE), a satellite event of the2001 Computer Aided Verification Confer-ence (CAV 01), brought together researchers,practitioners, and regulators in the hope offinding new, more effective software inspec-tion approaches. Submissions described howpractitioners and researchers were performinginspections, discussed inspections’ relevance,provided evidence of how refinement of theinspection process and computer-aided toolsupport can improve inspections, and ex-plained how careful software design couldmake inspections more effective. The bestideas from the workshop have been distilledinto pairs of articles appearing in linked spe-cial issues of IEEE Software and IEEE Trans-actions on Software Engineering.

Why two linked special issues?As guest editors, we had a specific goal

when we proposed the joint special issues tothe publications’ editorial boards. We had ob-served that the practitioners habitually neglectthe kind of research found in TSE on the(sometimes correct) assumption that it’s irrele-vant to them. On the other hand, researcherstend to write for each other and to lose con-tact with the realities that practitioners mustface. The linked issues try to narrow this gap.Some contributors to WISE were practitionerswho explained what they’re doing and whatproblems they encounter. Others were re-searchers trying to discover and verify (eithermathematically or experimentally) some fun-damental facts. We thought that these re-searchers should write articles that explainedto practitioners why the problems they werestudying were relevant to practice. We alsothought that the practitioners could communi-cate to researchers what inspecting a programis actually like. In addition, we asked that thepurpose of each paper in one publication beexplained to the readers of the other.

To summarize:

� The Software articles aim to make practi-tioners aware of research ideas that theymight be able to apply. These articles don’tcommunicate the research results as com-pletely as a normal research paper would.

� The TSE papers do communicate the re-search results. We considered a paper tomake a valid contribution if it showedhow to apply known results to the prob-lem of inspecting software for suitability(fitness for use). The papers are intendedfor people who are willing to read de-tailed, careful research papers.

We intend that each TSE paper and its corre-sponding Software article have little overlap.One reports results; the other explains how touse those results and perhaps what research isstill needed.

We hope that future guest editors will emu-late and improve the linked-special-issues ap-proach for other topics important to bothpractitioners and researchers. After all, con-necting theory with practice is the essence ofany type of engineering.

What we mean by inspectionBy inspection we mean a systematic ap-

proach to examining a program in detail. Suchan examination’s goal is to assess the qualityof the software in question, not the quality ofthe software development process.

In general, inspection means examining aproduct by following a prescribed, systematicprocess that aims to determine whether theproduct is fit for its intended use. For exam-ple, many jurisdictions require vehicle safetyinspections. (Some advocates of specific ap-proaches to software inspection assume thattheir method defines “inspection.” In fact, theword was well defined much earlier.) They leg-islate a list of parts that must be examined,measurements that must be made, and so on,and criteria for passing the inspection. Theword “inspection” usually implies that theprocess is described in documents (for exam-ple, checklists and printed forms) that explainexactly what the inspectors must do. Thesedocuments try to ensure that each inspectionis so careful and so complete that an inspec-tion’s failure to reveal any defects justifies hav-ing great confidence that the product will per-form as required.

An inspection process, while systematicand tightly prescribed, isn’t mechanical; theprocess description guides the inspectors butisn’t so prescriptive that a machine could per-form inspections without human involvement.Success depends on the inspectors understand-

J u l y / A u g u s t 2 0 0 3 I E E E S O F T W A R E 1 7

Connectingtheory with

practice is theessence of any

type ofengineering.

ing the product and the underlying technolo-gies, knowing how to use the appropriatetools, and having considerable experience do-ing related work.

Because the inspectors, like all of us, havelimits on their ability to handle details, the keyto inspection of any complex product is a pol-icy of divide and conquer—that is, examiningsmall parts of the product in isolation, whileensuring that

� Nothing is overlooked� The inspected components’ correctness

implies the whole product’s correctness

The inspection’s organization as a set ofdiscrete steps must assure that each step issimple enough to carry out reliably and thatone step can be carried out without detailedknowledge of the others. Inspection can betime consuming. Moreover, no inspectionprocess is perfect. Inspectors might take short-cuts, might inadequately understand whatthey are doing, and might identify a productas acceptable when it isn’t. Nonetheless, awell-designed inspection process can find er-rors that other methods would miss and canengender great trust.

Inspection’s benefitsIndustry widely employs testing and the re-

search community widely advocates formalverification as methods for improving soft-ware quality. Inspection falls somewhere be-tween the two. Formal verification has yet tocatch on with software practitioners, while in-spection in one form or another has beenwidely adopted by industry and advocated byleading software practitioners (for example,see Stuart Ball’s Embedded MicroprocessorSystems: Real World Design, Newnes, 2000,pp. 16–24). This difference in acceptance hasthree main causes:

� You can inspect the code itself, not justabstract models of it.

� Inspection doesn’t require as substantial atraining investment as verification.

� Inspection doesn’t require the time and theformula manipulation ability that verifica-tion of typical programs does.

Inspection seeks to complement testing.Testing helps detect errors, and formal verifi-

cation helps determine mathematical correct-ness, but you can have error-free (mathemati-cally correct) code that’s hard to understandand difficult to maintain. In addition to find-ing errors in code and related software docu-ments, inspection can also help determinewhether coding style guidelines are followed,comments in the code are relevant and of ap-propriate length, naming conventions are clearand consistent, the code is easy to maintain,and so on. Although these issues are irrelevantto theorem provers, model checkers, and au-tomated testing tools, they are crucial to thecost of building and maintaining large soft-ware products.

You don’t need to wait until code is com-plete to reap inspection’s benefits. Early in-spection of a document that states system re-quirements can help insure that the correctsystem is built. In our experience, even when aproduct’s formal verification uses mathemati-cal requirements, they might not accuratelycapture the designer’s or customer’s intent. In-spection of a requirements document helps as-sure that the requirements are capturing theright thing.

Inspection’s futureAlthough many companies now do inspec-

tion, they can do better. The Software articlesin this issue provide insights into how soft-ware practitioners can improve their inspec-tions’ effectiveness and applicability today.The TSE research papers provide the theoreti-cal underpinnings of these suggested improve-ments and offer insights into how we couldfurther improve inspections in the future. TheTSE articles are evidence that inspection con-tinues to be an active area of academic research.

Refining software inspectionOne way that researchers and practitioners

are addressing current inspection techniques’limitations is by refining inspection methodsto make them more appropriate for a particu-lar setting. Such refinement will help inspec-tors focus on the most important problems inthe sea of details.

In “Practical Code Inspection Techniques forObject-Oriented Systems: An ExperimentalComparison,” Alastair Dunsmore, Marc Roper,and Murray Wood propose three techniques forinspecting OO systems and provide preliminarydata on their relative effectiveness.

Early inspectionof a document

that statessystem

requirementscan help insurethat the correctsystem is built.

1 8 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

Reading can be a rudimentary form of in-spection. In “Prioritized Use Cases as a Vehi-cle for Software Inspections,” Thomas Thelin,Per Runeson, and Claes Wohlin combine usecases and operational-profile testing to assesssoftware from a user’s viewpoint. They thenuse an experimental evaluation to comparetheir method’s effectiveness to that of anotherwell-established reading technique.

Although these papers differ in their con-clusions, they illustrate how customizing theinspection process to the task at hand can pro-vide benefits.

Systems with real-time requirements andconcurrent activities

Software systems that must deal with a va-riety of ongoing activities (for example, devicemanagement, user interactions, and external-event monitoring) are generally less trustwor-thy than purely sequential programs. Concur-rency introduces a form of nondeterminisminto the system—external events, which hap-pen at unpredictable times, determine the in-ternal events’ order. (We consider a system tobe nondeterministic when the informationavailable to the observer or assessor is insuffi-cient to determine the system behavior. In suchcases, a system should be designed to handleall possible behaviors.) When nondeterminismis present, an assessor’s inability to remainaware of all possible sequences makes inspec-tion more difficult. Nondeterminism alsomakes testing more difficult because a test se-quence might cause an error in one case butnot in another.

One potentially worthwhile approach toquality assessment of systems with real-timerequirements in the presence of concurrency isto restrict the design to place it in a class that’seasier to analyze. In what’s likely the specialissues’ most controversial article, “MakingSoftware Timing Properties Easier to Inspectand Verify,” Jia Xu advocates handling con-current real-time systems through a prerun-time scheduling approach. He asks designersto accept strong restrictions on their work tomake the inspector’s job easier.

Tool-supported software inspectionWe organized WISE as a satellite event of

CAV 01 partly because we believe that com-puter-aided inspection and formal verificationtechniques have the greatest potential to im-

prove inspection. Many opportunities exist fortools to improve inspection efficiency and ac-curacy, ranging from tools that support the in-spection process’s workflow and bookkeep-ing, to integrated computer-aided verificationtechniques that let inspectors ask the impor-tant questions and delegate some of the me-chanical details to model checkers, theoremprovers, and other tools. In “Tool Support forFine-Grained Software Inspection,” Paul An-derson, Thomas Reps, Tim Teitelbaum, andMark Zarins explain how to use theirCodeSurfer tool to make inspection of com-plex software systems more manageable.

I n May of this year, a Soyuz TMA-1spaceship carrying a Russian cosmonautand two American astronauts landed

nearly 500 km off course after the craft unex-pectedly switched to a ballistic reentry trajec-tory. Preliminary indications are that the prob-lem was caused by software in the guidancecomputer in the new, modified version of thespaceship. That same week, Microsoft’s Pass-

J u l y / A u g u s t 2 0 0 3 I E E E S O F T W A R E 1 9

A. Aurum, H. Petersson, and C. Wohlin, ”State-of-the-Art: Software In-spections after 25 Years,” Software Testing Verification Reliability, vol.12, no. 3, Sept. 2002, pp. 133–154.

M.E. Fagan, “Design and Code Inspections to Reduce Errors in ProgramDevelopment,” IBM Systems J., vol. 15, no. 3, 1976, pp. 182–211.

T. Gilb and D. Graham, Software Inspection, Addison-Wesley, 1993.

P. Johnson, The WWW Formal Technical Review Archive, 1999, http://www2.ics.hawaii.edu/~johnson/FTR.

D.L. Parnas and D.M. Weiss, “Active Design Reviews: Principles andPractices,” J. Systems and Software, vol. 7, 1987, pp. 259–265. Alsopublished in Software Fundamentals: Collected Papers by David L.Parnas, D.M. Hoffman and D.M. Weiss, eds., Addison-Wesley, 2001,Chapter 17.

D.L. Parnas, “Inspection of Safety Critical Software Using Function Tables,” Proc. IFIP 13th World Computer Congress, vol. 3, North-Holland, 1994, pp. 270–277. Also published in Software Fundamen-tals: Collected Papers by David L. Parnas, D.M. Hoffman and D.M.Weiss, eds., Addison-Wesley, 2001, Chapter 19.

Further Reading

port online information repository system wasfound to have a major security flaw that let anattacker access a user’s personal informationsimply by knowing the user’s email addressand constructing an appropriate URL.

These are just the latest examples of soft-ware quality lapses that are shaking the pub-

lic’s confidence that software can be used tobuild safe, secure systems. In response, bothsoftware practitioners and software re-searchers must improve software’s reputation;the only way to do that is to improve softwarequality. Inspection is one way to do this. Still,we need further research to find more practi-cal, effective inspection approaches and tomeasure their effectiveness. We hope that thesespecial issues of Software and TSE motivateothers to take up this increasingly importantchallenge.

AcknowledgmentsWe thank all the 2001 Workshop on Inspection in

Software Engineering participants, particularly thosewho submitted articles for consideration in the spe-cial issues. The special issues wouldn’t have been pos-sible without the reviewers’ understanding and invalu-able feedback to the editors and authors. Finally, wethank John Knight, Steve McConnell, and WarrenHarrison for encouraging the linked-special-issuesidea, and the IEEE Software and IEEE Transactionson Software Engineering editorial staffs for theirsupport and understanding.

2 0 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

About the Authors

David L. Parnas is the director of the Software Quality Research Laboratory, a ScienceFoundation Ireland Fellow, and a professor of software engineering at the University of Limer-ick. He is also on leave from McMaster University. He is interested in most aspects of computersystem design. He received his PhD in electrical engineering from Carnegie Mellon Universityand is licensed as a professional engineer in Ontario, Canada. He is a fellow of the Royal Soci-ety of Canada and of the ACM, a senior member of the IEEE, and a member of the IEEE Com-puter Society. Contact him at the Dept. of Computer Science and Information Systems, Univ. ofLimerick, Limerick, Ireland; david.parnas@ul.ie.

Mark Lawford is an assistant professor in McMaster University’s Department of Comput-ing and Software, where he is helping to develop and teach the software engineering programs.His research interests include discrete-event systems and the practical application of formalmethods to real-time systems. He received his PhD in electrical and computer engineering fromthe University of Toronto. He is a member of the IEEE Control Systems Society and the IEEEComputer Society. Contact him at the Software Quality Research Laboratory, Dept. of Computingand Software, McMaster Univ., 1280 Main St. West, Hamilton, ON L8S 4K1, Canada.