What you'll learn

• How the main software development methodologies work: waterfall, agile, extreme programming, spiral, and RAD.
• The strengths, weaknesses, and best-use cases for each methodology.
• How to write clear algorithms using OCR-style pseudocode.
• How to follow an algorithm using a dry run and trace table.

Why software needs a development process

Software is rarely built by “just coding”. Real systems need planning, testing, user feedback, documentation, and maintenance. A development methodology gives a team a structured way to organise that work.

Common stages include:

1. Requirements analysis — finding out what the system must do.
2. Design — planning data structures, algorithms, interfaces, and architecture.
3. Implementation — writing the code.
4. Testing — checking the software works and finding defects.
5. Deployment — releasing the system for users.
6. Maintenance — fixing bugs, improving features, and adapting to change.

Different methodologies arrange these stages differently. Some move through them once in order; others repeat them many times.

The waterfall lifecycle

The waterfall lifecycle is a linear methodology where each stage is completed before the next one begins.

Typical waterfall order:

1. Requirements
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance

It is called “waterfall” because progress flows downwards through the stages, with limited movement back up.

Merits of waterfall

Waterfall works well when the requirements are stable and well understood. It produces clear documentation, which helps with contracts, safety checks, handover, and maintenance.

It is also easier to manage because each stage has defined outputs. For example, the design stage may produce diagrams and specifications before programming begins.

Drawbacks of waterfall

The main drawback is that users often do not see working software until late in the project. If requirements were misunderstood, the mistake may be discovered after a lot of work has already been done.

It also handles change poorly. A new requirement during testing may force the team to revisit design and implementation.

When waterfall might be used

Waterfall may be suitable for:

• Projects with fixed, clearly agreed requirements.
• Systems needing strong documentation.
• Contract-based work where each stage must be signed off.
• Safety-critical or regulated systems, although these may also use risk-focused models.

Agile methodologies

Agile is a family of iterative methodologies where software is developed in small cycles, with frequent feedback from users.

Instead of trying to specify everything at the start, an agile team builds a small useful version, reviews it, then improves it.

Agile often uses:

• User stories — short descriptions of what a user needs, such as “As a customer, I want to reset my password.”
• Sprints — short fixed time periods, often one to four weeks, in which a team builds selected features.
• Backlog — a prioritised list of features, fixes, and tasks.

Merits of agile

Agile handles changing requirements well. Users can give feedback early, so the product is more likely to match real needs.

It also allows early delivery of useful software. A system can begin with core features and grow over time.

Drawbacks of agile

Agile needs regular user involvement. If users are unavailable, feedback becomes weak.

It can also be harder to predict final cost, timescale, and scope because requirements may evolve. Documentation may be lighter unless the team deliberately maintains it.

When agile might be used

Agile is useful for:

• Apps and websites where user expectations may change.
• Start-ups testing ideas quickly.
• Projects where regular feedback is available.
• Systems where partial releases are valuable.

Extreme programming

Extreme programming (XP) is an agile methodology focused strongly on code quality, fast feedback, and adapting to change.

XP often includes:

• Pair programming — two programmers work together at one computer; one writes code while the other reviews and thinks ahead.
• Test-driven development (TDD) — tests are written before the code that passes them.
• Continuous integration — code is merged and tested frequently.
• Refactoring — improving code structure without changing what it does.
• Small releases — frequent delivery of working versions.
• Customer involvement — the customer or user representative gives regular feedback.

Merits of XP

XP can produce high-quality code because testing and review are built into the process. Pair programming can catch errors early, and TDD helps ensure the code meets requirements.

Drawbacks of XP

Pair programming can feel costly because two developers are assigned to one task. XP also needs discipline: if tests are skipped or feedback is unavailable, its benefits are reduced.

When XP might be used

XP suits small to medium software teams where requirements change often and code quality is important.

The spiral model

The spiral model is an iterative methodology that focuses on identifying and reducing risk.

Each loop of the spiral usually includes:

1. Setting objectives.
2. Identifying and analysing risks.
3. Developing and testing a prototype or version.
4. Evaluating the result and planning the next loop.

Merits of the spiral model

The spiral model is strong for large, complex, high-risk systems. Risks are considered early rather than ignored until testing.

For example, a team might build a prototype to test whether a chosen database can handle expected transaction volumes before committing to the full design.

Drawbacks of the spiral model

It can be expensive and complex to manage. It also requires people who can assess technical, financial, security, and safety risks accurately.

When the spiral model might be used

The spiral model may be suitable for:

• Defence systems.
• Medical software.
• Large financial systems.
• Projects where failure would be very costly.
• Systems using unfamiliar technology.

Rapid application development

Rapid application development (RAD) is a methodology focused on quickly building prototypes, getting user feedback, and refining the system.

RAD often uses reusable components, visual design tools, and close user involvement. The aim is speed and practical feedback.

Merits of RAD

RAD is good when users are unsure what they want until they see it. It can produce usable systems quickly, especially for user interfaces and business applications.

Drawbacks of RAD

The speed can lead to weak design if the team does not control quality. RAD is less suitable for systems where security, performance, reliability, or safety must be carefully engineered from the start.

When RAD might be used

RAD may suit:

• Database-driven business systems.
• Internal tools.
• User interface-heavy applications.
• Projects with tight deadlines and available users.

Comparing methodologies

Writing algorithms

An algorithm is a finite sequence of precise instructions for solving a problem.

In OCR H446, you may be asked to write or follow algorithms using pseudocode. Pseudocode is a language-like way of describing an algorithm without needing the exact syntax of a real programming language.

A good algorithm should be:

• Clear — each instruction has one meaning.
• Finite — it eventually stops.
• Correct — it solves the required problem.
• Complete — it handles the important cases, including edge cases.
• Maintainable — variable names and structure are understandable.

Basic building blocks

Most algorithms use three control structures.

Sequence

Sequence means instructions run in order.

Example:

total = 0
total = total + mark

Selection

Selection means the algorithm chooses between paths, usually using if, elseif, else, and endif.

Example:

if mark >= 40 then
    output "Pass"
else
    output "Fail"
endif

Iteration

Iteration means repetition. In OCR pseudocode, common loops include for…next, while…endwhile, and do…until.

Example:

for i = 0 to 4
    output scores[i]
next i

Following algorithms

To follow an algorithm, you perform a dry run: you track the values of variables step by step without actually running the program.

A trace table records how variable values change as the algorithm executes.

total = 0
count = 0

for i = 0 to 4
    if readings[i] > 0 then
        total = total + readings[i]
        count = count + 1
    endif
next i

if count > 0 then
    average = total DIV count
else
    average = 0
endif

output average

Writing better algorithms

When you write an algorithm in an exam or NEA design, first decide:

1. What are the inputs?
2. What processing is needed?
3. What are the outputs?
4. Are there repeated steps?
5. Are there decisions or edge cases?

For example, if you are asked to validate an age, you should consider whether values such as -1, 0, 17, 18, and very large numbers should be accepted or rejected.

A simple validation algorithm might be:

valid = false

while valid == false
    input age

    if age >= 0 and age <= 120 then
        valid = true
    else
        output "Age must be between 0 and 120"
    endif
endwhile

output "Accepted"

This algorithm repeats until the user enters a value in the accepted range.