Task: Tailor the Development Process for the Project

Analyze the Project

Purpose:

To get a feel for the problem at hand, and the resources available to the project.

It is crucial for the success of the project that the delivery process is relevant for the project at hand, and for the size and formality requirements of the project. Too much process tends to get in the way of creativity, effectiveness and efficiency. Too little process can lead to a chaotic environment, typically leading individual project members to make local decisions that may result in inefficient, inconsistent and unpredictable results.

Define the Scope of the Tailoring Effort

Purpose:

Define which process areas to cover in the project-specific process.

The results of analyzing the project resources and their experience with similar software development projects helps identify the scope of the tailoring effort. A project-specific process does not have to include all the disciplines in RUP, nor should it be necessary to cover all the roles defined in the RUP. Keep in mind that the RUP is a process framework suitable for a wide range of project types, and thus will be too much for one specific project to follow. The areas you select to cover in the project's process, depends heavily upon the existing skill sets of the project members, and the nature of the project at hand. Below are some typical considerations to make when defining the scope of the tailoring effort.

Areas where the project members already have a common way of working, where it is not necessary to introduce a new process and tools. For example, if they know how to test, it can be a good idea to not introduce the Test discipline of the RUP to limit the number of new factors. You can focus on introducing some parts of the RUP, to correct problems in their existing process. See Concept: Implementing a Process in a Project, section Improving Process and Tools , for details.
Areas (disciplines) where the project must introduce new process and tools, because there is no existing way of working. In some cases there is no existing process and tools to fall back on, and it is necessary to introduce most of the RUP, together with supporting tools. See Concept: Implementing a Process in a Project, section Change Everything , for details.
Problems in the existing process. Focus on improving areas in which the organization has had problems.
Which tools to use? If the project has decided to use certain tools, the development process should normally cover the corresponding areas of the RUP.
The project's capacity to change. When looking at the organization's problems there is a tendency to try to fix everything at once, especially since many of these problems occur together. This is usually a fatal trap. Organizations just like individuals can accommodate change but only within a limited range. If the capacity to change is low, you have to go slower, and maybe just introduce one or two disciplines of the RUP in the first project.
Areas where the project's members lack knowledge, or are weak. Let the development process cover these areas. Make sure that it is easy to find the right information in the RUP.

For more information on defining the scope of the tailoring effort, see Guideline: RUP Tailoring.

For a description of the factors affecting how a process is customized for a project, see Guideline: Process Discriminants.

Identified improvement areas must not necessarily be introduced for the first time in the same project. Reduce the number of unknown factors and look at areas where the development organization has experienced the most pain in the past. We recommend that you implement the RUP iteratively, as described in the Concept: Implementing a Process in a Project. For small projects there is also guidance in Example: A Small Project Adopts RUP.

Although there might be discovered needs for improvements within several disciplines, consider the option of introducing them iteratively over the course of several projects rather than aiming for a change-everything-at-once approach. One example of such a tradeoff is to introduce Requirements with Use-cases and defer the introduction of a new CM process, if previous projects have struggled with unclear and/or insufficient requirements, or if major complaints have been made by users that the delivered product does not meet their needs.

The tradeoffs made and the resulting scope should be documented as part of the process in order to communicate the scoping decisions to external stakeholders.

Develop Project-Specific Content

Purpose:

To create additional "process know-how" in areas where the coverage in the RUP process framework is deemed insufficient for the project.

The RUP method framework is manifested in a process model defined using a UML based meta-model. The RUP method framework is based on a meta-model called the "Unified Method Architecture" (UMA). The basics of UMA are described in Concept: Key Capabilities of the Unified Method Architecture (UMA).

You can extend the RUP framework by adding Roles, Tasks, and/or Work Products, or you can add project-specific Guidance to the existing RUP framework.

As a part of any project-specific process, there should be a set of available resources tailored to provide specific help and reference material for producing project artifacts. Examples of such resources are :

Common guidelines for how to produce certain artifacts.
Templates customized for use across projects. These will be partially instantiated with project information.
Artifact examples relevant to the project's defined set of deliverables and chosen technology.
Reusable assets, such as design patterns and code libraries.

At the onset of the project, the Project Manager typically works with the Process Engineer to select the appropriate set of resources, and make them available to the project members as part of the project-specific process. The need for additional resources is revisited at the beginning of each iteration.

Configure the Process

Purpose:

To right-size the process to support the exact needs of a project.

Configuring a process involves selecting the method content (work products, tasks, roles, etc.) that are to be included in the process. For specific recommendations on what method elements to include for each discipline, see the "important decisions in <discipline name>" guidelines that are provided for each of the RUP disciplines. Selecting the right set of method content for a given project is not a trivial task. To be effective, the process needs to be relevant and right-sized along different dimensions, like project size (resources and calendar time), formality, technological platform, domain, just to mention a few.

For information on a classification scheme for documenting the importance of individual work products and whether or not they will be used, see Guideline: Classifying Work Products.

Define the Lifecycle Model for the Project

Purpose:

To define the lifecycle model for the project.

An important part of tailoring a process for a project is deciding on a lifecycle model for the project to follow, including the breakdown into phases and iterations. For this part of the tailoring work, the process engineer should collaborate closely with the project manager since the chosen lifecycle model lays the groundwork for the project planning process. Depending on the nature of the project, there might be a need to adjust the RUP lifecycle to better match the specific needs. For example, green field development usually requires more effort in Inception than a maintenance project. Thus, the lifecycle description should be adjusted according to the nature of the project. See Concept: Iterations for a discussion on various types of lifecycle models.

In addition to selecting the overall lifecycle model, it is also important to decide how to perform the workflows associated with each of the disciplines that are included in the tailoring effort, as well as to decide when, during that project lifecycle, to introduce each part of the disciplines' workflow. Deciding how to perform the workflow involves deciding what activities to perform and in what order. Deciding when to perform each part of the workflow involves deciding where in the lifecycle (for example, what phase) to introduce the selected activities. For information on how to tailor the workflow for each of the RUP disciplines, see the usage notes for the reference workflows provided for each RUP discipline.

Some additional information that you may want to specify at this time is the timing and formality requirements of the work products at various points in the lifecycle. For example, in what phases is a work product created and/or or updated, and what is the required formality of the work product (for example, does it need a sign-off by the customer).

Make the Process Available to the Project Members

Purpose:

To make the project-specific process available to the project's members.

After the initial tailoring work is done, the resulting process needs to be made available to the project team in a consumable format.

One possibility is to make the process available via a web site that can either reside on a Web server on the organization's network, or be installed on each individual team member's computer. If the project members are connected to the network most of the time, then deploying to a Web server is recommended to avoid any overhead associated with updates to the process during the project lifecycle.

Maintain the Process

Although the bulk of the tailoring work is done in the early days of the project, it should be kept up-to-date continuously, as the project teams uncover obstacles and other issues in the process. As the process unfolds, lessons are learned during the process itself, which are used by the process engineer as feedback to improve the process. Assessments made during the project are also important input to improving the process.

Minor adjustments are typically handled by the project, and updates to the project-specific process are made as part of preparing the development environment for the upcoming iteration. These kind of process improvements will often lead to updates being made to the process-specific process (e.g, refinements to work product templates and guidelines). More complex issues are raised as change requests on the process.

One of the major benefits of iterative development is that it allows the project teams to gradually improve the way they develop software. We recommend that every project include process engineering micro-cycles consisting of the following steps :

Define process
Perform project work based on defined process
Assess your work
Refine process