1.8. Quality Assurance of Software Process: Necessity, Sufficiency, and Malleability
There is a basic difference between a process and the models that reside within it. The models are static. The models are produced at a point in time. They have syntax and a semantic meaning to which we can apply quality-control criteria. Even the models that are supposed to represent the dynamic behavior of the system[17] are not dynamic.
[17] In UML, there are hardly any genuine dynamic models—a dynamic model would be something like a prototype of a steam engine, giving out a real whistle and steam! The state chart diagram comes closest.
The process that produces these steps, however, has specifications for the model, as well as a detailed set of activities and tasks enabling us to produce the model. Furthermore, as discussed in Section 1.4.1 (defining the process), a process not only describes what to produce (the deliverables) and how to produce them (the activities and tasks) but also who produces them (the people, or more appropriately the roles they play).
Because of the fluidity that exists in a process, it is better (than putting together a syntax and semantic checklist) to ensure its quality by:
Making some aspects of the process mandatory
Describing process artifacts that satisfy more than just the basic necessity
Allowing the ability of the process itself to change
These are the necessary, sufficiency, and malleability aspects of quality in software processes as shown in Figure 1.13 and described in further detail below. Chapter 3 describes in greater detail the application of these concepts in practical UML-based projects.
Figure 1.13. Quality process levels: necessity, sufficiency, and malleability
1.8.1. Quality of Process—Necessity
Necessity of a process describes the steps that are a must before any deliverable of value comes out of the process.
For example, in baking a cake, the process description should ensure that the role of a cook; the flour and butter; and the very basic steps of mixing the flour, putting it in the oven, and removing the cake at the right time are mandatory. These are the basic necessities of baking a cake, without which there would be no cake.
Necessities of a process may not have much elegance about them. They can be a simple set of tasks cobbled together in a project task list or plan. Their execution is also likely to be linear, following the waterfall lifecycle of software development.
1.8.2. Quality of Process—Sufficiency
A process can be said to be sufficiently described and followed when it outlines all the process artifacts that provide for more than just the basic necessities.
In the example of baking the cake, sufficiency of the process can be judged by the aspects of the process that describe additional roles such as helper and taster, additional materials such as a decorative cherry placed on the cake, or a bookstand to hold the cookbook, and steps to make the process further satisfactory such as using a timer and cutting the cake into the right size to enable easier serving.
Sufficiency brings in the concept of elegance in process. When applied to UML-based projects, this means the application of the principles of Iterative, Incremental, and Parallel (IIP) development.
1.8.3. Quality of Process—Malleability
In discussing what the process should produce, and how it should produce deliverables, it is likely that the quality of the process that is producing the deliverables gets missed.
An ordinary process has its description—as in the steps and the roles executing those steps—preset. These steps are not easily changeable, especially when their execution has already started.
The ability of a process to lend itself to change by accepting feedback from the users of such a process, before and even during its execution, is what I call the malleability of the process.
The malleability aspect of the process comes from the architecture of the process itself: some aspects of a process that make it malleable include how the process is put together from its building blocks (provided of course the process has building blocks), how easy it is to configure such a process, if the process is a process-CASE tool itself, or if it can be easily input inside a CASE tool enabling the changing and creating of new processes suiting differing project requirements.
The malleability aspect of a process makes it a quality process, because it helps the process engineer provide additional emphasis on activities and tasks that are important to the project, while it eliminates tasks that might not be relevant to the given situation.
If not deployed and managed properly, processes tend to be cumbersome and bureaucratic. Malleability of a process ensures that the project, and the quality of the product, doesn't suffer from these drawbacks. However, we cannot apply a checklist to the malleability aspect of a process. This quality aspect of the process must be built in or architected by the producers of the process.