OCR A-Level Computer Science H446
Processors: Structure, Performance and Types
Input, Output and Storage
Systems Software
Applications Generation
Software Development
Types of Programming Language
Exchanging Data
Networks
Web Technologies
Data Types and Number Representation
Data Structures
Boolean Algebra
Legal, Moral, Cultural and Ethical Issues
Elements of Computational Thinking
Problem Solving and Programming
Algorithms
Software Development
Choosing a methodology: merits, drawbacks and fit
- 3 things to know
- Component 01
Overview
Recall questions on choosing a development methodology for stated projects, whether waterfall is obsolete, customer involvement, the trade-off between documentation and speed, cost estimation, and what goes wrong when agile loses its architecture.
What you need to know
Answer each one before you reveal it.
Explain the trade-off between documentation and speed across these methodologies.
Why can the final cost be estimated more reliably under waterfall than under agile?
Questions from this subtopic
Each one with the model answer underneath.
- 1
Is the waterfall lifecycle obsolete? Argue the case.
Model answer
No. It is a poor fit for projects where requirements are unclear or volatile, which is most commercial software, and that is why iterative methods dominate. But where the requirements really are fixed and known in advance - a system built to a published legal standard, a replacement for an existing system with identical behaviour, a safety-critical component that must be certified - its predictability and its complete documentation trail are genuine advantages that agile does not offer. It also copes better when the customer cannot supply continuous involvement, and when the work is contracted out at a fixed price. It is the wrong default, not a discredited method.
- 2
A start-up is building a consumer app in a market where competitors release features monthly and it is not yet certain what users will want. Recommend a methodology and justify it.
Model answer
Agile. The requirements are genuinely unknown and will change as user behaviour is observed, which is exactly the situation waterfall handles worst. Short iterations let the company release early, measure what users do, and re-prioritise, so effort is not spent building features nobody wants. Speed to market matters more than exhaustive documentation, the team is small, and the customer - here, the company's own product owner - can be involved continuously.
- 3
A government agency contracts a supplier to build a payroll system that must implement tax law exactly as published, at a fixed price agreed in advance. Recommend a methodology and justify it.
Model answer
Waterfall. The requirements are defined by legislation, so they are known in full at the start and will not shift during the build, removing the main reason for iterating. A fixed price and a public tender need a scope, a cost and a date settled in advance, which waterfall gives and agile does not. The thorough documentation at each stage supports audit and the long maintenance life such a system will have, and the agency need not provide a full-time representative to the supplier's team.
- 4
A team is building the flight control software for a new aircraft, using a novel sensor technology that has never been flown. Recommend a methodology and justify it.
Model answer
The spiral model. The defining feature of this project is technical risk - nobody yet knows whether the new sensor approach will work - and the spiral model exists to attack the largest risks first, with a prototype in each cycle to prove or disprove the approach before the rest of the system is committed to it. The project is also large, expensive and safety-critical, so the cost and complexity of formal risk analysis are easily justified, and the project can be halted after a cycle if the risk proves unacceptable.
- 5
A small business needs an internal booking system in six weeks, and its staff are available to comment on progress. Recommend a methodology and justify it.
Model answer
Rapid application development. The deadline is short and firm, the system is a straightforward interactive business application of the type RAD suits, and the users are on hand to react to prototypes. Building a working prototype immediately and refining it with their feedback will get a usable system in place far faster than analysing and documenting a full specification first, and much of it can be assembled from existing components.
- 6
A bank needs a new transaction processing component where a defect could cost millions, and it can afford to embed a business expert with the team. Recommend a methodology and justify it.
Model answer
Extreme programming. Its defining practices target exactly the problem here: pair programming reviews every line as it is written, and writing the tests before the code produces a comprehensive automated suite that catches regressions in a component that must never be wrong. Continuous integration keeps the build always working, and the on-site expert - which the bank has said it can supply - resolves questions about complex financial rules immediately rather than leaving developers to guess.
Other ways to work this
The same content, four other ways.
What is inside Levo
Six ways to work the same material.
Every question in Software Development, on a schedule.
Attempt a question from memory, write the correct version, then attempt it again. Levo records the jump between your first attempt and your last, and brings each question back on the day you are due to forget it.
Or £46 a year, about £3.83 a month. Cancel anytime.