1. Inspections : A Flexible Method to Increase Software Quality By Sylvie Trudel CRIM sylvie.trudel@crim.ca CUSEC, Concordia University March 2002

2. 2 Presentation Objectives l Provide a level of awareness on inspection practices in the software industry l Demonstrate flexibilty in a formal technical review method

3. 3 Agenda l History l Why Inspect ? l Inspection Objectives l Inspection Method l Quality Assurance And Managers Role l Return On Investment l Leverage and Barriers

4. 4 History l Created in the late 60’s (IBM) l Published by Fagan in the 70’s l Many methods developed over the last 10 years :  We will show an adaptation of Tom Gilb and Dorothy Graham’s work  Deployed and optimized over 2000 software inspections

5. 5 Why Inspect ? l Quality : Find and correct defects l Productivity : reduce time-to-market l Efficiency : Correct defects at their point of origin l Cost :  up to 1,000 times cheaper to correct an error during analysis than during test  up to 40,000 times if the defect is correct before deployment!

6. 6 Inspection Objectives l Find and fix defects l Help the developer l Reduce time-to-market l Alleviate the « downstream » effect of defects l Train team members (knowledge transfer) l Process improvement l And many more!

7. 7 Inspection Is Not... l Design Optimization l Quality of design approval l Level of ambition approval l A discussion forum l A bureaucratic routine! l IT IS:  Inner consistency checking of all related documents, by peers  Verifying against defined best practices (rules, checklists)  Only done if measurably profitable

8. 8 Inspection Context Inspection Process (documented) Author Product considered ready to inspect Sources (Physical, electronic, or references) Trained Inspectors Inspection Leader 1. Plan 2. Open 3. Inspect 4. Explain 5. Edit 6. Verify 7. Close RolesChecklistsRules Inspection Database Inspection Form Process Improvement Suggestions Re-inspection required Defects Noted Entry/Exit Criteria

9. 9 Sources Inspection Process : Detailed View 1. Plan the Inspection 2. Open the inspection 3. Inspect the product 4. Explain issues found 5. Edit the product 6. Verify corrections 7. Close the inspection Not Ready Corrections not accepted Author Ready Corrections accepted Process Improvement Suggestions Product considered ready to inspect Inspection Database Rules Roles Checklists Inspection Form Product (Updated) Product (Defects noted) Entry/Exit Criteria

10. 10 Inspecting: The Key Points l 2 to 5 inspectors :  at least 2 different roles  the author cannot be the inspection leader  the author can be an inspector with at least 2 other inspectors l Inspect slowly to find more important defects :  3 to 5 pages/hour for most documents  up to 20 pages/hour for code (~1,000 LOC) l Attitude, attitude, attitude!  Respect, professionalism, minded to help the author, aim for excellence, give/share/receive

11. 11 Inspection Rules : Some Examples l Generic  Complete  Clear  Consistent  Correct  Brief  Relevant l Design  Loose coupling  High cohesion l Requirements  Testable  High-level  Elementary l Code  Confined  Complexity  Style

12. 12 Most Common Inspector Roles l Logic l Requirements l User interface  Usability  Consistency l Standards l Quality l Design  Coupling  Cohesion l Rules l Algorithm l Graphics l Financial

13. 13 Quality Assurance Role l Audit inspection process usage l Inspect with a role such as « standard » or « quality » l Show « due diligence »  Have its own documents inspected

14. 14 Manager Role l Support inspection process usage l Provide resources l NEVER ask for individual inspection results l Show « due diligence »  Have its own documents inspected l Show enthusiasm on positive results l Sanction the “outlaws” l Do not inspect subordonate’s work  unless they insist

15. 15 Return On Investistment l Ratio of rework saved by inspection hour : ØAccording to Gilb  9.3 : 1 ØAccording to an IBM study  18 : 1 l Account for : ØCost of quality (inspection effort) ØCost of non-quality ØCorollaries (hard to put numbers on) n More performant software development teams (better productivity through enhanced communication) n Organization’s reputation

16. 16 Leverage l Positive attitude towards quality l Willingness to improve at all levels l Customer or contractual requirements l Working climate that promotes :  respect  excellence  innovation

17. 17 Barriers l Lack of resources l Previous bad experience l A blame culture l Big egos, prima donna behaviours l Opinion leaders who reject any process

18. 18 You certainly have questions ? Lets inspect!

19. 19 References l Tom Gilb and Dorothy Graham, Software inspections, Addison- Wesley, 1993 l Tom Gilb, Document Inspection Team Leader Course material, version 8.21, 1996 l Roger S. Pressman, Software Engineering: A practitioner’s Approach, 5th édition, McGraw-Hill, 2001 l Partick D’Astous, Les aspects de l’échange d’information dans un processus de génie logiciel, École Polytechnique de Montréal, 1996 l Karl E. Wiegers, Software Requirements, Microsoft Press, 2000

20. 20 Contact Sylvie Trudel Software Engineering Specialist sylvie.trudel@crim.ca (514) 840-1235 ext. 4562 CRIM Software Test Center www.crim.ca