The Eight Phases at a Glance
The lifecycle is usually drawn as a handful of named phases. Different books split them slightly differently, but a common and clear version has eight: plan, gather requirements, design, build, test, release, operate, and maintain.
This topic is a quick walk through all eight — just enough to recognize each one. You don't need depth yet, because nearly every phase becomes its own chapter later. Think of this as the table of contents for the whole journey.
An everyday parallel: a kitchen taking an order. Plan the menu, prep the ingredients, cook the dish, plate it, taste it, serve it — and then clean down and reset for the next order. Software has the same rhythm, with names.
| # | Phase | The question it answers |
|---|---|---|
| 1 | Plan | Is this worth building, and roughly how? |
| 2 | Requirements | What exactly should it do? |
| 3 | Design | How should it be shaped? |
| 4 | Build | Write the code |
| 5 | Test | Does it actually work? |
| 6 | Release | Get it to users |
| 7 | Operate | Keep it running |
| 8 | Maintain | Fix and improve it over time |
Plan and Requirements
The first two phases decide what and why, before a line of code exists. Planning asks whether the thing is worth doing and sketches the shape of the effort. Requirements pins down exactly what the software must do — the features, and how well they must work. Get these wrong and everything built on top is built in the wrong direction. Chapter 4 is devoted to them.
Design and Build
Design decides how the software will be shaped — its parts, how they fit, what's hidden behind what — before the typing starts. Build is the phase everyone pictures: writing the actual code. Design is Chapter 5; the craft of building well is Chapters 6 and 7.
Test and Release
Testing proves the software does what it should and catches what's broken before users do — Chapter 9. Release (also called deployment) is the act of getting the finished, tested software into users' hands — Chapter 10. These two together are the bridge from "it works on our machines" to "it works for the world".
Operate and Maintain
Operating is keeping the live software running, watched, and healthy — Chapter 11. Maintaining is the long tail of fixing bugs, patching security holes, and adding improvements for years. As the last topic stressed, this is where most of a system's life is spent — and it loops right back to planning the next change.
The Phases Overlap
One honest caveat: this neat list of eight is a map, not a strict marching order. In real teams the phases overlap and repeat — a team designs a little, builds a little, tests a little, then loops back. Drawing them in a line makes them easy to learn; just don't picture a team finishing "testing forever" before anyone is allowed to think about release. How rigidly the phases are separated is exactly what the next chapter's methodologies decide.
To make it concrete, here's Cadence's "streak counter" in one line through all eight: Priya plans it and writes the requirement, Marcus designs and builds it, Nora tests it, the team releases it, then they operate and maintain it as users rack up streaks. That one-line journey is the seed of the full worked example in the final chapter.
- "The phases always happen strictly in order, once." They overlap and repeat. The clean line is a teaching aid; real work loops between phases constantly.
- "Design is optional for small things." Some design always happens — the only question is whether it's deliberate or accidental. Skipping the design phase doesn't skip the designing.
- "Operate and maintain aren't really development." Running and evolving software is most of the lifecycle, and a core part of the job — not an afterthought once the "real work" is done.
- These eight names are the vocabulary the rest of the course (and the rest of the industry) uses to talk about where work is in its journey.
- Recognizing the phase you're in tells you what question you should be answering right now — and what's premature to worry about yet.
- Seeing the phases map to upcoming chapters turns this course from a list of topics into one connected story.
Knowledge Check
Which phase decides what the software should do, before any code is written?
- Requirements
- Build
- Test
- Release
What does the design phase decide?
- How the software will be shaped — its parts and how they fit together
- What features and capabilities the finished software should ultimately have
- The exact lines of code to type
- How to get the software to users
Why does the topic say the clean line of eight phases is "a map, not a strict marching order"?
- In real teams the phases overlap and repeat rather than finishing one completely before the next
- Because the phases don't actually exist in real projects
- Because there are really exactly twelve phases, not eight
- Because the phases can be carried out in any random order at all, with no consequences whatsoever
Where is most of a typical system's life spent?
- Operating and maintaining it after launch
- Writing the initial code in the build phase
- Gathering the requirements at the very start
- Running tests before release
A team that skips the formal "design phase" on a small feature still ends up designing it. Why?
- Some design always happens — skipping the phase only makes it accidental instead of deliberate
- Small features genuinely need no design of any kind, so that whole phase can be skipped entirely
- The testing phase secretly does the design instead
- Because a rule forbids designing small features
You got correct