IMPLEMENTING THE RATIONAL UNIFIED PROCESS STEP BY STEP

Implementing a new process in a software development organization can be described in six steps (see Figure 17-1). ^[2]

^[2] R. McFeeley. IDEAL: A User's Guide for Software Process Improvement, SEI Tech. Rep. CMU/SEI-96-HB-001, 1996.

Figure 17-1. The steps to implement a new software development process

Step 1: Assess the Current State.

You need to understand the current state of the software development organization in terms of its people, process, and supporting tools. You should also identify problems and potential areas for improvement as well as collect information about outside issues such as competitors and market trends. When this step is complete, you should know the following:

The current state of the software development organization
The kind of people who work here and their level of competence, skills, and motivation
The tools currently used in the organization
The current software engineering process and how it is described

Why should you assess the current state? Consider the following reasons:

You want to use it to create a plan to get from the current state of the organization to your goal.
You want to identify the areas that need to be improved first. You may not want to introduce the entire process and all the tools at once. Instead, you may prefer to do it in increments , starting with the areas that have the greatest need and the best potential for improvement.
You want to explain to the sponsors why you need to change the process, tools, and people.
You want to create motivation and a common understanding among the people who are affected directly or indirectly.

It is important to understand the project's level of management complexity and level of technical complexity. The more stakeholders the project has and the bigger the project, the higher the level of ceremony that is needed. More artifacts must be produced, communicated, explained, reviewed, and approved. The higher the level of technical complexity, the more effort that must be put into maintaining the artifacts and tracking the status of the project (see Figure 17-2).

Figure 17-2. Systems classified according to technical and managerial complexity

Step 2: Set (or Revise) Goals.

The second step is to set goals for the process, people, and tools, noting where you want to be when the process implementation project is complete. You set up goals for the following reasons:

Goals serve as an important input to planning the implementation of the process.
Goals, combined with the result of step 1 (a description of the current state), are used to motivate the sponsors and the people in the organization.

The result should be a list of measurable goals that are expressed so that they can be understood by project members . The goals can serve as a vision of the future state of the organization.

Step 3: Identify Risks.

To succeed in implementing a new process, you must control the many risks involved. We recommend that you perform a risk analysis in which you identify potential risks, try to understand their impact, and then rank them. You should also plan how you will mitigate the risks and in what order (as described in Chapter 7).

Switching from a linear process to an iterative process is not a risk-free undertaking. Software development organizations using an iterative approach for the first time may fall into several traps, including the following:

The first iteration is too ambitious, and people cannot focus on the most important risks.
There is a failure to implement and test in each iteration. In order to mitigate a risk you normally have to test what has been built.
Some stakeholders do not buy into or understand the iterative approach. They expect the project to progress as if it were using the waterfall method, where, for example, a complete design over the system should be produced early in the lifecycle.
You plan feature by feature instead of planning the complete project from the start (at a high level) and being prepared to change the plan along the way.
There is too much rework between the iterations, meaning you do things in an earlier iteration that you must redo later.
You fail to control requirements changes, thinking that changes do not matter very much because problems can be fixed in later iterations.
You undertake too much training too early. As a result, too much time elapses before people start to produce real work, and they tend to forget what they learned earlier.
You staff the project too quickly, and too many people are involved in the inception phase. This makes it difficult for workers to understand their responsibilities and runs the risk of leaving some people without tasks .
Tool support is insufficient, or people lack the skills to use them properly.
You fail to assess the true value of artifacts and thus produce unnecessary artifacts.

Step 4: Plan the Process Implementation.

You should develop a plan for implementing the process and the tools in the organization. This plan should describe how to move efficiently from the current state of the organization to the goal state.

Do not try to do everything at once. Instead, divide the implementation into a number of increments, and for each one, implement a portion of the new process with the supporting tools. Typically, you should focus on one of the areas where you believe the change will have the most impact. If the software development organization is weak in testing, you might start by introducing the test workflow of the Rational Unified Process with tools to automate testing. If, on the other hand, the organization is weak in capturing or managing requirements, you might start by introducing the requirements workflow with its supporting tools.

There are different approaches to implementing a process. The one you choose depends on two things:

The need for change in the current organization

If there are a lot of problems in the organization ”problems with the tools or with the way people work ”the frustration level in the organization will be high. In this case, you can be fairly aggressive and employ the new process and tools, or parts of them, in real projects.
The risks involved

If the risks are small, you can be fairly aggressive and quickly start using the process and tools in new projects. If the risks are great you must be careful, using pilot projects to verify the process and the tools.

We give examples of two approaches:

The "typical" approach
The "fast" approach

In the typical approach ( illustrated in Figure 17-3), you first implement the process in a Pilot Project. In an initial step you configure the process and describe it in a development case. You use the process on the Pilot Project. Experience from the Pilot Project is fed back into the development case. The process is then considered tested , or verified , and can be rolled out to a broader audience. As a Pilot Project you might use one of the following:

Figure 17-3. The "Typical" approach toimplementing a process and tools

A complete software development project that is considered to have low risk from a technical and financial perspective
The first complete iteration of an actual software development project, with the caveat that the main focus is on learning and improving the process and not on developing software

This approach is the most effective way to introduce the process and tools.

The fast approach (illustrated in Figure 17-4) is to use the process and tools directly in actual projects without first verifying that they work in a Pilot Project. This approach introduces a greater risk of failure, but there can be good reasons for taking these risks. For example, if the current process is very similar to the Rational Unified Process and if the tools are already used in the organization, it may be relatively easy and low-risk to implement the new process and tools.

Figure 17-4. The "fast" approach to implementing a process and tools

Make sure that you have chosen the right people to participate in the Pilot Project because they will pass the message on to the rest of the organization. Some of them will play important roles as mentors when the process is implemented in the rest of the organization.

Step 5: Execute the Process Implementation.

The most time-consuming step in implementing a process is to execute it according to the plan defined in step 4. Step 5 includes the following tasks:

Develop a new development case or update an existing one.
Acquire and adapt tools to support and to automate the process.
Train members of the development team to use the new process and tools.
Apply the process and tools in a software development project.

Step 6: Evaluate the Process Implementation.

When you have implemented the process and tools in a software development project, actual or pilot, you must evaluate the effort. Did you achieve the goals you established? Evaluate the people, the process, and the tools to understand which areas to focus on when you start again from step 1.