The shape of the lesson
By the end of the lesson, learners can
- The five stages: Whatever life cycle a team follows, the same five kinds of work have to be done.
- Waterfall: one pass: The waterfall model (Fig. 1) is linear and sequential.
- Iterative and RAD: Both of these life cycles accept that requirements change.
- Stages: analysis, design, coding, testing, maintenance.
- Waterfall: linear, one stage at a time; best for fixed, clear requirements.
- Iterative: repeated cycles, each adds to a working version.
- RAD: quick prototypes, constant user feedback, parallel time-boxed modules.
One picture every idea returns to
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.
Forty-five minutes, phase by phase
| Time | Phase | What happens in the room | Grouping |
|---|---|---|---|
| 0 to 5 min | Hook: predict | Open with the question in the title, From idea to release.. Real programs are not written in one sitting. Put the figure on the board: it is the one picture every idea in the lesson returns to. | Whole class, then pairs |
| 5 to 13 min | Teach and check: The five stages | Whatever life cycle a team follows, the same five kinds of work have to be done. | Whole class, then pairs |
| 13 to 21 min | Teach and check: Waterfall: one pass | The waterfall model (Fig. 1) is linear and sequential. | Pairs |
| 21 to 30 min | Teach and check: Iterative and RAD | Both of these life cycles accept that requirements change. Model the worked example Choosing a life cycle on the board, one line at a time. Your turn: Suggest a suitable life cycle for the control software of a hospital drug-infusion pump, whose requirements are fixed by regulations. Give one reason. | Frayer Model |
| 30 to 36 min | Check | The four Stage 1 questions from the student lesson, answered on mini whiteboards or by show of fingers. Re-teach the one most get wrong. | Individual, then whole class |
| 36 to 43 min | Plenary | The exam-style questions from Stage 2, one at a time: thirty seconds alone, then a random call. The feedback lines in the key give the examiner's wording. | Individual, random call |
| 43 to 45 min | Exit and homework | Set the worksheet below (6 questions, 18 marks). Learners self-assess against the objectives before they leave. | Individual |
Protect the parts that carry the learning
The sequence carries about fifty minutes of material, so the lab is driven by one student while the class predicts rather than explored freely. Times are a guide.
Protected: the check at 30 minutes. It is the only individual read on whether the key idea landed, and it is not cut.
Cut first if the build overruns: the last check in Iterative and RAD, never the check or the plenary.
In a 60 minute block: run worksheet questions 1 to 3 in class as a Rally Coach set and model both the hardest worked example and its check live.
Frayer Model
Pairs fill a four-box grid for the key term: definition, characteristics, examples and non-examples. The non-examples box is where the misconceptions surface, so give it the most time.
The full structure, with its variations and the other twelve, is on the cooperative-learning page.
What to head off, and how
| Trap learners fall into | Teaching move that pre-empts it |
|---|---|
| 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. |
| "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. |
Program development life cycles: worksheet
6 questions, 18 marks. Written in the style of the papers; no past paper question is reproduced.
Explain the purpose of a program development life cycle.
Describe what happens in the analysis, design and testing stages.
Describe the principles of the waterfall model and give one benefit and one drawback.
Describe the principles of the iterative model of development.
A games company wants a new mobile game. The designers expect to change the gameplay many times after watching players try it, and a demo is needed in two months. Recommend a life cycle and justify your choice.
Give two drawbacks of using RAD for a very large banking system.
Answer key and marking notes
- It splits development into defined stages, each with clear outputs and deadlines, so the project can be planned, managed and monitored.
- So that the final program meets the user's requirements, on time and within budget.
- Analysis: investigate the problem and current system, agree the requirements (requirements specification).
- Design: plan the solution, e.g. modules, algorithms, data structures, interface, test plan.
- Testing: run the program against the test plan to find errors and show it meets the requirements.
- Stages are followed in sequence, each completed (and signed off) before the next begins.
- The output of each stage is the input to the next; there is little or no going back.
- Benefit: easy to manage, with clear milestones and full documentation (or suits fixed requirements).
- Drawback: no working program until late / hard to change requirements / client sees the product only at the end.
- A simple version meeting part of the requirements is built first.
- Each iteration repeats design, coding and testing to add or improve features.
- This continues, with feedback after each iteration, until the full system is complete.
- RAD (accept iterative with a matching justification).
- Requirements are expected to change, which RAD handles well.
- Prototypes can be shown to players for feedback and refined.
- Development time is short; modules can be built in parallel and existing components reused.
- Hard to manage with many teams; needs highly skilled developers and users committed throughout.
- Less documentation and less attention to non-functional requirements such as security and performance, which a bank needs.
6 multiple-choice questions on this lesson
From the topic question bank. Assign them in the app for a marked score in your gradebook, or run the topic as a class game.
During which stage of the program development life cycle are the user interface designs and the test plan produced?
- ADesign
- BAnalysis
- CCoding
- DTesting
What is the main purpose of following a program development life cycle?
- ATo split development into planned stages with clear outputs, so the project can be managed and meets the requirements
- BTo guarantee that the finished program contains no errors at all when it is released to users
- CTo remove the need for any maintenance once the finished program has been released
- DTo let programmers start coding straight away, before anyone has agreed the requirements
A small charity wants a donations website. The volunteers are unsure which pages they need, can meet the developers every week to try out early versions, and want something working within a month. Which choice is best?
- ARapid application development, because prototypes can be built quickly and refined with weekly feedback
- BWaterfall, because each stage is completed and signed off before the next one begins
- CWaterfall, because the volunteers will see the finished website only at the very end
- DIterative, because the whole system must be fully understood at the start to divide it up
Which of these is a drawback of the iterative model?
- AThe whole system must be understood well enough at the start to divide it into increments
- BNo working version of the program is available until the very end of the project
- CChanges to the requirements cannot be included once the first coding has begun
- DThe customer gives no feedback on the program until the acceptance testing stage
Which statement correctly compares the waterfall model with rapid application development (RAD)?
- AWaterfall produces thorough documentation at every stage, while RAD produces less and gives less attention to non-functional requirements
- BWaterfall copes easily with changing requirements, while RAD needs the requirements fixed before any prototype is built
- CWaterfall needs users to be involved throughout, while RAD involves them only when the finished program is accepted
- DWaterfall develops modules in parallel by small teams, while RAD completes one stage at a time in a fixed order
A company is writing the control software for a railway signalling system. The requirements are set by safety regulations and will not change, and every stage must be fully documented and checked before the software is certified. Which life cycle is most suitable?
- AWaterfall, because fixed requirements and full documentation with sign-off at each stage suit it
- BRapid application development, because prototypes can be shown to the regulators every week
- CIterative, because a simple version can be put into service and improved in later versions
- DRapid application development, because little planning is needed before coding begins
Quiz key
Design plans how the requirements will be met: modules, algorithms, data structures, interface designs and the test plan. Analysis comes before and produces the requirements specification. Coding writes the program from the design, and testing is when the test plan is actually carried out.
A life cycle breaks a project into manageable stages with deliverables and deadlines, so progress and cost can be tracked and the program is more likely to meet the requirements on time. No method guarantees an error-free program. Maintenance is itself a stage of the life cycle. Agreeing the requirements during analysis comes before coding in every life cycle.
RAD suits unclear, changing requirements, users who are available throughout and a short deadline: prototypes are shown and refined quickly. Waterfall needs fixed requirements at the start, and the client seeing the product only at the end is a drawback, not a reason to choose it. Needing to understand the whole system at the start is a drawback of the iterative model, which does not fit unsure volunteers.
To build the system in increments, the developers must understand it well enough at the start to split it up; the model also needs more management and can overrun. A working version early, changes being cheaper to include, and feedback after each iteration are all benefits of the iterative model. The other three statements describe drawbacks of the waterfall model.
Waterfall documents each stage fully before sign-off; RAD has little up-front planning, so it produces less documentation and can neglect non-functional requirements such as performance. The other statements are reversed: RAD copes with changing requirements and involves users throughout, and RAD (not waterfall) builds modules in parallel to time limits, while waterfall goes one stage at a time.
Waterfall works best when the requirements are clear and fixed at the start, and each stage is completed, documented and signed off, which suits safety-critical software. RAD produces little documentation and is designed for changing requirements, and minimal planning is a risk, not a benefit, here. Putting a partial signalling system into service and improving it later would not be acceptable for certification.
Slides for this lesson
A projectable deck for every pack is on the way. Until then, present the student lesson full screen: its sections, figure and lab tabs follow the same order as the plan above.