1 复习. 2 Main Three Elements  Plan  Period plan  product plan  Project Plan  Measure  Size measurement  defect measurement  quality measurement.

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

Computer Engineering 203 R Smith Project Tracking 12/ Project Tracking Why do we want to track a project? What is the projects MOV? – Why is tracking.
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.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
山东大学齐鲁软件学院 1 Chapter 9 Managing Schedules. 山东大学齐鲁软件学院 2 In the chapter  How to develop schedules to track the progress of your work.  How to use checkpoints.
Personal Software Process
The Software Process Strategy The Software Process Strategy Part III.
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
Fundamental of Software Project Management Team Assignment 1 – K15T2 – Team 07.
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
Personal software process Mohammed ahmed ali. What is psp The personal software process (psp) is a structured set of process descriptions, measurements.
Personal Software Process Overview CIS 376 Bruce R. Maxim UM-Dearborn.
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.
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.
Chapter 15 Projecting Defects( 缺陷预测 ). 山东大学齐鲁软件学院 2 outline  Analyze and use your defect data to help improve both planning accuracy and product quality.
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.
1 9/19/2015ã 2007, Spencer Rugaber Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software.
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.
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Project Monitoring ( 监测 ) And Control Presented by Basker George.
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 #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.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #8 Software Engineering.
Participate in a Team to Achieve Organizational Goal
Software Engineering Prof. Dr. Bertrand Meyer March–June 2007 Chair of Software Engineering Lecture 2: The Personal Software Process.
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.
Systems Life Cycle. Know the elements of the system that are created Understand the need for thorough testing Be able to describe the different tests.
Time Management Personal and Project. Why is it important Time management is directly relevant to Project Management If we cannot manage our own time.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #4 Software Engineering.
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.
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.
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.
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.
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.
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.
Personal Design and Development Software Process PD 2 SP “The unexamined life is not worth living.” Plato.
Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 1 1/11/2004 Day 2, Part 1 Estimating Software Size Section 2 Calculating.
Introduction to the Personal Software Process. Overview Process Fundamentals PSP Concepts and Structure PSP Planning and Measurement PSP Quality Management.
CSC 480 Software Engineering PSP Project 1 August 20, 2004.
Microsoft Project 2010 ® Tutorial 5: Tracking Progress and Closing the Project.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Disciplined Software Engineering Lecture #6
Estimating with PROBE II
A possible solution: Personal Software Process (PSP)
In this tutorial you will:
Presentation transcript:

1 复习

2 Main Three Elements  Plan  Period plan  product plan  Project Plan  Measure  Size measurement  defect measurement  quality measurement.  Manage  Time, commitments, schedules and quality.

3 Mesure  Size measurement  Classification of codes  Defect measurement  Defect injection;  Defect removal;  Quality measurement  Product quality---yield;  Process quality---A/FR.

4 Plan  The forms of period plan, product plan, and project plan;  How to make above plans?  Estimate based on the historical data.  period plan, based on ?  product plan, based on ?  Project plan, based on ?

5 period plan  Table 4.1 Weekly activity summary (Page 34).  Understand where you spend time  Judge that a large task will likely take nearly the maximum time and a simple task close to the minimum.  Plan the subsequent work

6 product plan  A properly produced product plan includes three things:  The size and important features of the product to be produced;  An estimate of the time required to do the work;  A projection of the schedule.  Planning for large and small tasks  Three basic plan elements: size estimates, projected hours, and the schedule.( 规模估计、项目时间、项目 时间 )

7 Some definitions  Product: is something you produce for a co-worker, an employer or a customer.  Project: typically produce a product.  Task: is a defined element of work.  Process: describe the way do the project.  Plans: describe the way a specific project is to be done. How, when and at what cost  Job: is something you do, either a product or a task.

8 Balanced estimate ( 均 衡估计 )  A balanced set of estimates has about as many overestimates as underestimate.  The advantage of having balance estimates is that on average your jobs will take about as long as you estimated.  The key to good estimating, however, is to learn to make balanced estimates.

9 Program Size measurement  LOC (Lines of code)  JCL—Job Control Language ( 可交付的作业控制语言 )  Include: Statements, data define, data declaration, input/output formats define etc.  Exclude: Comments, empty lines.  The following C program has 3 LOC.  if ( a>b ) max=a;  else max=b;  printf(“The max number is%d\n”,max);

10 The gantt chart

11 checkpoints  What is checkpoint?  Break the work into several parts.  When each part is completed,you have made a defined level of progress.  Measurable schedule points like this are called checkpoints or milestones.  Each checkpoint is a identifiable point, with a planned completion date.  you can readily see if you are on schedule or falling behind.

12 Making a project schedule  Step1:analyzing the job in enough detail to identify its several component tasks.  Step2:estimate the size for each of these smaller tasks and determine the amount of work.  Step3:list each task on a Gannt chart with a schedule bar to show when it will start and end.

13 Tracking earned value( 积分 )  To see table9.1 (page 106), table9.2 (page 108) Calculating each task’s percentage of the total project.  If some task completed, you will earn some values,which named earned value.  If reach an earned value of100%, means you complete all the works.  By using earned value,could do the work in different order than originally planned and still track progress against the plan.

14 Summarizing weekly times

15 Summarizing weekly times

16 Calculating period times and rates

17 PSP Process Flow

18 Defects & Software quality  Defects are the primary measure of quality in PSP.  Finding and fixing defects will do great help to improving software quality.  Finding and fixing defects is necessary but not sufficient to assure software quality.

19 Date Number Type Inject Remove Fix Time Fix Defect —— —— ——— ——— ———— ———— ————— Description —————————————————————————  Help to gather defect data.  Describe each defect in enough detail so you can later understand it.  Analyze the data to see where you injected and removed defect,and which types caused the most trouble. Defect Recording Log

20 Reviewing before compiling  Reasons:  1.it take same time to do a review whether before or after compiling.  2.reviewing first will save a lot of compile time.  3.once have compiled,reviews are not as thorough.  4.compiling is equally effective before or after review.  5.the more the defects in compiling, the more in test.

21 Why do checklists help?  Checklist  A series of procedural steps that you want to follow precisely.  Generally used in various situations  Before you do shopping---shopping list  Before the flight takes off---checklist  Countdown of shuttle---the checklist having hundreds of steps  But still exploded twice!  Can also be a source of ideas! (when write paper)

22 Building a personal checklist (1/2)  Make a list by type of the numbers of defects found in each phase  Rank the defect types in descending order of the number of defects found in compile and test (Missed in code review).  For those few defect types with most defects, examine the Defect Recording Logs to see what specific problems caused the most trouble.  For defects resulting from the most important problems, determine the steps to take in the code view to find them.  Make entries in the Code Review Checklist to ensure that you take these steps.  After using the new checklist, examine the defects again in the same way.

23 Building a personal checklist (2/2)  If the checklist was effective at finding these most important defects, add another type and use it again.  If the checklist was not effective at finding some defect types, try to find a better solution and try it again.  In developing or updating the checklist, group similar checks together and do not duplicate them.  Apply code review by the new checklist to each of your new developed program to verify its effectiveness.  After defects analysis, it is also a good idea to consider what steps might prevent these defects in the future. Such as updating the coding standard or adding a step to the design process.

24 Improving the checklist  Make a habit of regularly reviewing your defect data and reexamining the check list.  Make the checklist becoming an encapsulation of your personal experience.  Steps:  Collect the defect data by recording to date and to date % items in your checklist.  During the postmortem phase for each program, analysis the defect data and your checklist, to update or drop items.  For dropping items, you must use the most five to ten programs’ defect data.  For updating items, you’d better to do that after finding several same defects missed in your review phase.  Periodically prune( 剪除 ) your checklist to keep your focus attention.

25 Coding standards  While the principal code review standard is the programming language syntax specification, a coding standard specifies coding styles or formats.  A standard is an officially accepted basis for comparison. A coding standard thus define an accepted set of coding practices which can serve as a model for your work.  Coding standards is an effective means of preventing defects in coding phase.  See table 14.9 for a coding standard

26 Defect density  Defect density(Dd): the defects per thousand lines of code, measured by defects/KLOC.  Add up the total numbers of defects found.  Count the number of new and changed LOC  Calculate the defects per KLOC  Be sure not include library routine and copy part in counting LOC.

27 Defect estimation  Using data of previously developed programs to calculate the D plan  Dd plan = 1000*(D 1 +D 2 +…+D i )/(N 1 +N 2 +…+N i )  D plan = N plan *Dd plan /1000 ,  or D plan = N plan *D to date /N to date.  The calculation of expected number of defects to be injected and removed in each phase.  D phase = D planned total *D to date % /100.

28 Measurement of defect-removal  Measure defect-removal effectiveness  Defect-Removal Rate: number of defects removed in one hour.  Defect-Removal Yield( 效益 ): Percentage of the defects found by a removal method.

29 Yield of defect removing  Def. Removed/Hour: Defects found rate in one phase  Also we would like to know how many defects were found and how many were missed in one defects removing phase--- Yield  Moreover,  Process Yield = the percentage of the defects found before the first compile and test.  That is the percentage of the defects found in review phases (code review and design review), the percentage of the defects found initiatively ( 主动地), not passively (被动地).

30 Yield Calculation  Yield plan  Yield actual  Yield To Date  Yield = 100*(Defects removed before compile)/(Defects injected before compile).  See example of calculation in table 16.2

31 Two meanings of the Design Defect  Define all those defects injected in the design phase to be design defects  Define those defect types that involve issues of programming function, logic, performance, and timing to be design defects  In this class, we follow the second definition  Thus generally we say that types 10 to 40 in table 12.1 are coding defects and types 50 to 100 are design defects.

32 Ease of finding defects in design and code review  You review a smaller modules of your own codes;  You know the logic of your codes and you know what it should do;  You understand the unusual cases and odd conditions;  So you’re the only person who can ensure the products are essentially defect-free. If you do not produce a defect-free program, no one else can do it for you!

33 Calculating the Yield Values(1/2)  Applying Yield method to any defect-removal step  Phase yield = 100*(defects removed during phase/defects in product at phase entry)  The calculation of Yield Values for each phase is shown in Figure 18.4 on page 245.  When subsequently find defects, the yield of all the phases that missed those defects declines  17/ ( 17+2 ) 与 17/ ( )的区别。

34 Calculating the Yield Values(2/2)  Process Yield = 100*(defects removed before compile)/ (defects injected before compile)

35 Estimating the ultimate Yield  The key problem is that we don’t know how many defects remained in the product after we do the last testing  Two ways of estimating  Count the defects during the rest useful life of our software product;  Just assume that the remaining defects in a product equal the number found in the last removal phase. That is the same as assuming that the yield of the last test phase was 50%

36 Estimating the ultimate Yield  Modification of the Yield Values of each phase  17/( ) = 42.5% changed to 17/( ) = 35.4%  With historical data on the actual yield for each defect-removal phase, you could make more accurate ultimate yields estimates.  With enough yield data, you could even calculate statistical ranges for the number of defects remaining.

37 The steps of approaching the final goal  Making your process Yield = 100%  First you need to have the goal;  It takes time to practise and practise again and again;  Do your work professionally, like learning to play a musical instrument. That is, doing your work with disciplined quality methods:  Gathering Data, analysis your data and modify your defect removal methods  Do you work from simple to complicated, from a small program to a large program.

38 Process measure Quality of programQuality of processThe way you work Better programChange the way you work 取决于 Know your process Measure the quality of process need

39 Simplifying the calculation of COQ  PSP counts all compile time as failure costs.  Even include some defect-free compile time.  PSP counts all test time as failure costs.  PSP counts all review time as appraisal costs.  Appraisal COQ: sum of all review time as a percentage of total development time;  Failure COQ: sum of all compile and test time as a percentage of total development time;  See the example of table 19.1

40 A/FR-Appraisal/Failure Ratio  Simpler calculate: code review time/(compile time+test time);  It measures the relative amount of time spent finding defects before the first compile.  You should attempt to achieve A/FR of 2 or more.  Why? See figure  Improving the product quality;  Saving test time.

41 How to achieve A/FRs above 2.0 ?  Putting more time on code reviewing;  This will not improve program quality!!!  It is important to productively use review time in finding defects.  Code review with high quality.  For frequently missed defects.  Insert appropriate steps in checklist.  Take more time,find more defects,increase A/FR

42 Calculating the true COQ  Break the review, compile, and test times to their respective appraisal and failure time.  C=C F +C A ; R=R F +R A ; T=T F +T A.  Appraisal COQ=100*(R A +C A +T A )/totaltime  Failure COQ=100*(R F +C F +T F )/totaltime.  See example in table 19.1 and table  To use this method,you need a stopwatch!

43 Making a commitment to quality  To decided that quality is important  To establish the goal of producing defect-free program  To manage our fallibility( 失误 ).  Care enough to continue doing.

44  Challenge yourself to do superior work and you will be surprised at what you can accomplish.

45 project plan summary

46 project plan summary

47 project plan summary

48 project plan summary

49 project plan summary

50 project plan summary

51