Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.

Slides:



Advertisements
Similar presentations
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Advertisements

Systematic Software Reviews Software reviews are a “quality improvement processes for written material”.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Technical Reviews A Presentation By Manuel Richey for EECS 814 November 17 th, 2005.
Static Technique. Static Technique - Review  A way of testing software work products  Program code, requirement spec., design spec.  Test plan, test.
Inspection (c) 2007 Mauro Pezzè & Michal Young Ch 18, slide 1 Photo credit jurvetson on Flickr.com; creative commons attribution license.
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.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
Overview Lesson 10,11 - Software Quality Assurance
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
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.
SE 555 Software Requirements & Specification Requirements Validation.
Software Quality Assurance For Software Engineering && Architecture and Design.
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.
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
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.
Software Inspections and Walkthroughs By. Adnan khan.
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.
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
Chapter 14: Inspection  Basic Concept and Generic Process  Fagan Inspection  Other Inspection and Related Activities.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Lecture 16 Formal Technical Reviews (FTRs) (also know as inspections) FOR0383 Software Quality Assurance 9/19/20151Dr Andy Brooks Don´t review in your.
CSE403 Software Engineering Autumn 2001 Technical Reviews Gary Kimura Lecture #19 November 14, 2001.
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.
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.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Quality Assurance IS 101Y/CMSC 101Y November 12, 2013 Carolyn Seaman University of Maryland Baltimore County.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
(1) Introduction to Software Review Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Inspection and Review The main objective of an Inspection or a Review is to Detect Defects. (Today -there may be some other goals or broader definition.
Unit III Static Testing. static testing Testing of a component or system at requirements or implementation level without execution of any software, e.g.,
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Software Quality Assurance and Testing Fazal Rehman Shamil.
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
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.
Software Engineering 2 Term Project by: Feras Batarseh Nestor Rivera.
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.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
© Mahindra Satyam 2009 Inspections and Reviews QMS Training.
Software Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management (SCM)
Verification and Validation
Verification and Validation
Verification and Validation
Inspection and Review The main objective of an Inspection or a Review is to detect defects. (Not for Giving Alternative Solutions) This activity and procedure.
Applied Software Project Management
QA Reviews Lecture # 6.
Software Reviews.
Testing, Inspection, Walkthrough
Review & Inspection Process
Presentation transcript:

Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas

Outline  Introduction  Generic Inspection and Variations  Inspection throughout Development Cycle  FTR Metrics  Tools  Conclusion

FTR: What it is...  A method involving a structured encounter in which a group of technical personnel analyzes an artifact according to a well-defined process. ::Output::  A structured artifact that assesses or improves the quality of the artifact as well as the quality of the method. ::Input::

FTR: What it is... A structured FTR is a forum for:  Finding defect information for the Author.  Educating peers about product.  Providing fault likelihood data for testers.  Providing detailed status report for managers.  Allowing process improvement group a test to measure.

FTR: What it isn’t...  Walk-through  No Measurements  Often informal, impromptu  Main purpose is developer training

Why Review?  Improves overall product quality  Early detection of defects  Reduces rework and its associated costs  Educate the participants and provide training  Setting standards of excellence / maintain process improvement momentum  Improve schedule performance  IBM reported 83% and AT&T 92% defect detection through inspections

Inspection Process Overview Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  6 Steps  Team  members  Experienced and involved in product development  Distinct and important roles

Inspection Process Overview Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Roles:  Organizer – plans the inspection activities  Moderator – ensures that procedures are followed and moderates the meetings.  Inspectors – responsible for detecting defects in the product  Presenter – presents the product in logical fashion paraphrased at a suitable rate  Author – author of the developed product.  Recorder – records the defects during the meeting  Collector – collects the defects if there is no meeting.

Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – organize inspection  Check to see if work products pass the entry criteria  Select inspection participants and assign roles  Schedule inspection meeting  Distribute inspection material  Prepare inspection documentation  Ensure product inspection readiness

Objective Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – educate participants on the product being inspected  Author explains the inspection materials  Can be beneficial when:  The inspection artifact is complex  If the artifact is part of large system  If new members participate in inspection  Could be rolled into previous or next phase if product is simple enough  Communicate inspection goals!

Defect Detection Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – to find defects  Can be divided into 2 phases:  Preparation (individual) phase.  Meeting (group) phases.  Individual preparation with the goal of detecting defects can help inspectors to be more prepared.

Defect Collection Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – collectively agree and document the defects (triage)  Decide on further inspection needed or not  Decisions made subjectively as a group.

Defect Collection Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – correct the defects collected in the previous phases  The author makes the detected changes and sends it for follow-up

Follow Up Planning Overview Defect Detection Defect Collection Defect Correction Follow-Up  Objective – to make sure all defects are resolved  Only one person involved and he/she verifies the defect resolution  Verifier should “return and report” to inspection team

Formal Inspection Methods  Fagan Inspection  Asynchronous Inspection  Phased Inspections  N-Fold Inspections

Fagan Inspection Overview Preparation Inspection Rework Follow-Up  4 Roles  Author  Reader  Moderator  Scribe  Meeting centric – cost of scheduling and time  Meetings add little to defect detection

Asynchronous Software Inspection Initialization Inspection Review Inspection Compile Final Defect List  Team  Author not involved  Moderator and Inspectors Re-Work

Asynchronous Software Inspection Initialization Inspection Review Inspection Compile Final Defect List  No meetings  Easy to assess participation  Process improvement from documenting all correspondences  Allows parallel communication  Can be distributed in space and time  Eliminates group approval Re-Work

Asynchronous Software Inspection Initialization Inspection Review Inspection Compile Final Defect List  Moderator sends out material  Initial Individual Review – create list of defects  Circulate the copy of defect list to all inspectors and discuss via  Individual Review – update defect list and send to Moderator  Moderator compiles final defect list, send it to author and follow up – eliminates group approval Re-Work

Phased Inspections  Consists of several coordinated partial inspections called phases  Each phase inspects for a specific property or small set of related properties  Each phase responsible for thorough checking of the properties  Some phases have single inspectors and others have multiple inspectors  Reference documents are provided to inspectors at the beginning of each phase and each inspects using checklists  Domain specific checklists  Application specific checklists

N-fold Inspection  N independent teams inspect the same product using traditional inspection method  Collective effort of multiple teams more faults than a single team  Moderator collects faults from independent teams and composes the final defect list

Requirements Inspection  Reading Techniques are techniques to analyze work product during defect detection  Ad-hoc  Checklist based reading  Scenario based readings  Perspective based reading  Defect based reading

Perspective based Reading  Inspectors stand in for specific stakeholders in the document to verify the quality of requirements.  Designer – detail for creating system components  Tester – detail for constructing test plans  User – correct functionality  For each perspective, reviewer creates high level work products from the requirements document

Code Inspections  Cognitive models for program comprehension  Bottom-up  Top-Down  Integrated  Systematic and as-needed comprehension

FTR Metrics  Helps you measure the effectiveness of the inspection  Aids in continuous process improvement  Provides feedback to management  A unit of work product varies often:  Usually 1000 lines of source code (not including comments)  Page counts and line counts for text

Some Generic Metrics  Average preparation effort and preparation rate per unit of material  Average examination effort per unit of material  Average explanation rate per unit of material  Average number of defects and major defects found per unit of material  Average hours per defect and per major defect

Nine Key Metrics by AT&T for Code Inspections  Total Non Comment lines of source code inspected, in KLOC  Average lines of code inspected  Average preparation rate  Average inspection rate  Average effort per KLOC  Average effort per fault detected.  Average faults detected per KLOC  Percentage of re-inspections  Defect-removal efficiency

Tools  Various tools for different inspection methods.  ICICLE – for inspection of C & C++ programs  Scrutiny & InspeQ for specific inspection processes  ASSIST –supports generic inspection process

Choosing a tool...  Threads of discussion  Sharing of Information  Train of thought  Visual Cues  Reaching a consensus  Coordination

The Future of FTR  FTR adoption is slow:  Managers see added cost of inspections instead of the benefits of greatly reduced defect leakage  Practitioners already have tight schedules and reluctant to take on additional responsibilities  Companies postpone adoption since peer reviews are part of CMM level 3.

FTR Barriers  Insufficient preparation  Moderator domination  Incorrect review rate  Ego-involvement and personality conflict  Issue resolution and meeting digression  Recording difficulties and clerical overhead

Conclusion  Organization’s size, culture and industry should be considered in deciding on the FTR method to use.  Review does not replace testing but can make it easier  Success of inspection lies in:  Process Adherence  Systematic Reading technique  Optimization

FTR: References ● Philip Johnson: ● Tom Gilb: ● IEEE STD