Checklist
The checklist plays a significant role in software development. As a senior software development manager at a major software organization observed , checklists that sum-marize the key points of the process are much more effective than the lengthy process documents (Bernstein, 1992). At IBM Rochester, the software development process consists of multiple phases, for example, requirements (RQ), system architecture (SD), high-level design (HLD), low-level design (LLD), code development (CODE), unit tests (UT), integration and building (I/B), component tests (CT), system tests (ST), and early customer programs (EP). Each phase has a set of tasks to complete and the phases with formal hand-off have entry and exit criteria. Checklists help developers and programmers ensure that all tasks are complete and that the important factors or quality characteristics of each task are covered. Several examples of checklists are design review checklist, code inspection checklist, moderator (for design review and code inspection) checklist, pre-code-integration (into the system library) checklist, entrance and exit criteria for system tests, and product readiness checklist.
The use of checklists is pervasive. Checklists, used daily by the entire development community, are developed and revised based on accumulated experience. Checklists are often a part of the process documents. Their daily use also keeps the processes alive .
Another type of checklist is the common error list, which is part of the stage kickoffs of the defect prevention process (DPP). As discussed in Chapter 2, DPP involves three key steps: (1) analysis of defects to trace the root causes, (2) action teams to implement suggested actions, and (3) stage kickoff meetings as the major feedback mechanism. Stage kickoff meetings are conducted by the technical teams at the beginning of each development phase. Reviewing lists of common errors and brainstorming on how to avoid them is one of the focus areas (Mays et al. , 1990).
Perhaps the most outstanding checklist at IBM Rochester software development is the PTF checklist. PTF is the abbreviation for program temporary fix, which is the fix delivered to customers when they encounter defects in the software system. Defective PTFs are detrimental to customer satisfaction and have always been a strong focus area at IBM Rochester. By implementing an automated PTF checklist and other action items (e.g., formal inspection of software fixes, root cause analysis of defective fixes, and regular refresher classes on the fix process so that developers can be up to date when they need to develop and deliver a fix), IBM Rochester has reduced the percentage of defective fixes to a mimum, below the 1% level. Note that the PTF checklist is just one part of the fix quality improvement approach; however, there is no doubt it played an important role in IBM Rochester's fix quality.
The PTF checklist was developed based on analysis of vast experiences accumulated over the years and is being reexamined and revised on a continuous basis. Starting as an online checklist, it has evolved into an automated expert system that is ingrained with the software fix process. When the fix process is invoked, the expert system automatically provides the advice and step-by-step guidance to software developers. As a result the process discipline is enforced. Figure 5.2 shows several items on the PTF checklist.
Figure 5.2. Sample Items from the PTF Checklist