CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE

Slides:



Advertisements
Similar presentations
Project Management Concepts
Advertisements

Formal Process of QA and quality related certifications Formal Process of QA and quality related certifications MIM 3 rd year – Sem V Abhishek Mishra –
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Static Technique. Static Technique - Review  A way of testing software work products  Program code, requirement spec., design spec.  Test plan, test.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
1 reviews8 Software Reviews, Walkthroughs, and Inspections The standard technique to ensure quality in software development.
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
1 Software Testing and Quality Assurance Lecture 2 Software Verification & Validation.
Overview Lesson 10,11 - Software Quality Assurance
Software Quality Metrics
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited Review objectives Formal design reviews (FDRs) Participants Preparations.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations.
Verification and Validation
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Software Quality Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
Introduction to Software Quality Assurance (SQA)
Software Inspections and Walkthroughs By. Adnan khan.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
N By: Md Rezaul Huda Reza n
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
S oftware Q uality A ssurance Part One Reviews and Inspections.
Software Quality Assurance Activities
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Software Quality Assurance
Formal and Informal Peer Reviews
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
程建群 博士 (Dr. Jason Cheng) 年 03 月 Software Engineering Part 06.
S Q A.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
Chapter 12: Software Inspection Omar Meqdadi SE 3860 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
Project management Topic 8 Quality Review. Overview of processes Prepare for Quality Review Questions list Meeting Agenda Review Meeting Sign-off Product.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
Advances In Software Inspection
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Management of Software Project CSM Review By:Nafas.
Peer Review Presented by : Basker George. Peer ( 同等的人 ) Review( 回顾 ) During the development of software, defects are inevitably ( 不可避免 ) injected. Defect.
VERIFICATION AND VALIDATION TECHNIQUES. The goals of verification and validation activities are to assess and improve the quality of the work products.
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
SQA COMPONENTS IN THE PROJECT LIFE CYCLE C HAPTER 8 Dr. Ahmad F. Shubita.
1 Software Testing and Quality Assurance Motivation and Review of Software Verification & Validation (2)
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Software Reviews Ashima Wadhwa.
Software Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management (SCM)
Quality Measurable characteristic Cyclomatic complexity Cohesion
Applied Software Project Management
QA Reviews Lecture # 6.
Chapter # 1 Overview of Software Quality Assurance
WALKTHROUGH and INSPECTION
Software Reviews.
3. Software Quality Management
Presentation transcript:

CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE

WITH PROPER INSPECTIONS EARLY SKEPTIC BELIEVER FIRST HAND EXPERIENCE WITH PROPER INSPECTIONS AND ITS REWARDS

AGENDA: 1 Anatomy of Inspection. Inspection Team Inspection Phases Inspection Types Wrap-up 2 Lessons learned through the evolution of the Inspection process. 3 Inspection Metrics 4 The National perspective 5 Examples of Payoff

Anatomy Of Inspection Primary Purpose Secondary Purposes “..to remove defects as early as possible in the development process.” Secondary Purposes Trace requirements to design. Provide a technically correct base for next phase of development. Increase programming quality Increase product quality Decrease life cycle cost Increase effectiveness of test activity Provide first indication of maintainability Encourage entry/exit criteria software management

Anatomy Of Inspection… Inspection Team MANAGER MODERATOR INSPECTORS READER AUTHOR

Inspection Phases Planning: Starting Phase The moderator will Establish conduct & progress for entire process. Identify team members and roles Assure that materials to be inspected are available and conform to standards. Determine entry criteria is met. Determine need for overview. Schedule meeting time and place. Provide team with materials, resources and meeting notice.

Inspection Phases… Overview: Discretionary Phase The Author: Gives a brief description of the product, its functionality and interfaces. The Attendees: Get familiar with product before the inspection The Moderator: Conducts the overview meeting. Provides the inspection package to the team. Gives inspection meeting notice.

Inspection Phases… Preparation: Begins at least 5 days before inspection meeting. Lead time to allow inspectors to examine the material for all possible defects. Time spent – as much as duration of inspection meeting – maximum of 2 hours. Inspectors record the defects and the time spent in preparation. Reader prepares to present the material to the team. Reader records any difficulties in understanding the material.

Inspection Phases… Inspection Meeting: The main event Team meets to inspect the product. Moderator ensures proper conduct of the meeting. Reader presents the product to the team in a systematic manner. Team identifies, discusses, validates and records the defects detected. Moderator decides if re-inspection is required. Moderator logs records of preparation and inspection times, defects found and re-inspection requirement. Moderator sends the findings to author and SQA.

Inspection Phases… Rework: Follow-Up: Author examines the defects and makes the necessary fixes. Author verifies the fixes and informs moderator. Moderator determines if re-inspection required. Follow-Up: Moderator assures that all defects logged have been fixed. Moderator logs the verification and sends the summary to SQE. Moderator declares inspection complete.

I0 I1 I2 INSPECTION TYPES SOFTWARE DEVELOPMENT PHASES REQUIREMENTS PROGRAM SPECIFICATIONS LOW-LEVEL OR DETAILED DESIGN HIGH-LEVEL DESIGN CODE IMPLEMENTATION I0 I2 I1

Inspection Types… High-Level Design Inspection I0: Examine the HLD to verify that the specification has been correctly mapped to functional design. Identify each requirement to process and task. One I0 per mode. Perform all six inspection phases.

Inspection Types… Low-Level Design Inspection I1: Held for any module that is new, has structural or interface change, or 40% or more change in SLOC. Verifies the detailed design before translation to code. Perform all six inspection phases. Coding begins only after the successful completion of this inspection.

Inspection Types… Code Inspection I2: Held for all/selected new or changed code. Code must compile cleanly. Perform all six inspection phases. Result of a successful I2 – Compiled code that conforms to requirements specifications, high-level and low-level design. Testing begins only after the successful completion of this inspection.

Inspection Types…Some more Requirements Inspections Specification Inspections Document Inspections Salient Points: Inspection is effective only when the product is presented in a standardized, structured form. The results of these inspections, logged in a standardized form, can help the management in decision making.

Anatomy of Inspection – Wrap-up Inspection Defect Types Design Defects Logic Defects Syntax Defects Standards Defects Data Defects Interface Defects Return code/Message Defects Prologue/Comment Defects Requirements change Defects Performance Improvement Defects

Inspections - Success Factors Inspection Prerequisites Technically competent and trained inspectors. Trained moderator. Proper planning and distribution of materials. Good professional attitude. Full preparation prior to inspection meeting. Completed design or cleanly compiled code. Updated resource requirements. Training for managers to understand and gain from inspections.

AGENDA: 1 Anatomy of Inspection. Inspection Team Inspection Phases Inspection Types Wrap-up 2 Lessons learned through the evolution of the Inspection process. 3 Inspection Metrics 4 The National perspective 5 Examples of Payoff

Lessons Learned Keep the psychological factor in mind. – Help, don’t embarass!!! Make inspections impersonal Keep team size to small groups of peers Make data collection consistent Utilize only trained personnel.

Inspection Metrics Established by AT&T Bell Labs. Defines nine metrics. Help plan, monitor, control and improve code inspection process. Helped to achieve >70% defect removal. Used the Goal-Question-Metric paradigm to derive the nine metrics.

Inspection Metrics… GQM paradigm Identify measurement goal. Pose specific question – in measurable terms – whose answer fulfills the goal. Enumerate the metrics. Example Goal – Monitor and Control Question – What is the quality of the inspected software? Metric – Average faults detected per KLOC - Average inspection rate - Average Preparation rate

Inspection Metrics… Total KLOC Average lines of code inspected = 1000 x KLOC / #Inspections Average Preparation rate = 1000 x KLOC / AvgInspectPrepTime Average Inspection rate = 1000 x KLOC / TotInspectMeetingTime Average Effort per KLOC = TotInspectionEffort / KLOC

Inspection Metrics… (cont’d) Average Effort per fault detected = TotalInspectEffort / #Faults_Detected Average Faults detected per KLOC = #Faults_detected / KLOC Percentage of re-inspections = 100 * #Re-Inspections / #Inspections Defect removal efficiency = 100 x #Faults_Detected / #CodingFaults

AGENDA: 1 Anatomy of Inspection. Inspection Team Inspection Phases Inspection Types Wrap-up 2 Lessons learned through the evolution of the Inspection process. 3 Inspection Metrics 4 The National perspective 5 Examples of Payoff

National Software Quality Experiment Reasons for the experiment Quality has become a national goal. Software Engineering is maturing. Aware consumers demand higher quality. Aggressive quality goals at corporate level. Experiment - 1992 27 inspections labs 327 trained professionals 90,925 SLOC inspected using packaged procedures. 22, 828 minutes of preparation effort 5,464 minutes of inspection time 1,849 defects detected

Examples of Payoff AT&T Bell Laboratories Bell Northern Research Adopted Nine Metrics based on GQM paradigm Reduced cost of fault removal by 300% Defect Removal Efficiency of +70% Bell Northern Research Inspections give 1 defect per person-hour invested – 2-4 times faster than testing 1 person-hour of code inspection saves 33 person-hours of future maintenance effort.

Examples of Payoff… Large Satellite Comm System The project was done in 1993. 330 KLOC on five target platforms with many COTS products. 73 inspection meetings over 4 months #Defects recorded – 2,760 Cost Savings - $1 million Cost to find and fix during test – Cost to find and fix via inspections prior to test

Examples of Payoff… Raytheon Inspection = Defect Detection Process DDP + Defect Prevention Process DPP Used DDP + DPP (1988-1994) Rework cost decrease: 45% to 5-10%. Increase software productivity 2.7x Reduced negative deviation from budget and deadlines from 40% to near 0. Reduced error density by factor of 3.

Final Words … And Questions???