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
- Coding and build
- Testing and QA
- Release to users
What does the design phase decide?
- How the software will be shaped — its parts and how they fit together
- Which features and capabilities the finished software should ultimately have
- The exact lines of code that each developer will type
- How the finished software will eventually be handed over to its 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 those phases don't actually exist in real projects, only in books
- Because there are really exactly twelve phases in the lifecycle rather than eight
- Because the phases can be run in any order the team likes, so testing may come before requirements
Where is most of a typical system's life spent?
- Operating and maintaining it long after launch
- Writing the initial code in the build phase
- Gathering the requirements at the very start
- Running the test suite in the release phase
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 safely be skipped entirely
- The testing phase takes care of the design work instead, deciding the shape once the code is written
- Because there is a rule somewhere that forbids doing design work on small features
You got correct