Software Development — OCR A-Level Computer Science
Software Development explained
Software Development covers 3 specification points, including (a) Understand the waterfall lifecycle, agile… and (b) The relative merits and drawbacks of….
Read the full explanation
Open a point below for its explanation and revision guidance.
(a) Understand the waterfall lifecycle, agile methodologies, extreme programming, the spiral model and rapid application development.
This statement covers five methodologies and their defining features. Waterfall runs requirements, design, implementation, testing and maintenance strictly in sequence. Agile methods build software iteratively in short cycles, delivering working increments and accepting change. Extreme programming, a named agile method, uses practices such as pair programming, test-driven development and frequent small releases. The spiral model loops through planning, risk analysis, engineering and evaluation, refining the product on each pass. Rapid application development relies on quick prototyping, active user involvement and short timeboxed builds. Learn each method's key feature.
(b) The relative merits and drawbacks of different methodologies and when they might be used.
This statement asks you to weigh merits and drawbacks and judge when each methodology suits a project. Waterfall offers clear documentation, but late change is costly, so it suits stable requirements. Agile methods adapt to change and deliver working software early, but need close customer involvement. Extreme programming improves code quality through testing and pairing, yet it can be demanding on teams and clients. The spiral model manages risk explicitly, so it suits large, high-risk projects but is costly for small ones. Rapid application development delivers visible results quickly, but may compromise scalability. Judge each by project size, risk, requirement certainty and time pressure.
(c) Writing and following algorithms.
This statement asks for two linked skills: writing algorithms and following algorithms. Writing an algorithm means producing a clear, ordered set of steps that solves a stated problem, usually in pseudocode or a flowchart, with the inputs, processing and outputs identified. Following an algorithm means working through given steps exactly as written, usually by tracing values in a trace table, to predict the output for a given input. For example, given a loop that sums the numbers 1 to 5, you record the value of each variable after every iteration until the loop ends. Both skills support the course aim of checking that an algorithm is correct before it is coded.
Your focus
- State the defining feature of waterfall, agile, extreme programming, the spiral model and rapid application development.
- Identify the methodology described in a short scenario.
- Distinguish sequential methodologies from iterative methodologies using examples.
Show all 9 objectives
- Compare the merits and drawbacks of two methodologies for a given scenario.
- Justify a methodology choice using project size, risk and requirement certainty.
- Identify a context in which a given methodology is unsuitable.
- Write an algorithm in pseudocode to solve a stated problem.
- Trace a given algorithm with a trace table to predict its output for a test input.
- Identify the step at which an algorithm produces an incorrect value.
Software Development exam tips
Marking Points
- Identifies waterfall as a sequential, phase-by-phase lifecycle in which each stage completes before the next starts.
- Identifies agile methodologies as iterative and incremental, with short cycles that deliver working increments.
- Identifies extreme programming as a named agile method that uses pair programming and test-driven development.
- Identifies the spiral model as risk-driven, looping through planning, risk analysis, engineering and evaluation.
- Identifies rapid application development as prototype-based, with active user involvement and timeboxed delivery.
- Identifies waterfall's clear documentation as a merit and its costly late change as a drawback.
- Identifies agile's adaptability and early working software as merits, and its need for customer availability as a drawback.
- Links the spiral model to large, high-risk projects and notes its cost and complexity as drawbacks.
- Links rapid application development to fast delivery and visible results, and notes reduced scalability as a drawback.
- Matches methodology choice to project factors such as requirement certainty, project size, risk and time pressure.
- Identifies the inputs, processing and outputs when writing an algorithm for a stated problem.
- Writes steps in a logical order that a reader could follow without the original problem statement.
- Uses selection and iteration constructs correctly, with every branch and loop termination condition defined.
- Traces an algorithm with a trace table, recording variable values at each step to predict the output.
- Predicts the output for a supplied test input and identifies the step at which an incorrect value first appears.
Examiner Tips
- 💡Match each option to the defining feature a scenario highlights, such as fixed, well-understood requirements pointing to waterfall.
- 💡Eliminate options that misattribute features, for example one-pass development credited to the spiral model.
- 💡Check option wording for the key term, such as 'risk' for the spiral model or 'pair programming' for XP.
- 💡Pair each merit with a drawback for the same methodology so that your comparison is balanced.
- 💡Use the project's stated constraints, such as risk or deadline, to justify the choice of methodology.
- 💡Check whether an option describes a suitable context rather than a universally best methodology.
- 💡Name the inputs, processing and outputs before writing steps so that your algorithm has a clear purpose.
- 💡When tracing, complete one full trace table row for each iteration and use the given test data exactly as supplied.
- 💡Check that each step can be followed by someone who has not seen the problem, and test your algorithm with a simple input before finalising it.
Common Mistakes
- Treats extreme programming as separate from agile; correct this by recognising XP as an agile method with specific engineering practices.
- Describes the spiral model as a single linear pass; correct this by stating that it repeats loops, each refining the product.
- Confuses rapid application development with waterfall because both involve phases; correct this by noting that RAD relies on prototypes and user feedback within short timeboxes.
- Lists a drawback as a merit, such as presenting waterfall's inflexibility as an advantage; correct this by stating the effect on the project.
- Recommends waterfall for projects with unclear requirements; correct this by matching waterfall to stable, well-understood requirements.
- Claims agile removes all planning; correct this by noting that agile plans in short iterations and still depends on customer input.
- Writes a loop with no condition that ends it; define a termination condition so the algorithm finishes.
- Traces an algorithm by judging its purpose rather than stepping through each line; work through each line in order and update the trace table at every change.
- Records only the final output of a trace and omits intermediate variable values; record each variable after every iteration.