Anda di halaman 1dari 21

Rational Unified Process

From Wikipedia, the free encyclopedia

(Redirected from IBM Rational Unified Process)
Jump to: navigation, search

The Rational Unified Process (RUP) is an iterative software development process framework
created by the Rational Software Corporation, a division of IBM since 2003.[1] RUP is not a
single concrete prescriptive process, but rather an adaptable process framework, intended to be
tailored by the development organizations and software project teams that will select the
elements of the process that are appropriate for their needs. RUP is a specific implementation of
the unified process.


 1 History
 2 Rational unified process topics
o 2.1 RUP building blocks
o 2.2 Four project life-cycle phases
 2.2.1 Inception phase
 2.2.2 Elaboration phase (Ortner)
 2.2.3 Construction phase
 2.2.4 Transition phase
o 2.3 The IBM Rational Method Composer product
o 2.4 Certification
o 2.5 Six best practices
 3 See also
 4 References
 5 Further reading
 6 External links

Rational Software originally developed the rational unified process as a software process
product. The product includes a hyperlinked knowledge-base with sample artifacts and detailed
descriptions for many different types of activities. RUP is included in the IBM Rational Method
Composer (RMC) product which allows customization of the process.

Philippe Kruchten, an experienced Rational technical representative was tasked with heading up
the original RUP team. This journey began with the creation of the Rational Objectory Process
(ROP) in 1996, when Rational acquired the Objectory Process that had been written by Ivar
Jacobson and company. This was renamed Rational Unified Process (RUP) in subsequent
releases, in part to align the name with that of the Unified Modeling Language.

These initial versions combined the Rational Software organisation's extensive field experience
building object-oriented systems (referred to by Rational field staff as the Rational Approach)
with Objectory's guidance on practices such as use cases, and incorporated extensive content
from Jim Rumbaugh's Object Modeling Technology (OMT) approach to modeling, Grady
Booch's Booch method, and the newly released UML 0.8.[2][3]

To help make this growing knowledge base more accessible, Philippe Kruchten was tasked with
the assembly of an explicit process framework for modern software engineering. This effort
employed the HTML-based process delivery mechanism developed by Objectory. The resulting
"Rational Unified Process" (RUP) completed a strategic tripod for Rational:

 a tailorable process that guided development

 tools that automated the application of that process
 services that accelerated adoption of both the process and the tools.

This guidance was augmented in subsequent versions with knowledge based on the experience of
companies that Rational had acquired.

In 1997, a requirements and test discipline were added to the approach, much of the additional
material sourced from the Requirements College method developed by Dean Leffingwell et al. at
Requisite, Inc., and the SQA Process method developed at SQA Inc., both companies having
been acquired by Rational Software.

In 1998 Rational Software added two new disciplines:

1. business modeling, much of this content had already been in the Objectory Process
2. a Configuration and Change Management discipline, sourced through the acquisition of
Pure Atria Corporation.

These additions lead to an overarching set of principles that were defined by Rational and
articulated within RUP as the six best practices for modern software engineering:

1. Develop iteratively, with risk as the primary iteration driver[4]

2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes

These best practices were tightly aligned with Rational's product line, and both drove the
ongoing development of Rational's products, as well as being used by Rational's field teams to
help customers improve the quality and predictability of their software development efforts.
Additional techniques including performance testing, UI Design, data engineering were included,
and an update to reflect changes in UML 1.1.

In 1999, a project management discipline was introduced, as well as techniques to support real-
time software development and updates to reflect UML 1.3

Between 2000 and 2003, a number of changes introduced guidance from ongoing Rational field
experience with iterative development, in addition to tool support for enacting RUP instances
and for customization of the RUP framework. These changes included:

1. the introduction of concepts and techniques from approaches such as eXtreme

Programming (XP), that would later come to be known collectively as agile methods.
This included techniques such as pair programming, test-first design, and papers that
explained how RUP enabled XP to scale for use on larger projects.
2. a complete overhaul of the testing discipline to better reflect how testing work was
conducted in different iterative development contexts.
3. the introduction of supporting guidance - known as "tool mentors" - for enacting the RUP
practices in various tools. These essentially provided step-by-step method support to
Rational tool users.
4. automating the customization of RUP in a way that would allow customers to select parts
from the RUP process framework, customize their selection with their own additions, and
still incorporate improvements in subsequent releases from Rational.

IBM acquired Rational Software in February 2003.

In 2006, IBM created a subset of RUP tailored for the delivery of Agile projects - released as an
OpenSource method called OpenUP through the Eclipse web-site.[5]

Rational unified process topics[edit]

RUP building blocks[edit]

RUP is based on a set building blocks and content elements, describing what is to be produced,
the necessary skills required and the step-by-step explanation describing how specific
development goals are to be achieved. The main building blocks, or content elements, are the

 Roles (who) – A role defines a set of related skills, competencies and responsibilities.
 Work products (what) – A work product represents something resulting from a task,
including all the documents and models produced while working through the process.
 Tasks (how) – A task describes a unit of work assigned to a Role that provides a
meaningful result.

Within each iteration, the tasks are categorized into nine disciplines:

 Six "engineering disciplines"

o Business modelling
o Requirements
o Analysis and design
o Implementation
o Test
o Deployment
 Three supporting disciplines
o Configuration and change management
o Project management
o Environment

Four project life-cycle phases[edit]

RUP phases and disciplines.

The RUP has determined a project life-cycle consisting of four phases. These phases allow the
process to be presented at a high level in a similar way to how a 'waterfall'-styled project might
be presented, although in essence the key to the process lies in the iterations of development that
lie within all of the phases. Also, each phase has one key objective and milestone at the end that
denotes the objective being accomplished. The visualization of RUP phases and disciplines over
time is referred to as the RUP hump chart.

Inception phase[edit]

The primary objective is to scope the system adequately as a basis for validating initial costing
and budgets. In this phase the business case which includes business context, success factors
(expected revenue, market recognition, etc.), and financial forecast is established. To
complement the business case, a basic use case model, project plan, initial risk assessment and
project description (the core project requirements, constraints and key features) are generated.
After these are completed, the project is checked against the following criteria:

 Stakeholder concurrence on scope definition and cost/schedule estimates.

 Requirements understanding as evidenced by the fidelity of the primary use cases.
 Credibility of the cost/schedule estimates, priorities, risks, and development process.
 Depth and breadth of any architectural prototype that was developed.
 Establishing a baseline by which to compare actual expenditures versus planned

If the project does not pass this milestone, called the life cycle objective milestone, it either can
be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration phase (Ortner)[edit]

The primary objective is to mitigate the key risk items identified by analysis up to the end of this
phase. The elaboration phase is where the project starts to take shape. In this phase the problem
domain analysis is made and the architecture of the project gets its basic form.

The outcome of the elaboration phase is:

 A use-case model in which the use-cases and the actors have been identified and most of
the use-case descriptions are developed. The use-case model should be 80% complete.
 A description of the software architecture in a software system development process.
 An executable architecture that realizes architecturally significant use cases.
 Business case and risk list which are revised.
 A development plan for the overall project.
 Prototypes that demonstrably mitigate each identified technical risk.
 A preliminary user manual (optional)

This phase must pass the lifecycle architecture milestone criteria answering the following

 Is the vision of the product stable?

 Is the architecture stable?
 Does the executable demonstration indicate that major risk elements are addressed and
 Is the construction phase plan sufficiently detailed and accurate?
 Do all stakeholders agree that the current vision can be achieved using current plan in the
context of the current architecture?
 Is the actual vs. planned resource expenditure acceptable?

If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned.
However, after leaving this phase, the project transitions into a high-risk operation where
changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is the system architecture.

Construction phase[edit]

The primary objective is to build the software system. In this phase, the main focus is on the
development of components and other features of the system. This is the phase when the bulk of
the coding takes place. In larger projects, several construction iterations may be developed in an
effort to divide the use cases into manageable segments that produce demonstrable prototypes.

This phase produces the first external release of the software. Its conclusion is marked by the
initial operational capability milestone.

Transition phase[edit]

The primary objective is to 'transit' the system from development into production, making it
available to and understood by the end user. The activities of this phase include training the end
users and maintainers and beta testing the system to validate it against the end users'
expectations. The product is also checked against the quality level set in the Inception phase.

If all objectives are met, the product release milestone is reached and the development cycle is

The IBM Rational Method Composer product[edit]

The IBM Rational Method Composer product is a tool for authoring, configuring, viewing, and
publishing processes. See IBM Rational Method Composer and an open source version Eclipse
Process Framework (EPF) project for more details.


In January 2007 the new RUP certification examination for IBM Certified Solution Designer -
Rational Unified Process 7.0 was released which replaces the previous version of the course
called IBM Rational Certified Specialist - Rational Unified Process.[6] The new examination will
not only test knowledge related to the RUP content but also to the process structure elements.[7]

To pass the new RUP certification examination, a person must take IBM's Test 839: Rational
Unified Process v7.0. You are given 75 minutes to take the 52 question exam. The passing score
is 62%.[8]

Six best practices[edit]

Six best practices as described in the rational unified process is a paradigm in software
engineering that lists six ideas to follow when designing any software project to minimize faults
and increase productivity. These practices are:[9][10]

Develop iteratively
It is best to know all requirements in advance; however, often this is not the case. Several
software development processes exist that deal with providing solution on how to
minimize cost in terms of development phases.
Manage requirements
Always keep in mind the requirements set by users.
Use components
Breaking down an advanced project is not only suggested but in fact unavoidable. This
promotes ability to test individual components before they are integrated into a larger
system. Also, code reuse is a big plus and can be accomplished more easily through the
use of object-oriented programming.
Model visually
Use diagrams to represent all major components, users, and their interaction. "UML",
short for Unified Modeling Language, is one tool that can be used to make this task more
Verify quality
Always make testing a major part of the project at any point of time. Testing becomes
heavier as the project progresses but should be a constant factor in any software product
Control changes
Many projects are created by many teams, sometimes in various locations, different
platforms may be used, etc. As a result, it is essential to make sure that changes made to a
system are synchronized and verified constantly. (See Continuous integration).

Agile Modeling (AM) is a practices-based software process whose scope is to

describe how to model and document in an effective and agile manner. The
practices of AM should be used, ideally in whole, to enhance other, more complete
software process such as eXtreme Programming (XP), the Rational
Unified Process (RUP), Disciplined Agile Delivery (DAD), and the
Enterprise Unified Process (EUP) to name a few. These processes cover a
wider scope than AM, in the first three cases the development process and in the
fourth the full software process including both development and production.
Although these processes all include modeling and documentation activities, in
one form or the other, there is definitely room for improvement. With DAD the
practices of AM are built right into the framework, with XP the modeling processes
should be better defined, and with RUP modeling processes could definitely stand
to be made more agile.

In this article I explore in detail how AM can be used in conjunction with the
various instantiations of the Unified Process (UP), including but not limited to the
RUP and the EUP. To do so, I discuss

 How modeling works in the Unified Process

 How good is the fit between AM and RUP?
 Case study
 Adopting AM on an UP project
 How does this work?
 References and Suggested Reading

How Modeling Works in the Unified Process

All efforts, including modeling, is organized into disciplines (formerly called
workflows) in the UP and is performed in an iterative and incremental manner. The
lifecycles of the AUP and EUP are presented in Figure 1 and Figure 2
respectively. The AUP is a subset of the RUP and the EUP a superset of the it. I
like to say that the UP is serial in the large and iterative in the small. The six
phases of the EUP clearly occur in a serial manner over time, at the beginning of
an UP project your focus is on project initiation activities during the Inception
phase, once your initial scope is understood your major focus becomes
requirements analysis and architecture evolution during the Elaboration phase,
then your focus shifts to building your system during the Construction phase, then
you deliver your software during the Transition phase, you operate and support
your software in the Production phase, and finally you remove it from production
during the Retirement phase. However, on a day-to-day basis you are working in
an iterative manner, perhaps doing some modeling, some implementation, some
testing, and some management activities.

In the RUP there are three disciplines[2] that encompass modeling activities for a
single project - Business Modeling, Requirements, and Analysis & Design - and
the EUP adds Enterprise Business Modeling and Enterprise Architecture.
The AUP on the other hand, being a subset of the RUP, combines the three
modeling disciplines into a single Model discipline. All six disciplines are described
in Table 1. For a description of potential artifacts to create during these disciplines
visit Agile Models Distilled.
Figure 1. The lifecycle of the Agile Unified Process (AUP).

Figure 2. The lifecycle for the Enterprise Unified Process (EUP).

Table 1. The Modeling Disciplines of the Unified Process.
Discipline Purpose
The purpose of this discipline is to model the business context,
the scope, of your system. Common modeling activities include
the development of:

 A context model (often a data flow diagram) showing

how your system fits into its overall environment
 A high-level business requirements model (often an
essential use case model)
 A glossary defining critical business terms
 A domain model (often a class diagram or data
diagram) depicting major business classes or entities
 A business process model (often a data flow diagram or
activity diagram) depicting a high-level overview of the
business process to be supported by your system. This
diagram is one level of detail greater than your context

The purpose of this discipline is to engineer the requirements

for your project, including the identification, modeling, and
documentation of those requirements. The main deliverable of
this discipline is the Software Requirements Specification
(SRS), also referred to as the Requirements Model, which
encompasses the captured requirements.
The purpose of this discipline is to evolve a robust architecture
Analysis & for your system based on your requirements, to transform the
Design requirements into a design, and to ensure that implementation
environment issues are reflected in your design.
In the AUP this is the combination of the Business Modeling,
Requirements, and Analysis & Design discipline.
The Enterprise Business Modeling discipline extends
business modeling to enable your organization to explicitly
realize the benefits of doing so outside the context of a project.
Enterprise The goal of the Enterprise Business Modeling discipline, also
Business sometimes referred to as enterprise requirements modeling, is
Modeling to enable you to understand and effectively communicate the
business that your organization is engaged in. It explores both
the business process that your organization engages in as well
as the overarching business requirements for the software
applications that support it.
The Enterprise Architecture discipline defines the
enterprise architecture of an organization. It consists of models
that define it, reference architectures, prototypes and working
models that demonstrate how it works, and frameworks that
make it easier to use. An enterprise architecture model is a
Enterprise representation of the structures and processes of an
Architecture organization; a good one depicts the organization both as it is
today and as it is envisioned in the future, and maps the various
views representing the architecture to one another. These
views include both business-oriented perspectives as well as
technical perspectives. In many ways enterprise architecture
models are a communication bridge between senior business
stakeholders and senior IT professionals.

How Good is the Fit Between AM and UP?

Now that we understand the basics of how modeling in the UP works, we can
examine how well AM fits in with it.Luckily many of AM's principles and practices
are arguably a part of the UP already, although perhaps not as explicitly as I would
like. Table 2 presents an examination of how well each individual AM practice is
currently implemented in the UP, if at all, and discusses how to adopt the practice
within the scope of the UP. My experience is that it is relatively straightforward for
UP teams to adopt AM practices if they choose to do so. This is because the UP is
very flexible, one of its underlying principles is that you should tailor it to meet your
unique needs, making it easy to merge AM practices into the UP.

Table 2. The Fit Between UP and AM.

Practice Fit
AM has a wide definition for project stakeholders, including
Active users, management, operations staff, and support staff to
name a few that are compatible with the UP. The UP clearly
Stakeholder includes project stakeholders, such as users and customers,
Participation throughout most of it disciplines. To be successful UP project
teams should allow project stakeholders to take on modeling
roles such as Business Process Designer and Requirements
Specifier as appropriate, there is nothing in the RUP
preventing this by the way. The more active project
stakeholders are the less of a need there will be for reviews,
management presentations, and other overhead activities that
reduce your team's development velocity.
The application of modeling standards, in particular the
diagrams of the Unified Modeling Language (UML), is
a significant part of the UP. Furthermore the RUP product
includes guidelines for the creation of many modeling
Apply artifacts, guidelines that your teams should consider adopting
Modeling and following as appropriate, and explicitly suggests that you
Standards tailor the guidelines that they provide for your exact needs. To
remain agile, however, UP teams should recognize that you
often need to bend the guidelines and standards - in other
words, don't let them become a straight jacket. There are
detailed UML modeling guidelines posted at this site.
UP teams are free to apply modeling patterns, the RUP
product describes many common modeling patterns, as part
Apply Patterns of their efforts for any of the modeling disciplines. This
Gently practice enhances the UP with its advice to ease into the
application of a pattern, the UP does not make this concept
as explicit as it could.
One of the strengths of the UP is that provides some advice
Apply the for when to create each type of model, and recent
Right incarnations of the RUP product includes significant advice for
Artifact(s) non-UML artifacts such as data models and user interface
storyboards (UI flow diagrams).
AM's concept of collective ownership can be used to enhance
the efforts on UP projects, assuming that the team culture
supports the concept of open and honest communication. The
UP supports collective ownership with its strong focus on
configuration management issues, it has a discipline
dedicated to this task, although its change management
Collective processes may potentially get in your way if developers and
Ownership project stakeholders are unable to distinguish when to
formalize change control and when not to. To be fair, this is a
problem regardless of when you apply AM on an UP project,
or on any type of project for that matter. UP teams should turn
the configuration management dial up a few notches and
allow anyone on the project to access and work on any
artifact that they wish, including models and documents.
The UP clearly includes this concept, one only has to look at
the activity diagrams depicting each discipline to see that
several artifacts are potentially being worked on in parallel.
Create Several However, this concept could be communicated better
because the near-serial flow in its activity diagrams presented
Models in for each major modeling activity doesn't communicate this
Parallel concept well. There is a larger issue as well when you
consider the lifecycle as a whole. Because the UP has
organized its modeling efforts into separate disciplines, for
very good reasons, it isn't as apparent that not only could you
work on several business modeling artifacts in parallel but you
could also work on requirements-oriented artifacts, analysis-
oriented artifacts, architecture artifacts, and design artifacts
too. UP teams can turn the dial up a few notches by reading
between the lines of the discipline activity diagrams and the
UP lifecycle diagram and choosing to perform activities from
several disciplines simultaneously when it makes sense to do
This practice is a choice made by the modeler(s), albeit one
that must be implicitly supported by the rest of the
development team. UP teams will need to adopt modeling
Create Simple guidelines that allow models that are just good enough and
Content the customers of those models (including programmers,
project stakeholders, and reviewers) must also be willing to
accept simple models. This is a cultural issue, one that is
often difficult for many organizations to adopt.
Depict Models
See Create Simple Content.
Modelers on UP teams are free to discard anything that they
Discard wish. As with the simplicity practices your organization's
Temporary culture must accept the concept of traveling light, of
Models developing and maintaining just enough models and
documents and no more.
UP teams are free to follow this practice. UP teams can turn
Display the communication dial up a notch by following the principle of
Models Open and Honest Communication by making all artifacts
Publicly available to everyone as well as to publicly display the critical
models used by the project team.
The UP includes the concept of integrating with external
systems, these systems are typically identified on use case
models and the RUP suggests introducing "boundary classes"
to implement the interface to these systems. At the time of
Formalize this writing the RUP appears weak with respect to activities
such as legacy system analysis and enterprise application
Contract integration (EAI). The explicit adoption of this practice clearly
Models strengthens the UP's integration activities and fits in well with
it's concepts of use case realizations - the interaction between
systems could be specified with one or more use cases and
then the corresponding use case realization would be the
formalized contract model.
This practice can be easily adopted by an UP team. As
Iterate to mentioned previously, the unfortunate depiction of UP
Another modeling activities as quasi-serial processes and the division
Artifact of modeling activities into separate disciplines can hinder the
iterative mindset required of agile modelers.
This practice is clearly an aspect of the UP - the UP's support
for iterations implies that you will be incrementally developing
Model in Small your model throughout your project. UP teams can easily turn
Increments the iterative and incremental dial up a few notches by
preferring smaller, simpler models that quickly lead to
implementation and testing.
The UP implicitly includes this practice. Every modeling
discipline clearly includes several roles, each role being filled
by one or more people. UP teams can turn the
Model With communication dial up a few notches by adopting tools that
Others support team modeling, such as whiteboards and
collaborative modeling tools (see the Communication
article) over single-user modeling tools.
The UP explicitly includes this practice. At the end of every
iteration, except perhaps for the ones during the Inception
Prove it With phase, the UP specifically states that you should have a
Code working prototype. Furthermore, the UP insists that you have
a working end-to-end prototype at the end of the Elaboration
phase that proves your architecture.
Reuse is an implicit part of the UP, and reuse management is
an explicit part of the Enterprise Unified Process (EUP). UP
teams can turn the reuse dial up a few notches by actively
Reuse Existing
preferring to reuse existing resources instead of building them
Resources from scratch, including but not limited to existing models,
existing components, open source software (OSS), and
existing tools.
There is no reason why you cannot store information in a
single place when following the UP. Unfortunately, many
Single Source organizations choose to instantiate the RUP in a
Information documentation-driven manner (which IBM Rational clearly
advices you not to do), and as a result they travel very heavy
and clearly take a multi-source approach.
In theory this can be an easy concept for UP teams to adopt
as it dramatically reduces the effort expended to keep your
artifacts up to date. However, in practice many organizations
prove to have a problem with this concept, particularly if they
have a strong "traceability" culture. Traceability is the ability to
relate aspects of project artifacts to one another, the support
for which is a strong feature of the UP as it is an important
aspect of its Configuration and Change Management
discipline. Furthermore, the RUP product includes tool
mentors for working with Rational RequisitePro, a
requirements traceability tool, making it appear easy to
Update Only maintain a traceability matrix between artifacts. My
When it Hurts experience is that organizations with traceability cultures will
often choose to update artifacts regularly, even if it isn't yet
painful to have the artifacts out of date, and update the
traceability matrix relating everything to one another. To turn
their productivity dial up several notches UP teams should
choose to travel light, to loosen up a bit and allow project
artifacts to get out of sync with one another, and to maintain a
traceability matrix between artifacts only when there is clear
benefit to do so AND their project stakeholders understand
the issues involved as well as authorize the effort. A
traceability matrix is effectively a document and is therefore a
business decision to be made by project stakeholders.
The RUP product includes tool mentors that make it easier for
Use the teams to work with tools sold by Rational Corporation.
Simplest Tools However, the reality is that UP teams are welcome to use any
development tool that they want and Rational tools compete
on their merits just like the products of any other company.
UP teams can turn their productivity dial up several notches
by expanding their horizons to include simple tools such as
whiteboards, index cards, and Post-It notes in addition to
CASE tools.

Something that is important to understand is that for AM to be successful the

culture of your organization must be open to the concepts, values, and principles
of agile software development.The problem is that the UP is often adopted by
organizations that either implicitly or explicitly do not accept the values of agile
software development. Their focus is often on following processes and using tools,
the RUP product clearly defines many processes and describes how to apply
Rational's tools effectively on software projects, and therefore the RUP is clearly
attractive to them. Unfortunately this goes against the agile value of preferring
individuals and interactions over processes and tools. When the culture of an
organization is documentation centric they may find the UP appealing because you
can instantiate it in such a way as to result in the creation of significant amounts of
documentation (you can also instantiate it to result in very little documentation,
remember, the UP is flexible). If an organization is documentation centric then this
aspect of its culture goes against agile software development's value of preferring
working software over comprehensive documentation. This organization may still
successfully adopt, tailor, and instantiate the UP but be unable to follow many of
AM's principles and practices effectively because it does not have an agile culture
(see the article When Does(n't) AM Make Sense). My point is that how well
AM and UP will fit together in your organization depends largely on your
organization's culture and not so much on the UP itself. You can easily use the
techniques of AM to improve your UP modeling efforts, but to be effective you will
find that you need to overcome cultural challenges within your organization.

Case Study: Wayne Enterprises

In early 2001 I was involved with a development project at Wayne Enterprises, the
name has been changed to protect the innocent, a medium-sized financial
institution. They had adopted the RUP and wanted to tailor it with Enterprise
Management concepts from the EUP, in particular they wanted to ensure that
the Inception phase and Elaboration phase efforts of individual projects were
supported by enterprise-level requirements, architecture, and reuse efforts. They
also wanted to ensure that their modeling processes were effective, they weren't
convinced that the UML was sufficient for their needs (it wasn't) and they wanted
to ensure that legacy integration modeling was reflected in their tailoring of
the RUP. I was eager to apply AM on a RUP project and they liked the basic
concept of the methodology and were willing to give it a try.

The culture of Wayne Enterprises was conducive to change, which was a huge
benefit. Management was open minded and willing to try new techniques, hence
the RUP. As you would expect the developers were also eager to try new
techniques and work with new technologies, although nowhere near as enamored
with the RUP as management was.Our approach was to pilot the RUP on a small
project - there was seven developers, one manager, one senior manager and four
users - over a period of seven months. The project was of mid-level importance, it
would be noticeable if we failed but it wouldn't put the company at risk. It was their
first real J2EE project, and the team was fairly typical: there was two mid-level
Java developers; a senior consultant experienced in EJB; another senior
developer with a C++, OMT, and UML background; a experienced business
analyst that was new to use cases and object-oriented development; a DB2
database administrator (DBA) learning Oracle; and a good QA/tester person with
some Java testing background.

At the beginning of the project we tailored the RUP with the practices of AM and a
portion of the EUP, the end result of which was the creation of something the RUP
calls a development case. This effort took several days, I had all the raw material
that we needed to add, and everyone recognized that there was little value in
spending much more time than that - everybody wanted to get to work on the
project.My involvement with the project was to help them with the initial creation of
the development case and initial overview training to the development team. I also
periodically reviewed the effort, both from an architectural point of view and from a
software process point of view - their first goal was to develop a good system and
their second goal was to ensure that they were learning how to do so effectively.

During the Inception phase the team produced a high-level requirements

model, about 20 use cases and a 15-page supplementary specification that the
business analyst evolved throughout the project. A lot of this documentation
was initially written by the user representatives, after breaking out of
requirements modeling sessions led by the business analyst and attended
by one or two developers at a time. The Elaboration phase was mostly white
boarding performed by the entire team and some coding and testing of an end-to-
end prototype to prove the architecture. They kept the models as simple as they
possibly could, some of this was motivated by the realization that they weren't
familiar with the technology and therefore it was futile to over model things, and
part of it was because they were eager to code EJBs, servlets, and JSPs. This
phase went a little slower than usual due to the team's inexperience with setting up
EJB, developing EJBs, and deploying them. The Elaboration phase was a good
learning experience for the team because it gave them experience in the
technology and in following their tailored process. It also helped to dampen the
DBA's argument that the data architecture was the primary concern, granted,
the legacy data issues were challenging, and was an important stepping stone
towards building a common understanding of how to work together as a team.
During the Construction phase the use of Together/J and the data modeling tool
was very common, although white boarding was still used for high-level thinking
and discussions. From what I could gather the architecture models stayed up on
the white boards, the critical ones were a layered deployment diagram and a high-
level sketch of the structure of the object schema. The DBA maintained and
evolved the data model, outputting it regularly to their plotter and tacking to
the wall. The organization already made it a practice to Display Models
Publicly long before they adopted RUP and AM. The team had five four-week
iterations in the Construction phase, implementing between two and five use cases
at a time. The Transition phase was fairly standard, from an AM point of view the
most important effort was a documentation clean up at the end.

As the project progressed the team ran into several issues:

1. Personnel. The Java/EJB developers took to the process pretty quickly,
much of the object-oriented development practices were familiar to them
already and they preferred an iterative and incremental approach to
development. The C++ developer had a "big design up front" (BDUF)
mindset that he started to overcome mid-project after seeing that our
emergent design approach actually worked in practice (see the Agile
Design Modeling article a discussion of these two approaches to design).
The DBA had a similar mindset although he wanted to create a data model
early in the project, which was clearly inappropriate because we wanted to
let our object design drive our database design so we diverted him to
focus on legacy analysis and the formalization of contract models with the
relevant groups. The business analyst struggled with learning how to
apply use cases effectively in combination with other requirements
artifacts. The tester was initially concerned that we weren't producing
detailed models that could be inspected and peer reviewed, but he
recognized the closer collaboration among the team and the combination
of Agile Testing and Quality Strategies was sufficient for our needs.
2. Management. The team had good senior management support
throughout the effort as it was clear to them that the team was delivering.
The team's senior manager focused on technical issues such as
scheduling and estimating and the junior manager focused on softer
issues such as ensuring the team had the resources they needed,
including training, and that they weren't being delayed by politics.
3. Tools. The team could have been more agile when it came to tool usage.
The practice of Use the Simplest Tools wasn't fully accepted,
whiteboards made sense to the team but index cards and essential user
interface prototypes using Post It Notes and flip chart paper were too
foreign for them. Initial diagrams were drawn on the whiteboard and in the
case of structural diagrams such as UML class diagrams and data
diagrams they were then transcribed into the appropriate CASE tool,
Together/J and Oracle Developer respectively. The use case diagram was
transcribed into Microsoft Visio, they needed to present it to senior
management and my suggestion that we simply provide them with a digital
picture of the whiteboard didn't go over well. The diagram also appeared in
the final documentation so the effort was worthwhile.
4. Cultural. The hardest thing to overcome was the serial/waterfall mindset
of some of the people involved. The C++ developer, who was learning
EJB, and DBA both had a BDUF mindset and the tester wanted to see
more formal documentation. The data-driven mentality of the DBA was
typical but eventually overcome when he saw that an object-driven
approach actually worked in practice - this was clearly a struggle for him at
first and I suspect that he was initially giving the team enough rope to
hang themselves with, but slowly saw that there are in fact more effective
ways to work than what he was familiar with. The managers were open to
iterative and incremental development, I suspect that not only did they
purchase Kruchten's RUP book (2000) they actually read it, and had
communicated the advantages of this approach to the user
representatives we were working with. One of our user representatives
had been involved with a "challenged project" in the past and definitely
didn't want to repeat that experience and as a result was incredibly open
to following the RUP.
5. Documentation. In my opinion the team wrote too much documentation,
but at the same time it increased their comfort level with the new approach
so that wasn't too bad. They stuck to the traditional RUP artifacts. Their
requirements model was focused around the use case diagram and a
collection of use cases, business rules, technical requirements, and
glossary written in English prose. The business analyst wrote and
maintained this document, keeping it up to date as the requirements
evolved. The Software Architecture Document (SAD) was maintained as
point form notes on an HTML page, whiteboard sketches, and arguably
in the CASE tool models. The notes, basically an overview of the team's
decisions, and the whiteboard diagrams were quite agile. However, the
team complained that there was nothing in between the high-level
sketches and the detailed diagrams in their CASE tools - both Together/J
and the data modeling tool are oriented towards detailed design and
development, not high-level architecture. In the end they discovered that
they didn't need the intermediate-level models, but this was a point of
contention for awhile. The data model appeared to be of value to the team
and was considered a permanent artifact, although the diagrams in
Together/J weren't perceived to be as important - Together/J writes most
information to Java class files, which were clearly considered critical to
success. The Test Model, the definition of the test cases, was maintained
by the tester, and although I never looked at it from what I could tell the
tester invested too much effort in its development. To be fair, the tester
was new to J2EE development and wanted to err on the side of caution.

Adopting AM on an UP Project
For an UP project team to adopt AM they will need to overcome the common
misconceptions that developers have about the UP as well as several cultural
barriers that are common within organizations that instantiate the UP. they need to
begin by thinking outside of the current UML-centric nature of the UP. To do this,
you should:

1. Forget the term "use-case driven". Yes, it's a wonderful marketing term
but the reality is that use cases aren't sufficient to drive much of anything.
Use cases are a good technique to document behavioral requirements but
that's only a small part of the functional requirements picture and an even
smaller part of the total requirements picture - they aren't very good at
documenting business rules, user interface requirements, constraints, or
non-functional requirements - which is why the UP includes something
called a supplementary specification to contain all these other things.
Requirements drive things, use cases don't. Your modeling efforts will
always remain hobbled if you don't separate the UP's software engineering
wheat from its marketing-rhetoric chaff.
2. Recognize that there are more modeling artifacts than those
described by the UML. AM's principle Multiple Models tells you that you
have many modeling artifacts at your disposal - change cases, user
stories, business rules, UML activity diagrams, UML class diagrams, data
models, and external interface specifications - to name a few. An
interesting implication of this principle is that you have far more than just
the diagrams of the UML at your disposal. The good news is that the UP
recognizes that a wide range of models is needed to explore the
complexities of modern software, recent versions do in fact include data
modeling and user interface design activities that are currently outside
the scope of the UML, the bad news is that it many people erroneously
perceive that the UP is simply a process for using the UML.
3. Recognize that the UP is not inherently documentation centric. The
UP is actually very clear that you should only develop the artifacts that you
actually need, however, this is good message is something that often gets
missed by many software professionals so it is something that is worth
repeating here. You should question every single model that the UP
suggests creating because it purposely describes a wide variety of
artifacts, many of which your project simply doesn't need. The UP includes
three major sets of modeling-oriented artifacts - the business modeling
set, the requirements set, and the analysis & design set - each of which in
turn is composed of several detailed artifacts. For example the business
modeling set includes a business use-case model, business rules, a
business architecture document, and a business supplementary
specification. Do you actually need all of these things? Likely not. If you do
need them, do you need them as formal documentation? Likely not.
Communicate AM's Travel Light and Model With a Purpose principles
to your project stakeholders, as well as the practices Update Only When
It Hurts and Discard Temporary Models.
4. Build a common process vision between developers and project
stakeholders. Managers often tend towards a prescriptive software
process, something that appears well defined and comprehensive such as
the UP, one with a perceived focus on control. Developers, on the other
hand, gravitate towards agile techniques such as XP and AM due to their
perceived focus on what is important to developers: building software.
Because management holds the purse strings many developers find
themselves in a situation where their managers have chosen to adopt the
UP and are now being required to follow it. Luckily the UP is flexible
enough that it can be tailored to be reasonably agile, but to do so
developers and project stakeholders will need to come to an agreement as
to the extent of the tailoring.
5. Actively promote iterative and incremental development. Agile
Modeling's practices of Model in Small Increments, Iterate to Another
Artifact and Create Several Models in Parallel can be tough ones for
experienced modelers to adopt - and chances are that your experienced
modelers are already chaffing at the UP's concepts of iterations, let alone
an even greater emphasis on iterative and incremental modeling.
Traditional modeling techniques often promoted a single artifact approach,
such as use-case modeling or user-interface prototyping sessions, and
often even modelers that focused, for example data modelers. Also, they
often promoted a BDUF approach where you modeled everything in detail
before you started coding. These concepts were great in theory, focusing
on a single artifact at a time should have allowed the modelers to get it
right quickly, but unfortunately practice shows this not to be the case. A
good way to ease into these practices is instead of use-case modeling
sessions run requirements modeling sessions where you work on use
cases, Class Responsibility Collaborator (CRC) cards, business
rules, and user interface prototypes simultaneously. Similarly, hold
analysis sessions where you are use case modeling, sequence
diagramming, user interface prototyping, and class modeling may
make sense, and design sessions where you are class modeling, state
modeling, data modeling, component modeling, user interface
prototyping, and hopefully even developing business code. Once you are
comfortable with these practices the next step is to then merge your
modeling efforts in with your implementation efforts, applying multiple
artifacts including all your potential models, source code, and test cases
as needed - truly iterative development. While you are doing this, keep
their focus on the requirements that you are implementing in the current
iteration, resulting in an incremental delivery of functionality each iteration.
6. Actively promote simplicity. Simplicity is a fundamental value of AM,
one that motivates several critical principles that can dramatically improve
the effectiveness of your modeling efforts.Many experienced modelers
want to specify everything they possibly can, for example, not only do they
wish to model the overall structure of their software in UML class diagrams
they also want to specify the scaffolding code needed to implement that
structure.This is a lot of effort which provides very little actual value. A
better approach is to create a class diagram that is just barely good
enough for your purpose, to depict the likely structure of your classes,
and then start coding from there. Agile modelers assume that the
programmers, often themselves, can figure out the details at the time and
instead will focus on issues that may not be so obvious. This approach
implies less work for the modeler and less modeling noise for the actual
programmer to wade through. When an agile modeler is creating a class
diagram they realize that they don't need to model all of the classes
required to build the software, instead they focus on getting the core
classes right and assume that the programmers are competent enough to
handle the rest1[1]. By keeping your models simple you are likely to work
faster while at the same time create something that is actually of value to
your programmers - models that focus on critical issues that are devoid of
7. Staff projects with generalizing specialists. Many organizations have
separate positions for modelers, motivating their staff to focus on
specialties, a practice that in my experience reduces your ability to be
agile.Although the UP is very clear that individual developers can and
should take multiple roles on a project my experience is that this is advice
that falls on deaf ears within many organizations.Instead what happens is
that organizations adopting the UP tend to introduce positions along the
lines of UP's modeling roles - for example Requirements Specifier, System
Analyst, User-Interface Designer, Database Designer - and therefore slots
people into individual roles, going against the advice of both AM and the
UP. If your only job on a software project is to produce models then there
is a tendency for you to over model things, first because you naturally
want to do a good job and second because if it's your job to model then
that means it's likely someone else's job not to model (e.g. their job is to
program). Because there is a hand-off there is now greater motivation to
add greater detail into your model, details that likely wouldn't be needed if
the people writing the code also developed the models that helped them to
identify what needed to be coded in the first place.
8. Live AM's principle of Open and Honest Communication. I've run into
several situations where a development team was reluctant to follow the
Display Models Publicly practice, one way to promote open and honest
communication with people external to your team, often because they
were afraid of what another political faction within the organization would
do with the information. However, when they finally worked up the courage
to display their models publicly they quickly discovered that the politicos
they were so afraid of couldn't find much to criticize, and when they did
this was great input that the developers quickly acted on and benefited

How Does This Work?

It is clearly possible to tailor the Unified Process (UP) with the practices of Agile
Modeling (AM). To succeed, your organization's culture must be receptive to both
the UP and to AM, and therein lies the rub - the goal of organizations that adopt
the UP is often to instantiate it as a fairly rigid and prescriptive process whereas
organizations that adopt AM typically want to work in a more fluid manner (in fact,
to be truly effective AM requires such an environment). Luckily the UP is flexible
enough so that it can be instantiated to be reasonably agile. When this is the
case, when you have instantiated a light-weight version of the UP, then the UP
and AM fit together well. Both the UP and AM are based on the idea that the
majority of software is best delivered iteratively and incrementally. Because the UP
explicitly includes modeling disciplines it is very easy to identify where AM
practices should be used to enhance your own tailoring of the UP. This works
when your project team and your project stakeholders choose to make it work.

[1]If this isn't the case then you have a serious human resources issue that you
need to deal with appropriately. Excessively complex models aren't going to help
address this situation in practice, and their creation will help management avoid
making the hard decisions regarding the quality of their staff.

[2] The Implementation discipline is arguably a fourth one because it includes an

activity called 'Structure The Implementation Model' which is essentially a second
look at the design model to organize it in such a way as to avoid integration and
build problems.

Share with friends: Tweet LinkedIn Facebook StumbleUpon Digg Baidu Google +

Let Us Help
We actively work with clients around the world to improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to
contact us, can be found at Scott Ambler + Associates.

Recommended Reading
This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software
Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD)
process decision framework. The DAD framework is a people-first, learning-oriented
hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is
goal-driven, is enterprise aware, and provides the foundation for scaling agile. This
book is particularly important for anyone who wants to understand how agile works
from end-to-end within an enterprise setting. Data professionals will find it
interesting because it shows how agile modeling and agile database techniques fit
into the overall solution delivery process. Enterprise professionals will find it
interesting beause it explicitly promotes the idea that disciplined agile teams should
be enterprise aware and therefore work closely with enterprise teams. Existing agile
developers will find it interesting because it shows how to extend Scrum-based and
Kanban-based strategies to provide a coherent, end-to-end streamlined delivery
The Object Primer 3rd Edition: Agile Model Driven Development with UML 2
is an important reference book for agile modelers, describing how to develop 35
types of agile models including all 13 UML 2 diagrams. Furthermore, this book
describes the fundamental programming and testing techniques for successful agile
solution delivery. The book also shows how to move from your agile models to
source code, how to succeed at implementation techniques such as refactoring
and test-driven development(TDD). The Object Primer also includes a chapter
overviewing the critical database development techniques ( database refactoring,
object/relational mapping, legacy analysis, and database access coding) from
my award-winning Agile Database Techniquesbook.
- See more at: