Scenario: A Small Project Adopts RUP

Topics

Project Overview To top of page

The following describes a scenario for a project of ABC Company, called Project X. Project X is a team consisting of a project manager, Jill, and four programmers, Angus, David, Susan, and Philip.  The duration of the project is four months. 

Jill is considering using the RUP as the basis for her project's software development process. She installs the RUP, which by default installs the "Classic RUP" process configuration. She reviews the parts of Classic RUP relevant to tailoring a process for a project.

She begins by evaluating the process needs for the project, in consultation with the team. Her conclusions are as follows.

  • The existing process and tools for configuration management are working well, so this aspect of the process can remain unchanged.
  • The team has some experience with use cases and component architectures, but could use more guidance in these areas.
  • The project would benefit from an iterative development approach, as a means of quickly driving down key project risks.
  • The stakeholders have good informal working relationships with the development team, and there is no need for formal contracts or reviews. The stakeholders have ongoing visibility during development.  The team is highly skilled and disciplined, and has shown in the past to produce quality products without much formal process.
  • Given the short time-frame of the project, only minor changes will be made to the toolset.
  • A separate parallel activity will be initiated to investigate tool benefits, re-use opportunities, and to further refine the process for future projects.

Jill then takes on the task of tailoring an appropriate process for the team to follow.

General Tailoring To top of page

Jill launches RUP builder and selects the the Small Project template configuration as a starting point. She selects and de-selects some components and plug-ins to perform a coarse configuration of the process. For example, she de-selects the process component "Database Design", as the team does not intend to do any data modeling on this project.

The resulting process is reasonably close to what the project needs, but not quite. Jill refines the process further by adding project-specific pages to the process views, including:

  • guidelines for the tools to be used on the project
  • guidelines re-used from a previous similar project, including Design Guidelines and Configuration and Change Management Guidelines
  • guidelines for review and assessment.

She adds an "Introduction to the Process X Process" page to the Getting Started view, where she describes the basic philosophy of the configured process. For example, she states that the included templates are intended to guide content, but the format is optional. She also indicates where current versions of key project artifacts will be located.

She then saves the configuration as "ABC Project X", and publishes it.

Roles and LifecycleTo top of page

Project X has a small team, so each person is responsible for a variety of RUP roles. Jill describes each person's reponsibilities in the Software Development Plan. For example, on Project X, Jill is responsible for the Project Manager and Process Engineer roles.

She also describes the lifecycle of the project in the Software Development Plan, including the phases, iterations, and key milestones.

Review To top of page

Jill provides a draft of the configured RUP, Development Case, and Software Development Plan to the team and other stakeholders for review. The team begins to follow the process. Some mistakes are made, and the process is refined. In the end, the project is successful, and the team has an appropriately tuned process that can be applied on future projects.

Rational Unified Process   2003.06.13