 |
Agile
Modeling (AM) is a practice-based methodology for
effective modeling and documentation of software-based
systems. Simply put, Agile Modeling (AM) is a collection of
values,
principles, and
practices for modeling software that can be applied
on a software development project in an effective and
light-weight manner. As you see in Figure 1 AM is meant to
be tailored into other, full-fledged methodologies such as
XP
or
RUP, enabling you to develop a software process which truly
meets your needs.
|
|
Figure 1.
AM enhances other software processes.
The values of AM, adopting and extending those of eXtreme
Programming v1, are
communication,
simplicity,
feedback,
courage, and
humility.
The keys to modeling success are to have effective communication between all
project stakeholders, to strive to develop the simplest solution possible that
meets all of your needs, to obtain feedback regarding your efforts often and
early, to have the courage to make and stick to your decisions, and to have the
humility to admit that you may not know everything, that others have value to
add to your project efforts.
AM is based on a collection of principles, such as the
importance of
assuming simplicity when you are
modeling and
embracing change as you are working
because requirements will change over time.
You should recognize that
incremental change of
your system over time enables agility and that you should
strive to obtain
rapid feedback on your work to
ensure that it accurately reflects the needs of your
project stakeholders. You should
model
with a purpose, if you don't know why you are
working on something or you don't know what the audience
of the model/document actually requires then you shouldn't be
working on it. Furthermore, you need
multiple models in your
intellectual
toolkit to be effective. A critical concept is
that models are not necessarily documents, a realization
that enables you
travel light by discarding most
of your models once they have fulfilled their
purpose. Agile modelers believe that
content is
more important than representation, that there are
many ways you can model the same concept yet still get
it right. To be an effective modeler you need to
recognize that
open and honest
communication is often the best policy to follow to
ensure effective teamwork. Finally, a focus on
quality
work is important because nobody likes to produce
sloppy work and that local adaptation of AM to
meet the exact needs of your environment is important.
To model in an agile manner you will apply AM's
practices as appropriate. Fundamental
practices include
creating several models in parallel,
applying the right artifact(s) for the situation,
and
iterating to another artifact to continue
moving forward at a steady pace.
Modeling in
small increments, and not attempting to create the
magical "all encompassing model" from your
ivory tower, is also fundamental to your success as an
agile modeler. Because models are only abstract
representations of software, abstractions that may not
be accurate, you should strive to
prove it with code
to show that your ideas actually work in
practice and not just in theory
Active stakeholder participation
is critical to the success of your modeling efforts
because your project stakeholders know what they want
and can provide you with the feedback that you require. The principle of assume simplicity
is a supported by the practices of
creating simple
content by focusing only on the aspects that you
need to model and not attempting to creating a highly
detailed model,
depicting models simply via
use of simple notations, and
using the simplest tools
to create your models. You travel light by
single sourcing information,
discarding
temporary models and
updating models only when it
hurts. Communication is enabled by
displaying
models publicly, either on a wall or internal web
site, through
collective ownership of your
project artifacts, through
applying modeling
standards, and by
modeling with others.
Your development efforts are greatly enhanced when you
apply patterns gently. Because you often need to
integrate with other systems, including legacy databases
as well as web-based services, you will find that you
need to
formalize contract models with the owners
of those systems. Read this article for a better
understanding of how
AM's practices fit together.
I would argue that AM is an agile
approach to modeling, that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers.
With an
Agile Model Driven Development (AMDD) (see
Figure 2) approach you
typically do just enough
high-level modeling at the beginning of a project to
understand the scope and potential architecture of the
system, and then during development iterations you take
a
just in time (JIT) model storming approach where you
model for several minutes as a precursor to
several hours of coding.
Figure 2. Agile Model Driven
Development (AMDD).
My experience is that these practices can be applied to most software development projects, you don't have to be working on an project following an agile software process (such as XP) to take advantage of the approaches described by AM, although one of AM's goals is to explain how to model when following the XP approach. A project team doesn't need to apply all of the practices, principles, and values of AM to benefit from it -- I have always been a firm believer that you should tailor your software process to reflect the unique needs of your environment -- although it is my opinion that like XP you are much more likely to succeed if you do adopt all of AM.
 |
|
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
of the
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
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 Techniques
book. |
|
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
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
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
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. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
