INFO 636 Software Engineering Process I Prof. Glenn Booker

1. INFO 636Software Engineering Process IProf. Glenn Booker Week 8 – Reviews INFO636 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 INFO636 Week 8

3. Reviews • Review types in descending order of formality include • Inspections • Walk-throughs • Personal reviews INFO636 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 INFO636 Week 8

5. Inspections • Then there’s an inspection meetingto 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 INFO636 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 INFO636 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! INFO636 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! INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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) INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 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 INFO636 Week 8