Personal Software Process Software Quality CIS 376 Bruce R. Maxim UM-Dearborn.

Slides:



Advertisements
Similar presentations
SOFTWARE TESTING. Software Testing Principles Types of software tests Test planning Test Development Test Execution and Reporting Test tools and Methods.
Advertisements

Test Execution and Defect management. 2 Module Objectives Introduction to Test Execution Checklist of Test Execution Defect management Defect Classification.
Chapter 4 Quality Assurance in Context
The Relationship between Cost & Quality Submitted by: Haya A. El-Agha Submitted to: Eng. Hani Abu Amr.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Personal Software Process
SE 450 Software Processes & Product Metrics Reliability: An Introduction.
© 2010 John Dalbey Ch 9: Reviews Humphrey proposes that personal reviews will result in improved quality. Now that we have a defined process and some real.
CS 350: Introduction to Software Engineering Slide Set 5 Software Quality C. M. Overstreet Old Dominion University Spring 2006.
Aplicaciones de Ingeniería de Software
SE 555 Software Requirements & Specification Requirements Validation.
Swami NatarajanJuly 14, 2015 RIT Software Engineering Reliability: Introduction.
Software Process and Product Metrics
Fundamental of Software Project Management Team Assignment 1 – K15T2 – Team 07.
User Interface Evaluation CIS 376 Bruce R. Maxim UM-Dearborn.
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
Personal Software Process Overview 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.
Quality Control McGraw-Hill/Irwin Copyright © 2012 by The McGraw-Hill Companies, Inc. All rights reserved.
Project Quality Management
Software Quality Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
Extreme Programming Software Development Written by Sanjay Kumar.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Chapter 1: Introduction to Software Testing Software Testing
CLEANROOM SOFTWARE ENGINEERING.
N By: Md Rezaul Huda Reza n
Disciplined Software Engineering Lecture #8 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
INFO 637Lecture #41 Software Engineering Process II Development Plan INFO 637 Glenn Booker.
1 9/19/2015ã 2007, Spencer Rugaber Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
Chapter 12 Defects. 山东大学计算机学院 2 In the chapter  Concept of Defects  Defects and software quality  What is Defect?  Defects versus Bugs  Defect types.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Quality Control Project Management Unit Credit Value : 4 Essential
CS 350, slide set 6 M. Overstreet Old Dominion University Spring 2005.
Testing Workflow In the Unified Process and Agile/Scrum processes.
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.
Testing Vs. Inspection Research Paper Diala T. Gammoh, Ph.D. Student Dr. Damla Turgut, Ph.D. University of Central Florida, Orlando Florida
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #8 Software Engineering.
From Quality Control to Quality Assurance…and Beyond Alan Page Microsoft.
Jump to first page (C) 1998, Arun Lakhotia 1 Quality Assurance: Reviews and Walkthroughs Arun Lakhotia University of Southwestern Louisiana Po Box
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 9 – Quality Management 1INFO636 Week 9.
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 8 – Reviews 1INFO636 Week 8.
PSP Quality Strategy [SE-280 Dr. Mark L. Hornick 1.
CSE SW Metrics and Quality Engineering Copyright © , Dennis J. Frailey, All Rights Reserved CSE8314M10 8/20/2001Slide 1 SMU CSE 8314 /
1 The Personal Software Process Estimation Based on Real Data* * Would Martin Fowler approve? “I want you to take this personally…”
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.
Chapter 19 Process Quality. 山东大学计算机学院 2 outline  Then meaning of process quality  Process measurement  COQ  Failure costs, Appraisal costs, Prevetion.
Implementation Phase CS4311 – Spring 2008 References: Shach, Object Oriented and Classical Software Engineering E. Braude, Software Engineering, an Object-Oriented.
INFO 637Lecture #71 Software Engineering Process II Product Implementation INFO 637 Glenn Booker.
Carnegie Mellon Software Engineering Institute © 2006 by Carnegie Mellon University Software Process Performance Measures James Over Software Engineering.
Software Quality Assurance and Testing Fazal Rehman Shamil.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
Software Engineering Lecture 8: Quality Assurance.
IT Project Management, Third Edition Chapter 8 1 Chapter 5: Project Quality Management.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
CAT Executive Review Team 3: Lions. Cycle 2 Key Lessons: Quality.
Software Quality Control and Quality Assurance: Introduction
Project Management PTM721S
Regression Testing with its types
Operations Management Framework
Software Engineering (CSI 321)
Personal Software Process Team Software Process
SEVERITY & PRIORITY RELATIONSHIP
Software Quality Engineering
Quality Measurable characteristic Cyclomatic complexity Cohesion
Baisc Of Software Testing
Chapter # 1 Overview of Software Quality Assurance
3. Software Quality Management
Presentation transcript:

Personal Software Process Software Quality CIS 376 Bruce R. Maxim UM-Dearborn

These notes are based on: Introduction to the Personal Software Process Watts S. Humphrey Addison-Wesley Longman (1997)

Software Quality Product meets the customer’s needs (not necessarily the same as customer’s wants) Defects are the primary measure of quality in PSP Yield Management –defect removal –defect prevention

Hierarchy of Needs Software performs its required tasks Product meets its performance requirements Software is usable Development is economical and timely Product is dependable and reliable

Software Bugs Latent bugs must –be operationally insignificant –not be destructive –not be observed often Bugs are not important to the customer if they do not –affect operations –cause inconvenience –cost time or money –cause loss of confidence in software results

PSP Quality Focus Low defect content is an essential prerequisite to quality software process Low defect rates can best be achieved at the PSP level (e.g. individual SE’s) SE’s are the ultimate source of defects are injected SE’s need to remove defects, determine their causes, and learn to prevent them

Testing and Inspections The sooner a defect is located the cheaper it is to repair and faster the repair Design inspections will –improve product quality –lead to a more predictable schedule –allow more time to focus on quality issues It is important for SE’s to review their own work before giving it to others to review

Some Fix Time Data Some typical fix time ratios –IBM rules of thumb - coding: 1.5; testing: 60; usage: 100 –Boehm - design: 1; development test: 15 to 40; acceptance test: 30 to 70; operation: 40 to 1000 –Remus - design: 1, code: 20, test: 82 –Ackerman - test: times inspection time –Russell - inspection: 1, test: 2 to 4, use: 33 –PSP research - unit test takes 12 times longer than code review to find and fix defects

Cost of Quality - part 1 Failure costs –repair, rework, scrap –in PSP includes all compile and testing time Appraisal costs –cost of defect inspections –in PSP includes all design and code review time

Cost of Quality - part 2 Prevention costs –finding and resolving defect causes –handle before project starts –should be a process (not product) activity –in PSP this includes formal specification and design work prototyping process analysis and improvement

PSP Quality Strategy - part 1 Identify PSP quality objectives, e.g. –remove all defects before first compile Establish PSP process quality measures, e.g. –overall process yield –LOC reviewed per hour Examine products reviewed –determine their ratings on the measures –see which behaviors impacted these results

PSP Quality Strategy - part 2 Based on these data, identify your most effective work practices. Incorporate these practices in your process artifacts –process scripts –checklists –forms Identify measures that predict process quality –use these as control variables –set specifications for these variables

PSP Quality Strategy - part 3 Track your performance against these specifications. Track your process to determine –when and if to change these specifications –actions to take for further process improvement

Appraisal to Failure Cost Ratio Appraisal COQ = 100*(design review time + code time)/ (total development time) Failure COQ (Cost of Quality) = 100*(compile time + test time)/(total development time) A/FR (Appraisal to Failure Cost Ratio) ratio = (Appraisal COQ)/(Failure COQ)

Yield vs. A/FR High A/FR ratios appear to lead to higher yields 70+% yields not achieved without A/FRs near 1.0 or above high A/FR does not guarantee high yield - the appraisal time must be spent effectively

Test Defects vs. A/FR Defects are reduced by high A/FR ratios To get very low numbers of test defects, A/FR values of above 2.0 appear required. With A/FRs between 1.0 and 2.0, low test defects are occasionally obtained. With an A/FR of below 1.0, low test defects are rare.

Yield and A/FR vs. Productivity Productivity has considerable variation among individuals. In some cases, high yield produces higher productivity but in others it does not. High A/FR also sometimes results in high productivity and sometimes not. Yield and A/FR are somewhat independent of productivity.

Process Benchmarks It is desirable to have high values for –yield –A/FR –productivity Since yield and A/FR are closely related, a yield vs A/FR benchmarking chart would not be useful. Yield vs. productivity or A/FR vs. productivity would likely be useful benchmarking charts.

Defect Removal Strategies - part 1 Focused inspections and reviews –high level design reviews - structural issues –detail level design reviews - logic correctness –code reviews - implementation issues Do not address –system issues in DLD –design issues in code reviews

Defect Removal Strategies - part 2 Do thorough reviews the first time and then trust them. Do thorough unit tests –black box –white box Do system tests once unit testing is done –integration –system –regression

Defect Prevention Finding defects is expensive so it is better to avoid them in the first place Defect prevention costs are only incurred once, but their savings impact every future project For PSP, defect prevention actions include improved design methods and prototyping

Defect Prevention Strategies Set priorities for defect types that are –found most frequently –the most troublesome –easily prevented In setting priorities consider the defects most often found in integration and system testing Incorporate your prevention actions in your process scripts, checklists, and forms

Defect Prevention Process Follow an established schedule Select 1 or 2 defect types for initial action Track and evaluate the effectiveness of the defect prevention actions Make needed adjustments and continue