Program Development Life cycle

Writing useful software is a large and complex job. If a developer just started typing code, they would risk building the wrong thing, missing important features, and producing an unreliable mess that is impossible to plan or manage.

A development life cycle solves this by dividing the work into ordered stages, each with a clear purpose. This gives several benefits:

• Requirements are agreed before coding begins, so the team builds the right system.
• The solution is designed before it is written, reducing mistakes.
• The program is tested systematically, so errors are found and removed.
• Progress can be planned, scheduled and monitored stage by stage.

The overall result is a more reliable product that meets the user's needs, delivered on time and within budget.

Every life-cycle model uses the same five core stages. What changes between models is how the stages are arranged (in one pass, or repeated). Read it as a story: work out what is needed, plan it, build it, check it, then look after it.

Stage	What happens	Key output
Analysis	Investigate the problem; gather and agree the user's requirements (interviews, studying current documents).	Agreed requirements
Design	Plan the structure of the solution: algorithms, data structures, file/database layout, user interface.	A design to build from
Coding	Turn the design into working program code. (Also called implementation.)	Program code
Testing	Run the program with test data (normal, boundary, erroneous); compare actual vs expected results.	A debugged program
Maintenance	After release, correct faults and update the program for changing needs.	A program kept fit for use

The stage order is itself examined — putting testing before coding, or design before analysis, loses marks.

The syllabus stresses the need for different life cycles depending on the program being developed. The single most important factor is the requirements:

• Are they clear, complete and stable (unlikely to change)?
• Or are they unclear and likely to change as the project goes on?

Other factors matter too: how quickly delivery is needed, how much formal documentation is required, the size of the system, and the availability and skill of the team and users.

These two ways of organising the same five stages capture the main difference:

The cascading shape gives the waterfall model its name: work flows down through the stages and does not flow back up.

Principle. The five stages are carried out in a single fixed sequence. Each stage is completed, documented and approved before the next begins, and you do not return to an earlier stage. Work flows steadily downwards like water over a waterfall.

When it works best. Projects whose requirements are clear, complete and unlikely to change — for example a payroll system or a system governed by fixed legal rules. Because nothing will change, fixing the requirements up front is an advantage, not a risk.

Benefits

• Simple to understand and easy to plan and manage — clear milestones and deadlines.
• Each stage produces thorough documentation and a formal sign-off, giving good traceability.
• Progress is easy to monitor because the stages are distinct.

Drawbacks

• Inflexible: because you cannot easily go back, any change to the requirements is costly and difficult.
• Testing comes late — errors are not found until near the end, where they are expensive to fix.
• The customer does not see working software until late in the project.

Both of these models reject the single-pass approach: they build software in repeated cycles so that change can be welcomed instead of feared.

Iterative model — principle. The software is built incrementally in repeated cycles (iterations). Each iteration produces a working part of the system and passes it through design, coding and testing; the next iteration refines or adds to it. The cycle repeats until the system is complete:

Benefit: changing requirements can be absorbed in the next iteration, and the customer sees working parts early and gives feedback. Drawback: it can be harder to plan and to document fully than waterfall.

Rapid Application Development (RAD) — principle. RAD aims to deliver software quickly through two key ideas:

1. Rapid prototyping — working prototypes are produced fast and refined repeatedly.
2. Heavy, continuous user involvement — users try each prototype and give feedback that drives the next version, so requirements are discovered as the system is built.

Benefits: very fast delivery; excellent when requirements are unclear or evolving; the final product fits real user needs because feedback is built in. Drawbacks: it needs a highly skilled team and strong, continuous user availability; if users cannot commit time, prototypes cannot be refined. It can also scale poorly to very large systems and may produce weaker formal documentation.

Iterative vs RAD: both repeat cycles, but RAD adds the emphasis on speed and on prototypes refined by constant user feedback.

Paper 2 loves to give a scenario and ask you to recommend and justify a life-cycle model. The marks are almost entirely in the justification, not the name.

A quick decision guide:

Project clue	Best model	Because
Requirements fixed, fully known, need strong documentation/sign-off	Waterfall	Single signed-off sequence suits stable requirements; inflexibility doesn't matter
Requirements may change; want feedback during development	Iterative	Change absorbed in the next iteration; customer feedback each cycle
Requirements unclear/evolving AND fast delivery needed	RAD	Rapid prototypes + continuous user feedback discover requirements quickly

How to write a top-mark justification:

1. Name the model.
2. Quote the deciding clue from the scenario (e.g. "the legal rules will not change").
3. Link the model's strength to that clue.
4. Acknowledge the drawback and explain why it doesn't matter here (or why it rules out an alternative).

Example: "Waterfall is best because the safety requirements are fixed and need full documentation; its inflexibility doesn't matter since nothing will change. RAD would be a poor fit — its strength is handling change, which isn't needed here, and its documentation is weaker."