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

No notes for slide

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 </li></ul><ul><ul><li>objective: finding analysis and design defects in SW artifacts produced in the initial phases of SW development </li></ul></ul><ul><li>testing </li></ul><ul><li>patterns & formal procedures </li></ul><ul><li>change control </li></ul><ul><li>SW metrics </li></ul><ul><ul><li>used to trace SW QA and to evaluate the impact of various methodologies and procedures </li></ul></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. 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>
  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. 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. 9. 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>
  10. 10. <ul><li>&quot;Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard </li></ul>
  11. 11. Specification review <ul><li>What to look for: </li></ul><ul><ul><li>Inconsistencies </li></ul></ul><ul><ul><li>Missing “else” branch of a specification </li></ul></ul><ul><ul><li>Misinterpretation – unclear requirements </li></ul></ul><ul><ul><li>Requirements that are excluding one another </li></ul></ul><ul><li>Exercise 1 (working groups): document the review of the following specification </li></ul><ul><ul><li>Use the checklist from the following link as support: </li></ul></ul>
  12. 12. Static code analysis <ul><li>performed without actually executing programs built from that software </li></ul><ul><li>Code compliance to certain guidelines </li></ul><ul><ul><li>M.I.S.R.A. compliance- Motor Industry Software Reliability Association </li></ul></ul><ul><ul><li>Example of MISRA rules </li></ul></ul><ul><li>Exercise 2 (homework): check the compliance of a .c file using the Q-AC Free Trail license from the following link: </li></ul><ul><ul><li>Bring the metrics & reports in the next seminar </li></ul></ul>
  13. 13. 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>
  14. 14. Code inspection <ul><li>Correctness of the algorithm implementation/specification </li></ul><ul><ul><li>Exercise 3 (working groups): identify if the following .c code implements correctly the Bubble sort algorithm </li></ul></ul><ul><ul><li>Use the following checklist as support </li></ul></ul>
  15. 15. 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>
  16. 16. <ul><li>THANK YOU! </li></ul>