2.9. Process Checks

Quality environment facilitates checking the syntax, semantics, and aesthetic aspects of models and other deliverables in the project (as was shown in Figure 1.13). These checks ensure the correctness, completeness, and consistency of the models. These models, in our UML-based discussions, were MOPS, MOSS, and MOBS. Quality management deals with the “how to” of conducting these checks. And a crucial aspect of this how to is the process. What is even more important is checking the steps of the process itself. This can be further explained by an example. If a semantic check for a class diagram is to ensure that the class represents the correct business entity from the problem space, then it is necessary for that to be performed in a satisfactory manner. The necessity of this step is a quality check itself—but a check of the process rather than the deliverable. We discuss the practical issues of process checks in the context of quality environment.

2.9.1. Checking What Is Necessary

First we need to decide whether a particular process-component (defined in Section 3.2.7) is necessary. Having short-listed the relevant process-components, the next level of process checks is for the necessary activities, followed by necessary tasks. Tasks are the atomic level of process checks. This can be done as follows.

Step through the task plan for the project. Tick off the necessary steps. Interact with the users for what they consider necessary in terms of the tasks and deliverables. The deliverables (MOPS, MOSS, MOBS) will be verified through the model checks. But the steps for those checks will be a part of the process. These checks will then be carried out in a quality workshop.

2.9.2. Checking What Would be Sufficient

Checking the sufficiency means checking what else in addition to necessity should be performed as a part of the process. This can change slightly depending on the type and size of projects discussed in Chapter 1. For example, large projects will have some of the steps of a process as necessary, rather than sufficient.

Sufficiency of process checks does not merely deal with the ticking off of a set of activities or tasks. More importantly, it deals with how many times a particular activity or task gets iterated. Thus, sufficiency of process checks also represents the depth of quality checking.

For example, documenting a use case is a task that is repeated many times in a project, until all use cases have been documented. However, repetition of the task document in a use case happens after many other tasks (like creating a use case diagram and analyzing a use case documentation) have been performed.

Sufficiency of checks means that a particular activity or task has been repeated enough times to provide confidence in the project team that the deliverable resulting from that activity task is as complete and correct as possible.

2.9.3. Checking the Malleability of a Process

While checking the necessity and sufficiency of a process can be outlined as a set of checks, the malleability of a process is involved more with its inherent characteristics than an external check. The science of methods underlying a process seems to imbibe this dichotomy within a process: the repeatability of the process resulting from its rigorous definition versus the ability of the process to suit various development environments such as the six different types of projects and their three different sizes discussed in Chapter 1.

Malleability attempts to ascertain the ability of the process to adapt to different development environments. Furthermore, malleability implies the ability of the instance of the process to adapt to the changes in the project itself, as the development progresses. For example, if a process mandates the creation of state chart diagrams for a class, but after two attempts at doing so the project team—and in particular the process engineer—realizes that for this particular project it's more beneficial to create the state chart diagrams directly from the use case descriptions and to use those diagrams to update class operations, the change in the process should be immediately reflected in the process description in the relevant process-components. Use of process-based CASE tools makes this much easier to accomplish. However, this is the malleable aspect of a process, and is crucial to the overall quality of the development.

A process tool should enable a feedback mechanism for the process users, and this feedback should be incorporated in (a) construction of the process instance, which is the area of process architecture, and (b) usage of the process, as the development progresses, which is the dynamic aspect of the process enactment itself. The measure of how easy it is to change the process during a project—during or at the end of each iteration—indicates the malleability of the process during enactment.