1.2.3 - Software-development methods

Waterfall plans work through defined stages

A development methodology organises how a team discovers requirements, designs a solution, implements it, tests it, delivers it and maintains it. The choice affects when users see results, how changes are handled and what evidence is produced. Testing compares actual behaviour with expected results; evaluation asks whether the system meets the needs and objectives.

Analysis investigates the problem and agrees requirements. Design specifies structures, algorithms and interfaces. Implementation builds the system. Testing checks it against the requirements. Deployment introduces it to users, and maintenance fixes faults or adapts it afterwards. Real projects can return to an earlier stage, but changing an approved requirement late can require revising dependent design, code and tests.

Suppose a payroll replacement must follow well-established calculations and produce a specified legal report format. Clear requirements and documented approvals can help a team plan and demonstrate what it built. However, if staff only discover an awkward workflow after the whole interface is implemented, substantial work may need changing. Sequential planning makes stable requirements valuable; it cannot make an uncertain requirement stable merely by writing it down.

Agile uses short iterations and user feedback

The team prioritises work, implements and tests a manageable set of features, then reviews it with users before choosing the next work. Requirements can evolve as people learn from working software.

An increment is a usable addition, such as a search screen that works with real records. A prototype can explore an idea without being ready for release. Agile does not mean “no planning”, “no documentation” or “skip testing”. Plans are revisited, and enough documentation and tests are needed to support safe changes and maintenance.

For an unfamiliar visitor-booking service, users might try a simple booking increment and discover that a group needs several arrival times. The next iteration can revise that requirement before every feature is built. Frequent feedback reduces the chance of delivering an entire unsuitable system. It also requires available, representative users and disciplined prioritisation; uncontrolled requests can expand scope, complicate estimates and leave important architecture work neglected.

In formative project practice, keep evidence of the cycle: the requirement being addressed, design choice, implemented version, test outcome, feedback and resulting change. For example, a failed boundary test may justify changing a validation condition, followed by a passing retest. Evidence can appear throughout an iterative report rather than being confined to one fixed stage. This practice develops skills; it does not authenticate or complete a learner's assessed project.

Extreme programming supports frequent reliable changes

Extreme programming, or XP, is an agile approach with closely connected development practices. Small releases and close customer involvement expose changing needs. Pair programming has two developers work together: one writes code while the other reviews and considers the next decisions, with roles changing. This can reveal defects early and spread knowledge, though it uses two people's time and depends on productive collaboration.

In test-driven development, a developer writes a test for a small required behaviour, sees it fail, writes code to satisfy it, then improves the code while keeping the tests passing. Refactoring changes internal structure while preserving behaviour, for example extracting a repeated calculation into one routine. Continuous integration merges small changes frequently and runs tests to find conflicts sooner. Simple design and collective responsibility for code support continuing adaptation.

Imagine a team frequently revising discount rules. Tests for threshold values help detect when a new rule breaks an old one; pairing can spot a mistaken comparison; refactoring can avoid updating four copied formulae inconsistently. None guarantees correctness. An incomplete test set may miss a requirement, and poorly controlled rapid changes can still introduce defects. XP requires time and discipline for its practices, rather than merely releasing unfinished code quickly.

Spiral makes risk analysis part of each cycle

The spiral model develops through repeated cycles in which objectives and alternatives are established, risks are analysed, a solution is developed and checked, and the next cycle is planned. Its distinguishing focus is explicit risk analysis, rather than repetition alone.

A risk is an uncertain event or difficulty that could prevent success, such as an unproved sensor interface, unacceptable response time or an unreliable supplier. A team can build a prototype or perform an experiment to reduce the most serious uncertainty before investing in the full system. A prototype built to measure sensor delay may be discarded; its purpose is evidence about that risk.

For a flood-warning system using unfamiliar sensors, the first cycle might test whether the readings arrive reliably within the required time. If not, the next plan may use a different communication method. This can avoid committing to a design that cannot meet the requirement. Specialist risk assessment, repeated planning and prototype work cost time and money, so the model may be disproportionate for a small, well-understood utility.

Rapid application development uses prototypes and reusable parts

Rapid application development, or RAD, aims to deliver quickly through prototyping, frequent user involvement and reusable components or development tools. A team can show screens early, revise them with users and assemble supported components rather than build every element from scratch. Time limits encourage prioritising essential requirements.

For a small internal room-booking tool, a forms component and existing database tools may allow staff to try a prototype within days. Feedback can refine field labels and workflow before release. Reuse can save time, but the available components may constrain the design. A prototype's convincing appearance does not establish security, performance or reliability. Poor user availability, tightly coupled components or complex novel requirements can undermine the speed advantage.

Choose a method by the actual uncertainty. Stable, approved requirements and required stage documentation can favour waterfall. Evolving requirements and available users can favour agile; XP adds disciplined code and testing practices. Major technical risks can justify spiral. A short deadline, reusable components and a modest interactive scope can favour RAD. More than one method can be defended: explain the fit, the trade-off and how the team will manage it.