Before the questions, make sure you can: explain what a software process is and why every team has one, even if it is not written down; describe the waterfall and V-model and say when a plan-driven process is the right choice; explain incremental and iterative development and Boehm's risk-driven spiral model; recall the four values of the Agile Manifesto and the roles, events and artifacts of Scrum (from CPS 3962) and apply them to a real team; use a Kanban board with WIP limits and apply Little's law (WIP = throughput × cycle time); explain continuous integration, continuous delivery and DevOps and compute the four DORA metrics from a deployment log; choose and justify a process for a given project using criticality, rate of change, team size, skills and culture; and design where AI assistants fit into a team's workflow, including a Definition of Done that covers AI-generated work.
A software process is the team's agreed way of turning ideas into working software: which activities happen, in what order, who decides, and how feedback flows back. Every team has a process — even "we just code" is a process, usually a bad one. There is no best process for every project. A pacemaker, a startup's app and a government tax system need different processes, because they have different risks. Choosing the process is an engineering decision.
Same activities, different arrangements
Chapter 1 listed the lifecycle activities: requirements, design, construction, verification and validation, deployment and operation, maintenance. Every process contains all of them. What changes between processes is:
- Order and overlap — one after another, or all a little bit every week?
- Size of each step — the whole system at once, or one small feature at a time?
- Feedback — how quickly do we learn that we were wrong?
- Documentation and control — how much is written, reviewed and signed before moving on?
Think of planning a trip. Plan-driven: you book every flight, hotel and museum ticket months in advance — perfect if nothing changes, expensive if something does. Agile: you book the first few days, then decide the rest as you learn what you like — flexible, but you cannot promise your boss the exact route. DevOps: you are also the driver and the mechanic, so you care about the car still working next year.
Plan-driven processes: waterfall and V-model
Waterfall. Each activity is completed and approved before the next begins: requirements → design → implementation → testing → deployment → maintenance. Each phase ends with a document (a requirements specification, a design document) that is reviewed and "signed off".
A surprising fact: the 1970 paper by Winston Royce that is usually cited for the waterfall warned against using it in its pure, single-pass form. Royce wrote that the simple sequence "is risky and invites failure" and recommended feedback between phases and building a pilot version first. The strictly sequential version is a simplification made later.
Strengths: clear milestones, easy to plan contracts and budgets, strong documentation (useful for audits and safety certification), works when requirements are well understood and stable. Weaknesses: users see working software very late; a requirements mistake is discovered during testing, when it is most expensive to fix; change is painful.
V-model. A variant that pairs every development phase with a testing phase, so that tests are planned when the corresponding specification is written:
| Left side (specify) | Right side (verify / validate) |
|---|---|
| User requirements | Acceptance testing |
| System specification | System testing |
| Architecture design | Integration testing |
| Module design | Unit testing |
| ↘ Coding ↙ |
The V-model is common in safety-critical domains (automotive, medical devices, avionics) where standards demand traceability from each requirement to its tests.
Waterfall is often mocked, but for a fixed-price contract with stable, regulated requirements (for example, firmware for an insulin pump that must be certified), a plan-driven process with heavy documentation is often the right choice. The mistake is using it where requirements are uncertain — like a new student app.
Incremental, iterative and the spiral
Incremental development delivers the system in pieces: increment 1 has the core features, increment 2 adds more, and so on. Users get value early and give feedback.
Iterative development repeats the whole cycle (a little requirements, design, code, test) several times, improving the same features each round.
Most modern processes are both: every iteration delivers a new, working increment.
Boehm's spiral model (1986–1988) made one idea central: manage risk first. Each loop of the spiral has four steps:
- Determine objectives, alternatives and constraints.
- Identify and resolve the biggest risks (for example with a prototype).
- Develop and test the next level of the product.
- Plan the next loop.
The spiral says: "Whatever scares you most, do it first." If the team is not sure the AI model can answer course questions well enough, build a quick prototype of Buddy in week 1 — before designing the login page, which is not risky at all.
Agile: a quick recall from CPS 3962
In February 2001, seventeen developers met in Utah and wrote the Manifesto for Agile Software Development. Its four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The manifesto adds: "while there is value in the items on the right, we value the items on the left more." Agile does not mean "no documentation" or "no plan" — it means the right side serves the left side.
Scrum (Scrum Guide, 2020 edition) is the most used Agile framework:
| Scrum element | Purpose | |
|---|---|---|
| Accountabilities | Product Owner | Maximizes the product's value; orders the Product Backlog |
| Scrum Master | Helps the team use Scrum well; removes impediments | |
| Developers | Build a usable Increment every Sprint | |
| Events | Sprint (≤ 1 month, often 2 weeks) | The container for all work |
| Sprint Planning | Choose the Sprint Goal and the work | |
| Daily Scrum (15 min) | Inspect progress toward the Sprint Goal, adapt the plan | |
| Sprint Review | Show the Increment to stakeholders, get feedback | |
| Sprint Retrospective | Improve how the team works | |
| Artifacts | Product Backlog (→ Product Goal) | Ordered list of everything that might be needed |
| Sprint Backlog (→ Sprint Goal) | The Sprint's plan | |
| Increment (→ Definition of Done) | Working, usable result |
The Definition of Done (DoD) is a shared checklist that every item must pass before it counts as "done" — for example: code reviewed, tests pass, documentation updated, deployed to the test server. Without it, "done" means something different to every developer.
Scrum is built on empiricism: transparency, inspection, adaptation. Every event is a chance to inspect something (the product, the plan, the process) and adapt it. A team that holds all the meetings but never changes anything is not doing Scrum.
Kanban: manage the flow, limit work in progress
Kanban (from Toyota's production system) does not use Sprints. The team visualizes work on a board with columns (e.g., To do → In progress → Review → Done) and sets a WIP limit (work-in-progress limit) on each active column: "no more than 3 cards in In progress". When a column is full, people must help finish work before starting new work — stop starting, start finishing.
Why limit WIP? Because of Little's law, a result from queueing theory that holds for any stable system:
average WIP = throughput × average cycle time
or, rearranged, cycle time = WIP ÷ throughput. If StudyBuddy's team finishes 2 cards per day (throughput) and has 10 cards in progress, each card takes on average 10 ÷ 2 = 5 days from start to finish. With the same throughput and only 4 cards in progress, cards take 2 days. Starting more work does not make work finish faster; it makes every item wait longer.
A team where everyone works on a different card "to stay busy" has high WIP and therefore long cycle times — and many half-finished features that give users nothing. Finishing one feature and releasing it beats having five features at 80%.
DevOps and continuous delivery
Traditionally, developers wrote code and a separate operations team ran it — and the two often blamed each other. DevOps is a culture and set of practices that joins them: the team that builds the software also deploys and operates it ("you build it, you run it"), with heavy automation.
- Continuous integration (CI): every developer merges small changes into the main branch at least daily; each merge automatically builds the system and runs the tests.
- Continuous delivery (CD): every change that passes the pipeline is ready to release at the push of a button.
- Continuous deployment: every change that passes the pipeline is released to users automatically.
The DORA research program (DevOps Research and Assessment) found four key metrics that predict both speed and stability:
| Metric | Question | Measures |
|---|---|---|
| Deployment frequency | How often do we release to users? | Speed |
| Lead time for changes | How long from commit to running in production? | Speed |
| Change failure rate | What % of deployments cause a failure that needs fixing? | Stability |
| Time to restore service | When a deployment fails, how long until users are OK again? | Stability |
A key finding: speed and stability go together. Teams that deploy small changes often also have fewer failures and recover faster, because small changes are easy to review, test and roll back. Knight Capital (Chapter 1) is the opposite: a large, rare, manual deployment.
Choosing a process
Barry Boehm and Richard Turner compared agile and plan-driven "home grounds" using five factors:
| Factor | Agile works best when… | Plan-driven works best when… |
|---|---|---|
| Criticality | Failures cost comfort or some money | Failures can cost lives or huge sums |
| Dynamism | Requirements change often | Requirements are stable |
| Size | Small teams | Large teams, many subcontractors |
| Personnel | Many experienced developers | Mostly juniors who need clear rules |
| Culture | People like freedom and change | People prefer clear roles and procedures |
Most real organizations use a hybrid: for example, Scrum inside a project that has fixed yearly budgets and a formal safety review before each release, or Kanban for bug fixes next to Scrum for new features.
StudyBuddy's choice. A small team, requirements that will change as students try the app, no life-critical failures, and a fixed semester deadline → Scrum with 2-week Sprints, a Kanban lane for urgent bugs, and a CI pipeline from week 1. But the privacy and security requirements are not allowed to change sprint by sprint — they are fixed early and checked in every Sprint Review (a small plan-driven island inside an agile process).
The AI angle: AI inside the process
AI assistants change the speed of some activities and create new bottlenecks:
| Activity | How AI helps | New risk |
|---|---|---|
| Requirements | Draft user stories, find missing cases | Invented requirements nobody asked for |
| Design | Suggest architectures, explain trade-offs | Fashionable designs that do not fit the context |
| Construction | Generate code and tests fast | More code than the team can review |
| Review | Summarize pull requests, spot simple issues | False confidence ("the AI reviewed it") |
| Operation | Explain logs and errors | Leaking production data into prompts |
The biggest change is the review bottleneck: when an AI can produce 500 lines in a minute, the limit on safe speed is how fast humans can understand and verify changes. Little's law applies here too: if code is generated faster than it is reviewed, unreviewed work piles up (WIP grows) and cycle time grows.
Good teams adapt their process explicitly:
- Small batches still win. Ask the AI for one small, reviewable change at a time — not a whole feature in one pull request.
- Spec first. Write the acceptance criteria (Chapter 3) before asking an assistant or agent to implement; review against the spec, not against the code's own comments.
- Update the Definition of Done, for example: "AI-generated code is read and understood by the person who commits it; it has tests that were written or checked by a human; no personal data was pasted into external tools; the AI-use log is updated."
- Measure, do not guess. Use DORA metrics and cycle time to see whether AI actually helps your team (remember the METR study: people feel faster even when they are not).
When asked to choose a process, never answer only "Agile because it is modern". Name the factors (criticality, requirements stability, team size, skills, culture, contracts/regulation) and show how each points toward your choice. Mention hybrid options when factors disagree.
Key takeaways
- A process decides the order, size, feedback and control of the same lifecycle activities.
- Waterfall / V-model: sequential, document-driven; right for stable, regulated, contract-based work; risky when requirements are uncertain. The V-model pairs each specification with a test level.
- Incremental + iterative development delivers working pieces and learns every cycle; the spiral attacks the biggest risks first.
- Agile values individuals, working software, collaboration and responding to change; Scrum has 3 accountabilities, 5 events, 3 artifacts, and a Definition of Done.
- Kanban limits WIP; Little's law: cycle time = WIP ÷ throughput — starting more work makes everything slower.
- DevOps / CI / CD: small, frequent, automated releases; the DORA metrics show that speed and stability go together.
- Choose the process from the project's risks and context; hybrids are normal.
- With AI, the bottleneck moves to review and verification: keep batches small, write the spec first, and put AI rules in the Definition of Done.
Ready? Close the notes and practise.
30 questions. Predict the output before you check — that is the skill the exam measures.