---

Keywords: Agile, XP, UML, Java, C# Title: Agile Development with ICONIX Process Authors: Doug Rosenberg, Matt Stephens and Mark Collins-Cope Publisher: Apress ISBN: 1590594649 Media: Book Verdict: An interesting read

Buy US Buy UK

In 'Extreme Programming Refactored: The Case Against XP' Doug Rosenberg and Matt Stephens applied a heavy dose of corrective satire to the extremes of extreme programming (XP). In pointing out some of the more zealous statements and practices that fall under the XP banner, (such as the mandating of compulsory pair programming), the authors were careful not to throw the (agile) baby out with the (XP) bathwater. The aim was to refactor the process not to destroy it completely.

Now, joined by Mark Collins-Cope, Rosenberg and Stephens are back with something altogether more constructive. 'Agile Development with ICONIX Process' is a very practically-based look at a methodology that aims to combine agility with the need to do up-front design and documentation. In other words to combine the best of the agile approach with the benefits normally accorded to heavy-weight processes such as RUP.

While there's a tendency for methodology books to make at least a passing nod towards the real world (even if it's only to acknowledge that it exists and that it's complex), this one is based around a single worked example. Starting at the beginning, with a fairly imprecise set of requirements and then moving through the process to finish with a couple of releases. It's a warts and all exercise, with many of the artefacts (use cases, UML, screen shots, design documents, source code etc), used in the book to illustrate how it all fits together.

The agile ICONIX process that emerges from the worked example, and from the additional material in the book, is one that is based in large part on 'disambiguating' requirements at every stage of the process. The authors suggest that it is ambiguity at every stage of the life-cycle that causes development problems. And where a purist XP process would suggest that it is code that disambiguates the requirements, leading to constant refactoring, here the authors suggest it is in the design not the implementation that you should seek clarity. Instead of programmers churning out code re-writes the ICONIX process uses a variety of tools - such as use cases, persona modelling, sequence diagrams and other components of UML, to drive out the ambiguity and push forward the design.

The subset of UML that is used is well described. The key elements are class diagrams to describe the static model, use cases to capture interaction, sequence diagrams and robustness diagrams. The latter were developed by Ivar Jacobson in his Objectory methodology that pre-dates his work with UML. It represents a graphical method of walking through a use-case and mapping which objects are required to accomplish it. In doing this it's likely that ambiguity in the use case and/or the class diagram are uncovered and therefore revising these leads to a clearer and more consistent design.

In addition to explaining the subset of UML that ICONIX uses, the book also devotes a good deal of attention to the set of agile practices that it uses. These include keeping bureaucracy down to a minimum (i.e. don't create documentation that doesn't drive the project forward), unit testing, agile planning, iterative development, automated builds and aiming for frequent small(ish) releases. These are pretty much the core practices that almost all of the various agilist methodologies adhere to.

Having a worked example serves to illustrate the various steps. The requirements are vague, repetitive and mix in the odd implementation details as well, (as nearly every set of requirements does). In this case the requirement is for a web application that uses a Global Information System (GIS) server to bring up hotel information when a user clicks on a map on a web page. The initial requirement is for a Java solution (which leads to the project being called a mapplet), but this quickly switches to the .NET platform using C#. Even with a major architectural change the design and development is not derailed.

The mapplet example provides a handy structure. It's clearly not a toy problem but nor is it an incredibly complex enterprise application that has to negotiate layers of middleware. However there is more to this book that just the mapplet. The authors do a good job of explaining the whys as well as the hows. The process that emerges seems to successfully straddle the divide between agile on the one hand and the heavy-weights on the other.