About the Agile Modeling Site: AgileModeling.com
- 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?
- In what context should each of these practices (not) be applied?
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 initiative 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.
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, The Object Primer 3rd Edition, and Disciplined Agile Delivery.