Slideshare.net (beta)

 
Post to TwitterPost to Twitter
Post: 
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 2 (more)

Software Inspection And Defect Management

From ajaykemparaj, 2 years ago

2838 views  |  0 comments  |  2 favorites  |  334 downloads
 

Categories

Add Category
 
 

Groups / Events

 

 
Embed
options

More Info

This slideshow is Public
Total Views: 2838
on Slideshare: 2838
from embeds: 0

Slideshow transcript

Slide 1: Software Inspection and Defect Management Kubendran G

Slide 2: Content Introduction  Quality Management  Defect  Defect management  Defect Classification  Cost to fix Defects  Defect Trends  Defect Control  Inspection – Review  Software Inspection Process  Case study  In Formal Inspection  Formal Inspection  Roles, Responsibility and Process Benefits of Inspections  Conclusions & Questioners  Feedback 

Slide 3: Project Efforts Work + Effort and Time Rework Rework is the cost of detection of defects, correction of  defects, detection of regression defects and correction of regression defects

Slide 4: Rework Phase – wise Distribution of Rework  Requirements : 1%  Preliminary Design : 4%  Detailed design : 8%  Code & Unit Test : 12%  Integration & System Test : 19%  Total Rework : 44%

Slide 5: Overview of Quality Management Reduce Rework to reduce time and costs  of Projects Quality Assurance - Prevention of defects  Quality Control - Detect defect early  Testing can be static and dynamic  Testing- Testing application. 

Slide 6: Defect Defect, fault, Problem, Error, Incident, Anomaly, Variance, Failure, Inconsistency, Feature, Bug The software does not do something that the  product specifications says it should do The software does something that the product  specification says it should not do

Slide 7: Potential Defects The software does something that the  product specifications does not mention The software does not do something  the specifications does not mention but should The software is difficult to understand,  hard to use, is slow or – in the tester’s eyes – will be viewed by the end user as just plain not right.

Slide 8: Defects 4 Cs Clear   Consistent  Correct  Complete

Slide 9: Causes of Defects Omission : I forgot something that I knew I  had to do Ignorance : I forgot something, because I  did not know, I had to do it Commission : I did something wrong  although I knew how to do it right Typography : I typed something wrong  though I knew how to do it right

Slide 10: Causes of Defects Knowledge : I did something wrong  because I did not know how to do it Information : I did something wrong  because I did not have the right information or information was misleading External : I did nothing wrong. The  problem was somewhere else and the defect was introduced by some other person

Slide 11: Defect classification INSPECTION REPORT Major Defect  Minor Defect  Potential Defect ( Investigate, Clarify)  Q – to be sorted during third hour off-line  PROCESS ANALYSIS MEETING REPORT Process Improvement Suggestion  Product Improvement Suggestion 

Slide 12: Cost to fix Defects 10000 9000 8000 7000 6000 5000 4000 3000 2000 1000 0 Reqs Design Code Testing Post Release

Slide 13: Defects Trends Requirements 20 Design 40 Code 100 Unit Test 50 Integration Test 20 System Test 10 Defects Profile without Reviews

Slide 14: Defects Control Requirements Reviews 5 (20) Design Reviews 10(40) Code Reviews 15(100) Unit Test 7 (50) Integration Test 3 (20) System Test 1(10) Defects Profile with Reviews

Slide 15: Review - Inspection Review:  Presentation of each SW Component to the Group in each Development Phase Discussion and Coordination with other components Goal: Clarification and Accept/Reject Decision Inspection:  Quality Improvement Process to the software project Goal: Defect Detection & Defect Prevention

Slide 16: What is Software Inspection/ Review Review is a team process to identify defects in  software work products early and efficiently. Review is a process where a group of people  scrutinize a work product with the intention of finding defects. They find the defects, discuss and help eliminate  the defects and the cause of defects Review is a powerful, efficient and effective  process for defect management

Slide 17: Software Inspection Process Requirements Document Inspection Design Test Plan Document Inspection Document Inspection Implementation Test Implementation Applying Testing Tools Document Inspection Code Inspection Code Inspection Test

Slide 18: Inspection - Objectives Defect Detection  documents are checked for  cleanness and consistency against rules Defect Prevention  learning from defects found  suggesting improvements 

Slide 19: What is Software Inspection/ Review (cont..) A simple process to identify defects  Highly structured meeting  Forum for independent evaluation  Form of static analysis or static testing  Early, in-process validation technique  Form of quality and reliability engineering  Performed by software engineering 

Slide 20: Objectives of Software Inspection Identify as many defects as possible  Identify defects in early stages of life cycle  Identify defects before testing and fielding  Identify defects cheaply and inexpensively  Reduce development and maintenance  costs Shorten development cycle time  Quantitatively control quality and  reliability

Slide 21: InFormal and Formal Inspection Informal Case Study  Formal Case Study 

Slide 22: Formal Inspection Process Inspection Stage Description Identifies work product to be inspected and sets Review Planning the inspection schedule. Optional phase where team members who are Overview Meeting unfamiliar with the work product to be inspected receive orientation. Team members inspect the work individually Individual Preparation looking for defects in the work product. Log Bugs, agreed by all . Defect Logging Meeting Root cause analysis. Process Analysis Meeting Action, Update the bug status. Rework The rework is verified, final inspection data is Follow up collected and summarized, and the inspection is officially closed. - Baseline the doc.

Slide 23: The Formal Inspection Team Author  The individual that assumes the role of Author will be ultimately responsible for  updating the work product after the inspection. PM.  Moderator  The Moderator is responsible for ensuring that the inspection procedures are  performed through out the entire inspection process. Lead.  Reader  The reader is responsible for leading the Inspection Team through the inspection  meeting by reading aloud small logical units, paraphrasing where appropriate. Recorder  The Recorder will document all defects that arise from the inspection meeting.  This documentation will include where the defect was found.  Inspector  All of the Inspection Team individuals are also considered to play the Inspector  role, independent of other roles assigned. Observers or Passive player or QA 

Slide 24: Benefits of Inspections IBM  Inspections Resulted in:  23% Increase in coding Productivity 38% Reduction in Defects detected after Unit test AT&T  Inspections Resulted in:  14% Increase in Productivity Tenfold Increase in Quality Inspections are 20 times more effective than Testing  HP  80% of Defects detected by Inspections were unlikely to  be detected by other means

Slide 25: Conclusions Reviews prepare the ground and stabilize SDP Adaptation of the inspection method for the Environment Gain in quality and experience Appreciated by authors and peers Help for team building in a distributed environment

Slide 26: Future Good understanding for the next phase:  stabilize inspection process and keep style  provide a helpful framework based on experience  use it through entire development cycle  ‘lighter’ inspection - faster turnaround time  use sampling techniques  keep real logging meetings where possible  provide metrics  stay flexible and efficient  http://atddoc.cern.ch/Atlas/DaqSoft/sde/Welcome.html doris.burckhart@cern.ch