Concepts: RUP Tailoring
Topics
- Introduction
- Extend the RUP framework
- Create a RUP configuration
- Instantiate the configured process on the project
Introduction 
The Rational Unified Process framework constitutes guidance on a rich set of software engineering practices. It is applicable to projects of different size and complexity, as well as for different development environments and domains. This means that no single project will benefit from using of all of RUP. Applying all of RUP on a single project will likely result in an inefficient project environment, where teams will struggle to keep focused on the important tasks, and struggle to find the right set of information. Thus, we recommend that all projects tailor the RUP.
This is a high-level summary of the concept of RUP Tailoring, the goal of which is to provide appropriate and customized guidance on how to develop software. In general, process tailoring may happen at two levels :
- At the organizational level, where process engineers modify, improve or configure a common process to be used organization-wide. This takes into consideration issues such as the application domain, reuse practices, and core technologies mastered by the company. One organization can have more than one organization-wide process, each adapted to a different type of development. In some cases, the predefined classic RUP configuration serves as the organization-wide process. Tailoring at the organizational level is described in more detail in the Process Engineering Process (PEP) - a component of the Rational Process Workbench(TM) product.
- At the project level, where process engineers take the organization-wide process and further refine it for a given project. This level takes into consideration the size of the project, the reuse of company assets, the initial cycle ("green-field development") versus the evolution cycle, and so on. Process tailoring at the project level is described in more details in the Activity: Tailor the Process for the Project.
The rest of this paper is organized into three categories of process customization work :
- Extend the process framework by creating RUP plug-ins.
- Configure the process by selecting the relevant process components and plug-ins in the RUP framework.
- Instantiate the process by fine-tuning the configuration to fit the exact needs of a project.
Extend the RUP Framework
The RUP process framework is manifested in a process model defined using an UML based meta-model. This meta-model is compliant with Object Management Group's (OMG) Software Process Engineering Meta-model (SPEM), which is a UML profile for process modeling. The RUP Website that you are currently looking at, is produced from this process model. The goal of extending the RUP framework is to add additional process know-how to fit with the specific process needs of the development organization or individual projects, in areas where the coverage of the RUP process framework is deemed insufficient for the project.
The RPW enables the creation of RUP extensions using the RUP plug-in technology. Following the recommendations for this technology, the RUP framework can be extended in two ways. You either create a structural plug-in to extend the RUP process model, or you create extensions that will provide a development organization's relevant reusable assets to the project through thin plug-ins. The two different options are discussed below.
Sub-topics:
Extending the RUP by Creating Structural Plug-ins
A RUP plug-in is typically a fraction of a software development process describing a specific domain, technology, or platform. A structural plug-in is a process fraction that extends the RUP process model by adding process elements, such as roles, activities, artifacts, and disciplines. RUP Modeler(TM) is a tool component of RPW that supports the development of structural plug-ins.
Most structural plug-ins will be developed in process mature organizations
where the focus is on utilizing the process synergy between projects, especially
where several projects are developed over the same domain and technology, or
in similar development environments. We recommend that you spend some time looking
at existing plug-ins before a plug-in project is started, to avoid "reinventing
the wheel". The 
developerWorks:IBM
Sponsored RUP Plug-Ins contains a complete list of available plug-ins that
you can download and include in your RUP configuration.
A single project usually does not take on the task of creating a structural plug-in to the RUP, unless the project is large enough to justify the cost of the plug-in development within the budget of the project. A structural plug-in is similar to any reusable asset in the sense that you don't want to take the cost of making it reusable unless you see a reuse potential for it beyond the scope of the project.
Extending the RUP by creating thin plug-ins
Thin plug-ins differ from the above mentioned structural plug-ins in that they don't require any modeling. This is a mechanism for organizations to package their organizational assets, such as artifact templates, guidelines, examples and other reusable assets for consumption in the individual project.
The creation of such plug-ins is done at very low cost and, as such, is highly applicable to any sized organization and can usually be justified within the budget of one single project. The RPW product enables the creation of such an extension through the tool component RUP Organizer(TM). The resulting artifact is a plug-in that can be loaded into the RUP Builder product and included in any process configuration.
See the Tool Mentor: Packaging Project-specific Assets into Thin Plug-ins with RUP Organizer for further information.
Create a RUP configuration
Configuring the RUP is a matter of right-sizing the process to match the needs of a specific organization or individual project. It involves selecting the right set of process components and to provide appropriate views into this configuration to hide parts of the process irrelevant for certain user-groups.
Creating a RUP configuration involves making a series of decisions :
- Selecting relevant process components from the RUP framework.
- Eliminating unnecessary process elements.
- Adding company specific processes and relevant resources to help the production of project artifacts.
- Defining views into the configuration to support different stakeholders' perspectives on the process.
The RUP product comes with a process configuration tool called RUP Builder(TM) for supporting the nontrivial tasks listed above. It provides a set of predefined RUP configurations for specific project contexts. Select the predefined configuration closest to the characteristics of your project, and tailor it further by selecting and deselecting process components as appropriate. Each process component presented in RUP Builder has a description page where you can read about what process elements it contains, as well as guidance on why you should include it in your configuration.
If thin or structural RUP plug-ins have been created using the RPW product, these are typically loaded into the RUP Builder repository and selected as part of the configuration, and thus becoming an integral part of the resulting Website.
Further, projects will often require that views be defined on top of the configured process, to suppress unwanted process elements for given teams within the project. The developers, for example, don't necessarily want to see the same details as the project manager. The RUP Builder allows for creation of such views, for example based on roles. When the process components are selected and the views created, RUP Builder allows for automatic generation of the RUP Website. The resulting RUP Website contains only the selected components and will present the views as separate instances (or tabs) of the treebrowser.
We recommend that all projects start by creating and publishing their RUP configuration in RUP Builder. See Tool Mentor: Configure Process Using RUP Builder for further information.
Instantiate the configured process on a project
Instantiating a RUP configuration on a project means turning the configuration into a enactable process instance for the project. This process instance - also called the Project-Specific Process - is fine-tuned to fit the exact needs of the project.
If the produced configuration is accurate, the task of instantiating it on the project will be fairly light. However, since a RUP configuration is produced from a set of process components, and these components are comprised of process elements,
The work of instantiating the process can include :
- Defining which artifacts the project will produce, when in the lifecycle they are produced, and how the quality of these artifacts will be verified.
- Collecting and customize relevant guidelines, templates, and examples. Make these available through the process Website.
- Customizing the lifecycle model to fit the characteristics of the project.
- Producing a project Website that serves as the project's artifact repository. This project web will typically reference the underlying process Website tailored for the project.
The RUP has a notion of a development case for documenting decisions made when fine-tuning the process. A process engineer often uses the development case as a means of communicating process related issues with the project members. Thus, it is important to make this artifact available to all project members. The formatting options of a development case is discussed in Guideline: Development Case. One common approach is to develope it as a minimal set of web pages, and provide details in the underlying RUP configuration. Below is an illustration of how these artifacts can be positioned to achieve a high degree of visibility.
Example of positioning the Development Case artifact
The instantiated process serves as a direct input to the planning of the project.
