1

CSc 131 Computer Software Engineering

Chapter 10Software Inspection

Herbert G. Mayer, CSU CSCStatus 8/18/2019

2

Syllabus

•  Inspection Types•  Fagan Inspection•  Entry & Exit Criteria•  Inspection Roles•  Inspection Size•  Caveat•  Summary•  References

3

What is Inspection

Inspection: Type of review to ID defects in SW, HW. Best to uncover early, minimizes damage, cost

4

SW Inspection•  Inspection in software engineering refers to any

work product by trained individuals who look for defects in code, using a defined, documented process

•  An inspection might also be referred to as a Fagan Inspection after Michael Fagan, the creator of a very popular software inspection process

•  An inspection is one of the most common review practices found in software projects

•  Goal of inspection is to identify defects•  Commonly inspected work products include SW

Requirements Specifications and Test Plans

5

Inspection

Goal of inspection: identify defects, in any part of SW, HW

6

Inspection Types•  Managerial, Technical•  Requirements, Design, Documentation•  Code, Tests, Changes•  Formal Inspection:

•  Code Reading

•  Structured Walkthrough•  Informal Walkthrough

•  Desk Checking

7

Formal Inspection: Fagan

•  Methodology due to Fagan, IBM; see [1]•  Emphasis on detection, measurement•  A Fagan inspection is process of trying to locate

defects in documents and source code•  Such as program source or formal specifications•  During various phases of SW development•  Named after Michael Fagan, credited being the

inventor of formal SW inspection

8

Formal Inspection: Fagan

•  Fagan inspection defines review as specific process with clear entry and exit criteria

•  In every such process, Fagan inspections can be used to validate if process output complies with specified exit criteria

•  Fagan inspection uses a group review method to evaluate the output of a given process

•  Extends to private reviewing as well•  This overall process is gradually moving into mid-

sized and smaller SW projects in industry

9

Formal Inspection: Fagan

Examples of reviewing activities for Fagan Inspection:

•  Requirement specification•  Software/Information System architecture•  Programming components

•  Actual source code

•  Or documents and comments explaining source code

•  Software testing•  For example during creation of test scripts

10

Formal Inspection: Fagan

•  SWE development process is typical application of Fagan inspection

•  Costs to remedy a defect are only a small fraction during early SW development phase

•  Versus fixing a defect during maintenance phase•  Essential to find defects close to point of creation!•  Done by inspecting output of each operation•  And comparing output requirements, AKA Exit

Criteria of that operation

11

Formal Inspection: Criteria •  Entry criteria are requirements that must be met to

enter a specific process•  For example, for Fagan inspections the high- and

low-level documents must comply with specific entry criteria before they can be used for a formal inspection process

•  Exit criteria are requirements to be met to complete a specific process

•  For example, for Fagan inspections the low-level document must comply with specific exit criteria (as specified in high-level document) before the development process can proceed to next phase

12

Formal Inspection: Criteria •  Exit criteria are specified in a high-level document,

which is then used as the standard to which the operation result (low-level document) is compared during the inspection

•  Minor defects defined are those that do not endanger correct SW functioning

13

Follow-Up

•  In follow-up phase of a Fagan Inspection, defects fixed in the rework phase should be verified again

•  Moderator responsible for verifying rework•  Sometimes fixed work can be accepted without

being verified, such as when the defect was trivial; careful SWE!

•  In non-trivial cases, a full re-inspection is performed by the inspection team, not only moderator

•  If verification fails, go back to the rework process

14

Inspection RolesInspection process performed by members of same team implementing the projectParticipants fulfill different roles within the inspection process:•  Author/Designer/Coder: the person who wrote the

low-level document or source code•  Reader: paraphrases low-level document•  Reviewers: reviews the low-level document from a

testing standpoint•  Moderator: responsible for inspection session,

functions as a coach; starts, ends, decides

15

Inspection Size•  No hard magic number for team size; no magic

number for code size to inspect•  Rules of thumb; to be refined by organization that

develops large SW •  Work Inspected:

•  200 – 500 Lines Of Code (LOC)•  1 – 3 hours•  Space between sessions

•  Number of people, team sizes:•  3 – 7 persons, more becomes costly and diminishes speed•  Best with 3 – 4 team members

16

Inspection Process•  Moderator instructs reader to proceed •  Reader reads lines; decide ahead of time when, how

to stop •  Reviewers signal any potential questions

•  Any team member flags suspected defect

•  Recorder documents defects•  ...continue •  Was this the final inspection?

•  If so, find agreement that and be clear: why!

•  If not, agree about next inspection: subject, time, size, participants

17

Inspection Pitfalls

•  Personalities! SW developers prone to view themselves as Prima Donna

•  Moderator must estimate a start quantity to be reviewed; easy to wish to do all in one step

•  Defect correction rather than detection; SWE are prone to “offer better solution”; stay away from spontaneous defect correction

•  Checklist issues; have a list beforehand, stick to it•  Groupthink, wrong level of detail…•  Bad recording or failing to follow-up

18

Causes of Defects

•  Omission: I forgot a step I should have completed•  Ignorance: I forgot to perform something, because I

was unaware of it•  Commission: I did something wrong, even though I

knew how to do it right (to save time etc.)•  Typography: I wrote something wrong (such as a

typo) though generally I do know how to do this correctly

19

Common Causes of Defects

20

Causes of Defects

•  Knowledge: I made a mistake because I did not know (at the time) how to do it right

•  Information: I did something wrong because I lacked correct information or our knowledge base was flawed

•  External: I did nothing wrong. The problem resided outside, and was introduced by some external agent (person, policy, etc.)

21

Informal Inspection

•  Done privately at desk, without formal meeting•  But completed within time constraints given•  Yet formal agreement a-priori about what to focus

on; when complete, how to report findings•  Can be as effective as formal group inspection•  Is actually best method for “well-crafted” source

code

22

Inspection TargetsAlmost any phase of substantial SWE project benefits from formal inspection:•  Specifying Requirements: Document & inspect!•  System Design: Document & inspect!•  Architecture Design: Document & inspect!•  Module Design: Document & inspect!•  Implement: Inspect!•  Test plans: Document & inspect!

23

Inspection Targets

24

Inspection Targets

After design has been reviewed and is complete, implementation starts; inspect all phases of any substantial SWE project:•  Unit testing hard, as other units missing•  Integration testing also may need some stubs•  System testing now bugs become expensive!•  Acceptance testing

25

Inspection Process Overview

Walk-through Kick-off Individual

checkingEditandfollow-up

Planning

Processimprovements

Productdocument

Changerequests

Rules,checklists,procedures

LoggingmeeBng

26

Caveat•  You now have studied a widely used inspection

process•  By the time you work in High-Tek and develop

systems that need inspection, other methods (better, more fashionable) will exist

•  Which is fine; actual method is not as critical•  That you practice an agreed upon, rational method

and use it consistently, with tangible benefit, that is important

•  Above all: have fun developing HW and SW and systems! And get paid well ☺

27

CMM•  Capability Maturity Model (CMM) is a development

model created after a study of data collected from organizations that contracted with the US Department of Defense

•  Which funded the research•  The term "maturity" relates to the degree of formality

and optimization of processes, from•  ad hoc practices•  to formally defined steps•  to managed result metrics•  to active optimization of the processes

•  See separate presentation for detail

28

Summary•  Goal of SW Inspection is to identify defects•  Real goal: early identification, since cost for

correction is significantly lower early on, rather than after implementation

•  What is to be inspected: Any work product related to SW, including documentation, requirements lists, particularly user requirements, actual code, test plans, tests, etc.

•  Inspection can be individual, at desk•  Or a group inspection; should be group of very

contained size, but have separate roles, including author, reviewer, recorder, moderator

29

References1.  Inspections by Fagan: https://en.wikipedia.org/wiki/

Fagan_inspection 2.  https://en.wikipedia.org/wiki/Software_inspection