Friday, October 10, 2008

ICONIX Process Rocks

Today we talk about my favorite software development process, so-called ICONIX.
This should probably give an answer to the few dinosaurs who like going around saying that AGILE is an excuse for not having a well-defined process (they probably think the V-Model still rocks - good lads).

ICONIX adopts a subset of core AGILE techniques and it is a behavioral requirements (Use Cases) driven process. The ICONIX process aims to be as low-celebration as possible carrying as little documentation as possible through iterations - in order to allow you to easily keep it up-to-date (this is a big difference from other AGILE processes, as XP, which aim at carrying no documentation at all).
For fans of TDD (Test Driven Development), it has been proved that ICONIX can be easily paired with the latter: http://www.springerlink.com/content/k15l318vq1013057/

Here's a practical overview of the process:
  1. Quick Draft of Functional Requirements (in theory throw-away)
  2. Quick Definition of a Domain Model (identify entities and classes)
  3. Model Use Cases on the base of previous steps (This is what drives development)
  4. Draw a throw-away robustness diagram for each use case (to understand relations between your classes)
  5. Draw a Sequence Diagram for each use case (here you'll understand which methods you really need)
  6. Model your test-cases on the use cases
  7. Implement
  8. Test
At each step you review your work as a whole updating your domain model (it's impossible to get it right first time) and adding comments on your use cases. By the end of step (5) you end up with ready-to-implement classes and logic with just little documentation to maintain if you re-factor or change anything. The following is indeed the only documentation you need to carry through iterations:
  • Use case diagram
  • Sequence Diagram for each use case
  • Test case diagram (or test plan)
If you need to add features, you add new use cases and follow the whole process.
 
In my experience the ICONIX process works regardless of the size of the project. In a medium-large project you just split the implementation of features in short iterations in an AGILE fashion. It is worth underlining that the big difference between most extreme AGILE processes and ICONIX is that you do keep documentation up-to-date, you don't just throw it away after each iteration. This is possible because the process aims (again) at keeping very light-weight documentation.

6 comments:

Anonymous said...

What's this "Do not mess with the butchers" shit on a right link click. Ever heard of tabbed browsing?!

Unknown said...

It's there to piss people off - and I guess it's working (note that the context menu appears after the alert).

Anonymous said...

You could add in your reference list the article "Agile Development with ICONIX Process"

http://www.methodsandtools.com/archive/archive.php?id=22

Anonymous said...

Iconix is relevant because of it's sales pitch; nothing more. In fact, it's nothing more than RUP with robutness diagrams instead of prototypes. Throw all the "agile" "SOA"-ish buzzwords at crap you want. What you get is the same old crap with a new sales pitch. It's appropriate here because it is another mess.

Unknown said...

@Anonymous

From your point of view, at least I am consistent my mess.

From my point of view, you're talking serious bullshit. I'd be interested in knowing what process you use.

Ashish Mittal said...

Hey,
I think iconix is partly applicable as I have documented and implemented lot of projects in java as well as PHP but I personally feel that its good to have the iconix process and thats because there is no hazzles of having the business logic with the certain analyst...

Once you the basics of UML and Iconix... we can keep the whole team on one track and no lack of information between any of the developer as well as business analyst....

It is always helpful whether the team is old or new developers have joined the team. Moreover, if the old developers think they have the business logic that's the secret that they don't know since I with my team is having full logic documented and we keep proper control on the code, if any developers goes we still able to bring in new developer and bring him on the track within 3 days of time...

But surely it needs time and resources to manage the whole stuff documented... but if a person compare the time with the team attrition rate its the best... we have...

Thanks
Ashish