|Task: Tailor the Development Process for the Project ||
|This task is where a development process is customized to meet the specific needs of the project.
The purpose of this task is to:
Right-size the software development process according to the specific needs of the project.
Provide enough relevant process guidance for the project members to do their jobs efficiently and with acceptable
Provide a relevant and accessible process description for the members of the project.
Analyze the Project
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
Define the Scope of the Tailoring Effort
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
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
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
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
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
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
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
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 :
No matter what level of tailoring is performed, it is important to capture the results of (and possibly the
rationale for) the tailoring effort. In addition, if the process being tailored is intended to be tailored
again (for example, the process is being tailored for an entire organization and the resulting organizational
process is intended to be tailored for each project), then it is also important to develop guidelines on how to
tailor the tailored development process. Such tailoring decisions and recommendations can be captured in a separate
document, or as an integral part of the development process. For more information on tailoring levels, see Concept: Tailoring RUP.
The Software Development Plan and organization has a major impact on
the Development Process, and vice versa. The tailoring of the process
must be coordinated with the development of the project plan. For example, if the project decides to use a different
set of phases than in the Rational Unified Process (RUP), this is something that needs to be captured in the tailored
development process. Also, once the development process has been tailored, it must be instantiated into an
enactable project plan. For more information on project planning, see Task: Plan Phases and Iterations and Task: Develop Iteration Plan.
When tailoring the process, we recommend that you don't tailor the entire process at once. Instead, focus on the
discipline that is to be applied in the project next. For more information on an iterative approach to
process implementation, see Concept: Implementing a Process in a Project.
An assessment of the development organization, if available, indicates
which areas the development organization as a whole needs to focus on. An informed decision on which of the identified
improvement areas should be targeted for the project needs to be made. This decision directly affects the scope of the
Tailoring the process for a project should be treated as a project in its own right, with separate plans, budget and
control mechanisms. You should define a business case for it, based on return-on-investment analysis. The actual
development of the plug-in will benefit from following the lifecycle and disciplines in the RUP. We recommend that you
try out the main ideas behind the plug-in on a real project before you start the project to develop the plug-in.
A Development Case can be used to document tailoring decisions
(for example, what parts of RUP were tailored and why), as well as guidelines for future tailoring efforts. Depending
on the level of tailoring being performed, the development case can be included as part of the Development Process itself, or it may just be used to plan, drive,
and document the tailoring effort. For more information on the tailoring levels, see Concept: Tailoring RUP.
|There are a number of different levels of tailoring available for the RUP. For more information, see Concept: Tailoring RUP.
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.