Software Reviews Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.

Slides:



Advertisements
Similar presentations
Software Engineering Jerzy Nawrocki Copyright, 2003 © Jerzy R. Nawrocki
Advertisements

Software Quality Management Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process.
Extreme Programming Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
Effort and Schedule Estimation Copyright, 1999 © Jerzy R. Nawrocki Personal Software.
Introduction to PSP Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
Software Testing Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
Planning at CMM level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering.
The Baseline Personal Process Copyright, 1999 © Jerzy R. Nawrocki Jerzy Nawrocki Personal Software Process Lecture 3.
Copyright (c) 2003 Howard E. Dow1 Results from Inspecting Test Automation Scripts Howie Dow
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003.
Code Inspections CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 22, 2007.
Personal Software Process
CS 350: Introduction to Software Engineering Slide Set 5 Software Quality C. M. Overstreet Old Dominion University Spring 2006.
1 Design and Code Inspections to Reduce Errors in Program Development. M.E. Fagan IBM Systems Journal, 1976 Presented by Ankush Varma.
Personal Software Process Software Quality CIS 376 Bruce R. Maxim UM-Dearborn.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Software Quality Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
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.
Comparison of CMM Level 2 and eXtreme Programming Copyright, 2002 © Bartosz Walter Quality Connection 2002, Helsinki Poznan University of Technology Poznan,
Software Quality Assurance Lecture #4 By: Faraz Ahmed.
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
Disciplined Software Engineering Lecture #8 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
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.
CS 350, slide set 6 M. Overstreet Old Dominion University Spring 2005.
DEFECTS By K.KARTHIKE. WHAT IS DEFECTS? Software bug, a failure of computer software to meet requirements Software bug The term defect and its relationship.
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 1998 Carnegie Mellon UniversityTutorial The Personal Software Process (PSP) The overview of the PSP that follows has been built from material made.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
Experimental Evaluation of Pair Programming Copyright, 2001 © Jerzy R. Nawrocki European Software Control & Metrics ESCOM’01 ESCOM’01 Poznan University.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #8 Software Engineering.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 9 – Quality Management 1INFO636 Week 9.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 8 – Reviews 1INFO636 Week 8.
Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
SE-280 Dr. Mark L. Hornick 1 Design and Code Reviews Review Checklists.
ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Defect Classes and the defect repository
Introduction to Requirements Eng. Copyright, 2001 © Jerzy R. Nawrocki Requirements.
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.
INFO 637Lecture #71 Software Engineering Process II Product Implementation INFO 637 Glenn Booker.
Configuration Management at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Inspection and Review The main objective of an Inspection or a Review is to detect defects. This activity and procedure was first formalized by Mike Fagan.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Introduction to Quality Management Copyright, 2000 © Jerzy R. Nawrocki Quality.
Software Engineering Lecture 8: Quality Assurance.
Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:
CS223: Software Engineering Lecture 21: Unit Testing Metric.
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.
CAT Executive Review Team 3: Lions. Cycle 2 Key Lessons: Quality.
1 Software Testing and Quality Assurance Motivation and Review of Software Verification & Validation (2)
Requirements Engineering Lecture 7
The Value of Managing the Review Process
Requirements Engineering Lecture 4
History of Software Inspections
Software Engineering Lab Session
SQA for Individuals based on
QA Reviews Lecture # 6.
WALKTHROUGH and INSPECTION
Presentation transcript:

Software Reviews Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture 13

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. Philip Crosby’83: conformance to requirements Software quality

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. Quality of design Quality of conformance Software quality

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. The relative time to identify defects (IBM): during design reviews: 1during design reviews: 1 during code inspections: 20during code inspections: 20 during machine test: 82during machine test: 82 Some fix time data

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. JPL, average cost per defect: inspections: $90 - $120inspections: $90 - $120 tests: $10 000tests: $10 000Conclusions: Remove most of the defects before testing Some fix cost data

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. An experienced software engineer injects ~ 100 defects per KLOCAn experienced software engineer injects ~ 100 defects per KLOC Half these defects are found by the compilerHalf these defects are found by the compiler To find a defect it takes hours (industry data)To find a defect it takes hours (industry data) The yield of the review or inspection: ~ 70%The yield of the review or inspection: ~ 70% Average cost of inspections: 0.5 hours/defectAverage cost of inspections: 0.5 hours/defect ErrorError Planning data

J. Nawrocki, PSP, Lecture 13 From the previous lecture.. Education: don’t understandEducation: don’t understand Communication: not properly informedCommunication: not properly informed Oversight: omitted doing somethingOversight: omitted doing something Transcription: knew but made a mistakeTranscription: knew but made a mistake Process: due to the processProcess: due to the process Basic defect causes Should be “to”, not “too” !!!

J. Nawrocki, PSP, Lecture 13 { n+=NF; } { n+=NF; } END { print n; } Review methods InspectionInspection (very formal) (very formal) Walk-throughWalk-through (a presentation) (a presentation) Personal reviewPersonal review (DIY) (DIY)

J. Nawrocki, PSP, Lecture 13 Fagan inspections Design Code Test External specifications (function) Internal specifications (module) - I 0 Logic specifications (logic) - I 1 design inspec Coding (logic) - I 2 code inspec Unit testing The lifecycle Function, component, system test

J. Nawrocki, PSP, Lecture 13 Fagan inspections Other inspections: IT 1 - test plan inspection IT 2 - test case inspection PI 0, PI 1, PI 3 - publication inspections

J. Nawrocki, PSP, Lecture 13 Fagan inspections DesignDesignCodeCodeUnittestUnittest I1I1 I2I2 I3I3 Net savings (hours/KLOC): I 1 : 94 I 2 : 51 I 3 : -20

J. Nawrocki, PSP, Lecture 13 Designer Fagan inspections Implementor Moderator Tester Review session

J. Nawrocki, PSP, Lecture 13 Fagan inspections 1. Overview (whole team) 2. Preparation (individual) 3. Inspection (whole team) 4. Rework 5. Follow-up Designer Implem. Moderator Tester Review session

J. Nawrocki, PSP, Lecture 13 Fagan inspections Overview (whole team) 500 not necessary Preparation (individual) Inspection (whole team) Rework Follow-up - - I1I1I1I1 I2I2I2I2 Rate of progress (loc/h) Inspection session <= 2 hoursInspection session <= 2 hours sessions per day1 - 2 sessions per day

J. Nawrocki, PSP, Lecture 13 Fagan inspections CD: CB definition CU: CB usage IC: Interconnect calls LO: Logic MD: More detail MN: Maintainability OT: Other PE: Performance PR: Prolog... Design error types Question: What should be the design error types for UML?

J. Nawrocki, PSP, Lecture 13 Fagan inspections CC: Code comments CU: CB usage DE: Design error IC: Interconnect calls LO: Logic MN: Maintainability OT: Other PE: Performance PR: Prolog... Code error types Question: What should be the design error types for Java or HTML?

J. Nawrocki, PSP, Lecture 13 Fagan inspections Are all constants defined? If a queue is being manipulated, can the execution be interrupted; If so, is queue protected by a locking structure? Are registers being restored on exits? Are all increment counts properly initialised (0 or 1)? Are absolutes shown where there should be symbolics? Are all blocks shown in design necessary? Checklist for design inspection Ex Wr Missing

J. Nawrocki, PSP, Lecture 13 Fagan inspections Is correct condition tested? Is correct variable used or test? Is each branch target correct? Is the most frequently exercised test leg the THEN clause? Are all required parameters passed set correctly? Does the inline expansion contain all required code? Checklist for code inspection Test branch Interconnect

J. Nawrocki, PSP, Lecture 13 Fagan inspections PR/M/Min L3: the prologue in the REMARKS section needs expansion. section needs expansion. LO/W/Maj L172: NAME-CHECK is performed one time too few. time too few. DE/W/Min L175: the design should allow for the occurrence of a period in a last occurrence of a period in a last name. name. Error list

J. Nawrocki, PSP, Lecture 13 Fagan inspections CC: Code comments CU: CB usage DE: Design error IC: Interconnect calls LO: Logic MN: Maintainability OT: Other PE: Performance PR: Prolog Major Minor Major Minor M W E M W E M W E M W E Date Code inspection report Mod/Mac: Total

J. Nawrocki, PSP, Lecture 13 Active design reviews Parnas and Weiss, 1985Parnas and Weiss, 1985 Questions posed by the author of the design - to encourage a thorough reviewQuestions posed by the author of the design - to encourage a thorough review Several brief reviews focusing on a part of a work product (part of a design document)Several brief reviews focusing on a part of a work product (part of a design document)

J. Nawrocki, PSP, Lecture 13 Phased inspections 1 Compliance with required internal documentation format. Also spelling and grammar can be checked here. 2. Source code layout. 3. Readability. 4. Good programming practice (gotos, global variables,..). 5. Correct use of various programming constructs (updating control variables for while, closing files,...). 6. Functional correctness.

J. Nawrocki, PSP, Lecture 13 Phased inspections Defects: indigenousindigenous seededseeded

J. Nawrocki, PSP, Lecture 13 Summary Fagan inspection are a formal and rigorous method of checking quality. Inspections are a basic tool in software quality assurance. Some aspects of Fagan inspections are outdated and their should be updated.

J. Nawrocki, PSP, Lecture 13 Further readings M. Fagan, “Design and Code Inspections..”, IBM System J., vol. 15, no.3, 1976, IBM System J., vol. 15, no.3, 1976, M. Fagan, “Advances in Software Inspections”, IEEE TSE, vol. SE-12, no. 7, IEEE TSE, vol. SE-12, no. 7, J.C. Knight, E.A. Myers, An improved inspection technique, CACM, vol. 36, No.11, Nov. 1993, technique, CACM, vol. 36, No.11, Nov. 1993, pp pp

J. Nawrocki, PSP, Lecture 13 Quality assessment 1. What is your general impression ? (1 - 6) 2. Was it too slow or too fast ? 3. Did you learn something important to you ? 4. What to improve and how ?