ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.

Slides:



Advertisements
Similar presentations
Software Testing Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
Advertisements

COMP8130 and 4130Adrian Marshall Verification & Validation INSPECTIONS Adrian Marshall.
Planning at CMM level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering.
Software Reviews Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
The Baseline Personal Process Copyright, 1999 © Jerzy R. Nawrocki Jerzy Nawrocki Personal Software Process Lecture 3.
More CMM Part Two : Details.
Procedures for CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Formal Technical Reviews
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Quality Assurance Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
Code Inspections CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 22, 2007.
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.
6/19/2007SE _6_19_TSPImp_SVT_Lecture.ppt1 Implementation Phase Inputs: Development strategy & plan Completed, inspected & baselined SRS & SDS.
SE 555 Software Requirements & Specification Requirements Validation.
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 Inspections and Walkthroughs By. Adnan khan.
Rational Suite and CMM Level 2 Copyright, 2000 © 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.
Configuration Management Copyright, 2002 © Jerzy R. Nawrocki Quality Management.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
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
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Quality Model for Requirements Eng. Copyright, 2002 © Jerzy R. Nawrocki Quality.
S Q A.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Requirements Verification & Validation Requirements Engineering & Project Management.
Project Planning Copyright, 2002 © Jerzy R. Nawrocki Requirements Engineering.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
Quality of Usage Scenarios Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
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.
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.
Introduction to Requirements Eng. Copyright, 2001 © Jerzy R. Nawrocki Requirements.
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.
Quality Model for RE Process Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
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.
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”.
Introduction to Quality Management Copyright, 2000 © Jerzy R. Nawrocki Quality.
Configuration Management (II) Copyright, 2000 © Jerzy R. Nawrocki Requirements.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
Software Engineering Lecture 8: Quality Assurance.
Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Requirements Management and Changes Copyright, 2003 © Jerzy R. Nawrocki Requirements.
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.
Requirements Engineering Lecture 7
Review Techniques SEII-Lecture 16
Software Configuration Management (SCM)
Requirements Engineering Lecture 2
Software Quality Engineering
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.
QA Reviews Lecture # 6.
3. Software Quality Management
Presentation transcript:

ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary Material Quality Management Auxiliary Material

J. Nawrocki, Reviews IntroductionIntroduction The relative time to identify defects (IBM ): during design reviews: 1 during code inspections: 20 during machine test: 82 Some fix time data Cost of fixing a defect

J. Nawrocki, Reviews Statement of work IntroductionIntroduction Statement of work External commitments Project at selected  milestones The software baseline (audit) Reviews at CMM Level 2

J. Nawrocki, Reviews Generic FTR procedure Parameters to be specified in SDP Name of the product URL of the standard doc-struct Due date for approved product Producer Review leader (SQA group) Recorder (SQA group) Reviewers (including recorder) Expected preparation time Expected meeting duration  SDSD P

J. Nawrocki, Reviews Generic FTR procedure Steps (I) Producer informs the project leaders + review leader + area manager (Bartek) that the product is ready and sends them a copy of it. The review leader contacts all the participants of the review meeting to establish the date of the meeting (preferably in 3 days). He also distributes copies of the product to the reviewers.

J. Nawrocki, Reviews Generic FTR procedure Steps (II) The review leader is responsible for establishing an agenda for the review meeting. The meeting takes place The recorder prepares a review report and sends it to the participants of the meeting. A copy of it must also go to the project managers, the area manager and the SDS supervisor.

J. Nawrocki, Reviews FTR meeting A proposed agenda (I) Review leader: Introduction of the agenda. Participants can propose some changes. Recorder: Collecting the preparation forms (copies) Producer: Presentation of the material. The producer “walks through” the material and explains, while reviewers raise issues. The recorder takes notes of valid defects and problems.

J. Nawrocki, Reviews FTR meeting A proposed agenda (II) Recorder: Summary of defects and problems. All attendees except producer: Anonymous (in written) presentation of early decision. Recorder: Collecting of early decisions and their presentation. Producer: “Last word” All attendees except producer: Making final decision

J. Nawrocki, Reviews FTR meeting The decision Accept. No modifications are necessary Accept provisionally. There are some minor defects that must be corrected but no additional review is required (the project manager is responsible for checking the follow-up). Reject. There are severe defects and another review is necessary.

J. Nawrocki, Reviews FTR meeting The decision If the decision made by the reviewers is not clear (e.g. some are for Accept, some for Reject), the final decision belongs to the area manager.

J. Nawrocki, Reviews Preparation form for FTR Heading Name of the product & its version:... Producer: Reviewer: The product received on: Expected preparation time: Actual preparation time: Meeting scheduled on: Early decision:

J. Nawrocki, Reviews Preparation form for FTR Body Severe defects & problems (e.g. hidden problems, ambiguity, lack of understanding, etc.) Problem description (annotation) Minor problems (e.g. spelling, grammar, format etc.) Problem description (annotation)

J. Nawrocki, Reviews Preparation form for FTR Education: don’t understand Communication: not properly informed Oversight: omitted doing something Transcription: knew & did but made a mistake Process: due to the process “Two” or “too”? Annotations - Basic defect causes

J. Nawrocki, Reviews 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, Reviews Fagan inspections Other inspections: IT 1 - test plan inspection IT 2 - test case inspection PI 0, PI 1, PI 3 - publication inspections

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

J. Nawrocki, Reviews Designer Fagan inspections Implementor Moderator Tester Review session

J. Nawrocki, Reviews 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, Reviews 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 hours sessions per day

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

J. Nawrocki, Reviews 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, Reviews Active design reviews Parnas and Weiss, 1985 Questions 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)

J. Nawrocki, Reviews 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, Reviews Phased inspections Defects: indigenous seeded

J. Nawrocki, Reviews SummarySummary Review procedures can be stated in a generic form. The main difference between a Fagan inspection and walk- through is: lack of checklists for walk- throughs, and lack of presentations for Fagan inspections.

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

J. Nawrocki, Reviews Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?