www.ischool.drexel.edu

INFO 636 Software Engineering Process I

Prof. Glenn Booker

Week 8 – Reviews

1INFO636 Week 8

www.ischool.drexel.eduINFO636 Week 8 2

Reviews

• Conducting reviews of requirements, design, and code is one of the best ways to improve your work’s quality and your productivity

• Here we’ll look at various types of reviews and how to document them

www.ischool.drexel.eduINFO636 Week 8 3

Reviews

• Review types in descending order of formality include– Inspections – Walk-throughs– Personal reviews

www.ischool.drexel.eduINFO636 Week 8 4

Inspections

• Inspections follow a structured procedure for evaluating a work product– Fagan inspections are among the best known

brand of inspection

• Inspections start with preparation, where each participant reviews the work separately, and makes note of defects found

www.ischool.drexel.eduINFO636 Week 8 5

Inspections

• Then there’s an inspection meeting to discuss the findings of each participant, and put together a cumulative list of defects

• Then the work product owner fixes the defects, and puts together a report to say so, in the repair and report phase

www.ischool.drexel.eduINFO636 Week 8 6

Walk-throughs

• Walk-throughs require little preparation, except by the work product owner

• A presentation is given, and participants provide feedback during it

• Follow-up is informal, with the work product owner responding to the comments received

www.ischool.drexel.eduINFO636 Week 8 7

Personal reviews

• Personal review is the work product owner reviewing their own stuff

• As compiling code has gotten trivially easy, many programmers have dropped reviewing their own work in the hopes that the computer will find their mistakes– Not a good strategy!

www.ischool.drexel.eduINFO636 Week 8 8

Target of Reviews

• Any work product can be the subject of reviews– Any document

• Requirements specification• Design models• Test plans• Internal project processes & procedures

– Source code• Scripts too!

www.ischool.drexel.eduINFO636 Week 8 9

Commentary

• For those taking INFO 637, the Team Software Process uses formal reviews extensively, so pay extra attention!

• N track people - while the text obviously focuses on reviews related to code, keep in mind that these methods and tools for reviews can be used to plan and conduct reviews for anything

www.ischool.drexel.eduINFO636 Week 8 10

Why Review Software?

• The history of the PSP has shown that most people– Initially spend much of their time (30-50%) in

compiling and testing– By the end of this course, only about 10% of

their time is spent testing

• Good reviews are a key to reducing testing time

www.ischool.drexel.eduINFO636 Week 8 11

Review Efficiency

• Finding and fixing defects is much faster to do in review than in testing– Humphrey found 8x faster fix time in review

than testing

• Code reviews are 3-5 times as efficient at finding defects than testing– Part of the reason is that testing finds

symptoms of the defect, which has to be investigated by debugging

www.ischool.drexel.eduINFO636 Week 8 12

Severity of Review

• We don’t mean to imply that every piece of code needs exhaustive review

• Different approaches can be used, depending on the complexity, risk, and importance of the code– Hence you might use inspections for critical

code, walk-throughs for typical code, and just personal review for low risk code

www.ischool.drexel.eduINFO636 Week 8 13

Review Principles

• Any kind of review process typically follows three principles– Establish defined review goals– Follow a defined process for conducting

a review (here, we’ll use scripts)– Measure and improve your review process

www.ischool.drexel.eduINFO636 Week 8 14

Separate Design and Code Reviews

• Design and code should be reviewed separately– Forces making a design before coding– It’s hard to decipher design from the code– Helps spot logic errors in design, and identify

design improvements– Helps focus review scope

www.ischool.drexel.eduINFO636 Week 8 15

Design Reviews

• Make your design reviewable– Follow a standard notation for design, such as

UML, DFD, ERD, etc.– Make sure design addresses both functional

and non-functional requirements– Follow personal design standards, hopefully

in concert with organizational standards

www.ischool.drexel.eduINFO636 Week 8 16

Design Reviews

• Follow a design review strategy– Look at various elements of design

systematically – don’t try to assess it all at once

• Design review strategy stages might include– Check for required program elements

www.ischool.drexel.eduINFO636 Week 8 17

Design Reviews

– Examine overall program structure and flow – Check for logical completeness– Check for robustness - handling errors, etc.– Check parameters and types for methods and

procedure calls– Check special variables, data types, and files,

including aliases

www.ischool.drexel.eduINFO636 Week 8 18

Design Reviews

• Check design against the requirements

• More elaborate inspections might use – A traceability matrix to prove completeness,

or – Use formal methods (Z, Larch) to show

correctness mathematically

www.ischool.drexel.eduINFO636 Week 8 19

Measuring Reviews

• Key basic measures for reviews are– Size of product being reviewed (in pages or

LOC)– The review time, in minutes– The number of defects found– And based on later work, the defects that

weren’t found by the review

www.ischool.drexel.eduINFO636 Week 8 20

Measuring Reviews

• Derived metrics for reviews are– Review yield, the percent of defects found by

review• Yield = 100*(defects found) /

(defects found + defects not found)

– Number of defects found per kLOC or page– Number of defects found per hour of review

time

www.ischool.drexel.eduINFO636 Week 8 21

Measuring Reviews

– The number of LOC or pages reviewed per hour

– Defect Removal Leverage (DRL)• The ratio of defects removed per hour for any two

phases or activities– DRL(coding) = Defects/hour(coding)/

Defects/hour(design)

www.ischool.drexel.eduINFO636 Week 8 22

Checklists

• Checklists are used to help make sure a process or procedure is followed consistently each time

• A sample code review checklist for C++ is on page 242; variations can be developed for other languages– It has several blank columns so each module

can be checked off separately

www.ischool.drexel.eduINFO636 Week 8 23

Designing Checklists

• Checklists should be designed so that you have to focus on only one topic at a time– Similar to reviewing a book for grammar

versus plot development – it’s hard to look for both at once

• To use a checklist most effectively, completely review one module

www.ischool.drexel.eduINFO636 Week 8 24

Using Checklists

• Different strategies should be considered for different types of reviews– Design review for a large application might

prefer to be from the top down– Code review often works better from the

bottom up for your code, but top down for someone else’s

www.ischool.drexel.eduINFO636 Week 8 25

Building Checklists

• Don’t take the example on p. 242 as the ultimate final perfect most-wonderful-of-all checklist that ever was *breathe*

• Study the kinds of problems you encounter (in your defect log) to see what you need to emphasize in your checklist– In other words, tailor the checklist for yourself

www.ischool.drexel.eduINFO636 Week 8 26

Building Checklists

• The types of defects are given on page 260 – again, consider adapting this to your needs and other languages

• One way to look for your most common types of defects is to lump all your defect logs together, and generate a Pareto chart by defect type

www.ischool.drexel.eduINFO636 Week 8 27

Building Checklists

• A refined defect type list is shown on page 262; you can use a Pareto diagram to figure out which kinds of defects you need to expand upon

• This also connects to the coding standard developed ages ago – you can use lessons learned from defect analysis to help refine the coding standard

www.ischool.drexel.eduINFO636 Week 8 28

Review Before or After Compile?

• A contentious issue in PSP is whether to review code before compile or after– A non-issue in some languages, which aren’t

compiled!

• In Humphrey’s experience, about 9% of all syntax errors aren’t caught by a compiler, so don’t expect it to catch everything

www.ischool.drexel.eduINFO636 Week 8 29

Reviews vs. Inspections

• As a matter of courtesy, make sure a program or document is in pretty good shape before submitting it for review or inspection– Very formal inspections might require code to

pass unit testing, and show test results as part of the inspection

– Humphrey doesn’t like testing before inspection, however

www.ischool.drexel.eduINFO636 Week 8 30

(P track) Report R4

• Report R4 (p. 771) analyzes the defects from all the previous assignments

• Tasks are:– Develop a process and scripts to create your

report– Follow that process and show the completed

report

www.ischool.drexel.eduINFO636 Week 8 31

(P track) Report R4

• Sample contents of the report should include, at a minimum– An analysis of estimating accuracy for size

and time for the programs to date– Analysis of defects injected and removed,

using table D23 as an example– Analysis of defects found by the compiler (if

any), ala table C24

www.ischool.drexel.eduINFO636 Week 8 32

(P track) Report R4

– Analysis of defect fix times, using table D22 again

– Develop a design checklist for use during design review

– Develop a code checklist for use during code review

– Discuss the results of the report, and set improvement goals for yourself

www.ischool.drexel.eduINFO636 Week 8 33

(P track) Report R4

• Use graphs where possible, but don’t forget to discuss the trends observed on them– A graph with no discussion is lonely

• This report is the culmination of the PSP 1.x level of process, leading us to PSP 2