Topics
|
|
Additional Guidance:
Additional Concepts:
|
The key to achieving the delicate balance between delivering quality software
and delivering it quickly (the software paradox!) is to understand the essential
elements of the process and to follow certain guidelines for tailoring the process
to best fit your project's specific needs. This should be done while adhering
to the best practices that have been proven throughout the industry to help
software development projects be successful.
Small can refer to the number of people on the project, the length of the project,
or the amount of software being developed. For the purposes of this roadmap,
a "Small Project" is defined as a project with:
- 3 to10 people
- project duration less than one year.
A key characteristic of most small projects is a lower level of formality.
Although there are exceptions, the larger the number of people on the project
and the larger and more complex the product, the greater the need for formal
process. For example, if your project has a geographically distributed team
of 100 people, or is working simultaneously on multiple related products with
multiple customers and subcontractors, you require much more formal process
than a typical five-person team. Similarly, a missile guidance system requires
more formal artifacts than an inventory system upgrade.
So why have a process at all? A process enables successful practices to be
repeated while unsuccessful ones to be dropped or improved. RUP in particular
provides:
- guidance on best practices
- a set of activities, roles, and artifacts your process may need to consider
- with guidance on when these are needed
- lots of good detailed information that help you effectively apply the techniques
that you decide are appropriate for your project. For example, if you are
doing a UML design model, you find out what diagrams are appropriate and how
to structure the model. Further, if you use Rational tools, there's additional
guidance on how to use them effectively as part of the overall process.
- guidance on how to tailor the process to address specific process-related
problems. For example, if your project has a lot of changing requirements,
you may benefit from the guidance on how to effectively manage requirements.
Most of the RUP activities and artifacts are needed on a small project - the
differences are more in terms of artifact formats and the level of formality,
detail, and effort applied to each activity. For the purposes of this roadmap,
a "small project process" will focus on projects which require little
formality. Some characteristics of this small project process are as follows.
- The number of documents tends to be smaller, and less detailed. Instead
of detailed Risk Management Plans and Product Acceptance Plans, small projects
may devote a couple of paragraphs to these topics as part of the overall Software
Development Plan. The Test Plan for each iteration may be a few paragraphs
in the Iteration Plan.
- Small projects often start off with a minimum of software development tools.
As a project grows and succeeds (which is the objective of all successful
small projects!), it will be important to include effective tools to help
automate your team's implementation
of the best practices.
- Formal reviews may be replaced with informal meetings and discussions.
- Many of the artifacts may be captured informally. A risk list may be created
on a whiteboard, and status assessments may be a few paragraphs in an email.
To define a process for your small project, you should first review the following
RUP basics:
Then evaluate any existing process you may be following against these essentials,
and focus revisions on any weak areas. Many projects choose to incrementally
adopt new tools and process, and initially use only small parts of RUP.
Consider documenting your selected process in a Development
Case. To help small projects get started, an Example
Development Case for Small Projects has been provided which describes a
relatively informal process which can be used for many small projects. It includes
information such as:
- which optional activities and artifacts will be used, and which will be
dropped,
- the relative timing of activities for each phase,
- which tools will be used, and
- the level of formality to be applied.
If this example is a close match to your project's needs, you may wish to use
it as-is. Minor differences and additions can be described in the Software Development
Plan.
A Software
Development Plan Template for Small Projects is provided to help guide your
small project planning.
Consider holding a workshop to "kick-start" the project, as described
in the RUP guidelines under Development Case Workshop. This is an opportunity
to discuss how your team will use RUP, to show the team how to use the development
environment, and to get feedback from the team about how to improve the development
process. This is also a great opportunity for your group to start becoming a
team, working together toward a common goal.
Additional
Process Tailoring
Many projects, even small projects, will require more or different activities
and artifacts than those described in the example development case for small
projects. For additional guidance on developing and tailoring a process, you
may wish to review the Environment
Discipline. In particular, the activities and guidelines associated with
Artifact: Development Case.
Smaller projects in particular may wish to adopt practices and techniques associated
with "Agile Processes". This is discussed in Roadmap:
Agile Practices in RUP and in White Paper:
Using the RUP for Small Projects: Expanding upon eXtreme Programming.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Overview >
Roadmaps >
