Fundamentals of Software Inspections What is the Inspection Method?

The Inspection Method is a proven technique for finding and removing defects in specifications, software, documentation, and other deliverables as early as possible. Inspection applies the concepts of statistical process control to produce high-quality deliverables at minimum cost. Inspections can be used on ANY written document -specifications, source code, contracts, test plans, test cases, etc. Inspections Methodology was developed by Michael Fagan of IBM ("Design and code inspections top reduce errors in program development", 1979), and has undergone continuous quality improvement itself. Fagan updated his paper in 1986 ("Advances in Software Inspections"), but a key contributor has been Tom Gilb ("Managing the Software Process"). Inspections have been used at IBM, BellNorthern Research, Tandem, and many other corporations to find defects faster, and hence at lower cost.

How Does Inspections Differ From Reviews?

Statistical quality control on the document - Inspections track a number of metrics designed to improve the inspection process itself! Statistical process control of producing organization Emphasis on earliest possible defect detection Emphasis on immediate and controlled correction - Corrections are also tracked to assure correction Trained and certified inspection leaders ("moderators") Moderator leadership ("Chief Moderator" concept) Specialized "roles" to increase defect total find rate for team Specialized checklists for each document type Formal "entry" criteria for inspections start-up Formal "exit" criteria for inspection completion Measurable criteria for repeating bad inspections Pareto analysis: identifying error-prone components Experiential optimum rates of work enforced Specific devices/techniques for avoiding individual "blame" Author does not lead, read, explain, or defend docs. No discussion of defect-assertion allowed Only author has control over correction Team size computed based upon efficiency needs - Inspections save money - and can PROVE IT Statistics drive local teams to improve work process - CONTINUOUS QUALITY IMPROVEMENT! Strong Team Spirit, includes author of document All important documents are subject to inspection Peer inspection - everyone learns new things on the job Maximum meeting: 2 hours (tiredness factor) Ability to achieve Six Sigma Quality Ability to reduce maintenance costs by a factor of 10 Ability to double project productivity

What is an Inspector?
An inspector is a person who reads a document looking for defects. Inspections also involve other people. An "author" creates the document that is inspected. A "moderator" recruits a team of inspectors and organizes inspection activities. Scribe records the defects found by inspectors. Often a person has more than one role during inspections (i.e. the moderator may also act as scribe and inspect as well). Contrast this to "reviews" and other previous methodologies, which do not necessarily assign roles in any formal fashion.

What Happens During an Inspection?

Inspection activities follow this cycle: An author give their document (the "low level" document) to a moderator and asks for an inspection. The moderator recruits a team of inspectors and gives them the low-level document and all other documents necessary for the inspection, including "high level" standards or prerequisites. Inspectors prepare by reading the low-level and noting all the defects found. Each inspector prepares IN PRIVATE at their convenience, but spends at least the amount of time recommended by the moderator. After preparation, the inspection team conducts a "defect logging meeting." The moderator is responsible for arranging the defect logging meeting. After logging, the author takes the defect log and "reworks" their document by fixing all the logged defects. The moderator tallies up the statistics from the meeting, and gives them to Quality Assurance for tracking and analysis. Note how the workload is spread around AMONG THE PEOPLE DOING THE WORK. Note that there are standards that are used to "push off of." Note that statistical information is gathered for later analysis to constantly improve the efficiency of the inspections process itself. All clear wins!

What is a Defect?
A defect is NOT a matter of opinion. A defect is a violation of a standard, or an inconsistency with another highlevel document. A standard tells the author how to produce a certain kind of document. For example, the authors of source code use a "C Coding Standard" and other related standards. A specification author might use a "Requirements Specification Standard." A defect occurs when a low-level (sometimes called "the inspectable") fails to comply with a standard that the author is expected to use. A high level document is an earlier document that is closely related to the low level document being inspected. For example, a source file might have a design specification, a series of Booch Diagrams, and/or a user manual as high levels. A defect occurs when a low level document does not follow correctly from its high levels - for example, when a function (or proc) does not comply with its design spec or man page. The moderator is responsible for getting you a copy of all relevent standards and high levels. Contrast this with old fashioned "reviews", where people are forced to defend their documents, defend their opinions on what is and what is not a "bug", etc. Inspections seek to move closer to what Professor Gerald Weinberg called "egoless programming." Again, inspections methodology enforces good software engineering practices.

Are Defects "Bad?"

Of course, and we should aim to remove ALL of them. But, we ALL make defects, and we all need help in finding them. Inspectors are the author's BEST FRIENDS. Its the lucky author that can find all the defects in their work during inspection, rather than getting a call from their boss chewing them about about customer-found bugs! Note this: defects is the correct term, not "bugs" or "anomalies." (this comes from J.M. Juran and W. Ed. Demings).

How Does an Inspector prepare For a Defect Logging Meeting?

Find as many defects as possible, especially "unique", meaningful defects that no other inspector on the team will find. Your moderator may assign you a special "role" to try and find the unique defects that can be seen from that special perspective. For example, moderator "Jane" might assign inspector "Bill" the role of "End-User Customer", and suggests that he spend at least 2 hours inspecting the low-level. Handing Bill the high-levels, Bill knows that he needs to put himself in the shoes of a customer. During his inspection, he tries to see things from the customer's viewpoint - and often this results in him finding the MOST IMPORTANT defects! Of course, if they also find OTHER defects not related to their role, these are noted as well. Contrast this with reviews, where role-playing is often ignored or occurs only informally! Also, inspections happen asynchronously, at inspector's convenience, improving the odds of a better inspection. In fact, in my experience inspections often occur AT NIGHT, at home which, for the firm, is a clear productivity improver itself! Defects are recorded any way the inspector wishes to. For each defect, estimate and record its "severity level." Also record any questions that you would like to ask the author. If you think that something is a defect, but you are not sure, record it as a question. Issues are also recorded for the

author. In this fashion, people become involved in the total product solution, not just a piece of code. At the Defect Logging Meeting, the moderator will ask you to furnish the following information: preparation time spent, number of pages inspected, number of defects found at each severity level, and number of questions.

What Happens During Defect Logging?

The moderator asks each inspector to log their defects. For each defect, the scribe records the location, severity, and number of occurances, along with a brief description. Also, each inspector poses their questions to the author. Depending upon the answer, a defect may be logged, or not. The GOAL of the defect logging meeting is to log as many defects as possible PER MINUTE. Here are the rules for the meeting: Inspectors describe each defect is about 7 words or less. Use telegram style, emphasizing key words. Inspectors are NOT allowed to discuss how to fix the defect! The author has sole responsibility to decide how to fix the defect. This avoids a MAJOR PROBLEM with reviews: too much "fix on the fly" (often resulting in horrible solutions!), too much discussion degenerating into chaos and longer meetings, too much defensiveness. There is NO discussion about whether or not a defect really exists. If you log it, its a defect. Note that the author may choose the method of solution (i.e. fix in code, fix in specifications, fix in docs, etc.). If you must discuss, do if OFF-LINE after the meeting. The author is NOT allowed to explain, describe, or defend their document, except in response to a question. Inspections participants are given training in the methodology and techniques, which then certifies them as Inspectors (or Moderators).

Do I Have to Accept EVERY Invitation To Be An Inspector?

No. You should spend less than 20% of your time in inspection activities. A key feature of the technique is that the work is spread around, and is viewed as a natural engineering function done by peers. Being asked to inspect is a honor indeed, as it sends a message indicating that your technical abilities are valued and your input respected. You in turn should take on the job as a serious part of your job, not a bother. Plus, its a great way to learn about different pieces of the product. Remember: others will repay your efforts by helping to inspect when you are the author. In Tom Gilb's experience, first year Inspections activities, even for the most motivated of firms, averages between 5% and 8% of time.