Introduction
Software Development Life Cycles
Software development life cycles are used to plan and manage the software development process, from the beginning through to the end of the process. Which model you may choose to use depends on a number of factors, including:
- The time-frame for development
- The size of the project
- The budget (also whether the budget is tightly fixed)
- The type of software being developed (e.g. GUI driven versus database driven)
- Whether the design of the final project can be accurately conceived at the Analysis phase.
- Whether final product is intended to be static or constantly added to.
Waterfall Model
Waterfall Model (1970 – )
Originally designed to cater for building physical engineer projects such as bridges and buildings, the model was adapted for software in the 1970s
Used for:
- Large projects where the specification/requirements are unlikely to change
Advantages
- Very easy to see where the project is up to / whether it is on track
- Easy to manage from the top down – clear responsibilities
Disadvantages
- Not very useful in rapidly changing environments or where the end product is going to be constantly changing
- Slow to implement – often 1 year plus
Iterative Development
Iterative Development (Late 1970s + )
The iterative development model is an adaption of the waterfall model where initially only a subset of the full solution is initially created. Once this subset has been released the next iteration begins, each time round adding more components. The process doesn’t necessarily end.
Useful for
Rapidly advancing technology, were the end product might not initially be known.
Advantages
- Constant testing and user involvement means that the product should closely match user requirements
- Extra features can be added depending on the time remaining.
Disadvantages
- Difficult to manage and to known how long before the final product will be ready.
Marshmallow challenge Adv of iterative vs waterfall anecdote
RAD
Rapid Application Development ( 1990 – )
Note: CIE haven’t specified which version of the RAD model they are using so their specific model may differ from the one below.
The RAD process was a reaction to the limitations of traditional waterfall model development. The process is heavily prototype driven, with constant user and customer interaction required throughout the process.
Advantages
- Great for small teams or where the system has a highly modular design where each component is independent.
- Particularly useful for GUI driven applications where constant user feedback is desirable.
- Quick to develop and implement
- Good involvement from the customer / user all through the process
- Highly flexible – great for new technology or where the the final product is unknown.
Disadvantages
- A lack of control means it’s difficult to use with large projects/organisations.