Reviews Checklists

download Reviews Checklists

of 12

  • date post

  • Category


  • view

  • download


Embed Size (px)



Transcript of Reviews Checklists

  • 1. SOFTWAREQUALITY ASSURANCE REVIEWS & CHECKLISTSSeminar: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

  • Asoftware reviewis
      • "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. 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

7. The team

  • An inspection team usually consists of four people
      • Moderator
      • Programmer
      • Test specialist
      • Programs 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. 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
      • Therecorder , who notes all potential defects, decisions, and action items identified during the walkthrough meeting.

9. 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 defectsfound - inspection repeats 10. 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

11. 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
  • Examples
      • Are comments accurate and meaningful?
      • Are all variables declared?
      • Java :
      • Requirements :