Scenario:
A Small Project Adopts RUP
Topics
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.
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.
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.
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.
| |
|