The Tale of Software Inspection at CRM
Typically in a software development team, the Program Manager(PM) is responsible for defining the customer problems, scenarios, use cases, high level design and detail requirements. The result of this activity is a functional specification (spec) that can be used to build the software. Developing specs is a creative process, in my experience. As a PM, you are responsible for ensuring the customer problem is fully articulated and prioritized. Moreover, the most suitable and innovative solution is proposed through research and close collaboration with customers, planners, developers, testers, user education gurus and designers.
Historically, the resulting spec is rigorously reviewed “only” by the feature team (i.e. folks who are responsible for various parts of the software development from designing, to writing code, to testing and delivery).
At CRM team, we have taken a different approach to increase the quality of the product and reduce the cost of software development through inspections. We realized that a group of product defects are more efficiently addressed if they are caught early on during the requirement reviews. As a result, in addition to traditional feature team reviews, we have introduced a Spec Inspection process before the technical designs are developed and coding starts.
Many years of research have gone into software inspections and it is not a new concept. A good book on the subject is Software Inspection by Tom Gilb and D. Graham.
According to IEEE Software Engineering Terminology, an inspection is defined as:
“.. a formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults violations of development standards and other problems.”
Taking part in an inspection is not as easy as one would think and hard work is needed to review the specs in detail and identify the defects. After the defects are identified, the feature team has to triage and decide which defects make the bar to be fixed based on severity. However, the end result is rewarding, resulting in less product defect later on in the process and most importantly, lower cost of software development as a whole (research has shown the cost of fixing the defects later on when the code is implemented is much higher than the inspection cost that could prevent the defects from getting into the product in the first place).
Be aware that extensive and lengthy inspections do not necessarily improve the product quality and reduce the defects and too little inspection also does not reveal the maximum value that the process could offer. It is a challenge to find a balance between the level of inspection and amount of time and effort your development team should dedicate to the process. It took our team a number of iterations until we found the right balance and we are still learning althouhg we are already seeing positive results.
Comments
- Anonymous
June 27, 2006
Arash, can you share more details on the specifics of this process? - Anonymous
June 30, 2006
Whay specifics are you interested in:-) What we follow in terms of specifics is close to what is described in the book. But as other processes go, each team need to add a certain degree of customization to the process in order to mold it into their specific needs. We have ran the inspections in our team in three milestones now. In each milestone we needed to apply a certain level of customization to get the most value out of the process based on the project constraints.