Reviews checklists

Uploaded on


More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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!