Development methodologies

Waterfall, spiral, agile, extreme programming and rapid application development: how each works, when to use it, and planning agile sprints.

A14.2Software development, law and ethicsA level45 min

Every project passes through analysis, design, implementation and testing, but not in the same way. A methodology is an organised way of working through those stages: in what order, how often, and how closely the client is involved. The exam expects you to describe five, and, more importantly, to argue which suits a given project.

Waterfall

In the waterfall model the stages happen one after another. Each stage is finished, documented and signed off before the next begins, and its output flows down into the next, like water down steps.

• Strengths: clear stages and deadlines make it easy to manage and to cost; full documentation helps new staff and maintenance; requirements are fixed early, which suits contracts.
• Weaknesses: the client sees working software only near the end; a misunderstood requirement is found late, when it is most expensive to fix; it copes badly with change.
• Suits: projects with clear, stable requirements, such as safety-critical control software, or a system that must meet a fixed legal specification.

The spiral model

The spiral model (Barry Boehm, 1986) is driven by risk. The project goes round a spiral many times. On each loop the team:

1. decides the objectives for this loop;
2. identifies the biggest risks and reduces them, often by building a prototype;
3. develops and tests the next version;
4. reviews it with the client and plans the next loop.

The spiral widens as the project grows: early loops are cheap experiments; later loops build the real thing.

• Strengths: risks are found and dealt with early; the client reviews each loop; it suits projects where failure would be very costly.
• Weaknesses: it needs people skilled in risk analysis; all that analysis is expensive, and too heavy for a small project.
• Suits: large, expensive, high-risk projects: a new air traffic control system, or the first autonomous robot a company has ever built.

Agile methodologies

Agile is a family of methodologies built on the idea that requirements will change, so the team should welcome change rather than resist it. Work is done in short iterations (in Scrum, called sprints, often two weeks long). Each iteration delivers working software that the client can try, so feedback shapes the next iteration.

The client's needs are written as user stories ("As a teacher, I want the robot to beep when it arrives, so that I know a parcel is here"). Stories are held in priority order in a product backlog. Each is estimated in story points, and the number of points a team finishes in a sprint is its velocity, used to plan the sprints ahead.

• Strengths: the client sees progress early and often; changes are cheap to take in; problems surface within one iteration.
• Weaknesses: the final cost and date are hard to predict; less documentation is written; it depends on the client being available throughout; it is harder to run with a large or scattered team.
• Suits: projects where requirements are unclear or likely to change, such as a new app for users whose needs are still being discovered.

Extreme programming

Extreme programming (XP) is an agile methodology that takes good programming practices to the extreme. Its practices are what you should name:

• Pair programming: two programmers at one computer, one writing and one reviewing, swapping often.
• Test-driven development: the test for a feature is written before the code that makes it pass.
• Continuous integration: code is merged and tested many times a day.
• Small, frequent releases and a customer on site to answer questions and write stories.
• Refactoring: improving the structure of working code without changing what it does.

• Collective code ownership, shared coding standards, and a sustainable pace (no long overtime).

• Strengths: very high code quality; the tests make change safe; the customer gets exactly what they asked for.

• Weaknesses: pairing doubles the programmers per feature; it needs a committed customer; little design documentation is produced.
• Suits: small to medium teams whose requirements change often and where quality matters.

Rapid application development

Rapid application development (RAD) builds prototypes quickly and refines them with users in workshops, again and again, until the prototype becomes the system. Each part of the work is time-boxed: given a fixed time, and what is not done in the time is left out or put off. RAD relies on reusable components and tools that generate code, such as interface builders.

• Strengths: users see and shape the system early, so it fits their needs; working software arrives quickly.
• Weaknesses: users must give a lot of time; quick prototypes can lead to poorly structured, inefficient code; it scales badly to large or performance-critical systems.
• Suits: small to medium systems with a large user interface and unclear requirements, such as a booking system for the school's robots.

Comparing them

In an exam answer, pick the methodology, then link each reason to the scenario. "Agile, because the school's teachers do not yet know what reports they want, and two-week sprints let them try each one and ask for changes" earns marks; "agile, because it is flexible" does not.

Velocity in practice

A team plans sprints from the backlog and its velocity. Stories are taken in priority order; a sprint is full when the next story will not fit. A story bigger than a whole sprint must be split into smaller stories first.

VELOCITY = 8
backlog = [("stop at the wall", 3), ("beep on arrival", 2), ("report battery", 1), ("follow a line", 5)]

used = 0
for story, points in backlog:
    if used + points <= VELOCITY:
        used += points
        print(f"sprint 1 takes: {story} ({points} points, {used} used)")
    else:
        print(f"next sprint: {story}")
        break

Run this in the simulator

Task: plan the sprints

Plan the delivery robot's sprints. VELOCITY is the whole number of story points the team finishes in one sprint. backlog is a list of (story, points) tuples in priority order: story is a string, and points is a whole number of 1 or more.

1. Go through the backlog in order. Any story with more points than VELOCITY cannot fit in a sprint: print too big, split it: <story> and leave it out of the plan.
2. Put the remaining stories into sprints, in order. Add each story to the current sprint while the sprint's total stays at or below VELOCITY. When the next story would take the total over VELOCITY, that sprint is finished and the story starts a new sprint.
3. Print each sprint as sprint <n>: <stories> (<total> points), numbering from 1, with the stories separated by ,.
4. Finally print sprints needed: <n>.

Compare with VELOCITY in your code, not the number 8. The robot stays still.

# the two lines every program starts with: the commands, then the robot
from bugbot import *
connect()

VELOCITY = 8
backlog = [("drive to a bay", 5), ("stop at the wall", 3), ("beep when blocked", 2), ("map the room", 13),
           ("report battery", 1), ("follow a line", 8), ("avoid people", 5), ("log each delivery", 3)]

Challenges

1. Sprint 2 has only 3 points in it. Change the rule so a sprint keeps looking further down the backlog for stories that fit. What does this gain, and what does it cost the client's priorities?
2. A hospital wants software to control the dose from an infusion pump. Recommend a methodology and give three reasons linked to the hospital.
3. Explain why test-driven development makes refactoring safer.