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 to 10 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
So why have a process at all? A process enables successful practices to be repeated, and unsuccessful practices to be
dropped or improved. RUP in particular provides:
guidance on best practices
a set of tasks, roles, and work products 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
Many of the same RUP activities and artifacts are needed on both small and large projects - the differences are more in
terms of workproduct formats and the level of formality, detail, and effort applied to each task. 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 process.
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.
Using the Rational Method Composer (RMC), you can select and deselect RUP content
packages to perform a coarse tailoring of the process, and then do a finer tuning with process views, including adding
your own project-specific guidelines. Note that RMC includes a Small Project method configuration. This is a smaller
configuration of the RUP that includes "informal" templates and excludes guidance applicable to larger or more formal
projects. Small projects should start with this template and apply their own project-specific tailoring. For more
information on tailoring the RUP, see Concept: Tailoring RUP.
The Example: A Small Project Adopts RUP, gives an example for how a small project might
approach defining a process. Detailed guidance for defining and documenting a software development process for a
project is provided by Task: Tailor the Development Process for the Project .
Smaller projects in particular may wish to adopt practices and techniques associated with "Agile Processes". This is
discussed in Concept:
Agile Practices in RUP and in Whitepaper: Using the RUP for Small Projects: Expanding upon eXtreme Programming.