Guidelines:
Tailoring the Process
Topics
As you sort through the many artifacts, activities, 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.
The key to a good process is in tailoring it to be as simple as possible,
following a best practices approach.
The guidelines included here should be considered for tailoring a process. More detailed guidelines are provided in
Concepts:
Implementing a Process in a Project and in Activity:
Develop Development Case.
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 activities and artifacts 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,
activities and artifacts 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 standard tasks.
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 activities are required, consider having them done by qualified support staff.
Minimize formal intermediate artifacts
The format of intermediate artifacts—those artifacts
not intended for the final product—is not as important as the activity
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 everything.”
One trap that's easy to fall into is formalizing artifacts far too
soon. Early versions of artifacts 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 an artifact that's largely expendable. Hand-drawn diagrams and simple
descriptions on index cards are often sufficient in the early stages of an
artifact and, for some projects, may be all that's required.
An artifact 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 an artifact 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 artifact 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 documentation.
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 best 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 best practices. Follow the
spirit of these best practices when tailoring the activities and artifacts to
fit your needs.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Artifacts >
Environment Artifact Set >
Development Case >
Guidelines >
