The delivery lifecycle — study guide
The concept's fragments, read in order.
Software has a lifecycle, not a finish line
Building software is not a single leap from idea to finished program. It moves through a handful of recurring phases, each answering a different question: what to build, how to build it, the building itself, checking it, shipping it, and keeping it running. A common set of these phases is requirements, design, implementation, testing, deployment, and maintenance, though the exact names and the count vary from one source to another — you will see the same lifecycle drawn with five phases or with seven. Moving through software this way is like building a house - you decide what you need, draw up plans, build, inspect, and move in, then renovate later rather than being finished forever.
What makes it a lifecycle rather than a checklist is the last phase folding back to the first. Maintenance is not the end of the road; the fixes and changes it turns up become new requirements, and the phases begin again on the next version. Software that people actually use is never truly finished, so the loop keeps turning for as long as the software is alive.
Deciding what to build
The requirements phase works out what to build and why, before anyone argues about how. It is where the goal of the software gets pinned down — who it is for, what it needs to do, and how you will know it is doing it — turning a vague idea into something concrete enough to design against.
Getting this wrong is the most expensive mistake in the whole lifecycle. Every later phase rests on it: the design serves the requirements, the code serves the design, and the testing checks the result back against the requirements, so a misunderstanding here quietly spreads through everything downstream. The steady rule across software work is that the earlier a mistake is caught, the cheaper it is to fix — which makes a requirements error, discovered only much later, the costliest kind there is.
Deciding how to build it
Design decides how the software will be built before the code is written. It settles the structure — the major pieces, the interfaces between them, and how the data is shaped and moves — so that implementation has a plan to follow instead of a blank page. Where requirements fix what the software must do, design chooses the arrangement of parts that will do it.
Doing this before writing code is like drawing a blueprint before laying any bricks, since changing a line on paper costs far less than moving a wall that is already built. The payoff is in what changes cost: a decision about structure or architecture is cheap to revise while it is still a line in a document, and painfully expensive to revise once it has become load-bearing code that other code already depends on. Design is where those decisions are meant to be made and reconsidered, while they are still cheap.
Writing the code
Implementation is the coding phase, where the design turns into working software one piece at a time. Developers translate the structure and interfaces the design settled on into actual code that runs, filling in the plan with the real thing.
The code grows inside version control as it is written — the same commits and branches git tracks for any project — so the record of how the software came to be is kept alongside the software itself. Implementation is the phase people picture when they imagine building software, but it is only one phase: it goes smoothly exactly to the degree that the requirements and design in front of it were done well.
Checking it does what it should
The testing phase checks that the built software actually meets its requirements before it reaches users. It is the point in the lifecycle where the working software is exercised and compared against what the requirements asked for, so that defects surface while they are still cheaper to fix than they would be after release.
Here testing is one phase among the others, a place in the lifecycle rather than a full account of the craft. How testing actually works — what gets checked, what is worth automating, and how much is enough — is a concept of its own; this phase simply names where in the lifecycle that work belongs and what it is for: catching the gap between what was asked for and what was built.
Shipping it, then keeping it alive
Deployment puts the software in front of the people who will use it. It moves the finished build out of development and into the environment where it actually runs and serves real users, the moment the work stops being an internal exercise. In modern practice much of that move is automated rather than done by hand, though how that automation is built is a separate concern of its own.
Maintenance is everything after that, and it is where working software spends most of its life. Once real users touch it, bugs surface that no one anticipated, needs shift, and the world the software runs in keeps changing, so someone keeps fixing, adjusting, and extending it for as long as it stays in use. This is the phase that turns the lifecycle into a loop: the changes maintenance turns up are the next round's requirements. Working software is never finished; it is only maintained.
One pass, or many
There are two broad ways to run these phases. Waterfall runs them once, in strict sequence: finish requirements, then design, then implementation, then testing, then release, each phase completed before the next begins and little room to go back once a phase is called done. It is orderly, and its weakness is exactly that order — it assumes you got each phase right before moving on.
The iterative approach runs the phases in short, repeated cycles instead. Each cycle is a small pass through the same phases that delivers a working increment of the software, and the next cycle revisits them armed with what the last one revealed. Working this way is like writing an essay in drafts you keep revising, rather than trying to write it perfectly from start to finish in a single pass. Agile is the best-known name for this iterative style, and it is widely adopted — the dominant way modern software gets built — because a project's requirements rarely hold still long enough for a single straight-line pass to survive contact with them.
Even a solo project has phases
These phases are not a big-company ritual you get to skip on something small. Even a one-person website or a little command-line tool moves through every one of them: you decide what it should do, work out how, build it, check that it works, put it somewhere real, and then keep fixing it. The phases are still there whether or not you name them; skipping one usually means paying for it later.
Recognizing them is what guards against the most common mistake — starting to write code before you know what you are building, and then discovering in the middle that you were solving the wrong problem. You do not need heavy process to get the benefit. Just naming the phase you are in, even silently, tells you which question you are supposed to be answering right now, and keeps you from answering a different one by accident.