Inspections: Editing and Follow-up
Inspections - Process Improvement Meetings
Immediately after an Inspection meeting, the moderator may choose to conduct a separate meeting, which deals with process improvement.
This meeting follows hard-on-the-heels of the Inspection meeting and uses the issues that arose during the Inspection as a basis for considering process improvements. Defects were logged during the Inspection against rules that were broken. The moderator encourages the Inspection participants to come up with five areas for discussion and examination. Perhaps the group will choose defects relating to the five rules that were reported as broken most frequently during the preceding Inspection.
Once five areas are selected for consideration, the moderator will probe each area for possible root causes as to why the issues occurred. Only about three minutes is allowed to ascertain the probable root causes of each issue. These root causes may then be quickly prioritised for each issue.
At least one action item is then logged to address or repair the major root cause for each of the defect areas under discussion. This will be minuted against one of the meeting participants for follow-up action. In this way five rapidly identified and agreed improvements are undertaken in order to reduce the number of defects entering similar Inspection products and/or processes for future Inspections.
As an example, suppose it was identified that a specification had many
requirements that were not testable. Suggested root causes could be that
the business analysts had not been informed that each requirement should
be measurable and testable, or that insufficient time was allowed for
business analysis, or that many of the requirements remained untestable
in the absence of a specific test tool.
Action items that might have been logged include:
- In-house training for Business Analysts
is to be planned,
underscoring the fact that each requirement should be testable - completion date three days time - Mary. - Test tool to be motivated for purchase, and cost order-of magnitude quotes to be obtained - completion date one week - Bob.
- Project duration schedules to be extended by twenty percent during business analysis stage. Discussion to be held at next Project Manager's forum - Wendy.
If these items are addressed prior to the next Inspection meeting, then fewer defects are likely to be present in the next and subsequent Inspections for that product type.
Inspections - Editing
The Inspection logging meeting produces a set of minutes that include the logged defects. These are given to the author, who must then affect the repairs to the inspected material. The author is the only one with authority to reclassify defects from major to minor and vice versa.
Every logged defect must be dealt with, even if strictly-speaking, they were technically correct. The fact that people miss-interpreted the issues implies that during maintenance, or building of subsequent software products, they could (?would) be miss-interpreted again. The time taken to repair the defects is recorded as part of the data required for later quantative analysis of the Inspection method.
Inspections - Follow Up
The Inspection moderator is responsible for ensuring that the author has attended to each defect logged. The moderator does not judge the soundness of each repair, but merely ensures that the author has addressed each issue. The author, after all, is the subject expert, and not the moderator.
Inspections - Conclusion
We have seen that Inspections are the most effective means of detecting defects in our software development life cycle. They are massively parallel, effective communication meetings concerning our work products. They assume that individuals often make mistakes or work on the basis of wrong assumptions. They have specific rules to aid persons in varied Inspection roles, to stimulate objectiveness and remind each person of where technical hiccups have occurred previously.
Inspections are counter-intuitive, in that reading rates are much slower than the normal reading rates achievable by the persons inspecting the products. Although they deal with (soft) human-cognitive issues, they are based upon (hard) statistical process control methods.
Inspections are self-correcting; each Inspection process will adapt and adjust to the specific quality problems in your project!
Perhaps most-enigmatically, as effective as Inspections are for finding defects, the real purpose of Inspections is not to find defects, but rather to educate each project member so that they will not inject defects into their products in the first place! In other words, formalised software Inspections, seek from the outset to become redundant and unnecessary, as project teams are helped to introduce fewer and fewer defects into software products.
The implementation of Inspections shares many characteristics with human fitness. Both the implementation of Inspections and becoming fit require an initial desire and then dedication and effort to achieve the desired state. Once the desired state is achieved, it must be measured and constantly maintained or else it will gradually be lost. Fitness, and the Inspection process are easier to achieve with the support of like-minded persons. Many people would support the process, until the effort and dedication necessary become apparent, and then the path of least resistance may be chosen. Inspection is a job, but remember in business, it is the survival of the fittest!
Wayne Mallinson