CODE INSPECTION: A REVIEW

Robson Ytallo Silva de Oliveira, Paula Gonçalves Ferreira

CIn - Informatics Center, UFPE - Federal University of Pernambuco, Recife - PE, Brazil

Alexandre Alvaro, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira

C.E.S.A.R – Recife Center for Advanced Studies and Systems, Recife – PE, Brazil

Keywords: Code Inspection, Quality Assurance, Software Reuse, Maintainability.

Abstract: The software inspection process is generally considered a software engineering best practice. For a long

time, it had the goals of finding and fixing defects as soon as possible. For this reason, techniques are

suggested for use in a software reuse process in order to improve the quality of the assets developed and

reused. Thus, the code become itself easier to understand and changeable, and improving its maintainability,

minimizing redundancies and improving language proficiency, safety and portability. In this way, looking

for analyzing this area, this paper presents a survey of code inspection research.

1 INTRODUCTION

Code inspections have emerged as one of most

effective quality assurance techniques in software

engineering. The primary goal of an inspection is to

find defects before the testing phase; and hence

strongly contribute to improve the quality of

software with budget and time benefits (DeMarco,

1982). A real example of code inspection benefits

could be seen at Jet Propulsion Laboratory that gives

support to NASA (Wohlin et al., 2002). They saved

US$ 7,5 million performing around 300 inspections.

The main goal of this survey is study the state-

of-the-art in code inspection research, in an attempt

to analyze this possible trend and to provide insights

in proposal of a well-defined software components

code inspection process. Thus, the main techniques,

process, methods and results were identified and

analyzed.

Besides this introduction, the reminder of this

paper is organized as follows. The Section 2

presents the most relevant techniques for the code

inspection activity that will be considered in the

works found in the literature. Section 3 splits the

code inspection area in two ages and surveys the

state-of-the-art related to code inspection research.

Finally, Section 4 presents the concluding remarks

and directions for future work.

2 CODE INSPECTION

TECHNIQUES

There are a lot of techniques that very important to

guide the code inspection process. They have been

studied and used during last years. The most relevant

code inspection technique was presented by Michael

Fagan in 1976 (Fagan, 1976). The technique was

called FTR (Formal Technical Review) and consists

of five steps, as follows:

 Overview: The author presents the scope

and the proposal of his software product;

 Preparation: In this step, the reviewers

only understand the code;

 Inspection Meeting: The reviewers work

together in order to identify errors and

reporting them;

 Rework: The author repairs the issues

reported in the last step;

 Follow-up: A moderator analyses the

rework step and judge if it is necessary to

repeat the process.

Usually a practical model, based on FTR, is used

when the cost of the code inspection process is

bigger than its benefits, which is composed of three

steps, as follows:

537

Ytallo Silva de Oliveira R., Gonçalves Ferreira P., Alvaro A., Santana de Almeida E. and Romero de Lemos Meira S. (2007).

CODE INSPECTION: A REVIEW.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 537-540

DOI: 10.5220/0002366505370540

 SciTePress

 Preparation: The reviewers understand the

code. In addition, they need to find defects

in this step in contrast to FTR;

 Collection: The errors discovered are

analyzed and issues are reported when a

defect is considered a real one;

 Repair: In this phase, the reported issues

are addressed to the author repair them.

Some practical model variants try contributing

through their characteristics in the Cost-Benefit

relation. The most known of them are:

 Active Design Review (ADR): It is a

technique based on multiple sessions,

where each session is divided in short

phases which are independent;

 Phased Inspection (PI): As well as ADR,

PI is based on multiple sessions, but its

phases are sequential. The reparation is

done after each phase;

 N-Fold Inspections: This uses the concept

of N-teams which are designated to

perform the same task of inspection. In the

end of process, a moderator is responsible

to remove the redundancies. In general, N-

Fold Inspections have a high price due to

people are addressed to develop the same

task.

3 CODE INSPECTION: A

SURVEY

Analyzing the techniques presented and how they

have been used during the life of software

development, it is possible to divide the code

inspection process in two ages: Before 1976 and

From 1976 until today. However, this survey will

consider just the second age due to this area is scarce

of works and results before Fagan’s model.

First, in 1995, Haton (Hatton, 1995) suggests the

static inspection idea, which is purely the concept of

the code inspection. If suppose a dynamic

inspection, the concepts of test and inspection can be

mixed. Sometimes, the defect is evident into the

software, but the reviewers does not know where

they are, being necessary to run it. To understand the

idea, it is used an analogy: an engineer walks along

a stationary train, punching its wheels. If he has

experience, he is able to identify if there is any crack

in the train, if it is prejudicial and where. In the code

inspection, a static process identifies language

inconsistencies, furthermore becoming the code

easier to be understood and documented,

contributing, consequently, with software reuse. The

great disadvantage, in accordance with this work, it

is the necessity to have an experienced professional

in the language and the system.

Porter et al., in 1997 (Porter et al., 1997),

presented a report related to cost-benefits of the code

inspection techniques. The work had the follow

results:

 No difference in time and effectiveness

between groups with two or four people;

 Two groups with two people are not more

efficient than one group with two people;

 “Multiple sessions” do not have more

effectiveness than “single sessions”.

Still under 1997, (Porter and Johnson, 1997), was

motivated for a work from 1985 (Eick et al., 1992).

The oldest work discussed about the relation

between the steps of Preparation and Inspection

Meeting from FTR model. According to (Eick et al.,

1992), the most of defects were found in the second

step due to using the first one to find errors too,

opposed to the original model. The new work

analysed the relation between Real and Nominal

Group into a code inspection process.

Before the conclusions, it will be defined the

both kinds of groups (Porter and Johnson, 1997):

 Real: “participants meet face-to-face and

interact with each other to accomplish the

group task”.

 Nominal: “participants work individually

without interacting with each other, and

their individual results are pooled together

to accomplish the group task”.

Two experiments was performed and the more

significant result did not find any difference in

effectiveness between real and nominal groups,

nevertheless preparing and joining people – real

group – have a high price.

In 1987, (Basili and Selby, 1987) compared and

combined code inspection techniques. After ten

years, (Wood et al., 1997) performed a similar work,

obtaining the same results: the individual techniques

are very important, but the best results are generated

through techniques combination.

Several works about code inspection are related

or use the FTR model. Few significant modifications

are determined. But in 1998, (Johnson, 1998) wrote

some recommendations for Fagan’s model.

Although the recommendations weren’t being

explicitly referenced into the future works, it is easy

to identify some of them adopted, such as: provide

tighter integration between FTR and development

model; Minimize meetings and maximize

asynchronicity; Shift the focus from defect removal

ICEIS 2007 - International Conference on Enterprise Information Systems

538

to improved developer quality; Build organizational

knowledge bases on review; Outsource review and

insource review knowledge; Investigate computer-

mediated review technology; and Break the

boundaries on review group size.

In (Brykczynski, 1999), Brykczynski listed a

range of checklists, suggesting what to be used or

avoided. By suggestions, it is possible to identify the

Johnson’s recommendation (Johnson, 1998) to build

organizational knowledge bases on review.

Although (Johnson, 1998) is not referenced,

Brykczynski suggests updating the checklist to

maintain an updated knowledge base.

In 1999, the main concern is about Object-

Oriented (OO) Designs. Usually, when an OO code

is inspecting, only a piece of it is analyzed. It can be

very difficult to understand only that piece if we

consider some concepts like polymorphism and

inheritance. Travassos et al. (Travassos et al., 1999)

cited the importance of reading techniques in OO

context. The great problem for OO code inspection

is the preparation phase. Sometimes it is not well-

defined or sometimes it has a high price to be

performed.

In 2000, Kimble and White (Kimble and White,

2000) describes an alternative source code analysis

in order to identify automatically the existence of

recursion, missing functionality and logical errors.

The method used a parser to massage the code to a

set of conventions. A modified notation was created

and from this a Control Flow Diagram (CFD) was

built and the thread analysis was done easier due to

well-defined flows.

Still in 2000, Adams (Adams, 2000) presented an

interesting work, that could be considered very

radical, but his words make sense. According to

Adams, six years before Michael Fagan publish his

work describing the FTR model, Apollo 11 was

launched to space. Considering the Flight Control

Software that helped guide Eagle, Adams concludes

that many complex software systems was developed

and some kind of inspection process was adopted

before 1976. Thus, he creates some questions about

if inspections and reviews are really necessary.

Another work developed in 2000, Nandivada and

Dutta (Nandivada and Dutta, 2000) describes a new

model for code reviews. It is called “The 9 Quadrant

model” and it is based on statistical techniques such

as control charts. The model provides a single

framework to generate a scatter chart between yield

and cost of code review. 9Q model serves as an

excellent tool for process decision-making and

indirectly addresses planning of code reviews,

determining their efficiency and improving the

process.

In 2001, the Bifel et al. (Bifel et al., 2001) work

was concerned in evaluating re-inspection. A re-

inspection repeats the inspection process and is often

believed to be less efficient. Thus, a cost-benefit

model was proposed in this work to help whether a

re-inspection justifies its cost. The work concluded

that more than 80% of re-inspections weren’t

necessary and the remaining were necessary due to

the reviewers weren’t familiar with the system or

with the process.

In 2002, according to Wohlin et al. (Wohlin et

al., 2002), the advantages of inspections were not

well perceived by management. Knowing that

“benchmarking is a continuous improvement process

rather than a competitive comparison” (Wohlin et

al., 2002), and “It is a widely used business practice

and has been accepted as a key component for

organizations to search for improvement in quality,

competitive position or market share” (Wohlin et al.,

2002), benchmarking could compare tools, people,

environments, and so on to build a well-defined code

inspection. Several tools for software benchmarking

have also been developed. Although makes no

reference to (Johnson, 1998), it follows the

recommendation to build organizational knowledge

bases on review.

Again, the relation between Real and Nominal

Groups was discussed by Tyran and George (Tyran

and George, 2002) in 2002. This time was suggested

to use a Group Support System (GSS), attending the

recommendation of Johnson (1998) to investigate

computer-mediated review technology. The GSS’s

are responsible to address group process issues in

collaborative groups, helping to minimize problems

associated with the meeting process. In addition,

according to Tyran and George (2002), to use a

GSS-supported, teams perform best the code

inspection, detecting more defects.

The Usage-Based Reading (UBR) techniques

was discussed by Thelin et al. (Thelin et al., 2003),

in 2003. According to work, the UBR which uses the

traditional inspection concepts, use cases and

operational profile testing, is more effective and

efficient than the checklist-based method.

In 2005, Remillard (Remillard, 2005) presented

his experiences using Source Code Review Systems.

He describes the tools Bugzilla and CodeStriker,

showing their main features. According to work, the

CodeStriker looks like having more advantages

considering the other compared systems. This

assumption is giving emphasis by license type,

CODE INSPECTION - A Review

539

revision control system integration, data storage and

kind of inspections supported.

4 CONCLUSION AND FUTURE

REMARKS

This paper has presented a survey related to the

state-of-the-art in the code inspection research. As

we can observe, the FTR Model was predominant in

the works analyzed. Still on, a set of works found

into literature presented some variants but all of

them follow the Fagan’s principles.

For future work, we planned to establish a well-

defined process for software component code

inspection in conjunction with RiSE

projects in

order to evaluate this one process. One of the main

motivations for us is due to the fact that we did not

find into the literature a code inspection process

specific for software components. However, this is

one of the three bases adopted in our group for

quality assurance in software components,

composed of a component certification process

(Alvaro et al., 200) (Alvaro et al., 2006) and test’s

component. The code inspection requirements and

the process will be described in future papers.

REFERENCES

Adams, T. (2000). The God of Inspection. ACM SIGSOFT

- Software Engineering Notes, 25, 02, 30.

Alvaro, A., Almeida, E. S., Meira, S. L. (2005). Software

Component Certification: A Survey. In 31st IEEE

EUROMICRO Conference on Software Engineering

and Advanced Applications (SEAA), Component-

Based Software Engineering (CBSE) Track, Porto,

Portugal. IEEE Press.

Alvaro, A., Almeida, E. S., Meira, S. L. (2006). Towards a

Software Component Certification framework. In 5th

International Conference on COTS-Based Software

Systems (ICCBSS), Poster Session, Florida, EUA.

Lecture Notes in Computer Science (LNCS), Springer-

Verlag.

Basili, V., Selby, R. (1987). Comparing the Effectiveness

of Software Testing Strategies. IEEE Transactions on

Software Engineering, 1278-1296.

Bifel, S., Freimut, B., Laitenberger, O. (2001).

Investigating the Cost-Effectiveness of Reinspections

in Software Development. In IEEE International

Conference on Software Engineering (ICSE), 155-164.

Reuse in Software Engineering (RiSE) group –

http://www.rise.com.br

Brykczynski, B. (1999). A Survey of Software Inspection

Checklists. ACM SIGSOFT - Software Engineering

Notes, 24, 01, 82-89.

DeMarco, T. (1982). Controlling Software Projects.

Yourdon Press. New York.

Eick, S.G., Loader, C.R., Long, M.D., Vander Wiel, S.A.,

Votta, L.G. (1992). Estimating Software Fault Content

Before Coding, In 14th Internacional Conference on

Software Engineering (ICSE), 59-65.

Fagan, M. (1976). Design and Code Inspections to Reduce

Errors in Program Development. IBM Systems

Journal, 15, 3, 182-211.

Hatton, L. (1995). Static Inspection: Tapping the wells of

software. Programming Research Ltd. 85-87.

Johnson, P. (1998). Reengineering Inspection.

Communications of the ACM, 41, 02, 49-52.

Kimble, J., White, L. (2000). An Alternative Source Code

Analysis. In The International Conference on Software

Maintenance (ICSM), 64-75.

Nandivada, R., Dutta, S. (2000). The 9 Quadrant Model

for Code Reviews. In IEEE Asia Pacific Conference

on Quality Software, 188-193.

Porter, A., Johnson, P. (1997). Assessing Software Review

Meetings: Results of a Comparative Analysis of Two

Experimental Studies. IEEE Transactions on Software

Engineering, 23, 03, 129-145.

Porter, A., Siy, H., Toman, C., Votta, L. (1997). An

Experiment to Assess the Cost-Benefits of Code

Inspections in Large Scale Software Development.

IEEE Transactions on Software Engineering, 23, 06,

329-346.

Remillard, J. (2005). Source Code Review Systems. IEEE

Software, 22, 01, 74-77.

Thelin, T., Runeson,, P., Wohlin, C. (2003). Prioritized

Use Cases as a Vehicle for Software Inspections. IEEE

Software, 20, 04, 30-33.

Travassos, G., Shull, F., Fredericks, M., Basili, V. (1999).

Detecting Defects in Object-Oriented Designs: Using

Reading Techniques to Increase Software Quality. In

14th ACM SIGPLAN conference on Object-oriented

programming, systems, languages, and applications,

34, 10.

Tyran, C., George, J. (2002). Improving Software

Inspections with Group Process Support.

Communications of the ACM, 45, 09, 87-92.

Wohlin, C., Aurum, A., Petersson, H., Shull, F.,

Ciolkowski, M. (2002). Software Inspection

Benchmarking - A Qualitative and Quantitative

Comparative Opportunity. In 8th IEEE Symposium on

Software Metrics, 118-127.

Wood, M., Roper, M., Brooks, A., Miller, J. (1997).

Comparing and Combining Software Defect Detection

Techniques: A Replicated Empirical Study. In 6th

European Software Engineering Conference / 5th

ACM SIGSOFT Symposium on the Foundations of

Software Engineering, 1301, 162-277.

ICEIS 2007 - International Conference on Enterprise Information Systems

540