Review Techniques SEII-Lecture 16

Slides:



Advertisements
Similar presentations
Procedures for CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Advertisements

Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
SOFTWARE Quality Management
Formal Technical Reviews
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
SE382 Software Engineering Lecture 21b
Software Quality Assurance (SQA). Recap SQA goal, attributes and metrics SQA plan Formal Technical Review (FTR) Statistical SQA – Six Sigma – Identifying.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
Software Quality Assurance
Overview Lesson 10,11 - Software Quality Assurance
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.
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
SE 555 Software Requirements & Specification Requirements Validation.
Software Quality Assurance Instructor: Dr. Jerry Gao.
Software Quality Assurance
Overview Software Quality Software Quality and Quality Assurance
What is Software Quality?
Assistance - Savita Kini November 15, Software Quality Assurance - Outline ä What is Software Quality assurance(SQA)? ä Quality Concepts. ä Software.
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.
S oftware Q uality A ssurance Part One Reviews and Inspections.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
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.
Chapter 8 Software Quality Assurance
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.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
S Q A.
Software Project Management Lecture # 10. Outline Quality Management (chapter 26)  What is quality?  Meaning of Quality in Various Context  Some quality.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Chapter 12: Software Inspection Omar Meqdadi SE 3860 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Project quality management. Introduction Project quality management includes the process required to ensure that the project satisfies the needs for which.
SQA. 2 Software Quality Assurance What is Software Quality assurance(SQA)? Quality Concepts. Software Quality Assurance Activities. Software Reviews and.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
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.
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.
Quality Issues. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009.
Software reviews Cost impact of software defects Defect amplification model Review metrics and their use – Preparation effort (E p ), assessment effort.
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.
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 26 Quality Management Software Engineering: A Practitioner’s Approach, 6/e Chapter 26 Quality.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
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 Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
CS223: Software Engineering
Software Testing & QA (VI)
Software Project Management
SOFTWARE PROCESS AND PROJECT METRICS
Software Quality Assurance
Software Engineering: A Practitioner’s Approach, 6/e 第 12 章 评审技术 copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only.
Chapter 20 Review Techniques
Software Quality Engineering
Software Quality Assurance
Lecture 12: Chapter 15 Review Techniques
Chapter 26 Quality Management
Cost Impact of Software Defects
Reviews & Inspections ... there is no particular reason
Software Project Management
Chapter 20 Review Techniques
Dr. Rob Hasker SE 3800 Note 9 Reviews.
Review Techniques copyright © 1996, 2001, 2005 R. S
Chapter 26 Quality Management
QA Reviews Lecture # 6.
Quality Management By Prakash G Asnani
3. Software Quality Management
Presentation transcript:

Review Techniques SEII-Lecture 16 Dr. Muzafar Khan Assistant Professor Department of Computer Science CIIT, Islamabad.

Recap Multi-aspects concept Software quality Software quality models Transcendental view, user view, manufacturer’s view, product view, value-based view Software quality Effective software process, useful product, add value for producer and user of a software product Software quality models Garvin’s quality dimensions, McCall’s quality factors, ISO 9126 quality model Software quality dilemma Achieving software quality

Software Reviews Filter for software process To err is human People are good at catching others’ errors Three steps Point out needed improvements Conform those parts that are OK Achieve technical work of uniform quality without reviews Different types of reviews

Cost Impact of Software Defects Defect and fault are synonymous Primary objective is to find errors Primary benefit is early discovery of errors No propagation in next step Design activities introduce 50-65% of all errors Review techniques are 75% effective to uncover design flaws It leads to reduced cost at later stages

Defect Amplification Model Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 419

Example – No Reviews Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 419

Example –Reviews Conducted Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 419

Review Metrics and Their Use [1/2] Each action requires dedicated human effort Project effort is finite Need of metrics to assess effectiveness of each action Review metrics Preparation effort (Ep) Number of person-hours prior to actual review Assessment effort (Ep) Number of person-hours required for actual review

Review Metrics and Their Use [2/2] Rework effort (Er) Number of person-hours to correct errors uncovered during the review Work product size (WPS) Size of work reviewed e.g. number of UML models Minor errors found (Errminor) Number of minor errors found Major errors found (Errmajor) Number of major errors found

Analyzing Metrics [1/2] Ereview = Ep + Ea + Er Errtot = Eminor + Emajor Error density – number of errors found per unit of work reviewed Error density = Errtot/WPS Example: 18 UML diagrams, 32 pages document, 18 minor and 04 major errors Error density = 22/18 = 1.2 errors per UML diagrams OR 22/32 = 0.68 errors per page

Analyzing Metrics [2/2] Different work products are reviewed Percentage of errors uncovered for each review is computed against the total number of errors for all reviews Error density for each work product is computed When all reviews are conducted, average values indicate the errors in new documents

Cost Effectiveness of Reviews Difficult to measure Example: 0.6 errors per page 4 person-hours to correct minor error 18 person-hours to correct major error Minor errors occurs about six time more frequently as compared to major errors based on the review data Requirements-related error needs 6 person-hours to correct Same error requires 45 person-hours if uncovered during testing Effort saved per error = Etesting – Ereviews 45 - 6 = 39 person-hours

Effort Expanded With and Without Reviews Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 422

Reviews: A Formality Spectrum Level of formality depends on different factors Product, time, people Four characteristics of reference model Roles Planning and preparation for the review Review structure Follow-up

Reference Model Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 423

Informal Reviews Simple desk check, casual meeting, or review-oriented aspects of pair programming Effectiveness is considerably lower No advance planning/preparation, no agenda, no follow-up Still good to uncover errors that may propagate Simple review checklist to improve the efficiency

Example: Review Checklist Work product: prototype Reviewers: designer and colleague Is the layout designed using standard conventions? Left to right? Top to bottom? Does the presentation need to be scrolled? Are color and placement, typeface, and size used effectively? Are all navigation options or functions represented at the same level of abstraction? Are all navigation choices clearly labeled?

Formal Technical Reviews Objectives are To uncover errors in function, logic, or implementation To verify that the software under review meets its requirements To ensure that it is according to predefined standards To achieve that it is developed in a uniform manner To make project more manageable Training ground for juniors Promotes backup and continuity Walkthroughs and inspections

The Review Meeting [1/2] Constraints 3-5 people No more than two hours (for each person) of advance preparation Meeting duration should be less than two hours Focus should be on specific and small part of overall software Producer informs project leader about the work product Project leader contacts review leader Review leader is responsible for the rest of arrangement

The Review Meeting [2/2] Meeting is attended by the review leader, all reviewers, and the producer One reviewer serves as recorder Meeting starts with an introduction of the agenda and the producer Producer “walk through” the work product Decisions Accept the product without further modification Reject the product due to severe errors Accept the product provisionally Sign-off at the end of meeting

Review Reporting and Record Keeping Review issues list is produced Identify problem areas An action item checklist for corrections Formal technical review summary report (a single page with possible attachments) What was reviewed? Who reviewed it? What were the findings and conclusions? Follow-up procedure to ensure the rework

Review Guidelines [1/2] Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Enunciate problem areas, but don’t attempt to solve every problem noted Take written notes Limit the number of participants and insist upon advance preparation

Review Guidelines [2/2] Develop a checklist for each product that is likely to be reviewed Allocate resources and schedule time for formal reviews Conduct meaningful training for all reviewers Review your early reviews

Summary Software reviews Cost impact of software defects Defect amplification model Review metrics and their use Preparation effort (Ep), assessment effort (Ep), Rework effort (Er), work product size (WPS), minor errors found (Errminor), major errors found (Errmajor) Formal and informal reviews Review meeting, review reporting and record keeping, review guidelines