Development Methodologies Summarised

The Waterfall Model is the oldest and probably most commonly understood development methodology. The phases within this model are variously described, but fundamentally follow a progression of separate, consecutive phases:

• Requirements
• Design
• Coding and implementation
• Test
• Use

The main criticisim of this model is that it is not iterative or, in other words, each phase is conducted only once per component with feedback only to the preceeding step. In practical terms it means that there is no means of managing change to the requirements within the model itself. It also requires a highly disciplined approach to each phase, as a mistake or oversight in an early phase is usually costly to correct in a later phase. To mitigate these risks it is common to follow arelease early, release often approach to build confidence within the team and with the client.

The General V Model is a derivative of the waterfall model, but with project definition phases in the left arm and the relative equivalent test phases opposite in the right arm and coding forming the apex of the V.

Business requirements                       Operation & maintenance

System requirements               System testing

Technical Design           Unit testing

Coding and implementation

Spiral Model

The Spiral Model was intended for is in large, complex projects where iterations were greater than six months in duration. The steps can be generalised as:

1. Define system requirements by interviewing a representation of all users
2. A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives which can help in developing a cost effective project are analyzed and strategies to use them are decided. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A prototype is created. This is usually a scaled down approximation of the final product.
4. A second prototype is evolved by a four step process:
   1. evaluate strengths and weaknesses of the first prototype
   2. define the requirements of the second prototype
   3. planning and design
   4. construction and testing

Agile

The Agile Manifesto (2001) reads as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.