2.1. Quality Management
2.1.1. Quality Environment
This chapter discusses organization of the quality function, or quality management. It is effectively the tip of the quality context triangle (see Figure 1.2)—the quality environment. An effective quality environment includes the people who perform the quality checks, their organizational structure, and how those responsible for quality checks should interact with the rest of the project members. Quality management is a part of project management and, therefore, utilizes all aspects of management itself. This involves understanding the project in the context of the overall business, identifying and organizing teams, putting together a detailed process, setting standards, facilitating modeling, managing external relationships, and so forth.
A well-organized project team is also able to monitor and track projects—a fundamental aspect of quality. When we organize quality-conscious project teams, we organize teams that can hit a “moving target.” These quality teams bring together various players who will influence the actual quality of the software and, equally importantly, will influence the perception of quality within the project. Therefore, quality teams bring people together who will understand the problem, produce the models, produce the product, test it, deploy it, and use it. Good project teams also consider the roles that handle training, help desks, and so forth.
Based on the above, we move forward by setting the scene for the nontechnical aspects of management as well as quality management. Organizing and documenting the necessary and sufficient aspects of a quality process is essential to being able to shoot at the moving quality target. These are issues that go beyond software modeling, and they are discussed here with the aim of positively influencing the outcome of a UML-based project.
2.1.2. Nontechnical Management
Meyer [1995] has discussed in great detail the nontechnical role of a project manager who deals mainly with team formation and management. This nontechnical project manager role includes the sociological or human aspect of management that is applied to project teams and quality teams within the project. This application of sociology by managers to project teams is crucial to producing quality, because in the final analysis people produce quality—albeit supported by good tools and processes.
Goldberg and Rubin [1995] also discuss the importance of team formation, especially with regard to its structure and operation. A crucial aspect of their discussion is organizing teams in such a way as to carry out a successful reuse program in an object-oriented environment. This is because the sociological aspect of a development project is critical for both reuse and project quality. For example, it is a common experience that ownership of the reusable component is an emotional issue for the person who owns that component—requiring careful support from the project manager when the component has to be modified—especially if errors are found.
Quality-related work also generates emotions among project teams. For example, people entrusted with quality assurance and people whose work products (deliverables) are subjected to quality checks are often at opposite ends of the emotional spectrum. This happens because those entrusted with quality function must enforce the process and seek out errors in the deliverables or work products; the producers of the models may not always appreciate it.
While these sociological challenges in an object-oriented environment are well known, they are simply the extension of sociological challenges confronted by all teams—particularly the global teams that we come across in an outsourced project [O'Hara-Devereaux and Johansen 1994]. Team formation, operation, and motivation are not simple tasks, mainly because they do not seem to follow a given formula. Constantine, during the panel discussion on these soft issues at OOPSLA 96 in San Jose, stated:
It is easier to communicate with machines and solve the problems; but with people, it is difficult. This is mainly so because people are very difficult to generalize.
However, handling this difficulty is precisely at the heart of the success or failure of a particular project. Today's Information and Communication Technology (ICT) industry is such that most equipment, development environments, architectures, and commercial off-the-shelf software and components are easily purchased—perhaps at a fraction of the cost spent to develop them. The differentiating edge, however, as Kriendler [1993] points out, is created by a “company's work force and the quality of their development processes.” The skills and ability of the work force come to fruition depending on the way the teams are organized and managed, and the quality is improved through the quality process applied in development. Work forces and processes are discussed at length in subsequent sections.
2.1.3. Process and Quality
A significant aid to creating and managing quality teams is a good software process (shown in Figure 1.4). A process provides the necessary infrastructure of activities to carry out a successful project. Thus, a project and the process used within a project are interdependent. A process on its own cannot achieve much unless it is supported by good management skills. However, management itself also needs a well-thought-out process.
The responsibility of a quality-conscious process is not limited to simply producing software—although that is a significant deliverable in any software project. We want to produce a software product that evolves, scales, and changes according to the needs of its users. However, these needs continue to change almost daily, and so does the perception of quality. Therefore, we need a process that also handles the changing quality needs.
A quality-conscious process has some necessary steps and other sufficient steps. Furthermore, such a process includes a mechanism to improve the software process itself. Thus, the process has a component that enables the improvement of the overall process. This is the malleable aspect of a process and interests us from both software development and quality viewpoints. These necessary, sufficient, and malleable aspects of a quality process provide the additional focus of a quality process—the separate and sustained effort to produce a good quality product, good quality software models (such as our UML-based models), and a quality environment.
It is interesting to note how, at times, this necessarily separate and sustained effort toward quality gets treated as a part of normal software development. The reasoning behind this is: If everyone involved in a project accomplishes what he or she has to do in the best possible way, the eventual product is a quality product.
One can immediately challenge this thinking by asking, “Who decides what everyone should do?” While no one can deny that quality is everyone's responsibility, it is a greater responsibility for some than for others! It is this focused responsibility on quality that is derived from a separate quality function within the overall process. It is important for a process to be well thought out, put together, instantiated, and deployed. This is a part of the quality function, which is followed by enactment and monitoring of the process.
In order to achieve the process discipline (or discipline in following a method[1]), it is necessary to plan and organize the quality function in the same way that normal project management functions are organized. Thus, we use all the concepts of project management in quality management, but still maintain quality management as a distinct function with its own set of activities, tasks, roles, and deliverables.
[1] The discipline of methods is a science in itself. Creation and configuration of methods needs a scientific approach that eventually translates into their practical deployment, enactment, and monitoring. For more details, see www.MethodScience.com.
An example of the confusion that can otherwise result is seen when we ask the basic question, “Who creates and maintains a quality plan?” Theoretically, either the project manager or the process consultant performs this work. However, it is more appropriate to assign this to the role of quality manager. If quality is everyone's responsibility, then, despite all good intentions, it will end up being no one's responsibility.
This is not to say that people are not sincere in their desire to bring quality in their work. In fact, information technology—despite being only half a century old—is full of people who take utmost pride in their work. Many IT professionals eat, breathe, and live code—and eventually, the work they produce is of very good quality. What we intend in this discussion is to create a quality environment and inculcate a quality discipline that results in quality by individuals and teams. If management facilitates a separate and sustained quality effort, by enabling verification and validation of models and products, organizing and motivating people, and providing a planned approach to quality assurance activities, then the work of those innumerable sincere IT professionals will be that much more effective.