1.4. Quality Software Process

Most of the work that goes on in the quality environment (as shown in the quality context triangle in Figure 1.2) is process based. Note also that in discussing the various levels of quality and how they relate to each other, the process quality level is important. Processes play a crucial role in producing quality. Processes also help management reduce development time, control the scope of the project, and provide potential checkpoints to ensure validation and verification of what is being produced.

1.4.1. What Constitutes a Process?

The dictionary defines process as:

A course of action or proceeding, especially a series of stages in manufacture or some other operation; the progress or course of something (in the process of construction).

From this definition we infer that a process involves a course of action that is performed by a series of steps. The definition also indicates fluidity—it indicates that a process represents some sort of behavior. A process, by this definition, is essentially a set of activities that is performed in a given sequence. It is a dynamic behavior plan rather than a static or hierarchical organization of work that used to be based on the old concept of work breakdown structure. Furthermore, this sequence of steps itself should be malleable and can be created based on the given situation in which the process is performed.

Other characteristics of these activities or steps is that they are performed on a thing or an object. Furthermore, in order to perform these actions, a certain set of tools or equipment might be required. It is also reasonable to extend the understanding of a process by assuming that the actions within the process will have to follow a certain discipline. It is also necessary to have someone performing this set of actions. The output or the end result of these activities is one or more deliverables.

1.4.2. A Sample Cooking Process

This explanation of a process is better understood by using a cooking example [Younessi and Henderson-Sellers 1997]. Consider the process of preparing a meal. It starts with the raw materials with which you want to cook the meal, and the tools that are necessary to carry out the tasks. In the case of baking a cake, the materials include the flour, butter, eggs, and additional raw materials; the tools include the pots and pans, oven, and other associated tools. These are the technological aspects of the process of cooking a meal.

However, the cake will not properly bake unless the raw materials are mixed in a certain proportion, and in a specific sequence. This information may be available in a book or a video that describes the mix and the sequence in baking the cake. This detailed recipe or baking method to be followed is the methodological aspect of the process of baking a cake.

Finally, the cook may be influenced by motivational factors (for example, the cook may be a professional who is paid for his work or a mother who bakes for her family). The general condition of the kitchen—including whether it has enough ventilation and light, whether it is air conditioned, and whether it is ergonomically designed—also plays a significant role in the final output. Thus, the skills of the cook and the environmental conditions in which the process is taking place constitute the sociological dimension of the process of baking a cake.

Each of these dimensions of the process needs to be considered carefully in order to produce a quality product. The study of this process can lead the cook to change the process when the cake is baked next time around, or it may allow a process expert to modify the process while the cake is being baked. This can be easily done only if the process is well defined and is divided into suitable components that lend themselves to change—they are the malleable part of the process.

1.4.3. The Orthogonal Process Relationship

The three dimensions of the process are not sequential to each other. That is to say, when the cook is mixing the dough, all three dimensions mentioned in the earlier section are in play. There is the “what” or technological aspect of dough, butter, and oven; the “how” or methodological aspect of the cookbook; and the “who” or sociological aspect of the cook. A number of activities are performed within each of these dimensions in order to achieve the overall objective. Furthermore, each of these three dimensions is made up of a subset of the overall set of activities within a process. A collection of a subset of such cohesive activities can form a component of a process, or simply, process-component.^[8]

^[8] Readers comfortable with the basics of a process may find it helpful to take a quick look at the process-component for baking a cake, as shown in Figure 3.3. Other readers should wait till they reach Chapter 3 for further elaboration on and creation of a process-component.

The activities from one dimension of a process relate to the activities of the other dimensions. Most of the time, activities from the three dimensions happen simultaneously. Taking the cooking example further, we may start with a cookbook, peruse it, and decide what we want to cook. Or we might know what we want, and refer to the correct recipe as we cook. Another example is that the cleaning and setting up of the kitchen (sociological dimension of the process) may go on, along with the study of the recipe (methodological dimension of the process).

In all practical cooking situations, the three dimensions of the process are executed depending on the management of the overall process discipline. We can say that the dimensions of a process are orthogonal to each other—each influencing the other aspects of the dimension. Figure 1.3 shows the dimensions of a process and their orthogonal relationship.

Based on this detailed example, we make the following observations about the process:

• A process is essentially made up of three dimensions.

• Each dimension of the process can be a process in itself.

• Processes comprise a set of activities.

• A collection of a subset of cohesive activities may be called a process-component.

• Activities within the processes have a flow.

• Activities from all three dimensions may be conducted at the same time.

• The relationship between the three dimensions of a process is orthogonal.

The above discussion intends to create an understanding of what a process constitutes, and what its various dimensions are (namely, the what, how, and who of a process). This understanding is crucial in our understanding of software and quality processes that are discussed in subsequent chapters of this book. This results in a quality process for software development, with specific process components that are focused on quality assurance and quality control.

1.4.4. Process in Software Context

Is following a standard software development process sufficient to produce quality? In my opinion, the answer is no. A separate and sustained effort at quality is required that is distinct from the standard software development process.

There is a distinction between the software process (commonly referred to as software development process or software engineering process) and the quality process. Together, the software process and the quality process make what I call the “Quality Software Process,” as shown in Figure 1.4. This is discussed in further detail below.

1.4.5. Software Process

I am using “software process” as a generic term to describe software development processes. While many software development organizations have processes of their own, others prefer to “buy” these development processes, which are available off the shelf. Software processes are also available in CASE tools. Examples of some of the off-the-shelf software processes include RUP, OPEN, MeNtOR, Catalysis, ICONIX Crystal, FDD, and XP. See Process Tools Using UML for a list of available processing tools.

In the context of UML-based projects, a process has to suggest how a particular diagram is produced. Then it has to provide detailed guidelines on how the various diagrams are put together to create complete models. It has to suggest the level at which the diagrams have to be used. A process further suggests the dependencies of the diagrams on each other. These are necessary aspects of a process which influence the quality of the model, which in turn influences the quality of the code that plays its part with the data quality to provide overall system quality.

While a process can provide details of all the necessary activities, tasks, roles, and deliverables, merely describing these details is not enough for a good process. It is important for a process to provide details on how these elements of a process are put together and enacted in an iterative and incremental fashion. Chapter 3 discusses these iterative and incremental aspects of a quality process in greater detail.

1.4.6. Quality Process

Quality process, as part of the Quality Software Process (shown in Figure 1.4), is almost an independent entity. Although it heavily influences the software process, and is in turn influenced by the enactment of the software process, it still has its own activities and tasks and process-components (see Chapter 3), and together they make up a suite of process-components of their own. The purpose of this quality process is to ensure that the software process produces quality models and quality products. Additionally, the quality process also ensures feedback to itself—that is, a quality process has to ensure its own quality by applying the same principles, concepts, and techniques that it applies in ensuring the quality of the standard software development process.

A quality process deals with four things:

A quality process not only helps to produce software that satisfies the needs of the end user, it also helps to improve productivity by reducing costly errors. As shown in Figure 1.5, by a rough estimate, if it costs only $1.00 to fix an error in the early part of a software development lifecycle, it can cost anywhere between $20 and $200 to fix the same error when it is discovered later in the lifecycle. A quality process ensures that we don't hurry through the software development process and don't cut corners to meet the target dates. Brooks [1995] aptly describes the truth of the matter when he quotes: “. . . Focus on quality, and productivity will follow.” Brooks argues, based on Jones, that costly and late projects invest most of the extra work and time in finding and repairing errors in specification, design, and implementation. Brooks offers data that show a strong correlation between lack of systematic quality controls and schedule disasters.

We have established the importance of quality process; now we summarize the difference between the normal development process and a quality process. The process that deals with software development is what I call the software process. This has been discussed earlier, and it varies depending on the type of projects we have. For example, development and integration projects need to use a process that enables design and development of large numbers of new classes, components, and database tables.

However, a package implementation project must use the process in a way that enables detailed capture and documentation of the business requirements and functionalities. And, again, a data warehousing project will need to use the process differently from the way it is used in the previous examples.

A quality process deals with each of these software development processes and their variations. The quality process ensures that the software process has the correct checkpoints and has the right amount of quality techniques applied at those checkpoints to ensure that the project is on track. Typically the quality process comes in between the various iterations and increments related to the software process.

Together, the quality process and the software process become the “Quality Software Process,” as shown earlier in Figure 1.4.

1.4.7. Quality Assurance and Testing: Let's Not Confuse Them

Quality assurance usually gets confused with testing. This has been aptly highlighted in the UML arena by McGregor and Sykes [2001]. Many times we hear: “The product is in QA.” That is not the correct interpretation of quality assurance. What is meant by QA in this context is actually quality control or testing. This error is not limited to day-to-day users or developers but even to people dealing with popular processes. For example, Jacobson, Booch, and Rumbaugh [1999] in the Unified Software Development Process talk about quality assurance as a set of tools that are used to test applications and components. Once again what is implied are tools that would help to automate product testing.

That, of course, is only one function of QA. Perry correctly differentiates the two: “The role of quality control (QC) is to measure products against a standard or attribute.” Thus, according to Perry, the purpose of QC is to identify defects and correct them so that a defect-free product is produced. QA is separate from QC and deals with the overall management of quality.

In this book we apply the overall quality assurance function to the projects that use UML. We do not restrict ourselves to mere QC or testing, although this testing aspect of QA does happen to be an important part of our QA strategy and is discussed separately in Chapter 6.

Furthermore, we extend our discussion of QA to include not just the management of the quality process but also the management of the overall quality function. This requires attention to obtaining resources and forming quality teams (their management, quality planning, budgeting, and so on), as discussed earlier. It is only when the product is produced or the database is loaded or the integration is complete that the final aspect of QC or testing comes into play. So to correctly restate the common phrase that “the product is in QA”: The product is in testing or QC.