This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.

Slides:



Advertisements
Similar presentations
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Advertisements

Tutorial: Using PSP0 Personal Software Process for Engineers: Part I
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.
PRO2 - 1 Introduction to the Personal Software Process SWENET PRO2 Module Developed with support from the National Science Foundation.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
SE 501 Software Development Processes Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 7.
Copyright © 1997 Carnegie Mellon University Introduction to the Personal Software Process - Lecture 1 1 Introduction to the Personal Software Process Lecture.
S5-1 © 2001 Carnegie Mellon University OCTAVE SM Process 5 Identify Key Components Software Engineering Institute Carnegie Mellon University Pittsburgh,
Personal Software Process
Aplicaciones de Ingeniería de Software
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
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 #5 Software Engineering.
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.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Chapter 15 Projecting Defects( 缺陷预测 ). 山东大学齐鲁软件学院 2 outline  Analyze and use your defect data to help improve both planning accuracy and product quality.
SE 501 Software Development Processes Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 8.
ELP Helper MSE Project Presentation I Aghsan Ahmad Major Professor: Dr. Bill Hankley.
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.
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.
Disciplined Software Engineering Lecture #4 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Disciplined Software Engineering Lecture #6 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
CS 350, slide set 6 M. Overstreet Old Dominion University Spring 2005.
1 ADVANCED MICROSOFT EXCEL Lesson 9 Applying Advanced Worksheets and Charts Options.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Lecture: The Personal Software Process. 2 Overview  Personal Software Process assumptions process stages measures and quality strategy results.
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.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
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 #8 Software Engineering.
SE 501 Software Development Processes Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 9.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 9 – Quality Management 1INFO636 Week 9.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #4 Software Engineering.
PSP Quality Strategy [SE-280 Dr. Mark L. Hornick 1.
1 The Personal Software Process Estimation Based on Real Data* * Would Martin Fowler approve? “I want you to take this personally…”
CS 350: Introduction to Software Engineering Slide Set 3 Estimating with Probe I C. M. Overstreet Old Dominion University Fall 2005.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Disciplined Software Engineering Lecture #3 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Disciplined Software Engineering Lecture #2 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #2 Software Engineering.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
SE-280 Dr. Mark L. Hornick 1 Design and Code Reviews Review Checklists.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Implementation Phase CS4311 – Spring 2008 References: Shach, Object Oriented and Classical Software Engineering E. Braude, Software Engineering, an Object-Oriented.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
CS 350: Introduction to Software Engineering Slide Set 2 Process Measurement C. M. Overstreet Old Dominion University Fall 2005.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Empirical Estimation Models Based upon historic data Basic Structure E = A + B * (ev) C where A, B, c are empirical constants ‘ev’ is the effort in terms.
Carnegie Mellon Software Engineering Institute © 2006 by Carnegie Mellon University Software Process Performance Measures James Over Software Engineering.
Introduction to the Personal Software Process. Overview Process Fundamentals PSP Concepts and Structure PSP Planning and Measurement PSP Quality Management.
CS 350: Introduction to Software Engineering Slide Set 3 Estimating with Probe I C. M. Overstreet Old Dominion University Spring 2006.
CAT Executive Review Team 3: Lions. Cycle 2 Key Lessons: Quality.
Disciplined Software Engineering Lecture #6
Estimating with PROBE II
A possible solution: Personal Software Process (PSP)
Software Inspections and Testing
SQA for Individuals based on
Presentation transcript:

This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University January 2006 Pittsburgh, PA PSP II - Using PSP2 - 1 Personal Software Process SM for Engineers: Part II Tutorial: Using PSP2

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 2 Tutorial Objectives After this tutorial, you will understand the new PSP2 process elements know how to use the PSP2 scripts and forms be prepared to use PSP2 for program 5

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 3 PSP2 Objectives The objectives of PSP2 are to introduce design and code reviews methods for evaluating and improving the quality of your reviews

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 4 New Process Elements There are two new process elements. design review checklist code review checklist Design and code review checklists are described separately. PSP2 adds two key capabilities to the PSP design and code reviews quality planning The PSP2 project plan summary supports these two new capabilities.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 5 Design and Code Reviews Two phases have been added to the process 1.Design reviews (DLDR) 2.Code reviews (CR) Time and defect data from these phases are summarized on the PSP2 Project Plan Summary.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 6 Quality Planning PSP2 introduces quality planning. Quality planning involves estimating the total number of defects that will be injected estimating the number of defects that will be injected and removed in each process phase estimating the amount of time needed for design and code reviews adjusting these parameters as needed to ensure a high quality result

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 7 Estimating Total Defects To estimate the total defects injected and removed, use the estimated program size and to-date defect density to calculate the estimated total defects. Use this formula Planned total defects =To-date total defects/KLOC × Planned Added and Modified LOC / 1000

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 8 Estimating Defects by Phase To estimate defects injected and removed by phase, distribute the planned total defects injected and removed based on historical data. Planned Total Defects To Date % defects injected in each phase To Date % defects removed in each phase

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP2 - 9 Estimating Review Time These PSP benchmarks can be used to estimate design review and code review time in phase. For manual calculations, starting with the code review rate is recommended.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Estimating With Review Rates -1 Benchmark data on code review rates can be used to estimate review time. From PSP data, we know that code review rates under 200 LOC/hour generally give high yield. Using planned added and modified LOC, code review time can be calculated using this formula. Assume a similar rate for design reviews.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Estimating With Review Rates -2 To add review time to your plan increase the total minutes, and/or reduce compile and test time As a final check of your estimate, make sure that review rates are less than 200 LOC per hour defect removal rates are between -3 to 5 per hour for design review -5 to 10 per hour for code review A/FR is about 2.0

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Estimating Considerations Initially no historical data are available for planning defects injected and removed in review phases. Until you have data for design and code review phases, you may want to consider defects injected are 0 defects removed should be based on your yield goal Your yield goal should be based on your interim report analysis. If you do not have a yield goal, you should try to achieve greater than 60% yield.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Estimating Defects Removed Defects removed in a review phase are calculated using number of defects escaping from prior phases number of defects injected in a phase percentage of defects removed, i.e. Phase Yield Defects present=escapes + injected Defects removed=present × phase yield

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Yield-based Quality Planning An alternative approach to quality planning is to start with the desired PSP process yield. Process yield is the percentage of defects removed before the first compile. First choose a target process yield, then use historical data to calculate the quality plan. defects injected and removed by phase time in phase for design review, code review, compile, and test

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Choosing a Desired Yield The ideal yield is 100%, all defects injected are removed before the first compile and test. While you are likely to achieve 100% yield periodically, this may not be a realistic goal. Class average yields will typically exceed 50% to 60%. PSP class data indicate that yields of 60% to 80% are easy to achieve with PSP design and code reviews.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Phase Yield Phase yield is the percentage of defects that were removed in a phase and is based on defects entering the phase + defects injected in the phase. With PSP2, the process yield is a function of the design and code review yields, and the proportion of defects present for the design review. Choose a target process yield and solve this equation for the design and code review yields. PSP yield =CR yield × (1 - DR yield × Design defects %) + DR yield × Design Defects %

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Other factors Other factors to consider Defects may be removed in phases other than DLDR, CR, Compile, and Test. Defects may be injected in compile or test Calculating the desired phase yield is difficult Due to the complexity of this approach, automated support is necessary. To produce a yield-based quality plan, enter the target yield as the planned yield.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Estimating Review Time Finding defects early will reduce defects found in compile and test. The support tool computes the time saved using the average defect removal rate for compile or test. The time saved is then used for design and code reviews. The allocation of time saved is based on the ratio of estimated time in design vs. estimated time in code.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Derived Quality Measures PSP2 also provides the following derived quality measures. Defect removal efficiency Defect removal leverage Test defects per KLOC Total defects per KLOC Yield

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Defect Removal Efficiency Defect removal efficiency is calculated automatically and shows the number of defects removed per hour for 1.Design review 2.Code review 3.Compile 4.Test

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Defect removal leverage is calculated automatically and compares removal efficiency for 1.Design Review vs. Unit Test 2.Code Review vs. Unit Test 3.Compile vs. Unit Test Defect Removal Leverage

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Test Defects Per KLOC 1.Test defects per KLOC is calculated automatically and is an indicator of the quality of the program that you put into test.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Total Defects Per KLOC 1.Total defects per KLOC is calculated automatically and is a measure of the total defects injected during the process.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Yield 1.Yield (actual and to-date) is calculated automatically for the entire process and is the percentage of defects injected and removed before the first compile.

© 2006 by Carnegie Mellon University January 2006 PSP II - Using PSP Messages to Remember You will see more improvement from design and code reviews than any other process change you make. Quality will improve. Productivity will increase. PSP2 provides data that allows you to plan for specific quality levels control quality during development improve the quality of your PSP increase productivity without sacrificing quality