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.

Resources:

Iconix process website

Iconix Software Engineering website

Books References:

AGILE Development with ICONIX Process