Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reviews Checklists


Published on

  • Be the first to comment

Reviews Checklists

  1. 1. SOFTWARE QUALITY ASSURANCE REVIEWS & CHECKLISTS Seminar: Oana FEIDI Quality Manager – Continental Automotive
  2. 2. Prerequisites <ul><li>rework cost in average is responsible for ~40% of the total software development cost </li></ul><ul><li>engineers spend up to 1/3 of their compiling & testing, relying on these activities to detect defects </li></ul><ul><li>reviews – an inexpensive& effective approach for reducing rework </li></ul><ul><ul><li>NASA – by introducing software reviews activities in its projects </li></ul></ul><ul><ul><ul><li>29% of total improvement in its process </li></ul></ul></ul><ul><ul><ul><li>10% in the reliability on its products </li></ul></ul></ul>
  3. 3. Software Quality activities <ul><li>software reviews – objective: finding analysis and design defects in SW artifacts produced in the initial phases of SW development </li></ul><ul><li>testing </li></ul><ul><li>patterns & formal procedures </li></ul><ul><li>change control </li></ul><ul><li>SW metrics – used to trace SW QA and to evaluate the impact of various methodologies and procedures </li></ul><ul><li>Documented & stored records </li></ul>
  4. 4. Review <ul><li>A software review is </li></ul><ul><ul><ul><li>&quot;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”] </li></ul></ul></ul><ul><li>The earlier errors are found, </li></ul><ul><ul><ul><li>the lower the costs of correcting the errors and </li></ul></ul></ul><ul><ul><ul><li>the higher the probability of correcting the errors correctly </li></ul></ul></ul><ul><li>Categories </li></ul><ul><ul><ul><li>Walkthrough </li></ul></ul></ul><ul><ul><ul><li>Code Inspection </li></ul></ul></ul>Source :
  5. 5. Reviews targets <ul><li>to have a more comprehensible project, that facilitates comprehension by other developers, by describing in a condensed way what is described in the code </li></ul><ul><li>saving implementation time, by removing problems with faulty logic and missing functionality before implementation </li></ul><ul><li>improving the efficiency of the reviews, since fewer artifacts need to be reviewed together and defects are removed incrementally, rather than at one time </li></ul>
  6. 6. Code Inspections <ul><li>A set of procedures and error-detection techniques </li></ul><ul><li>Concentrates on discovering errors, not correcting them </li></ul><ul><li>Objective : to find errors in the program, thus improving the quality of work </li></ul><ul><li>Benefits </li></ul><ul><ul><ul><li>The programmer receives feedback concerning programming style, choice of algorithms and programming techniques </li></ul></ul></ul><ul><ul><ul><li>The other members of the team: share experience </li></ul></ul></ul><ul><li>Optimal amount of time: 90-120 min </li></ul><ul><li>Rate: average 150 program statements/hour </li></ul><ul><li>Comments should be directed toward the program, rather than the programmer </li></ul>
  7. 7. The team <ul><li>An inspection team usually consists of four people </li></ul><ul><ul><ul><li>Moderator </li></ul></ul></ul><ul><ul><ul><li>Programmer </li></ul></ul></ul><ul><ul><ul><li>Test specialist </li></ul></ul></ul><ul><ul><ul><li>Program’s designer </li></ul></ul></ul><ul><li>Moderator </li></ul><ul><li>Distributes materials and schedules the inspection session </li></ul><ul><li>Leads the session </li></ul><ul><ul><ul><li>ensures that the discussions proceed along productive lines </li></ul></ul></ul><ul><ul><ul><li>ensures that the participants focus their attention on finding errors, not correcting them </li></ul></ul></ul><ul><li>Records all errors found </li></ul><ul><li>Ensures that the errors are subsequently corrected </li></ul>
  8. 8. Walkthroughs <ul><li>“ 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&quot; [IEEE 1028:1997 – “IEEE Standard for software reviews”] </li></ul><ul><li>Objectives </li></ul><ul><ul><ul><li>to gain feedback about the technical quality or content of the document </li></ul></ul></ul><ul><ul><ul><li>to familiarize the audience with the content </li></ul></ul></ul><ul><li>IEEE 1028 recommends three specialist roles in a walkthrough: </li></ul><ul><ul><ul><li>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; </li></ul></ul></ul><ul><ul><ul><li>walkthrough leader , who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and </li></ul></ul></ul><ul><ul><ul><li>The recorder , who notes all potential defects, decisions, and action items identified during the walkthrough meeting. </li></ul></ul></ul>
  9. 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 defects found - inspection repeats
  10. 10. Review template structure <ul><li>Location of error </li></ul><ul><ul><ul><li>chapter, function, … </li></ul></ul></ul><ul><li>Severity </li></ul><ul><ul><ul><li>major, minor </li></ul></ul></ul><ul><li>Type </li></ul><ul><ul><ul><li>error or remark </li></ul></ul></ul><ul><ul><ul><li>algorithm, documentation, data usage </li></ul></ul></ul><ul><li>Time spent per review </li></ul><ul><li>Metrics : </li></ul><ul><li>effort per review </li></ul><ul><li>findings per review </li></ul><ul><li>number of lines reviewed </li></ul>
  11. 11. Checklist <ul><li>An important part of the inspection is the use of checklist to examine the program for common errors </li></ul><ul><li>As general as possible </li></ul><ul><li>Based on lessons learned </li></ul><ul><li>Examples </li></ul><ul><ul><ul><li>“ Are comments accurate and meaningful?” </li></ul></ul></ul><ul><ul><ul><li>“ Are all variables declared?” </li></ul></ul></ul><ul><ul><ul><li>Java : </li></ul></ul></ul><ul><ul><ul><li>Requirements : </li></ul></ul></ul><ul><ul><ul><li> </li></ul></ul></ul>
  12. 12. <ul><li>THANK YOU! </li></ul>