Reviews checklists


Published on

Published in: Technology, Business
  • 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. INTRO <ul><li>Software Quality Assurance : a systematic and planned pattern of actions that are demanded to guarantee software quality </li></ul><ul><li>Activities to check software quality: </li></ul><ul><ul><li>Software reviews </li></ul></ul><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><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Patterns and formal procedures </li></ul></ul><ul><ul><li>Change control </li></ul></ul><ul><ul><li>Software metrics </li></ul></ul><ul><ul><li>Registering and record keeping </li></ul></ul>
  3. 3. PREREQUISITES Source :
  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>German company: </li></ul><ul><ul><ul><li>a defect caught by testing costs 14.5 time as much to correct compare to one discovered by formal inspection </li></ul></ul></ul><ul><ul><ul><li>a defect discovered by a customer costs 68 times as much to fix </li></ul></ul></ul>
  5. 5. REVIEWS: BENEFITS <ul><li>Decrease the costs of fixing a defect </li></ul><ul><li>Shorten the delivery time </li></ul><ul><li>Reduce the rework, thus increasing productivity </li></ul><ul><li>Group reviews provide an opportunity to see how other team members are working </li></ul><ul><ul><li>(Knowledge is automatically exchanged: </li></ul></ul><ul><ul><ul><li>programming language features </li></ul></ul></ul><ul><ul><ul><li>coding and commenting style </li></ul></ul></ul><ul><ul><ul><li>program architecture </li></ul></ul></ul><ul><ul><ul><li>design notations </li></ul></ul></ul><ul><ul><ul><li>ways to document requirements) </li></ul></ul></ul><ul><ul><li>provide an effective “forum” for less experienced team members </li></ul></ul>
  6. 6. REVIEW: COMMON BUGS Source : Error Type Review Testing Module interface errors X Excessive code complexity X Un-required functionality present X Usability problems X Performance problems X X Badly structured code X Failure to meet requirements X X Boundary value errors X X
  8. 8. REVIEW TYPE: WALKTHROUGH <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. SUCCESSFUL REVIEW: TIPS & TRICKS <ul><li>Check your egos at the door </li></ul><ul><ul><li>“ we prefer to have a peer find a defect, </li></ul></ul><ul><ul><li>rather than the customer” </li></ul></ul><ul><li>Critique the products, not the producers </li></ul><ul><li>Find problems during the review; </li></ul><ul><li>don’t try to fix them </li></ul><ul><li>Limit inspection meetings to a max 2 hours </li></ul><ul><ul><li>Optimum balance: 150-200 lines of code/hour </li></ul></ul><ul><ul><li>Optimum balance: 4-6 pages of design or text/hour </li></ul></ul><ul><li>Avoid style issues unless they impact the performance or understandability </li></ul><ul><ul><li>Use coding standards or code “beautifiers” </li></ul></ul><ul><ul><li>Focus on uncovering errors in logic, function or implementation </li></ul></ul><ul><li>Inspect early and often, formally & informally </li></ul>
  10. 10. FAILED REVIEW: AVOIDING TIPS & TRICKS <ul><li>Developers fear that the review result will be used against them during evaluation </li></ul><ul><li>Authors are unable to separate their egos from their work products; claim they don’t need reviews; become defensive during the review </li></ul><ul><li>Participants don’t prepare adequately prior to the review meeting </li></ul><ul><li>Documents under review are not self-explanatory </li></ul><ul><li>Author does not take the result of the review seriously </li></ul><ul><li>Review meetings loose their focus -> trap to fall into technical discussions rather than covering the document under review </li></ul><ul><li>Project schedule doesn’t leave room for reviews </li></ul>
  11. 11. REVIEW: DOCUMENTATION <ul><li>Documentation of review results is the major distinction between informal and informal review </li></ul><ul><li>Each error found is described in enough detail (line of code reference, function name, (sub)chapters) </li></ul><ul><li>Each company customizes its own classification for defects/issues (errors/remarks); severity; development phase in which the error was introduced </li></ul><ul><li>Documentation of review means: </li></ul><ul><ul><li>Record defects during review meeting </li></ul></ul><ul><ul><li>Collect data from multiple inspections </li></ul></ul><ul><ul><li>Analyze defect trend </li></ul></ul><ul><ul><ul><li>Assess review effectiveness </li></ul></ul></ul><ul><ul><ul><li>Identify ways to improve the software development process to prevent common types of defects </li></ul></ul></ul>
  12. 12. CHECKLIST <ul><li>“ hunt for anticipating types of errors” </li></ul><ul><li>Sample for code inspections ( ) </li></ul>
  13. 13. <ul><li>&quot;Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard </li></ul>
  14. 14. 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 (working groups): </li></ul><ul><ul><li>document the review of the specification received (including checklist) </li></ul></ul>
  15. 15. <ul><li>THANK YOU! </li></ul>