Reviews checklists
Upcoming SlideShare
Loading in...5
×
 

Reviews checklists

on

  • 3,508 views

 

Statistics

Views

Total Views
3,508
Views on SlideShare
3,508
Embed Views
0

Actions

Likes
0
Downloads
64
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Reviews checklists Reviews checklists Presentation Transcript

  • SOFTWARE QUALITY ASSURANCE REVIEWS & CHECKLISTS Seminar: Oana FEIDI Quality Manager – Continental Automotive
  • INTRO
    • Software Quality Assurance : a systematic and planned pattern of actions that are demanded to guarantee software quality
    • Activities to check software quality:
      • Software reviews
        • objective: finding analysis and design defects in SW artifacts produced in the initial phases of SW development
      • Testing
      • Patterns and formal procedures
      • Change control
      • Software metrics
      • Registering and record keeping
  • PREREQUISITES Source : http://cronos.cos.ufrj.br/publicacoes/reltec/es55601.pdf
  • 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”]
    • German company:
        • a defect caught by testing costs 14.5 time as much to correct compare to one discovered by formal inspection
        • a defect discovered by a customer costs 68 times as much to fix
  • REVIEWS: BENEFITS
    • Decrease the costs of fixing a defect
    • Shorten the delivery time
    • Reduce the rework, thus increasing productivity
    • Group reviews provide an opportunity to see how other team members are working
      • (Knowledge is automatically exchanged:
        • programming language features
        • coding and commenting style
        • program architecture
        • design notations
        • ways to document requirements)
      • provide an effective “forum” for less experienced team members
  • REVIEW: COMMON BUGS Source : http://www.processimpact.com/articles/inspects.html 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
  • REVIEW TYPE: (FAGAN) INSPECTION
  • REVIEW TYPE: WALKTHROUGH
    • “ 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.
  • SUCCESSFUL REVIEW: TIPS & TRICKS
    • Check your egos at the door
      • “ we prefer to have a peer find a defect,
      • rather than the customer”
    • Critique the products, not the producers
    • Find problems during the review;
    • don’t try to fix them
    • Limit inspection meetings to a max 2 hours
      • Optimum balance: 150-200 lines of code/hour
      • Optimum balance: 4-6 pages of design or text/hour
    • Avoid style issues unless they impact the performance or understandability
      • Use coding standards or code “beautifiers”
      • Focus on uncovering errors in logic, function or implementation
    • Inspect early and often, formally & informally
  • FAILED REVIEW: AVOIDING TIPS & TRICKS
    • Developers fear that the review result will be used against them during evaluation
    • Authors are unable to separate their egos from their work products; claim they don’t need reviews; become defensive during the review
    • Participants don’t prepare adequately prior to the review meeting
    • Documents under review are not self-explanatory
    • Author does not take the result of the review seriously
    • Review meetings loose their focus -> trap to fall into technical discussions rather than covering the document under review
    • Project schedule doesn’t leave room for reviews
  • REVIEW: DOCUMENTATION
    • Documentation of review results is the major distinction between informal and informal review
    • Each error found is described in enough detail (line of code reference, function name, (sub)chapters)
    • Each company customizes its own classification for defects/issues (errors/remarks); severity; development phase in which the error was introduced
    • Documentation of review means:
      • Record defects during review meeting
      • Collect data from multiple inspections
      • Analyze defect trend
        • Assess review effectiveness
        • Identify ways to improve the software development process to prevent common types of defects
  • CHECKLIST
    • “ hunt for anticipating types of errors”
    • Sample for code inspections ( http://www.processimpact.com/articles/inspects.html )
    • "Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard
  • SPECIFICATION REVIEW
    • What to look for:
      • Inconsistencies
      • Missing “else” branch of a specification
      • Misinterpretation – unclear requirements
      • Requirements that are excluding one another
    • Exercise (working groups):
      • document the review of the specification received (including checklist)
    • THANK YOU!