1. 1 复习

2. 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. 3 Mesure  Size measurement  Classification of codes  Defect measurement  Defect injection;  Defect removal;  Quality measurement  Product quality---yield;  Process quality---A/FR.

4. 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. 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. 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. 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. 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. 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. 10 The gantt chart

11. 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. 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. 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. 14 Summarizing weekly times

15. 15 Summarizing weekly times

16. 16 Calculating period times and rates

17. 17 PSP Process Flow

18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/ （ 17+15 ）的区别。

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

35. 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. 36 Estimating the ultimate Yield  Modification of the Yield Values of each phase  17/(17+15+8) = 42.5% changed to 17/(17+15+8+8) = 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. 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. 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. 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. 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 19.1-19.6  Improving the product quality;  Saving test time.

41. 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. 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 19.3.  To use this method,you need a stopwatch!

43. 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. 44  Challenge yourself to do superior work and you will be surprised at what you can accomplish.

45. 45 project plan summary

46. 46 project plan summary

47. 47 project plan summary

48. 48 project plan summary

49. 49 project plan summary

50. 50 project plan summary

51. 51