Best Practices for Software Projects - Iterative Development

For years, the primary methodology for delivering software projects was the "Waterfall Method".  With the Waterfall method, all software requirements are gathered up front, designs are done for each requirement, and each feature is coded and tested before migrating to production.  For projects that exceed one year of development and implementation, there are risks of the project being cancelled (according to the Standish Group, about 31% are cancelled before completion).

Weaknesses of the Waterfall Method:

• Since all requirements are gathered (and designs done) upfront, the software life cycle is normally a year or longer.
• Business rules change along with market conditions.  Due to the long software life cycle, the software may no longer meet the needs of the company after being implemented.
• Testing is performed after all features are analyzed, designed and coded.  If a major design flaw is found during the testing phase, it may need to be addressed in many functional areas, causing the time to fix the defect much longer due to the large number of requirements.

Iterative Development Model

An alternative approach is the Iterative Development Life Cycle (sometimes referred to as the Spiral Life Cycle). 

With the Iterative Life Cycle, analysis is done just the same as with the Waterfall method.  However, once analysis is done, each requirement is prioritized as follows:

• High - These are mission critical requirements that absolutely have to be done in the first release. 
• Medium - These are requirements that are important but can be worked around until implemented.
• Low - These are requirements that are nice-to-have but not critical to the operation of the software.

Once priorities have been established, the releases are planned.  The first release (Release 1.0) will contain just the High priority items and should take about 1 to 3 months to deliver. 

Below are the advantages of the Iterative Life Cycle:

• The Design phase goes much faster, as designs are only done on the items in the current release (Release 1.0 for example). 
• Coding and Testing go much faster because there are less items to code and test.  If major design flaws are found, re-work is much faster since the functional areas have been greatly reduced.
• The client gets into production in less than 3 months, allowing them to begin earning revenue or reducing expenses quicker with their product.
• If market conditions change for the client, changes can be incorporated in the next iterative release, allowing the software to be much more nimble.
• As the software is implemented, the client can make recommendations for the next iteration due to experiences learned in the past iteration.

Our experience has found that you should space iterations at least 2 – 3 months a part. If iterations are closer than that, you spend too much time on convergence and the project timeframe expands. During the coding phase, code reviews must be done weekly to ensure that the developers are delivering to specification and all source code is put under source control. Also, full installation routines are to be used for each iterative release as it would be done in production.