3.2. The Process Metamodel

3.2.1. Describing the Process Metamodel

In order to better understand the three dimensions of the process described above, and to further describe the various elements of a process as applicable to UML-based software development, we created the metamodel shown in Figure 3.1. It is not a formal metamodel, but one created to explain the process-components described later in this chapter. A metamodel is a succinct and helpful way of understanding things. For example, the UML has a metamodel that encapsulates the rules that govern the creation of UML diagrams. A look at the UML metamodel can tell us how a class relates to the attributes and operations inside of it.

The purpose of the process metamodel, as shown in Figure 3.1, is to provide the underlying rules for how the process elements connect to and relate with each other. Discussions on formalizing a process metamodel are underway at the OMG. In the meantime, this simplistic process metamodel serves our purpose of discussing and creating a Quality Software Process (QSP). The metamodel shown in Figure 3.1 uses the UML's class diagram notations, which readers should know. It can be interpreted as follows:

The process-component is shown as the building block for the process. This process-component is made up of activities, deliverables, and roles. Activities associate with tasks. The lifecycle provides the philosophical background for construction of a process. Examples of software lifecycles are shown as waterfall, spiral, and fountain models. A Software Engineering Process (SEP) is based on this lifecycle. In order to create a SEP, the process-components are instantiated. The SEP is made up of iterations, which can be 1, 2, 3, and so on. Similarly, a SEP is also made up of increments, which are first, second, and third (and can be many more). Increments are made up of iterations.

Each of these elements, appearing in the process metamodel, is further described with their corresponding notations.

3.2.2. Process Ingredients

Figure 3.2 shows the notations that are used to describe a process. These notations represent the elements that constitute the “what,” “how,” and “who” of the process. Some of these notations are UML-like, such as the role. Others, like deliverables, are needed to express the process aspect. These notations are also simple. They can be easily written on whiteboards, facilitating process-based discussion and leaving the opportunity open for other uses of these process elements, such as describing processes in a typical business exercise. These process elements can also be inserted in a process-based CASE tool that in medium to large projects will greatly ease their enactment. Each of the process elements shown in Figure 3.2 is described in the subsequent sections.

3.2.3. The Role Element in a Process

The role provides a descriptive profile of the person who is involved in executing the process. In a quality-conscious process, this role is properly defined and documented. A person will fulfill the description of the role provided here. The person playing the given role is responsible for carrying out the process. He or she can also be the recipient of the process. If use case proponents wish to use the term actor, they may—despite the fine difference between actor and role. Some of the characteristics of a good quality role are:

• The role is well defined and is understood by the person who is responsible for the role.

• The person playing the role should be able to understand the activities that he is responsible for.

• The role must be assigned the suite of activities and tasks that the role player is capable of performing.

• Depending on the scope of the process, the actor element can have multiple instances. For example, a large development process may have 20 programmers but a small-scoped process may have only two.

• Examples of roles defined for a UML-based project include Project Manager, Business Analyst, System Designer and Tester, and Developer/Programmer.

3.2.4. The Activity Element in a Process

The activity is the description of the responsibility of the role in the process. The activity element is shown with an elliptical rectangle, and it describes in general what the role encompasses. Activities have a sequence or dependencies. Some activities can also be performed in parallel by more than one role. The activity element in a process is the controlling element for a set of tasks within the process. Therefore, the activity element on its own doesn't have the same concrete existence as the tasks. Actors playing the roles described above carry out the activities by performing a sequence of tasks within the activities. Some of the characteristics of an activity element are:

• Activity is the overall controlling element for a set of tasks.

• It is helpful in understanding the flow of events.

• Some activities may begin before others end. Thus, activities may be carried out in parallel.

• Activities are accomplished by completing the set of tasks which they encompass.

• It is not essential for all tasks within an activity to be accomplished in a single iteration.

• Example activities within UML-based projects include storyboarding, business class modeling, use case modeling, operational analysis, advanced interface design, quality resourcing, and test execution.

3.2.5. The Task Element in a Process

The task element in a process discipline is the atomic element in the working of a process. As shown in Figure 3.2, tasks are rectangles with rounded edges. Tasks are carried out under the umbrella of the encompassing activity. Thus, the purpose of the well-defined tasks is to complete the activity under which they fall. Some characteristics of the task element include the following:

• They are the performing elements in a process; that is, they don't need to be further subdivided before they are performed.

• A set of tasks belongs to an activity.

• In the overall process, these tasks are usually carried out in a specific sequence. The designer of the process usually specifies the sequence.

• However, since activities may sometimes be performed in parallel, so can tasks.

• The result of the execution of tasks in a sequence is the completion of an activity.

• Tasks have a concrete existence of their own. This implies that when a task is completed, it is effectively an incremental completion of the activity under which the task is performed.

• Tasks are what the project manager puts in a project plan. Thus, they can be assigned a time for completion and resources to complete them.

• Examples of tasks in a UML-based project are draw a business class diagram, conduct research, apply equality review, and execute a prototype.

• Techniques for carrying out a task may be described.

3.2.6. The Deliverable Element in a Process

A deliverable is the final output or result of the process. The roles (actors) are involved in performing various activities, which are carried out by executing a set of well-defined tasks. These tasks result in creating and upgrading what are called deliverables. Since deliverables are the result of work carried out by the roles, they are also called “work products.” Deliverables can be concrete, as in a set of documents, or they can be abstract, as in a motivated work force (which results from work performed by a project manager). In our cooking example, the final deliverable is a baked cake. Deliverables in a UML-based project are usually produced iteratively. That means, even if a deliverable is shown as being produced as a result of activities, only some of the tasks within the activities will result in a partial completion of the deliverables. Eventually, more activities and tasks within the activities will be performed to complete the deliverable. This deliverable and its corresponding notation are shown in Figure 3.2.

3.2.7. A Process-Component

A process-component is a collection of a subset of the activities, tasks, roles, and deliverables in a process. Thus, a process-component indicates a logical collection of process elements that combine to accomplish a sizeable chunk of the process. The term process-component signifies that a suite of process elements is treated as a component, having a common set of roles working on a logically cohesive set of activities and tasks, resulting in a significant deliverable within that area of the process. Examples of process-components in a UML-based project are Business Evaluation, Requirements Modeling, System Architecture, and Quality Control.

3.2.8. Iterations

An iteration signifies an execution of a sequence of process-components, but with varying intensity. For example, some process-components related to evaluating the business proposal for a project are performed with high intensity in the first iteration, but the process-components dealing with requirements modeling are performed with high intensity in the second iteration. An iteration in a medium-sized project may last for about three months, at the end of which reviewable deliverables should be produced. Larger projects will need more time to complete iteration.

3.2.9. Putting Together a Process-Component: A Baking Process

Once the notations are described and understood by the process participants, the representation of the process by means of a diagram plays a significant part in conveying the activities, their sequence, the final deliverable being produced, and the roles responsible for producing those deliverables. Figure 3.3 shows graphically, by using the notations described in detail in the previous section, the simple baking process that we have been using as an example.

• There are three formal roles that are involved in this process-component. They are the chef, the food inspector (quality manager), and the consumer.

• The process is made up of a series of activities: environment creation, baking, quality checking, and consuming. Each of these activities has a set of tasks to go with it. For example, environment creation will have the tasks of procuring the raw materials, like sugar and butter, and preparing the kitchen. The activity of baking includes tasks like mixing the batter, preheating the oven, putting the pan in the oven, and taking the cake out of the oven at the right time. For a large cake (for example, a wedding cake) the activity of quality checking will come into play, followed by consumption. Consumption activity is shown as iterative, and it may be performed numerous times. The consumers of the cake will be multiple people filling the role.

• The final deliverable is shown as a baked caked. If necessary, the raw materials going into the process-component can also be shown (they are not shown here).