1.3. Quality Levels

Perry [1991] highlights goals, methods, and performance as three major aspects of quality. The quality context triangle, shown in Figure 1.2, further expands on Perry's basic definition. Understanding and appreciating quality, especially in the context of software, can be developed if we consider the various levels at which quality criteria can be applied.

For example, the goals of quality at the process level are established to ensure that all necessary steps in the process have been followed—and repeated a sufficient number of times. Model quality, on the other hand, may focus on the most efficient design that results in high performance and/or easier maintenance. These various focuses of quality are highlighted in the layers of the quality context triangle of Figure 1.2. These divisions facilitate easier understanding and concentration of quality effort in the area most needed. The following quality levels deserve our attention when we consider software quality:

• Data Quality

• Code Quality

• Model/Architecture Quality

• Process Quality

• Management Quality

• The Quality Environment

There are times when the distinctions shown here might blur, but they are important in providing a background for a project's quality needs.

Furthermore, each of these quality needs can have two aspects to it: quality control, which deals with ensuring the quality of whatever is produced within these areas, and quality assurance, which deals with the quality of process that produces artifacts within these areas.

The following sections discuss these elements of the quality context triangle in further detail.

1.3.1. Data Quality

In Figure 1.2, the basic layer of quality is the data quality, which is the widest layer of the triangle. Data in any modern industrial application (including Web applications), or in any multidimensional data warehouse application can span from gigabytes to terabytes and more. Ensuring the quality of this data is a major part of both quality control and quality assurance. The quality manager must be aware of techniques of equivalence partitioning, boundary values, and so on, in sampling, checking, and correcting the data that goes into a system. Data quality is an important aspect of quality to be considered, especially in large-scale conversion projects. Detailed description of techniques to ensure data quality and related testing is discussed in Chapter 6.

1.3.2. Code Quality

The next layer of the context triangle is the code quality, or quality of the programs written. This layer is at a higher abstraction than the data level. Programs can deal with a large amount of data, but they themselves may not be as large as the data they manipulate. In assuring programming quality, we consider the logic of the program, as well as standards such as naming of attributes and operations and the layout of code specific to a particular language. The compilation, link, integration, and build of code are verified and validated, resulting in a good quality code.

Because the code deals with and manipulates the data, the quality of the code influences the quality of the data (to a certain extent). If coding were the only activity happening in a project, then certainly quality assurance and quality control of code and its accompanying data would complete the job of a quality manager. Since that is not the case, code quality is separate from data and model quality.

1.3.3. Model Quality

In a UML-based project, we do not code directly from what the developers or the users have in their heads (thankfully). First the problem is modeled in detail, and then the solution is modeled. The problem and the solution models are influenced by models of the architecture, which stay in the background. All UML-based projects undertake a detailed amount of modeling, which is neither the actual data nor the actual code. These models go on to improve the quality of the code produced.

However, it is not just their influence on the implemented code that interests us, but also their own quality—that is, the quality of the models themselves. We want the models we have produced to be subjected to the quality assurance process. It is important that these models adhere to known standards and are also subjected to stringent quality control, because models play a crucial role in improving the quality—by improving the communication among project team members and among projects. This detailed quality aspect of the UML-based models themselves is a topic outside the scope of this book, and is covered separately in another book [Unhelkar 2003].

1.3.4. Process Quality

One way to ensure production of good models is to produce them by following a quality-conscious process. Models in UML-based projects are outputs or deliverables that are produced by following certain steps. Once these steps are researched and organized (and possibly supported by a process-tool), they become a full process. The process plays a crucial role in what gets produced as a model. Therefore, it is absolutely vital to consider the process aspect of quality within the context triangle.

Furthermore, as Fowler [2000] correctly states, without having at least some semblance of a process, it is difficult to discuss modeling. This also implies that it is difficult to disregard process in a serious discussion of quality of the models produced. A set of well-thought-out activities and tasks, as available in a process, is likely to result in more accurate and higher quality models than a random attempt. This level of the quality context triangle finds a separate, serious, and sustained workout in Chapters 3 and 4.

1.3.5. Management Quality

“Management of Quality” or “Quality of Management”? While most of the time these two phrases are used interchangeably, they are two separate aspects of quality, albeit heavily dependent on each other.

“Quality of Management” delves into the quality of everything that needs to be managed in a project and that is represented by “Management Quality” in the quality context triangle. This includes the need to organize resources, form teams, set objectives, prioritize scope, manage risks, and enable communication, to name a few. These are standard project management tasks. The manner in which they are performed has a direct bearing on the success or failure of a project. These tasks need to be performed in a quality way, leading us to the discussion on quality of management. It is important to perform all management tasks with quality consciousness, because more projects fail because of a lack of proper project management considerations than because of technical issues.

This viewpoint is ratified by a KPMG report presented by Greatrex [1996] at the IT Project Management conference in Auckland in April 1996. More than 250 companies whose IT projects failed were surveyed. The results indicate that in 32 percent of the cases inadequate project management led to project failure. Other major factors were inadequate communication (20 percent) and failure to define objectives (17 percent). These factors can all be categorized into what Constantine [1995] calls soft factors and what DeMarco and Lister [1987] call sociological factors.

When we talk about quality of management we are talking about the manner in which these soft factors are handled by management. The quality of management is discussed and highlighted, as are the related process aspects, deliverables produced, and the application of quality techniques to the management approach. An improvement in quality of management leads to an overall improvement in the way in which risks are managed, objectives are scoped, and teams are motivated, for example.

Management of quality, on the other hand, is different. It deals with applying the principles of management to the quality work itself. For example, managing the quality assurance personnel, organizing the quality meetings, procuring the quality control tools, and managing the risks associated with quality (as well as extreme quality) are some of the things that fall under the category of management of quality. One of the primary responsibilities of a quality manager in managing quality is creating a complete quality environment.

1.3.6. Quality Environment

This is a separate and focused attempt at quality; it can also be described as quality management that deals with the creation and management of quality environment, as shown in Figure 1.2. Planning for quality, organizing the resources, and providing an approach with associated quality tools is part of creating and managing the quality environment.

Placed on top of the quality triangle, the quality environment deals with all aspects of quality underneath it. The quality environment is responsible for data quality, code quality, model quality, process quality, and management quality. Furthermore, it is also responsible for itself—that is, organizing the quality management functions itself is subject to the quality criteria setup in the quality environment.

Specifically, in terms of a process, the quality environment deals with the tools and techniques of the process itself. It deals with process transition issues, training issues, pilot project selection, process deployment with a case tool, and quality control organization. It provides an overall environment in which good process, followed by good models, followed by good programming, followed by good data is made possible. A software process can deal with a project, but the questions of whether to create an in-house process or buy an “off-the-shelf” one, how to ascertain a suitable process if buying one, how to customize it, and how to deploy it should fall outside the process. For example, if I am deciding to use a particular process, such as eXtreme Programming (XP) or RUP, that decision-making process should not be a part of XP or RUP. That decision is taken by or suggested by a quality process—which in turn is within the full quality environment. A quality environment, therefore, is made up of not only a software development process, but also a quality process.