Real programs are not written in one sitting. Every professional project follows a life cycle: a planned set of stages from finding out what is needed to keeping the finished program working. Learn the five stages and the three life cycles you must compare: waterfall, iterative and rapid application development.
A program development life cycle is a structured sequence of stages used to plan, build and look after a program: analysis, design, coding, testing and maintenance. Its purpose is to make development organised and predictable, so that the program meets the user's requirements, on time and within budget. Different projects need different life cycles: the waterfall model completes each stage once, in order; the iterative model repeats the cycle to grow the program in versions; rapid application development (RAD) builds prototypes quickly with constant user feedback.
Whatever life cycle a team follows, the same five kinds of work have to be done. What changes from one life cycle to another is the order, and how often each stage is repeated.
| Stage | What happens | Typical output |
|---|---|---|
| Analysis | Investigate the problem and the current system (interviews, questionnaires, observation, documents); agree what the new program must do; check it is feasible. | Requirements specification |
| Design | Plan how the program will meet the requirements: decomposition into modules, algorithms, data structures, file and database design, user interface, test plan. | Structure charts, pseudocode, flowcharts, state-transition diagrams, interface designs |
| Coding | Write the program in a high-level language from the design; modules are tested as they are written. | Program code, annotated |
| Testing | Run the whole program with the test plan to find and remove errors and to show that it meets the requirements. | Completed test plan, corrected program |
| Maintenance | After the program is in use: correct errors that appear, adapt it to changes, improve it. | Updated versions |
Name the stage that matches the activity. Writing the test plan belongs to design; running it belongs to testing. Finding out what the user needs is analysis, not design.
The waterfall model (Fig. 1) is linear and sequential. Each stage is completed and signed off before the next begins, and the documents from one stage are the input to the next. In its strict form you do not go back up the waterfall.
| Benefits | Drawbacks |
|---|---|
| Simple to understand and to manage; each stage has a clear deliverable and deadline | No working program until late in the project, so problems are found late and are costly to fix |
| Thorough documentation is produced at every stage | Difficult to change the requirements once a stage is complete |
| Works well when the requirements are fully known, clear and fixed at the start | The client sees the product only at the end, so it may not be what they wanted |
| Progress is easy to measure against the plan | Unsuitable for large, complex or long projects whose requirements are likely to change |
"Waterfall is old so it is bad" earns nothing. It is the right choice when requirements are stable and well understood, for example a small program for a fixed specification or safety-critical software that must be fully documented.
Four quick checks. Each correct answer earns XP and records this skill on your profile.
In which stage of the program development life cycle is the requirements specification produced?
Which statement describes the waterfall model?
What is a key principle of rapid application development?
Which activity belongs to the maintenance stage?
Both of these life cycles accept that requirements change. They deliver something working early and improve it, but they do it in different ways.
| Iterative | Rapid application development (RAD) | |
|---|---|---|
| Principles | Start with a simple version that meets part of the requirements. Each iteration goes through design, coding and testing again and adds or improves features, until the full system is built. | Very little up-front planning. Working prototypes are built quickly, shown to users and refined. Modules are developed in parallel by small teams to strict time limits (time-boxing), reusing existing components and tools. |
| Benefits | A working version exists early; each small part is easier to test and debug; customer feedback after each iteration; changes in requirements are easier and cheaper to include; risk is spread across iterations. | Very short development time; users are involved throughout, so the product closely matches their needs; requirements can change at any time; early, constant feedback; components can be reused. |
| Drawbacks | The whole system must be understood well enough at the start to split it into increments; needs more management and more resources; repeated cycles can let the project overrun. | Needs highly skilled developers and users who are available and committed throughout; only suits systems that can be split into modules; less documentation and less attention to non-functional requirements (such as performance); hard to manage on very large projects. |
Unlocks once the four checks above are done. Worth more XP, written to AS Paper 1 and Paper 2 standard.
Which is a drawback of the waterfall model?
Which is a benefit of the iterative model?
Which is a drawback of RAD?
A government department needs a tax calculator built to a fixed, fully documented specification. Which life cycle best suits it?
This skill is now recorded on your profile. Keep the chain going.