Fourteen tips
to better your PSPSM [1]
Tip #5
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.
5. Better your reviews
Since their introduction in 1976, formal inspections have had a highly positive impact on the maturity of the software process and on the quality of the software products of numerous companies world-wide [Gilb-93]. A large body of evidence has established the fact that inspections are one of the most cost effective and easiest measures that can be put in place to make an immediate positive impact on any organization involved in software development.
Unfortunately, the process improvement aspect of inspections is often neglected in practice. This is a shame since the two processes of Defect Detection (DDP) and Defect Prevention (DPP) work in synergy to reduce recurring costs of rework (Figure 5-1). Nowhere is this more obvious than at the individual level. Since I am the creator of my own errors, I am the best qualified to understand their root cause and improve my personal process based on my own data to reduce future rework and go home earlier at night.
Figure 5-1: The review processes
Besides, if your organization has institutionalized inspections, chances are you do a personal review before submitting your precious creation to its unforgiving review by your peers. The PSP review script, defect type standards, defect log, quality metrics, Pareto charts and other graphs from the support spreadsheet offer a remarkably complete set of elements to not only improve the quality of your programs but, most importantly, improve the quality of your personal process. The PSP reviews are probably the most immediately applicable techniques for use on the job. TSP data shows that the synergy of PSP reviews and formal inspections can be credited with most of the return on investment from the PSP training.
That is why I complain if I do not see obvious signs of changes to the DLDR and CR checklists after each assignment. Typically, changes are indicated by bold facing the new element. The checklists must always be a living document updated by reviewing the defect log and doing a quick causal analysis during post mortem. Time must be added to the PM phase during planning for this purpose, starting at 7A. I also recommend the tracking of “Hits” (an error was found thanks to the checklist) and “Miss” (the checklist listed the potential error but it was missed in the review nevertheless) to help the student track the effectiveness of the reviews. Figure 5-2 shows such work in progress.
|
Ada code review checklist (partial) for 9A |
||||
|
Purpose |
To help you perform effective code reviews with Ada |
Units |
||
|
Completeness |
Specs and bodies have consistent param type profiles (function spec template) Comments in spec addressed to end user Comments in body addressed to maintainer Changed identifiers done with global selective substitution |
√ M √ √ |
√ H √ - |
√ √ √ - |
|
Validation |
Implementation meets acceptance criteria
from traceability matrix PDL maps to design. Correct PDL if not. Check object type semantics with scenarios (torture tests) Check performance and accuracy constraints (little O notation) |
√ √ √ - |
- √ √ - |
√ H - - |
|
High level verification |
Application note remains consistent with object when body is modified. Perform incremental regression testing. Verify implementation against design-derived data Desk check implementation with trace table |
√ H M - |
- √ M √ |
H √ M - |
Figure 5-2:
Tracking Hits and Miss
As you probably know, review speed is the most crucial review parameter. Even though you may get lucky with one of the PSP exercises and catch all your defects at 1,000 LOC/h, you won’t be able to maintain this impressive performance consistently on the job. Four methods can be used to compute review time. The first three are covered in class. The last one is a more recent SEI discovery from data on over 1,200 engineers:
· Use your defect detection rate: Your total defect density is 122 defect/KLOC and you plan to write 85 LOC (new and changed) which means a total of 10 defects. Your defects injected ToDate% from you plan summary shows 18% injected in design and 78% injected in code. Therefore you expect to remove 2 defects in DLDR and the remaining 8 in CR. Your data also shows that you remove 3.1 defects per hour in DLDR and 6.7 defects per hour in CR. So, you plan on 2/3.1*60 or roughly 40mn for DLDR and on 8/6.7*60 or roughly 70mn in CR.
· Use your preferred speed limit: You typically do excellent DLDR on the job at less than 120 LOC/h and consistently reach at least 80% yield when you do not exceed 80 LOC/h in CR (you are using trace tables since your data has demonstrated their value in reducing integration and system test time). These data yield a lower limit of 42mn for DLDR and 64 mn for CR.
· Use the A/FR upper limit : you systematically use cross reviews after your own personal reviews and often find no unit test defect with an A/FR > 5.3. You plan on 5 mn in compile and 15mn in unit test to perform a thorough branch testing with the debugger and truly torture the module. Therefore, you need 20*5.3 or roughly 110 mn in DLDR + CR time.
· Your data shows that you inject 1.9 defect per hour in design and 3.6 defects per hour in coding. Since you remove 3.1 defects per hour in DLDR and 6.7 defects per hour in CR, plan on spending 1.9/3.1 or 62% or your design time doing DLDR and 3.6/6.7 or 54% of your coding time in CR.
Finally, I have mentioned cross reviews. It is common practice in science as well as in any engineering discipline to have someone else review and criticize your work. This is one thing that the extreme programming folks do. If only they collected the data and used it for process improvement, they would have made a step toward TSP! When someone else reviews your work, their time is entered into both time logs. You decide if the issues raised are indeed defects, in which case you add these in your defect log. I have some data showing the positive impact of cross reviews and about the synergy between these and formal inspections [Roy-02].
Bibliography
[Gilb-93] Tom Gilb and Dorothy Graham, “Software Inspections”, Addison-Wesley, 1993.
[Roy-02] Daniel Roy, “Synergy of inspection techniques from PSP to CMM”, SEPG 2002. See “papers” section in http://www.stpp.com for a copy.