4.4. Enacting the Quality Process

In a quality process such as the one described here, checkpoints are needed at the end of each iteration of the process component. This is where we apply the process checks of necessity and sufficiency. They are followed by the ability of the development process to modify and change itself to suit the actual project or to map to the actual project. This is where the malleability aspect comes in.

4.4.1. Creating Iterations and Increments in Lucky Insurance's Development

An iterative and incremental project plan ensures that the user is continuously involved in the development process. Table 4.1 shows how a typical insurance system's development occurs in an iterative and incremental fashion. The left-most column in the table shows the actual release versions of the entire system. These releases are shown as versions 0.1, 0.5, 0.9, and the first main release (1.0). Corresponding to each of the releases is a row indicating what is likely to be achieved in that release. The horizontal rows indicate the part of an iteration that is completed within the release. The vertical slices correspond to each of the subsystems or packages, and represent a physical increment.

As you will notice from Table 4.1, the client subsystem is part of the first increment of this project plan. Therefore, in the initial release of the system, the client use cases get completed first, along with their corresponding class diagrams and the solution design. The other increments are in the offing, and will perhaps follow the first increment. Some of the domain-level activities that deal with the entire insurance domain will continue to happen in the background across all iterations and increments.

Compare the approach outlined in Table 4.1 with a waterfall-based software development lifecycle. A waterfall-based approach completes all use cases and activity diagrams across all subsystems before proceeding with the business class diagrams, and so on. If, during the implementation of a suite of class diagrams, an error in understanding the requirements is discovered, then the analysis-level diagrams need to be changed, which is a very difficult undertaking.

In the iterative and incremental approach discussed here, risks are reduced by letting the users shape the requirements through an initial iteration within an increment of the system. Completing and correcting requirements and designs, even with this IIP approach, is difficult to achieve because the requirements change and because the users learn more about what they want as they see the output of each iteration. What can be said with confidence is that this is the ideal way to guarantee the least-incomplete and least-incorrect models. I take the humble view of least incompleteness and least incorrectness, because in practice, despite taking extra care and following the process precisely, I have always come across well-meaning users, architects, and designers who want to add “one more thing” to the requirements.

4.4.2. An Iterative Project Task Plan

The iterative and incremental approach outlined in Table 4.1 needs to be placed in a project task plan in order to enable a project manager to follow it. This requires the project manager to create a task plan that repeats the activities and tasks from the process-components. This project plan can incorporate all the increments at the outset, or one increment only with provisions for adding to and updating the project plan with additional increments.

Table 4.2 shows a small cross section of such a plan. As you will notice, the tasks related to requirements modeling (these tasks will be mostly derived from the process-components) are repeated for the subsystems. The essence of what is shown in Table 4.2 is that all practical project plans have sequential tasks, as shown by the task numbers in the first column. However, iterative and incremental development means that the project manager has to attempt to repeat activities and tasks at suitable intervals. Finally, although the tasks in Table 4.2 are repeated for different subsystems, identification of these subsystems is not shown here. It can be assumed that these subsystems will have been identified earlier in the project plan.

4.4.3. Iterative Project Management Tools

The project plan in Table 4.2 would usually be created in a sequential task-based project management tool such as Microsoft Project. However, it is worth considering project-management tools that are iterative and incremental in nature themselves. That means these project-management tools use techniques to enable the project manager to manage the project without repeating the tasks (as was necessary in the sample project plan in Table 4.2). Examples of such process tools are discussed in Process Tools Using UML. These tools give due consideration to the iterative and incremental aspect of a process. This means these process CASE tools are able to take the activities and tasks of the process and place them within the context of a project-management framework that allows these activities and tasks to be performed again and again, a sufficient number of times, resulting in a complete and correct deliverable.

The iterative and incremental nature of process tools also helps to provide not only detailed cross-referencing on all activities and tasks within the process, but also excellent tracking mechanisms for the activities and tasks. Despite their growing importance, availability, and capability, in practical enactment of the process, these process CASE tools usually end up being used together with the sequential project-management tools such as Microsoft Project.