12 Software development
Choose a suitable development life cycle, refine a design and use testing evidence to improve a program.
Section 12 · Software development
Mapped to Cambridge International AS & A Level Computer Science 9618, 2027–2029 Version 2. These original lessons and self-checks are independent study support; they are not Cambridge papers, official marks or grades. The course does not yet provide a timed four-paper simulation or a locked-down Paper 4 programming environment.
Before you begin
- Use the 2027–2029 syllabus for your exam year. AS candidates study Sections 1–12; A Level candidates study Sections 1–20. Paper 4 uses a programming language chosen from Python, Java or Visual Basic in console mode.
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Which model is characterised by sequential completed stages?
What you will learn
- Explain the key representations, structures or processes in this syllabus section
- Apply the method to a new computer-science example
- Justify a design choice and check its limits
Life cycles organise development work
A waterfall model completes stages in sequence and suits projects with stable requirements, though changes late in the process can be costly. Iterative development repeats planning, building and evaluation; it can incorporate feedback but requires ongoing coordination.
Rapid application development uses short cycles, reusable components and frequent user involvement. It may deliver a prototype quickly, but depends on available users and careful scope management. Choose a model by considering requirements, risk, time and feedback needs.
Design and testing make quality observable
A design can use structure charts, pseudocode, flowcharts and data definitions to show modules, decisions and interfaces before implementation. A good module has one clear responsibility and a testable interface.
Testing compares actual behaviour with expected results. Normal, boundary and erroneous tests reveal different failures. A test plan records inputs, expected outcomes and observed outcomes; debugging identifies and corrects the cause, then regression testing checks that the fix did not break other behaviour.
Pause and explain
What is regression testing?
Worked example
A school is replacing a small timetable tool, and users are unsure about the best screens. Which development approach could test ideas early?
Show the worked solution
- User needs are not yet fully settled.
- An iterative or RAD approach can produce an early version for feedback.
- The team should still set scope, test requirements and maintain quality checks.
Answer An iterative or RAD approach supports early prototypes and feedback; the choice depends on user availability and project risk.
Try a topic test
Choose Easy, Normal or Difficult. Save your answers and open worked review after finishing.
Test this topic →From guided practice to a new situation
Write your answer and reasoning first. Use a hint only if you are stuck. The model solution is for self-checking; your written work is not automatically marked.
A safety-critical system has detailed, stable requirements but expensive late changes. Recommend a development model and one limitation to manage.
Give me a hint
Match predictability and documentation needs while acknowledging change costs.
Compare my reasoning
- Waterfall provides defined sequential stages and documentation.
- Its limitation is that changing requirements late can cause costly rework.
- Use reviews and early validation to reduce that risk.
Waterfall can fit stable requirements; early validation is important because late changes are costly.
Look for these in your work
- Model matched
- Relevant limitation
- Mitigation suggested
A system accepts a score from 0 to 100 inclusive. Give boundary tests and expected outcomes around the upper limit.
Give me a hint
Test the maximum valid value and the nearest invalid value on each side.
Compare my reasoning
- 99 should be accepted.
- 100 should be accepted.
- 101 should be rejected or reprompted.
99 accepted, 100 accepted, 101 rejected.
Look for these in your work
- Below-boundary tested
- Boundary tested
- Above-boundary tested
A bug fix changes a shared discount function. Describe a focused regression test plan.
Give me a hint
Test the changed case and unaffected routes that rely on the function.
Compare my reasoning
- Retest the failing discount case with its original expected value.
- Test another valid discount and a boundary such as zero or the maximum.
- Run representative checkout tests to check the shared function did not alter unrelated totals.
Retest the original bug, key boundaries and dependent checkout flows.
Look for these in your work
- Original failure retested
- Boundary covered
- Dependent behaviour checked
Common mistakes
- Saying waterfall is always bad or iterative is always best.
- Treating a test plan as proof that all possible inputs were tested.
- Fixing a bug without running regression tests.
What can you explain now?
Why include boundary values in a test plan?
Compare with the explanation
Errors often occur at the edges of allowed ranges.
Boundary tests check values at and around limits where conditions can be implemented incorrectly.
After trying it yourself, choose your next review. This is your self-assessment.
Your review choice appears on Today. Sign in to sync it across devices.
Make it stick
How do requirements, model choice, design, test data and regression testing fit into software development?
If you needed the solution, close it and solve the problem again from a blank page. A correct answer is stronger when you can explain the reason for each step.