Software Development Methodologies

In this post we’ll go through the different software development methodologies along with their advantages and disadvantages and when to use each model.

Iterative Model

An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

Consider an iterative life cycle model which consists of repeating the following four phases in sequence:

A Requirements phase, in which the requirements for the software are gathered and analysed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements.

A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

An Implementation and Test phase, when the software is coded, integrated and tested.

A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.

For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping.

Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made.

The iterative life cycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution.

The key to successful use of an iterative software development life cycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model.

Advantages of Iterative Model

  • Generates working software quickly and early during the software life cycle.
  • More flexible – less costly to change scope and requirements.
  • Easier to test and debug during a smaller iteration.
  • Easier to manage risk because risky pieces are identified and handled during its iteration.
  • Each iteration is an easily managed milestone.

Disadvantages of Iterative Model

  • Each phase of an iteration is rigid and do not overlap each other.
  • Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

Incremental Model

The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

The product is decomposed into a number of components, each of which are designed and built separately (termed as builds). Each component is delivered to the client when it is complete. This allows partial utilisation of product and avoids a long development time. It also creates a large initial capital outlay with the subsequent long wait avoided. This model of development also helps ease the traumatic effect of introducing completely new system all at once.

There are some problems with this model. One is that each new build must be integrated with previous builds and any existing systems. The task of decomposing product into builds not trivial either. If there are too few few builds and each build degenerates this turns into Build-And-Fix model. However if there are too many builds then there is little added utility from each build.

Advantages of Incremental Model

  • Generates working software quickly and early during the software life cycle.
  • More flexible – less costly to change scope and requirements.
  • Easier to test and debug during a smaller iteration.
  • Easier to manage risk because risky pieces are identified and handled during its iteration.
  • Each iteration is an easily managed milestone.

Disadvantages of Incremental Model

  • Each phase of an iteration is rigid and do not overlap each other.
  • Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

When to use Incremental Model

  • Such models are used where requirements are clear and can implement by phase wise. From the figure it’s clear that the requirements ® is divided into R1, R2……….Rn and delivered accordingly.
  • Mostly such model is used in web applications and product based companies.

Agile Model

The agile model is a combination of both iterative and incremental model by breaking a product into components where on each cycle or iteration, a working model of a component is delivered.

The model produces ongoing releases (iterative), each time adding small changes to the previous release (iterative). During each iteration, as the product is being built, it is also tested to ensure that at the end of the iteration the product is shippable.

The Agile model emphasizes collaboration, as the customers, developers and testers work together throughout the project.

An advantage of the Agile model is that it quickly delivers a working product and is considered a very realistic development approach.

One disadvantage of this model is that because it depends heavily on customer interaction, the project can head the wrong way if the customer is not clear about the requirements or the direction he or she wants to go.

V Model

The V Model is an enhanced version of the classic waterfall model whereby each level of the development life-cycle is verified before moving on to the next level. With this model, software testing explicitly starts at the very beginning, i.e. as soon as the requirements are written.

Here, by testing we mean verification by means of reviews and inspections, i.e. static testing. This helps in identifying errors very early in the life-cycle and minimizes potential future defects appearing in the code later in the life-cycle.

Each level of the development life-cycle has a corresponding test plan. i.e. as each phase is being worked on, a test plan is developed to prepare for the testing of the products of that phase. By developing the test plans, we can also define the expected results for testing of the products for that level as well as defining the entry and exit criteria for each level.

Like Waterfall, each stage begins only after the previous one has ended. This model is useful when there are no unknown requirements, as it’s still difficult to go back and make changes.

V Model - Advantages

  • Each phase has specific deliverables.
  • Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
  • Time concern in comparison with the waterfall model is low or even we can say 50% less.
  • Works well for small projects where requirements are easily understood.
  • Utility of the resources is high.

V Model - Disadvantages

  • Quite rigid, like the waterfall model.
  • Little flexibility and adjusting scope is difficult and expensive.
  • Software is developed during the implementation phase, so no early prototypes of the software are produced.
  • V Model doesn’t provide a clear path for problems found during testing phases.

When to use the V model

  • As per my knowledge I personally think / feel where time and cost is the constraints of the project then we can use such models for quick and cost effective delivery.
  • In comparison with waterfall model, V Model is more or less the same but the activity of testing starts very early, which leads to less time, and cost of the project.

Waterfall Model

The waterfall model is the oldest and most straightforward of the structured SDLC methodologies. There are strict phases and each phase needs to be completed first before going to the next phase. There is no going back.

Each phase relies on information from the previous stage and has its own project plan.

Waterfall is easy to understand and simple to manage. However, it is usually prone to delays as each phase needs to be reviewed and fully signed off before the next phase can begin.

Also, since there is little room for revisions once a stage is completed, problems can’t be fixed until you get to the maintenance stage.

This model works best when all requirements are known and flexibility is not required and the project has a fixed timeline.

Advantages of waterfall model

  • Each phase has specific deliverables and a review process.
  • Phases are processed and completed one at a time.
  • Works well for smaller projects where requirements are very well understood.
  • It reinforces the notions of “define before design” and “design before code”.

Disadvantages of waterfall model

  • Adjusting scope during the life cycle can kill a project
  • No working software is produced until late during the life cycle.
  • High amounts of risk and uncertainty.
  • Poor model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Poor model where requirements are at a moderate to high risk of changing.

When to use waterfall model

  • Such model is highly used where requirements are clear and there will be no changes in the development time. We can find such scenarios in defense projects, where requirements will be clear since before they write requirements they will analyses well.
  • We can also name this kind of life cycle model for migration projects, where requirements will be same only platform or languages may vary / change.
  • Also can use for projects where sponsor themselves will do testing activities, since till the completion of the coding we will not deliver the project.