Rational Unified Best Practices (RUP)

If you are an application development project manager, or if you are looking to become one, you
will very likely be asked if you have ever used RUP, or Rational Unified Process. For the
uninitiated, RUP can seem very much like a mysterious “black box,” or a magic potion from
which the perfect piece of software will flow. In fact, there are a set of RUP Best Practices
defined in the RUP literature which give some easy-to-understand guidelines on what it takes to
implement RUP successfully. In this article, I will provide some background on each best
practice, in the context of current RUP adoption, as well as my own personal experience using
RUP to manage software development projects. Each best practice is accompanied by
suggestions on how you as a project manager can implement or integrate these RUP best
practices into your own project.

RUP Best Practice #1: Develop iteratively.

Iterative development came about because too many software projects were being delivered with
the perception of poor quality, which is generally the result of poor testing practices. In addition,
too many bugs, or defects, were being found late in the system development life cycle. The
problem is that if design defects are being discovered during the UAT (user acceptance testing)
phase, this is far too late in the cycle to give adequate attention to addressing the bugs without
slipping the delivery date.

An iteration is defined as a distinct sequence of activities with an established plan and evaluation
criteria, resulting in an executable operable release. This methodology makes it possible to
develop a pre-defined set of working software in iterations. The RUP initiation, elaboration,
construction, and transition phases can all be iterated.

One or more iterations can occur with each of the four RUP phases, each iteration concluding
with a milestone. In the inception phase, the milestone is an idea. In elaboration, the milestone is
the architecture. In construction, the milestones are the internal executable releases. In the
transition phase, the milestone is the finished software product.

For the Project Manager: The project manager must guide the project team to divide a
development project into manageable RUP iterations. At each stage of the resulting iterations,
the project manager needs to identify possible risks and take action during the current iteration to
try to remediate that risk. Lowering the project’s overall risk profile is preferable to carrying the
risk over to the next iteration.
RUP Best Practice #2: Manage requirements.

The effective management of requirements is the key to building a software application product
that genuinely meets user needs. Generally, managing requirements effectively is important
whether RUP is used or not. However, RUP provides a tried and tested framework that defines
how requirements are managed.

In RUP, the use case is an essential tool for capturing requirements. The use case is written in the
form of scenarios that describe all the services that can be offered to users and to other systems,
in a meaningful and complete manner. Once requirements are documented in use cases, they can
be organized and prioritized according to importance, ability to deliver, cost, and other assorted
criteria to determine if the requirement is needed for the final product.

For the Project Manager: One of the project manager’s highest priorities is to get stakeholders
involved during the earliest elaboration phases. Then as requirements change, the team must
evaluate the impact of the change, and decide whether or not a certain change should be
implemented. The benefit of RUP is that change is expected, and the team should understand that
requirements must always be reassessed. The project manager must constantly be
communicating any requirements changes to all stakeholders and participants, as this will be of
utmost importance to gaining final acceptance for each iteration and ultimately the final product.

RUP Best Practice #3: Use component architectures.

RUP development is based on the use and reuse of component modules or subsystems that serve
a certain function. The use of component architectures lessens complexity as well as the relative
size of the application. A system that reuses well-tested architectural components is less prone to
variability and more robust as well. The use of component based architectures usually results in
fewer dependencies between code modules and provides more flexibility when building
additional functionality and feature sets during the next iteration.

During RUP inception and elaboration, various architectural elements must be defined and
baselined. There are four distinct architectures in RUP: 1) business-specific, 2) application-
specific, 3) middleware-specific, and 4) system software-specific. The system software refers to
more infrastructure-related components such as operating systems. Of the four architectures, the
business-specific architecture is the one that may most easily be eliminated.

For the Project Manager: The project manager can greatly influence the ability of a team to move
toward component-based architectures. First, the project needs to engage architects and
developers who are well-versed in RUP, and component infrastructures such as Java, CORBA,
COM, and .NET. The project manager also must ensure that the project budget takes into
account the purchase of any development tools that will be needed. Often these tools may be free
or open-source, but they still need to be purchased when used at an enterprise level.

RUP Best Practice #4: Model visually.

Unified Modeling Language, or UML, has become a fundamental tool for effective object-
oriented programming, and the construction of component architectures as mentioned above.
UML functions as a common language that business analysts, web designers, and developers can
all understand. A software application or platform can be expressed through various UML
models with accompanying diagrams as an output, for instance, the Use Case Model, or
requirements model, has use case diagrams as an output. Other common types of modeling
diagrams that result from the use of UML models are class diagrams, object diagrams, sequence
diagrams, collaboration diagrams, state diagrams, activity diagrams, component diagrams, and
deployment diagrams. The advantage of using a platform-based modeling tool versus a stand-
alone tool is that it is then possible to generate pseudocode to aid programming efforts based on
the model.

For the Project Manager: Just as project managers have project management best practices in the
PMBOK, RUP can be considered as a collection of best practices for the software developer.
Any project manager involved in software development projects should take the time to become
familiar with the terminology, models, and phases of RUP and UML.

The project manager in a RUP-based development organization should also spend some time
first developing the documentation store for the project. The use of RUP and UML generates a
large amount of documentation, diagrams, and other artifacts. The project team – analysts,
developers, infrastructure staff, and project managers – must be given an organized structure in
which to store documents, otherwise the data store can become completely unsearchable, and
thus unusable. Logical organizational breakdowns can include functions, phases, iterations, and
modules.

The project manager needs to realize that the high-level documentation structure created for a
project will probably stay with the project until the end. Depending on the tool, once the
structure is built, it can be very difficult to reorganize, especially for a longer multi-year project.

RUP Best Practice #5: Continuously verify quality.

Like other RUP processes, quality assessment is meant to be built into every activity and process
in the development cycle. This means that testing is done throughout the project. The earlier a
defect is found, the easier it will be to fix. An even worse situation occurs if a defect is not
found, and developers continue to build on top of that defective component. Then when the
defect is finally found and fixed, a whole new round of development and testing has to be done
with the upstream or downstream components.

Defects should be collected and tracked in a database defect or bug tracking system such as
Rational ClearQuest or Mercury Test Director.

For the Project Manager: The project manager should always build in a UAT (user acceptance
test) period near the end of each of the construction iterations. This ensures that the project
receives customer acceptance at the critical step before the development team moves to the next
development milestone. One person or group must be responsible for keeping track of issues
discovered during UAT so that they can be addressed either by fixing the problem, negotiating
an agreement to leave the problem as is, or perhaps something in between. A lingering issue
discovered during UAT may be the same issue that keeps a project stakeholder from signing off
on the project.

Besides functional QA testing, UAT or customer acceptance testing, and performance and load
testing, there are a few other tests which many development organizations now require an
application to pass before allowing it to move into production status. Application security
testing, or penetration testing, is now almost mandatory for any software application, especially
one that is delivered via the internet. Some organizations also require that the application
database pass a series of checks to make sure that the database has been constructed according to
data architecture standards such as data consistency, and database object naming. A usability test
can be very effective in finding and correcting user interface problems before the end user
discovers them in UAT; usability testing is best accomplished with an outside vendor. Finally,
depending on the application, the project manager may also have to schedule time to perform
integration testing and end-to-end testing.

It is important for any application development project manager to find out what type of testing
will be required for their application and what resources will be available to perform the tests,
and whether the test must be done from within the project team or by a separate external party.
Often these departments are scheduled out months in advance and it may require the engagement
of a third party testing company to complete the test on time. In addition, the project team should
assign a knowledgeable person to take the lead during these different tests, which at times
become mini-projects in themselves; this can be the project manager if he or she has the
knowledge and bandwidth to do so.

RUP Best Practice #6: Manage change.

One final RUP best practice is to effectively manage changes to software during the iterative
development process. One of the key principles of change management in RUP is to ensure that
changes have no negative results – to this end, the RUP process provides excellent guidelines on
how to control, track, and monitor changes. One very important aspect of RUP is that each
developer should be given his or her own secure development space so that they are isolated
from changes made in other workspaces. The integration of different code elements occurs later.

In RUP, change management does not apply to just the code itself, otherwise known as
configuration management. The IBM Rational toolkit includes a widely used code management
application called ClearCase for this purpose. In RUP, change management should also be
applied to all other project artifacts and documents, such as requirements documents, use cases,
iteration plans, and test plans.

For the Project Manager: The RUP project manager needs to be an effective change manager.
Both RUP and the PMBOK highlight change management as an important discipline. In a
software development project, the project manager can try to enforce change management to
track different components in the development process but this can be difficult as they may be
considered within the scope of the development manager rather than the project manager. In
addition, many developers do not want to take the time to log entries into a spreadsheet or
tracking system. It is best to employ a separate tool or assign the role of controlling component
changes to certain people.