|
July
2001 Feature Article
|
|
The Kick-off Meeting and Private Inspection Process In Test Focus last month we saw that the Inspection Moderator would use sampling to ensure that minimum entry criteria for the product to be inspected were met. We also learned that rules are to be used for the inspection process and that reading inspection rates are very slow, counter-intuitively slow in fact, often averaging about one hour per page of material. Before proceeding, we need to underline the importance of having documented material to inspect, be it a code listing, design diagram, test case, or a specification. Some development teams have become confused. As a result they have replaced paper documentation with NO documentation rather than with electronically documented specifications, designs and the like. This is not progress. Oral tradition, for all its richness, cannot effectively be used for highly complex, long-living systems. Apart from the communicative aspects of writing, the discipline of putting our thoughts in writing often exposes our lack of knowledge and exploration of a subject. With these weaknesses now suitably exposed, they can be subject to the remedy of thought, rather than left to the realm of chance, ill-founded wishes and lack of homework. Figure 1
Click on image to enlarge Figure 1 contrasts written material, with orally communicated material. One doesn't need to be a rocket scientist to see that written material is far superior for the task of software development. Correction: if in fact you are a rocket scientist, you will already be basing your work on elaborately documented designs, procedures and knowledge! We now describe other factors concerning the kick-off meeting and then go on to describe the private inspection process. The Kick-Off Meeting (continued) The moderator will now assign various roles to the inspectors. Typical roles may include those from the list below, which is not exhaustive; other roles may suggest themselves for your product, project and industry. Be creative. For each private inspection role, have one of the inspectors either pretend they are from that category, or first-prize is to actually get someone from the desired category. Sample of Possible Private Inspection Roles:
More than one role may be assigned to a single inspector. Roles should be chosen to suit each person's real-life role and interests where possible. Should a person reading in a particular set of roles, report defects they notice which belong to other roles? Yes, because the person or persons covering those other roles may miss the defects. However, concentrate in your own role or roles, as this will minimise duplication in the detected defects. Figure 2
|
Figure 2 illustrates the point that roles overlap only marginally. This results in each person inspecting the material with rules chosen to uncover major technical flaws, at a pace optimal for detection of such flaws, with minimum chance of duplication. Rules will now be distributed amongst the roles, again to reduce overlap and the number of rules each person must consider. The roles and rules will change depending upon the product under inspection. It is easy to realise that a code inspection will have vastly different roles and rules from that of a design, project management plan, or contract inspection. Figure 2: The Effect of Varied Roles During Inspection - Maximum Coverage and Minimum Duplication Private Inspections There is an optimal rate to read material being subjected to inspection. The following tongue-in-cheek story will illustrate why slower reading rates are important for detecting defects during inspection. I come from Gauteng. In Gauteng we are very busy. To relax, on some Sundays I travel from my home in Centurion to the south gate of the Kruger Park. I leave home at four in the morning and arrive at six when the gate opens. I then set my car's auto cruise control to 120 km/h and move through the park to its northernmost end. The defects I see are the animals that come through the dashboard. Oh yes I always find some defects; I've got zebra, impala, vervet monkey and wild dog dents to prove it! We too will find some major defects in our specifications when we race through them (not surprising, as each page contains many major defects). No. I lied. I don't go through the park at 120km/h. In Gauteng (as you know) we are all very law-abiding. I really set the auto cruise to 60 km/h, which is legal for Kruger Park tar roads. My family finds this quite frustrating. One will say, "There's something behind that rock", I'll answer, "Nice rock". Another will say, "Look! Zebra!", and as we cruise at 60 km/h I'll respond, "Nice stripes". "Look! Giraffe!", will be met with, "Long neck" and so on. I'll frazzle my staff as we speed along with cursory attention. Who really sees the stuff at the park? Its
those who stop at the rock and then discover, "Nah, its just a branch
that looks like a lion's ear". But while stopped
three rhino
jog across the road right behind you and into the bush! I've stopped to
watch buffalo, and heard army ants (true story). They make
a noise when they "march" in columns (also true). Listen carefully
and you'll hear "links, regs, links
" (This
is now
stretching the truth). What does one do in a private inspection time? 1. Record the time taken to scan (at any speed) the supporting documentation (standards, rules, checklists and inputs from the preceding phase). 2. Read the material under inspection at a slow pace, taking time to consider which rules may be broken (thus indicating a defect). Look into the text, context, logic, meaning, and apply all your faculties to expose defects in the current product. 3. Tabulate each defect thus found as page number, line number, rule broken, three or four explanatory words, and then classify the defect as major or minor. A useful rule of thumb is that a major defect will cause ten or more hours of rework/wasted effort for team members down stream of the defect if it was not detected and corrected now. 4. Note the time taken for the material under inspection in minutes per page. There is also science in noting these times. Next month we will see that a simple graph and some arithmetic prove that faster reading equates to slower project progress and time lost!
|
| << June 2001 | August 2001 >> |