Fourteen tips
to better your PSPSM [1]
Tip #4
Daniel M. Roy
(President STPP, Inc.
SEI visiting scientist and
transition partner)
Abstract: Fourteen tips are proposed to better use the PSP framework so that
improvement is made easier and PSP is routinely used on the job. Tips for PSP
support tools and about expanding the PSP to small teams are added to make the
transition to Team Software Process (TSP-SM[2])
even smoother.
Einstein liked to say “Everything should be made as simple as possible, but no simpler!”
I think Watts did a marvelous job keeping the PSP scripts as simple as possible, but no simpler. Now, the book and every single class assignment workshop encourage us to build on PSP principles. So, what’s wrong with building a checklist for planning? The instructors’ checklists (when you get your assignment back) give you an idea of what to put there as well as other tidbits for many more process elements. Figure 4-1 is just an example.
|
Purpose |
1.
To guide you in planning PSP assignments
|
|
|
General |
As you complete each action, check off item in box at right |
|
|
Process |
Process tutorial and workshop exercise reviewed and understood Process description in appendix C read Appropriate section in the book read Personal improvement goals for this assignment logged in PIP |
|
|
Requirements |
Appropriate section of appendix A Read and understood Program description (appendix C) understood (main USE case written) Formulas and algorithm from Appendix A re-written from scratch Intermediary results noted for later V&V (test points) Input data entered in file and double checked against book Output format sketched or prototyped with expected final results |
|
|
Conceptual design |
Libraries and other sources searched for reusable components Reused objects double checked for suitability (scenarios) Base components double checked for suitability (USE case) Build sequence determined (iterated USE cases defined) Test strategy defined (test harness, data, watch points) Package/Dependency diagram verified against USE cases Class diagram sketched |
|
|
Size estimation |
Size estimates lessons learned and rationale reviewed (from previous PIPs) Suitable number of objects identified (>5) Most objects are of average size (M) Number of methods consistent with class diagram Data from table 5.7 correctly used Rationale for size selection and PROBE method selection documented (PIP) |
|
|
Time estimation |
Time estimation lessons learned and rationale reviewed Rationale for PROBE time estimation method selection documented (PIP) Are PROBE time estimates consistent with N*avg(LOC/h)? Are PROBE time estimates comparable to back of the envelope time estimates by object? Should extra time be provided for this assignment (document why in PIP ) |
|
|
Review plan |
Size estimation template complete (all sections) PROBE parameters consistent with latest method selected Total size, coding speed and overall productivity believable All manual computations double checked for accuracy Review times respect the speed limit (<200 LOC/h) A/FR > 2.0 (at least) You plan on 100% yield |
|
Fig. 4-1: PSP Planning Checklist
This clearly shows that a lot goes into planning with PSP. Not all of that should be “charged” to the assignment at hand. The tip on time log discussed how education time (reading the book for instance) can be logged without polluting the time per phase statistics.
PROBE is a very powerful tool. As such, it must be used with care. The criteria for size selection on the size estimation template and PROBE method selection are discussed in class and the support spreadsheet is very helpful to play “what if” games. But in the end, the estimates must be carefully examined:
· Base code:
ü You plan on a base of 125 LOC without any deletion or modification. Should you count this module in the reuse section instead?
ü You answer no to the above. Are you sure there will be absolutely NO deletion nor modification?
ü Base additions are often misunderstood. If you think you will be able to reuse that stuff, put it under new objects instead.
· Other LOCs:
ü Review your size estimation template. Does it match your conceptual design?
ü If you had to modify a reuse component, you must enter 0 for its size in the actual reuse column on that line of the size estimation template and add the previous size of this component to the actual base instead.
ü Estimated new reuse will be computed as a portion of the estimated New and Changed. Since this estimate may have undergone PROBE method processing, make sure to correct the number of new reuse LOC accordingly or you may plan on more than 100% new reuse (or on much less than you meant depending on whether PROBE corrected your raw object LOC estimate “E” up or down).
· PROBE:
ü The class allows the engineer to use his/her own PROBE table. Watch it! You better be consistent (really build your own table before 4A and stick with it) or your data will never converge. I tried this when I took the class using Watts’ algorithm on some 50,000 LOC of Ada that had survived various jobs. I did not have enough data for some categories of objects! On the job, I would start with only ONE category.
ü You could improve with any reasonable data in table 5.7 provided that you compare your estimates with your actuals line by line during PM. You will see that you just need to select another size category to get much closer. For instance, you may have to select Large instead of Medium sometimes (if you systematically underestimate) but remember PROBE will nicely correct for you most of the time provided that you are consistent. You do not want to “over correct” the estimate (I double it in my mind and, sure enough, PROBE doubles it again for me).
ü Now, your raw estimate “E” turns out to be 22 LOC for 6A. Do you really believe that? Worse, PROBE tells you that. Do you simply buy it because it’s the process? If it does not sound right, go back and double check your assumptions. That should include the assumption that you perfectly understand what the program must really do. If not, you got a planning error found in planning. Better now that later!
ü You use VB6. Is LOC the only thing you need to plan? Could the number of controls, the number of modified attributes, the number of reused intrinsic modules, etc. be a part of your effort, and therefore of your estimates? Probably. For now, use table 5.7 and make a note of all these extra parameters in your PIP. Revisit that stuff at R4 or R5 time. All this will probably be of great use on the job. As for the PSP class, don’t you think you have enough work to do?
ü PROBE allows you to select a size estimation method independent of the time estimation method (say method A for size and method C for time). Double check planned productivity, particularly if the improved New and Changed LOC estimate “N” is very different from the raw object LOC estimate “E”
ü PROBE does not specifically consider application complexity in the estimation of time. This is because the PSP assignments belong to the same class of statistical programs. On the job, you may want to apply the same principles used for PSP size estimation tables and produce a productivity table based on the complexity of your application. Again, for the class, you have enough to do as it is.
· Plan summary:
ü You plan on 167 LOC new and changed. Your time estimate for coding is 22mn (ToDate % does it again). Do you buy it? My typing speed is about 400 LOC/h. But coding involves much more than typing.
ü You plan on 15mn in compile and 45mn in test. You plan to spend 10mn in DLDR and 20mn in CR. Happy? Check your A/FR. The book recommends A/FR >2.0. Since I also request students to do cross reviews, my value is closer to 5.0. Your mileage will vary but an A/FR of 0.5 spells trouble.
ü If you plan to review the design for 167 LOC in 10mn that’s probably because the design is lightly documented. Try Watts’ templates. Try it at least once. Check the CR speed as well. Time on your hand? Try trace tables! More on that in the review tip.
ü The ToDate% defects injected from the support spreadsheet would have you inject 4 defects in design and 10 defects in code. It always amazes me to see how accurate these predictions can be! Now, the ToDate% removed statistics would have you remove 2 defects in DLDR and 6 in CR. Happy? Plan on 100% yield no matter what the spreadsheet says. Be in ambush for ALL 4 defects in DLDR, and for ALL 10 defects in CR. You found only half? Review again. More on how to do this in the reviews tip.
The point is that your planning exit criteria should include a personal critical review and a cross review with a colleague or even with the instructor (as recommended in all class assignment workshops). Of course, rationale and assumptions in selecting objects and their relative size and any deviation from the standard procedures should be carefully recorded in PIPs for later reviews. This is how to close the feedback loop and truly live up to the spirit of level 5.