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
Programming (XP), the
Solutions Framework (MSF) for Agile, the
Unified Process (RUP), the
Agile Unified Process (AUP), and the
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.
In the case of XP and MSF the modeling processes
should be better defined, and in the case of both the
RUP and the EUP the 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
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
are presented in Figure 1 and
Figure 2 respectively. The
AUP is a subset of the RUP and the EUP a superset of the
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
testing, and some management
the RUP there are three disciplines 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
The lifecycle of the Agile Unified Process (AUP).
The lifecycle for the Enterprise Unified Process (EUP).
The Modeling Disciplines of the Unified Process.
The purpose of this discipline
model the business context, the scope, of your
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
- 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
diagram is one level of detail greater than
your context diagram
The purpose of this discipline
is to engineer the requirements for your project, including
the identification, modeling, and documentation of
The main deliverable of this discipline is
the Software Requirements Specification (SRS),
also referred to as the Requirements Model, which
encompasses the captured requirements.
Analysis & Design
The purpose of this discipline
is to evolve a robust architecture for your system
based on your requirements, to transform the
requirements into a design, and to ensure that
implementation environment issues are reflected in
AUP this is the combination of the Business
Modeling, Requirements, and Analysis & Design
Enterprise Business Modeling
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.
The goal of the Enterprise Business
Modeling discipline, also sometimes referred to
as enterprise requirements modeling, is 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.
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 representation of the
structures and processes of an 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.
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.
The Fit Between UP and AM.
AM has a wide definition for
project stakeholders, including users, management,
operations staff, and support staff to name a few
that are compatible with the UP. The UP clearly includes project
stakeholders, such as users and customers,
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
management presentations, and other overhead
activities that reduce your team’s development
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 artifacts, guidelines
that your teams should consider adopting and
following as appropriate, and explicitly suggests
that you 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
UP teams are free to apply
modeling patterns, the RUP product describes many
common modeling patterns, as part of their efforts
for any of the modeling disciplines. This 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
the Right Artifact(s)
One of the strengths of the
UP is that provides some advice for when to create
each type of model, and recent incarnations of the
RUP product includes significant advice for
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 processes may potentially get in
your way if developers and 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.
Several Models in Parallel
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. However, this concept could be communicated
better because the near-serial flow in its
activity diagrams presented for each major
modeling activity doesn’t communicate this
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
guidelines that allow models that are just good
enough and the customers of those models
(including programmers, project stakeholders, and
reviewers) must also be willing to accept simple
is a cultural issue, one that is often difficult
for many organizations to adopt.
See Create Simple Content.
Modelers on UP teams are free
to discard anything that they wish. As with the simplicity practices your
organization’s culture must accept the
concept of traveling light, of developing and
maintaining just enough models and documents and
UP teams are free to follow
this practice. UP teams can turn the communication dial up
a notch by following the principle of Open and
Honest Communication by making all artifacts
available to everyone as well as to publicly
display the critical models used by the project
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 this writing the
RUP appears weak with respect to activities such
as legacy system analysis and enterprise
application integration (EAI). The explicit adoption of this practice
clearly 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
to Another Artifact
This practice can be easily
adopted by an UP team. As mentioned previously, the unfortunate
depiction of UP modeling activities as
quasi-serial processes and the division of
modeling activities into separate disciplines can
hinder the iterative mindset required of agile
in Small Increments
This practice is clearly an
aspect of the UP – the UP’s support for
iterations implies that you will be incrementally
developing your model throughout your project.
UP teams can easily turn 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 communication
dial up a few notches by adopting tools that
support team modeling, such as whiteboards and
collaborative modeling tools (see the Communication
article) over single-user modeling tools.
it With Code
The UP explicitly includes
this practice. At the end of every
iteration, except perhaps for the ones during the
Inception phase, the UP specifically states that
you should have a 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 preferring to reuse existing
resources instead of building them from scratch,
including but not limited to existing models,
existing components, open source software (OSS),
and existing tools.
Single Source Information
There is no reason why you cannot store
information in a single place when following the
UP. Unfortunately, many organizations
choose to instantiate the RUP in a
documentation-driven manner (which IBM Rational
clearly advices you not to do), and as a result
they travel very heavy and clearly take a
Only When it Hurts
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 maintain a traceability matrix between
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
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 Simplest Tools
The RUP product includes tool
mentors that make it easier for teams to work with
tools sold by Rational Corporation. 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
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
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
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
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
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
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
They had adopted the RUP and wanted to tailor it
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
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
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
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
also helped to dampen the DBA’s argument that the
architecture was the primary concern, granted, the
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
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:
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 significant developer testing using
and an EJB testing tool and
testing in the large activities such as system testing and
user acceptance testing (UAT) was sufficient for our
Management. The team had
good senior management support throughout the effort
as it was clear to them that the team was
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
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.
The hardest thing to overcome was the
serial/waterfall mindset of some of the people
C++ developer, who was learning EJB, and DBA both
BDUF mindset and the tester wanted to see more
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.
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
notes, basically an overview of the team’s
decisions, and the whiteboard diagrams were quite
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
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:
Forget the term “use-case
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.
Recognize that there are
more modeling artifacts than those described by the
Multiple Models tells you that you
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
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
scope of the UML,
the bad news is that it many people erroneously
perceive that the UP is simply a process for using
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
Do you actually need all of these things?
If you do need them, do you need them as
Travel Light and
With a Purpose principles to your project
stakeholders, as well as the practices
Only When It Hurts and
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
Actively promote iterative
and incremental development.
Agile Modeling’s practices of
Iterate to Another Artifact
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
good way to ease into these practices is instead of
use-case modeling sessions run requirements
modeling sessions where you work on
Responsibility Collaborator (CRC) cards,
user interface prototypes simultaneously.
Similarly, hold analysis sessions where you are
class modeling may make sense, and
design sessions where you are
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.
Actively promote simplicity.
Simplicity is a fundamental
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
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 rest.
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 fluff.
Staff projects with
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
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
Live AM’s principle of Open
and Honest Communication.
I’ve run into several situations where a
development team was reluctant to follow the
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 from.
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.
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 techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around.
Enterprise Unified Process: Extending the Rational Unified Process
describes the EUP, an extension to the RUP. Whereas the
RUP defines a software development lifecycle, the EUP
extends it to cover the entire information technology (IT) lifecycle.
The extensions include two new phases,
Retirement, and several new disciplines:
Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling,
Software Process Improvement).
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 W.
Ambler + Associates.