Renowned software innovator and architect Grady Booch stated “People are more important than any process. Good people with a good process will outperform good people with no process every time”. Typically, software projects are inherently very complex due to the ever changing requirements and due to the ambiguity in expectations of different stakeholders. With the traditional waterfall approach, many times several original requirements may become totally irrelevant by the time the project completes. A lot of projects with multi-million $$$ investments end-up being big flops as the development teams fail to understand the real requirements of the stakeholders. As the project size grows, so does the probability of failure. Iterative Development Process and many variations of this process have greatly improved the success rates of software projects over the past decade or so. I summarize the traditional Waterfall approach and the Iterative Development Process below.Waterfall Model

The Waterfall model usually flows through the following stages:

Waterfall Model

In this traditional approach, the project starts with a lengthy requirements phase and moves to the design phase only after the requirements are well documented, signed-off and ‘frozen’. This is where the trouble starts as software requirements can hardly be complete at the beginning of the project. If there are any changes in requirements during the subsequent stages of the project, it follows a usually lengthy & cumbersome change management process. Especially changes originating in requirements at later stages of the project are nearly impossible to accommodate or result in significant additional budget. Another big drawback of the approach is that the stakeholders will get to see any meaningful working software only at the later stages of the implementation phase or early testing phase. Any drift in the understanding of the real needs of the stakeholders and the actual implementation of these requirements in the software being built are hard to mitigate or a time-consuming endeavor at that stage.

Iterative Development Model        

In this model the entire project is broken into several iterations where each iteration has its own small requirements, design, implementation, testing and deployment stages.

Iterative Development Model

The major shift in this approach is that the requirements are not considered final at the beginning of the project and never ‘frozen’. The inherent assumption is that the requirements will keep changing and will evolve over the course of the project. The lifecycle of the project is based on the successive enlargement and refinement of a system through multiple iterations. The output of each iteration is a tested, integrated and executable subsystem. At the end of each iteration, the stakeholders are given the opportunity to ‘play’ with the subsystem and their feedback and often ‘change requests’ are planned and incorporated into the subsequent iterations.

The advantages of this approach several:

  • Early visible progress of the project
  • Early feedback, user engagement and adaption, leading to a refined system that more closely meets the real needs of stakeholders
  • Complexity can be well managed
  • Critical & high-risk features of the system are addressed in earlier iterations
  • The learning / experience gained within an iteration is utilized in subsequent iterations

References:

Applying UML and Patterns by Craig Larman

MIBAR uses a proven implementation process that’s adapted to your unique business needs, giving you a smooth transition experience every step of the way. Learn more about our business software implementation process, or schedule a free consultation to get started.