SDLC – Iterative and Incremental Model

SDLC – Iterative and Incremental Model

The Iterative and Incremental SDLC model unites an iterative design and workflow with an incremental build model. In this case, the team develops a product in cycles, building small parts in an evolutionary way.

The development process starts with the simple implementation of a small, strictly limited set of product requirements. The product is then enhanced and turned into more complete versions of itself until it’s complete and ready for deployment. Each iteration may contain design updates and new functionality.

A valuable feature of the Iterative and Incremental model is that development can be started without knowing all the requirements. This software development life cycle model contains the steps from other SDLC models — requirements gathering, design, implementation, and testing — but over the course of multiple builds. The development team takes advantage of what was achieved in previous builds to make the next build better.

The Iterative and Incremental SDLC model can look like a set of mini Waterfall or mini V-Shaped models.

Advantages of iterative and incremental SDLC model:

  • Produces business value early, as a working product is delivered with every increment
  • Can be done using scarce resources
  • Provides space for flexibility
  • Allows more focus on user value
  • Works well with parallel development
  • Detects problems at early stages
  • Easy to evaluate development progress
  • Uses lots of customer feedback

Disadvantages of iterative and incremental SDLC model:

  • Requires heavy documentation
  • Follows a predefined set of phases
  • Increments are defined by function and feature dependencies
  • Requires more user involvement by developers than Waterfall or other linear SDLCs
  • May be hard to integrate features between iterations if they aren’t planned in advance
  • Architecture or design problems may occur because of incomplete requirements at the early stages
  • Complicated to manage
  • Hard to predict the end of the project

Best for:

  • Complicated and mission-critical projects like ERP systems
  • Projects with strict requirements for the final product but with space for additional enhancements
  • Projects where major requirements are defined but some functionalities may evolve or enhancements may be made
  • Projects where the required technology is new and hasn’t been mastered yet or is only planned for some part of the product
  • Products with high-risk features that may need to be changed