3.1. The Process Backbone
In Sections 1.4.2 and 1.4.3, we considered the three dimensions of a process and discussed a simple baking example to demonstrate them. Here, we begin the discussion of a process by extending that example further, in order to put it in a process metamodel. This will help us immensely as we construct the quality software process-components later in the chapter. We will also use that understanding to facilitate the creation of a process metamodel.
3.1.1. The Three Dimensions of a Process
The first dimension of a process develops an understanding of the materials on which the actions are performed, as well as the tools that help to perform those actions. This forms the technological dimension of a process. In the example of baking a cake, the activities related to this technological dimension are the evaluation of the dish, the ingredients, and the equipment. This constitutes the “what” of a process.
The second dimension of a process is the step-by-step guide to “how” a particular process is conducted. The discipline of conducting a process comprises a sequence of well-defined activities and tasks that are organized in a specific order. This discipline, or method of working, constitutes the methodological dimension of a process. Some activities corresponding to this dimension in the baking example are recipe, cookbook, and timing. This constitutes the “how” of a process.
The third dimension of a process deals with the people who are going to take responsibility for the actions, and carry them out by following the prescribed methodology. An understanding of the dimension of a process that deals with the people who carry out the tasks, and the environment or the organizational context in which those tasks are carried out, results in the sociology of a process—the sociological dimension. In the baking example, the sociological aspect is comprised of the cook, the kitchen environment, and the “soft” issue of cake presentation.
Quality assurance, although a part of the overall process, has a separate set of deliverables, activities, tasks, and roles. Therefore, these elements of the process are separately defined—focusing on the quality management, quality assurance, and quality control suite of activities. These quality-related activities continue to influence the rest of the process. They are also self-influencing in the sense that each quality activity can be used to perform quality assurance on itself. For example, an activity of workshopping in a quality-assurance part of the process can be used to verify the process of conducting workshops in a process. Understanding these three dimensions is crucial to understanding the logic behind the metamodel for a process.
3.1.2. “What” of a Process
The “what” of a process is the technological dimension of the process that answers everything related to the physical things in the process. This primarily includes the raw material with which the process is executed, as well as the deliverables. It is concerned with the technology of the process. Many factors from the technological dimension influence the overall output of a process. These factors include the quality of material that is used, the availability of the material, and the appropriateness of the tools that are used in the process. Thus, everything that deals with the “what” in a process plays a part in influencing its deliverable. Examples of some of these technological factors in a UML-based project are summarized in Table 3.1.
| Model (components, other deliverables) | Tool (TogetherSoft or ROSE, for example) | |
|---|---|---|
| Availability | Problem statements, existing applications, MOPS, MOSS, and MOBS | Is TogetherSoft available, or is ROSE better? Consider other options |
| Standards | UML as a standard for modeling; documentation of project standards | Compliance of TogetherSoft to UML standards |
| Appropriateness | Is MOPS the right thing to create a model in problem space? | Is TogetherSoft the right tool for modeling? (for example, it can't be used for a process) |
3.1.3. “How” of a Process
The “how” or the methodological aspect of the process deals with the steps you follow to produce the deliverable. It is essentially a glossary of the distilled experiences of numerous project managers. The “how” of a process is instrumental in conserving effort when the process is enacted. Taking the cooking example further, the “how” of the process is the recipe book for the baking process. A description of the activities and tasks using suitable notations and language is essential to expressing the “how” of a process. In the case of UML-based projects, examples of the methodological dimension of the process are as follows:
| Requirements Modeling Process-component (and others, as described later in this chapter) | |
|---|---|
| Notations | UML notations for models; process notations, as described later in this chapter. |
| Language (description) | The actual description of the methodological aspect (the how)—by using the building blocks of a process. These are the process-components described later in this chapter. |
| Documentation | This is the accompanying standard for process, models, the description of how to use them, and their acceptance criteria. |
3.1.4. “Who” of a Process
Simply following a method, as described in a recipe book, does not produce the desired deliverable. Application of the methodology is the purview of the person who is applying it. Success depends on the skills and experience of the person, as well as the environment in which she is working. Thus skills, experience, and environment form the sociological factors, or the “who” of a project. These are also called soft factors, as they deal with the softer or human-relations issues of a process. Refer to Chapter 2 for further discussion of soft (not easily quantifiable) factors.
Skills, one of the factors influencing the final outcome of a process, require regular training—especially when new ways of doing things and new equipment become available on a daily basis. Experience comes from practicing developed skills in a real environment. In addition to the skills and experience, it is also important to consider the motivational factors and their influence on the process. These are some of the sociological factors that continue to influence the final outcome of the project. For a UML-based project, some of these sociological factors are summarized in Table 3.3.
| Business Analyst (and so on with other roles) | |
|---|---|
| Skills (role description) | The title and description of the role is described here. Also, the relevant skill set needed for this role is described here. A business analyst must have good business domain knowledge, familiarity with UML notations, comfort with use case and activity diagrams, and good interviewing and workshopping techniques. |
| Experience | A minimum of two years of business analysis experience might be considered essential for a person to be able to “get up to speed” in week one of a project. However, business analysts with less experience can also provide significant input into the project, provided they have had additional training in both UML techniques and the process. |
| Environment | The sociological factor or e-factor, as described in Chapter 2, should be handled here. Proper working environments (desks, phones, email facilities, decent meeting areas, and so on) are physical considerations that should be addressed in a UML-based project. |