As you sort through the many work products, tasks, and roles in the Rational Unified Process (RUP), you may ask
yourself these questions:
Do I need this one?
How do I sort through all of these items to determine which ones I need for my project?
Isn't it obvious that the RUP is only for big projects?
The topic of tailoring addresses all of these questions.
A software project's purpose is to produce a product. A good process enables the project to produce a product that
meets the needs of its stakeholders, on time and within budget. For additional information, see artifact: Product.
The key to a good process is in tailoring it to be as simple as possible, while upholding the Key Principles.
The guidelines included here should be considered when tailoring a process. More detailed guidance is provided in Concept: Tailoring RUP.
A common problem for many projects is that they often focus heavily in one particular area, to the extent that they get
bogged down with the details of that particular area before making sure that they have a good idea of what "key"
elements are involved in the whole process lifecycle of producing a quality product.
It's usually better to address all key elements of a process in a lightweight manner before focusing heavily on any one
particular problem area.
Once the framework for a quality software process is in place, a project can effectively focus on a particular area
that has been identified as a major contributor to their problems. This selection is based on identifying and
prioritizing risks to the project, and determining early mitigation strategies for those identified risks.
Do not include tasks and work products that cannot be clearly justified
The well-intentioned project manager or process engineer may have a large wish list of nice-to-have metrics, controls,
reports, and so on. However, tasks and work products cost time and money. Some of these costs, such as daily
interaction with the environment toolset, may or may not be visible, but simply get folded into lower productivity on
You must distinguish critical process needs from the wish list and determine whether the benefits outweigh the cost.
Shield your developers from the process
You probably have highly trained staff with valuable skills in designing, implementing, and testing. Don't have them
spend hours each week filling out forms, enhancing documentation, or fighting with unwieldy tools. If these tasks are
required, consider having them done by qualified support staff.
Minimize formal intermediate work products
The format of intermediate work products-those work products not intended for the final product-is not as important as
the task and thought needed to produce them. It doesn't matter what they look like, or what tools you use to build
them, provided they serve their purpose. As Dwight D. Eisenhower said, "The plan is nothing; the planning is
One trap that's easy to fall into is formalizing work products far too soon. Early versions of work products
often evolve quickly and remain fluid for some time as different representations while their implications are explored.
Formal documentation can impede this process; you can waste a lot of time polishing a work product that's largely
expendable. Hand-drawn diagrams and simple descriptions on index cards are often sufficient in the early stages of a
work product and, for some projects, may be all that's required.
A work product may be tailored so it can be maintained in any form. For example, the Vision document may be captured as
a Web page, the Project Plan may be captured as a Microsoft Project file, and the Risk List may be captured as a Rational RequisitePro requirement type.
Generate when possible
Some projects spend a lot of time populating templates of formal documents by manually cutting and pasting
information. Instead, consider generating required documents from the source, using tools such as Rational SoDA, or negotiate a simpler way of providing the same
information, such as using Rational Rose Publisher to generate a Web-based design model.
In many cases, you can skip a work product altogether because the information is implicitly provided in the
environment. For example, rather than generate the section of the Requirements Management Plan that lists attributes of
requirements types, you may want to only provide the tailored Rational RequisitePro project with the applicable
requirements types and traceability, and then walk through it with the interested parties. Another example is to
provide a read-only version of the Microsoft Project files to the interested parties, rather than duplicating graphics
into a separate Software Development Plan.
Use the Web
A useful work product is one that communicates valuable information. This information should be at the fingertips
of those who need it. Web technology is an excellent mechanism for this purpose. If the requirements, design, and
implementation are available on the Web, there's no need to generate large sets of quickly obsolesced paper
Use integrated tools
Select tools that fit the process and tailor the process to fit the tools. The desired results are an easy-to-use
process and toolset. Integrated tools generally provide greater consistency, and more informative metrics and
reports than tools that are not integrated.
Regularly revisit the process to refine and reduce its complexity. If your staff isn't convinced that each step in the
process provides added value for the end product, then the process is probably broken.
Tailor while retaining practices
The RUP encourages tailoring. However, tailoring is not a license to bypass the process altogether. The
essentials of the RUP are embodied in its practices. Follow the spirit of these practices when tailoring the tasks and
work products to fit your needs.