Purpose
  • To right-size the software development process according to the specific needs of the project
  • To provide a relevant and accessible process description for the members of the project
Role:  Process Engineer 
Frequency: The bulk of the work takes part at the onset of the project. May repeat as necessary in any iteration
Steps
Input Artifacts:  Resulting Artifacts: 
Tool Mentors: 
More Information: 

Workflow Details: 

Analyze the Project To top of page

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 development 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 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.

Process ceremony varies a lot in different development organizations. Some are very process mature, and have dedicated process groups to look after the definition and improvements of the development process throughout the organization. Others are concerned with project-specific tailoring only. These projects will typically start with one of the predefined configurations that come with the RUP product, and from there instantiate the process for every project. The approach taken to tailor the process for the project, depends heavily on several factors, for instance :

  • The development organization's process maturity.
  • The size of the project in terms of calendar time and number of development resources.
  • The project members previous exposure to similar processes.
  • The formality requirements of the project.

See Guideline: Process Discriminants for details.

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 upcoming project needs to be made. This is further discussed in the next section Define the Scope of the Process. See also Artifact: Development-Organization Assessment for further details.

Define the Scope of the Process To top of page

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. Which 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 Concepts: 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 Concepts: 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.

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 Concepts: Implementing a Process in a Project. 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 end-users that the delivered product does not meet their needs.

The tradeoffs made should be documented to communicate the scoping decisions to external stakeholders. When creating the configuration in the RUP Builder product, these decisions can be documented as a description of the configuration and will surface in the published Website. You can also decide to document this in the project's Development Case under the section titled "Scope".

Extend the Process Framework (optional) To top of page

Purpose:  To add additional process know-how to the project-specific process, in areas where the coverage in the RUP process framework is deemed insufficient for the project.

One of the strengths of the RUP process framework is that it is applicable to a wide range of projects and environments. But this may at the same time be perceived as a disadvantage too, because the process description tends to become a bit too generic. The RUP plug-in technology is designed to overcome some of these issues by allowing tool or technology vendors and individual companies to create more specific process descriptions through plug-ins. You will find an up-to-date list of plug-ins available for download in the http://www.ibm.com/developerworks/rational/rupcenter -- This hyperlink in not present in this generated website RUP section of developerWorks®: Rational®.

The Rational Process Workbench(TM) (RPW) product 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.

Creating a RUP plug-in (structural) 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.

See Guideline: RUP Tailoring, section Extend the RUP, for more information.

Configure the Process To top of page

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

The RUP framework is built up of a set of process components and plug-ins, each component contains a set of related process elements. Creating a RUP configuring means selecting between a set of process components. Selecting the right set of components 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 more detailed information on configuring RUP, refer to

Prepare the Process for the Project To top of page

Purpose:  To define how the configured process is enacted in the project.

A process description configured for a project is often not at the level of details ready to be enacted. For example, the process defines a set of artifacts to use based on a selection of relevant process components (as described in the previous section Create a RUP Configuration), but it does not specify timing and formality requirements of the artifacts for this particular project. Prescriptive guidelines and partially instantiated artifact templates are also considered to be part of an instantiated project-specific process. The required effort to perform this step is highly dependent on the precision of the configured process. Any such deviation from the underlying process should be justified and documented as part of the project-specific process.

The work of instantiating the configured is described in detail in the following activities, all performed by the Process Engineer :

Introduce the Process to the Project Members To top of page

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 published into a consumable format. The RUP Builder product provides a means to publish the configured process resulting in a RUP Website that contains only the selected process components and resources. See Tool Mentor: Publish Process Configuration Using RUP Builder for tool specific guidance. The Process Engineer needs to work with the Project Manager to make the project-specific process public, and decide on how to educate the project members. This can vary from an informal 2 hour presentation to more formal training, depending on the size of the project and the project members' familiarity with similar development processes. Every significant update of the process during the project lifecycle, should be re-launched to the project, focusing on the changes.

The Website for the project-specific process can be published to a Web server on the organization's network, or installed on each individual team member's computer. If the project members are connected to the network most of the time, then deploying the RUP Website to a Web server is recommended to avoid any overhead associated with updates to the process during the project lifecycle.

See Activity: Launch Development Process for further information.

Maintain the Process To top of page

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. Assessments made during the project are 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 artifacts, such as development case, project-specific guidelines and project-specific templates. More complex issues are raised as change requests on the process. This is usually handled by a process group outside the boundaries of the project, that has the responsibility of the software development process on an organizational basis.

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

The Process Engineering Process within the Rational Process Workbench product contains information on Process Improvement in an organizational setting.



© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13