 |
First and foremost, the purpose of this site is to develop and promote the
Agile Modeling (AM) methodology. I hope to both share my experiences with
you as well as to learn from your experiences, to discuss and grow this approach
to software modeling. Where am I coming from? Well, I've been developing
software since the mid 1980s and writing about software
development since the mid 1990s. As a consultant my focus
has been on helping organization improve how they
develop software, and often on how they went about modeling it. During
that period I've asked and tried to answer some very pointed questions, such as:
-
How do you develop software effectively?
-
How do you model software?
-
What types of artifacts should you consider developing while
you model software?
-
How do the artifacts fit together?
-
What modeling practices work?
-
What modeling practices don't seem to work very well?
|
|
To share the answers that I had come to I started writing and
co-editing a series of books about software processes. In 1995 I had
introduced my own object modeling notation, as well as my own agile software
process (The Pinball Process) in the first edition of
The
Object Primer. When the Unified Modeling Language (UML) reared its
head in 1997 I quickly adopted it for my second book
Building
Object Applications That Work, showing how to extend it for real world
development. My experience developing actual business application software
was that the UML was far from complete, and that you needed a wide range of
modeling techniques to be successful, a message that the object-oriented theoreticians
were either oblivious to or simply didn't want to hear not to mention the
CASE
tool vendors that didn't actually have a full solution to sell you and thus I
assume were happy that the UML was likewise incomplete (and clearly is still
incomplete today).
It was shortly afterwards I started looking at the bigger
software development picture, I had been involved with a large project that had
failed miserably, and proposed my own heavy-weight prescriptive software process
that I called the Object-Oriented Software Process (OOSP) in my books
Process
Patterns (1998) and More
Process Patterns (1999). In parallel Rational Corporation was putting
together the Rational Unified Process for software development, which, like the
UML before it was clearly going to take the industry by storm. This forced
me to make the difficult decision of accepting that it was unlikely that I could
compete with the marketing muscle of Rational and therefore should try to find a
way to help ensure that the Unified Process actually met the real-world needs of
software developers (hopefully avoiding the problems that the UML's
incompleteness have caused). I decided to describe
enhancements
to the Unified Process, based mostly on my own OOSP as well as on the OPEN
Process and other leading techniques. This led to CMP's Unified
Process series of books, co-edited by myself and Larry Constantine, in
The
Unified Process Inception Phase,
The
Unified Process Elaboration Phase,
The
Unified Process Construction Phase, and
The
Unified Process Transition and Production Phases.
The EUP is now described in detail at the
Enterprise Unified Process (EUP) home page.
While I was doing all this work on heavy-weight software
processes Kent Beck and others were working on eXtreme Programming (XP),
presenting them first as a collection of process and organizational patterns and
then as a series of books. I instantly became fascinated with XP,
recognizing a similar, yet much more evolved, collection of principles and
practices that I had written about in The Object Primer and Building
Object Applications That Work. It became clear to me that depending on
the nature of your working environment that sometimes an agile process such as
XP was your best approach whereas other times a prescriptive approach such as
The Unified Process was your better choice. This motivated me to return to
my roots, to revisit my approach to software development and to reflect on the
fundamental practices and principles that improved modeling. I rewrote The
Object Primer, an introductory text to what I consider to be the fundamental
modeling techniques that software developers require, describing modeling
techniques for requirements, analysis and design of object-oriented and
component-based software. In the book I cover essential modeling
techniques, change cases, user interface modeling, the techniques of the UML,
and structured/procedural techniques such as data modeling. As I indicated
earlier, my experience is that the UML is merely a good start at filling your
"modeling technique toolbox", but it isn't sufficient for real-world
development. I also showed how to take your designs and translate them
into code (Java was used) as well as test and validate your work.
Just as The Object Primer went to print I realized that a
modeling techniques book, although a great start, was only part of the overall
solution. I also needed to explore the principles and practices that
modelers follow as they apply the various modeling techniques that I describe in
The Object Primer 2nd Edition. Hence I started work on the concept
of eXtreme
Modeling (XM) (now Agile Modeling, read
about the name change) first as a (continuing) collection of columns in Software
Development, now at this site, and eventually in the
books
Agile
Modeling,
Agile Database Techniques, and
The Object Primer 3rd Edition.
Feel free to
contact me if you are interesting in
training or
modeling services.
Translations:
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.
|
