SDLC phases and process models: the same phases, different loops

Every model runs the same phases; models differ in how long each loop is and when users first see working software.

Before you read: predict

ExamHall's anti-cheat team is planning its next feature: a flag for candidates who paste text into an answer box. "We're agile now, so we skip writing requirements and designs," the team lead says. "Developers start coding on Monday, and proctors will first see the flag at launch, in ten weeks," she adds.

Which reply do the Agile Manifesto and the SWEBOK Guide support?

The 30-second version

Requirements, design, build, test, release and operate happen in every project. Waterfall and the V-model make one pass; iterative and agile repeat the phases in short loops. Feedback comes when a check, or a user, can see the mistake, and the team builds on it until then. Ask where each defect entered and which check should have seen it.

Every model runs the same phases; models differ in how long each loop is and when users first see working software.

How it works

Step 1 of 13

Same phases. SWEBOK's definitions of waterfall, spiral and incremental development all list requirements, design, implementation and testing; installation and operation follow. [S1]

In the kitchen

the surfer's account of her waves and style → requirements (step 1)
the drawn outline, then the shaped blank → design, then build (step 1)
ding repairs over the years → operate and maintain (step 1)

Analogy: A custom surfboard (board craft)

A surfer orders a board. She tells the shaper the waves she rides and how she surfs; he draws an outline, shapes the foam blank and checks it against his template; she rides it; for years after, he repairs its dings.

At the shaper's	In software
the surfer's account of her waves and style	requirements (step 1)
the drawn outline, then the shaped blank	design, then build (step 1)
the blank checked against the template	a test against the written spec (step 10)
the surfer riding it in the waves	feedback from someone with the need (step 10)
the board glassed and finished before she rides it	one pass (steps 3, 9)
a rough test board ridden each weekend, the next shaped from what she felt	short loops (steps 7, 9)
ding repairs over the years	operate and maintain (step 1)

Breaks down when: a glassed board is costly to reshape, while software can often be changed the next day.

In real terms: for each process, list its loops, who sees working software at the end of each, and which checks compare with the spec or with the need.

Examples, run for real

4.1 ExamHall EXH-4680 → MR !4980: the focus flag's false positives

Proctors complained that candidates switched to other apps unnoticed. ExamHall's anti-cheat team wrote a rule, built it and shipped it to every sitting in one release. EXH-4680 replays that timeline with synthetic figures; MR !4980 is the fix.

EXH-4680 · anti-cheat focus flag · proctor complaint in week 0, one release to every sitting in week 7
  phases       requirements w1 · design w2 · build w3–5 · test w6 · release w7 · operate w8+
  written rule flag a candidate whose exam window loses focus for over 3 s · proctors meant: switching to another app
  checks       unit tests w3–5 (spec): pass · code review w5 (spec): pass · staging QA w6 (spec): pass · proctor reports w8 (need): shows it, 38 of 120 flags false
  entered      requirements w1 · first shown w8, 7 weeks later · not held: proctor walkthrough of the rule w1 (need), the first check that could show it
MR !4980 · focus moving to the exam's own zoom and reader windows no longer counts · same week: 82 flags, 0 false

The rule entered in requirements: it said "focus", while proctors meant other apps. The unit tests, the code review and staging QA all compared the code with that written rule, so all three passed (step 10). The first check that compared it with the proctors' need ran a week after release, seven weeks after the rule was written. The phase where it should have been caught is requirements: a proctor walkthrough of the written rule against recorded sessions, in week 1 (step 11).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 7

On this lesson's feedback-timing model, four teams at a streaming company start a new feature on the same Monday:

Captions: 20 weeks of requirements, design, build and test in turn, then one release to viewers.
Downloads: a 16-week V-model plan.
Watch party: 30 weeks in 6-week iterations, each ending in a beta release to viewers.
Profiles: 24 weeks in 2-week sprints, each ending in a demo to the product team; from the fifth sprint on, each sprint's increment also goes to viewers.

Put the teams in order of when viewers can first give feedback on their feature, earliest first.

Your order

1empty
2empty
3empty
4empty

Tap the lines in the order you expect.

Question 2 of 7

On this lesson's feedback-timing model, a streaming app's spec says: "Show Skip Intro for every episode's intro." The team's checks for the feature:

day 2: the product team walks five viewers through the written spec;
from day 5: CI runs a unit test for each rule in the spec on every push;
day 12: QA tests the whole app on staging against the spec;
day 20: 200 beta viewers use the app.

On day 5 a developer pushes code that shows the button only when the intro is longer than 60 seconds.

Which check is the first that can show this slip?

Question 3 of 7

A streaming company's team is building a new TV app. Its plan, as written on two dates:

January, week 1: eight features, signed off by the product owner; launch on 30 June; budget $400,000.
April, week 13: the same eight features; launch on 15 September; budget $520,000.

Every four weeks the team ships the features it has finished to viewers.

In the SWEBOK Guide's terms, which life cycle is this?

Question 4 of 7

Four lines from a streaming team's notes on how it works.

Which line goes against the Agile Manifesto's principles?

Question 5 of 7

An interviewer asks: "Walk me through the lifecycle of a feature at your current company, from idea to production, and say where its bugs get caught." Use a feature you shipped, or ExamHall's paste flag from the opening question.

Write your answer in at most 150 words.

Your answer (optional, stays on this page)

Question 6 of 7

On this lesson's feedback-timing model, a streaming team plans 24 weeks for offline downloads. Requirements take weeks 1–2, and in week 1 the team writes that downloads expire after 48 hours, a misread: viewers need them for a 10-day trip. Building starts in week 3. Instead of one release in week 24, the team now releases to viewers at the end of every 6th week, and viewers' first reports arrive the week a release goes out.

How many weeks of building happen on the misread before viewers can first report it?

Question 7 of 7

A streaming company's VP lays out the plan for a new ad-insertion service: three months of requirements and design, five of building, one of testing, then launch to every advertiser. "Planning all nine months up front keeps the uncertainty low," she says.

Which reply does the SWEBOK Guide support?

Go deeper

Pro tip

Answer process questions with where feedback arrives. Asked "what process do you use?", name the loop's length and each place feedback arrives: review in hours, CI in minutes, staging, a canary, user reports in weeks. When: the first answer to any process question. Status: SELF (the row's pro tip; not run).

Source

S1 · SWEBOK Guide V4.0a, Software Engineering Process KA (IEEE Computer Society), https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf, PDF pages 221–229, text by pdfjs-dist 6.3.289 with line-end soft hyphens joined (swebok-v4-process.txt). "no ideal process, or set of processes exists: software processes must be selected, adapted, and applied as appropriate for each project and each organizational context." (step 2); "requirements definition, design, implementation, and testing occur in an overlapping, iterative (rather than sequential) manner" (steps 1, 6); "typically a concept phase, requirements phase, design phase, implementation phase, test phase, and installation and checkout phase" (step 1); "It implements a very strict process, in which one phase cannot be started until the previous one is finished." (step 3); "performed in that order, possibly with overlap but with little or no iteration." (step 3); "The waterfall model is document-driven." (step 3); "Many variants or extensions, such as the V-model" (step 4); "Predictive life cycles assume that the set of requirements that will be implemented is a closed set that will not undergo substantive change unless a force majeure occurs." (step 5); "Nevertheless, the Agile Manifesto does not say that documents (e.g. to define requirements) are not needed, documents are needed" (step 8); "One is that Agile is a method in itself, which it is not." (step 8); "Another is that Agile is “faster” than waterfall because you need not produce any document." (step 8); "The waterfall model was useful because it introduced a systematization in the development of software systems".
S2 · Manifesto for Agile Software Development (2001), https://agilemanifesto.org/ (agile-manifesto.txt). "That is, while there is value in the items on the right, we value the items on the left more." (step 8).
S3 · Principles behind the Agile Manifesto, https://agilemanifesto.org/principles.html (agile-principles.txt). "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." (step 7).

Steps 9–11 and 13 are this lesson's model and the row's pro tip; no source states them, and no cited key rests on them.

Checked against the tools and docs as of 2026-10-17.

Predict first