The Development Life Cycle

The bill gets paid either way

The development life cycle is usually handed over as a list of phases to memorise in order, which makes it look like paperwork invented to stop programmers programming. It is the opposite. Every one of those phases happens on every project, whether anybody planned it or not. Nobody decides to skip testing; they meet testing when a user finds the fault. Nobody decides to skip checking whether a thing is possible; they meet that question halfway through, when the old data turns out not to come out of the old system at all. Nobody decides to skip training; they meet it when the staff quietly carry on using paper. So the only real choice is whether you meet each phase early and on purpose, or late and by accident. Everything in this module follows from that one idea, including why there is more than one way of running a project and why the choice between them matters.

Five words used precisely

These five turn up constantly and are used loosely almost everywhere else. Here they mean something exact.

Two parts of a launch that are not code

A school is replacing its paper attendance registers with an app. Five things still have to happen before it is genuinely in use. Tap the TWO that most people forget are part of putting a system live.

• The app is written and the faults found so far are fixed
• Every teacher is shown how to use it, including the ones who were absent that day
• The app is installed on the school servers
• The paper registers are collected in, so there is no longer a second way of doing it
• The icon is changed to the school colours

The one question that decides the approach

A charity wants a system for matching volunteers to jobs. They have never had one, they are not sure what they need, and they expect to learn a lot once people start using it. Which fact about this project matters most when choosing how to run it?

• That what they want is very likely to change while the system is being built
• That it is a charity, so the budget will be tight
• That they have never had a system before, so anything is an improvement
• That the users are volunteers rather than paid staff

Where the expensive changes land

Both ways of working cost the same to change something. The difference is WHEN you find out that it needs changing, and how much has been built on top of it by then.

Five things that went wrong, five different reasons

Put the phases in order

A project is being run deliberately rather than by accident. Put the phases in the order they are first met.

• Scoping and feasibility: work out what is being asked for and whether it can be done at all
• Analysis: find out in detail what the system must do, and write it down
• Design: decide how it will be built before building it
• Implementation: build it
• Testing: check it does what was written down
• Deployment: move the data, train the people, stop the old way
• Maintenance: fix, adapt and improve it for as long as it is used

What top marks look like here

Three things separate a strong answer on this topic from one that has simply learned the list. Never name an approach without naming the project fact that chose it. "I would use an approach that fixes everything in advance" is a guess. "I would fix everything in advance BECAUSE this is a payroll system, the rules are written in law and will not move, and the customer needs a firm price" is an answer. Always say what the choice costs you. Every approach buys something and sells something else. Deciding it all up front buys certainty and sells the right to change your mind. Working in small pieces buys the right to change course and sells the firm promise of what will exist at the end. An answer that describes only the upside has not finished. ⭐ And remember which phase is the longest. Building a system takes months; keeping it running takes years, and most of what is ever spent on a system is spent after it goes live. Any answer that treats launch day as the end of the story has the shape of the thing wrong.

Which way would you run it

For each project, decide whether it is safer to fix everything in advance, to work in small pieces and adjust, or whether either would genuinely do. Three lives.

The tailor and the cheap cloth

Somebody orders a coat. The cloth is expensive and there is exactly enough of it, so the first cut is the only cut. One tailor measures carefully, cuts the good cloth straight away, and sews. When the coat is tried on, the shoulders are wrong. There is no spare cloth, so the wrong shoulders stay. Everything they did was skilled, and the coat is still wrong, because the only chance to find out was at the end. The other tailor makes the whole thing first in cheap calico. It looks terrible and takes a day. It is tried on, the shoulders are obviously wrong, they are unpicked and redone in cheap cloth, and only then is the good cloth cut, once, correctly. The second tailor did more work and wasted less. ⭐ And notice what the cheap version is really for. It is not a rehearsal of the sewing. It is the cheapest possible way of finding out something that could otherwise only be learned when it was far too late to act on.

What makes it a justified choice

A student writes "I would use an approach that builds in small pieces." Select every addition that would turn that into an answer worth full marks.

• The fact about THIS project that makes it the right choice
• What the choice gives up, stated plainly
• Why the other approach would be worse here specifically
• A textbook definition of both approaches
• A note that this approach is the more modern of the two

Finish the life cycle sentences

The question of whether a thing can be done at all, with the time, money and data available, is its _____, and asking it on day one is far cheaper than discovering it on day sixty. The written statement of what the finished product must do is the set of _____, and everything built later is judged against it. Moving the data, training the people and stopping the old way of working together make up _____, which is why working code is not the same as a working _____. Afterwards comes _____, usually the longest phase of all and where most of the money goes. Choosing to fix everything in advance buys a firm date and sells the right to change your mind, so an answer that names an approach without naming that _____ has not finished.

Build the justification

A supermarket chain wants a system to predict how much bread each store will sell. Nobody has built one before and the managers admit they will want to change what it shows once they see it. Assemble the answer.

One system, four decisions

A leisure centre is replacing its paper booking book with a system. Each stage sets out where the project is and hands you the decision.

• At the first meeting the manager describes exactly what is wanted and asks the team to start building on Monday. Nobody has checked whether the twelve years of old bookings can be got out of the current spreadsheets. Decide.
• The manager has described what is needed. The receptionists, who will use it forty times a day, have not been asked anything. The manager says their time is too valuable to spend in meetings. Decide.
• Launch day is in a week. The system is built and tested. The plan is to switch it on at nine on Monday and take the paper book away the same morning. Decide.
• The system was written by an outside developer, who has now finished. The centre wants to add a members discount next year, and nobody at the centre can change the code. Somebody asks who actually owns it. Decide what should have happened.

Justify an approach

A hospital wants a system for booking outpatient appointments. The booking rules are set by national policy and will not change during the build, the finance office needs a firm price before it can be approved, and a fault could mean a patient misses treatment. Explain how you would run this project.

• Say which approach you would take, in your own words
• Name the facts about THIS project that decide it, not the general merits of the approach
• Say plainly what your choice gives up, and why that is affordable here
• Explain one thing that has to happen at deployment beyond the software working
• Finish by saying why the work does not end on launch day