Software Development Methodologies Zoo

[Waterfall - 1970]

The waterfall model is a sequential software development process (...) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

You can't stop a waterfall - meaning that if you're in the middle of a project and requirements change ... well ... let's say you're in troubles.

[V-Model - late '80s]

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

This is a zombie model, it's dead but plenty of ISO and CMM fanatics out there think V-Model is still pretty cool. V-Model is indeed a very good methodology for high-ceremony organizations for its ability to give management a sense of false security.

[Cowboy Coding - wild west]

Cowboy Coding is a term used to describe software development where the developers have autonomy over the development process. This includes control of the project's schedule, algorithms, tools, and coding style.

In an ideal world, this would be my favourite. Whenever I start my own company I am pretty sure I'll adopt and formalize Cowboy Coding [yippy kayay!].

[SCRUM - early '90s]

Scrum is an iterative incremental process of software development commonly used with agile software development. (...)

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similar to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers [chicken and pigs!].

During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potential shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.

Conceptually born in early '90s, SCRUM started being widely adopted 10 years later. It's like the model farm of AGILE software development with ScrumMaster to coordinate chicken and pigs. All you need to know is pigs do all the work.

[ICONIX - late '90s]

ICONIX is a software development methodology which predates both the Rational Unified Process (RUP), Extreme Programming(XP) and Agile software development. Like RUP, the ICONIX process is UML Use Case driven but more lightweight than RUP. Unlike the XP and Agile approaches, ICONIX provides sufficient requirement and design documentation, but without analysis paralysis. The ICONIX Process uses only four UML based diagrams in a four step process that turns use case text into working code.

A principle distinction of ICONIX is its use of robustness analysis (...). This process makes the use cases much easier to design, test and estimate.

ICONIX basically combines an AGILE approach with a robustness oriented low-ceremony design. This Process carries the strictly necessary amount of weight to still ride fast. This is the process I use at the moment, you can read more about it on this post.

[Extreme Programming - XP]

Extreme Programming (XP) is a software engineering methodology prescribing a set of daily stakeholder practices that embody and encourage particular XP values. Proponents believe that exercising these practices—traditional software engineering practices taken to so-called "extreme" levels—leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality.

Proponents of Extreme Programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.

XP is all about speed, and we all like speed if it means no documentation. Biggest drawbacks of this approach may be problems like feature creep and scope creep - moslty due to lack of persistent reference.

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