Your SlideShare is downloading. ×

Reviews checklists


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Software Quality Assurance Reviews & Checklists Seminar: Oana FEIDI Quality Manager – Continental Automotive
  • 2. Prerequisites
    • rework cost in average is responsible for ~40% of the total software development cost
    • engineers spend up to 1/3 of their compiling & testing, relying on these activities to detect defects
    • reviews – an inexpensive& effective approach for reducing rework
      • NASA – by introducing software reviews activities in its projects
        • 29% of total improvement in its process
        • 10% in the reliability on its products
  • 3. Software Quality activities
    • software reviews
      • objective: finding analysis and design defects in SW artifacts produced in the initial phases of SW development
    • testing
    • patterns & formal procedures
    • change control
    • SW metrics
      • used to trace SW QA and to evaluate the impact of various methodologies and procedures
    • Documented & stored records
  • 4. Review
    • A software review is
        • "A process or meeting during which a software product is [examined by] project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval” [IEEE 1028:1997 – “IEEE Standard for software reviews”]
    • The earlier errors are found,
        • the lower the costs of correcting the errors and
        • the higher the probability of correcting the errors correctly
    • Categories
        • Walkthrough
        • Code Inspection
    Source :
  • 5. Reviews targets
    • to have a more comprehensible project, that facilitates comprehension by other developers, by describing in a condensed way what is described in the code
    • saving implementation time, by removing problems with faulty logic and missing functionality before implementation
    • improving the efficiency of the reviews, since fewer artifacts need to be reviewed together and defects are removed incrementally, rather than at one time
  • 6. Walkthroughs
    • “ a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems" [IEEE 1028:1997 – “IEEE Standard for software reviews”]
    • Objectives
        • to gain feedback about the technical quality or content of the document
        • to familiarize the audience with the content
    • IEEE 1028 recommends three specialist roles in a walkthrough:
        • author , who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items;
        • walkthrough leader , who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and
        • The recorder , who notes all potential defects, decisions, and action items identified during the walkthrough meeting.
  • 7. The team
    • An inspection team usually consists of four people
        • Moderator
        • Programmer
        • Test specialist
        • Program’s designer
    • Moderator
    • Distributes materials and schedules the inspection session
    • Leads the session
        • ensures that the discussions proceed along productive lines
        • ensures that the participants focus their attention on finding errors, not correcting them
    • Records all errors found
    • Ensures that the errors are subsequently corrected
  • 8. Review flow Planning: - verify materials meet entry criteria - schedule meeting - distribute documents Meeting: - materials presented by authors / materials reviewed as a group - defects recorded - metrics collected (if necessary) Rework : - author fixes defects alone DONE Additional defects found - inspection repeats
  • 9. Review template structure
    • Location of error
        • chapter, function, …
    • Severity
        • major, minor
    • Type
        • error or remark
        • algorithm, documentation, data usage
    • Time spent per review
    • Metrics :
    • effort per review
    • findings per review
    • number of lines reviewed
  • 10.
    • "Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard
  • 11. Specification review
    • What to look for:
      • Inconsistencies
      • Missing “else” branch of a specification
      • Misinterpretation – unclear requirements
      • Requirements that are excluding one another
    • Exercise 1 (working groups): document the review of the following specification
      • Use the checklist from the following link as support:
  • 12. Static code analysis
    • performed without actually executing programs built from that software
    • Code compliance to certain guidelines
      • M.I.S.R.A. compliance- Motor Industry Software Reliability Association
      • Example of MISRA rules
    • Exercise 2 (homework): check the compliance of a .c file using the Q-AC Free Trail license from the following link:
      • Bring the metrics & reports in the next seminar
  • 13. Code Inspections
    • A set of procedures and error-detection techniques
    • Concentrates on discovering errors, not correcting them
    • Objective : to find errors in the program, thus improving the quality of work
    • Benefits
        • The programmer receives feedback concerning programming style, choice of algorithms and programming techniques
        • The other members of the team: share experience
    • Optimal amount of time: 90-120 min
    • Rate: average 150 program statements/hour
    • Comments should be directed toward the program, rather than the programmer
  • 14. Code inspection
    • Correctness of the algorithm implementation/specification
      • Exercise 3 (working groups): identify if the following .c code implements correctly the Bubble sort algorithm
      • Use the following checklist as support
  • 15. Checklist
    • An important part of the inspection is the use of checklist to examine the program for common errors
    • As general as possible
    • Based on lessons learned
  • 16.
    • THANK YOU!