Software Process Models

Processes, Process Control and Process Models

Before we can compare ways of building software, we need words for what is being compared. This section sets up that vocabulary: what a process is, what a model of a process adds, and the two basic ways of keeping a process under control. Every later section in this Part, and much of Part III, leans on these terms.

Process, process model, SDLC exam

Whatever the model, the same handful of SDLC activities turn up. The slides list them in order: requirements gathering (finding out what the system must do), system or architectural design (deciding how it will be structured), implementation (coding and putting the pieces together, called integration), testing, and evolution, which covers delivery, release and deployment as well as maintenance after go-live.

Process model versus method

Boehm (1988) sharpens the idea. A process model fixes two things: the order of the stages and the transition criteria for moving from one stage to the next. So a model answers exactly two questions: "What shall we do next?" and "How long shall we continue to do it?". A method is a different thing: it tells you how to do the work inside one phase. "Do design after requirements, and stop when the design document is signed off" is process; "draw UML class diagrams to do the design" is method.

Check yourselfA team lead says: "Our process is: we use user stories for requirements and write unit tests in JUnit." By Boehm's definition, has she described a process model?

No. User stories and JUnit are methods: they say how to work inside a phase. A process model would say what happens next and how long each stage continues, i.e. the order of stages and the criteria for moving on (for example "requirements are fixed before design starts", or "every two weeks we review and re-plan").

Defined versus empirical process control exam

"Process control" means how you keep the work heading where it should. There are two basic ways. Defined control fixes the steps in advance and follows them, trusting that the same inputs give the same output. Empirical control accepts that you can't foresee everything, so it steers by observing what actually happens, inspecting the result and adapting. What decides between them is how predictable the work is.

Software development is mostly novel work: each system is built once, often with people, tools or problems the team hasn't met before. So a purely defined process rarely fits it well. That is where the iterative, spiral and agile models come in: each one adds some empirical feedback to the plan.

Check yourselfWhich statements describe empirical process control? (Select all that apply.)

1. Estimates are treated as indicative only.
2. Change control is used because change is expensive.
3. It suits complex, volatile or novel environments.
4. The same inputs reliably give the same output.
5. Short development cycles are used to inspect and adapt.

A, C and E. B and D are the defined side: enforcing a plan with change control, and the "same inputs, same output" recipe idea. In an MRQ each wrong tick cancels a right one, so leave B and D blank rather than guessing.

Before SDLCs: Code-and-Fix and the Software Crisis

Formal life cycles weren't invented for fun: each phase they contain exists because its absence once caused real damage. The quickest way to see why is to look at what people did before, starting with the process almost every student has used.

The "student programming assignment" process

The lecture opens with a process you may recognise. Step through it, and watch each of its three problems point at an activity that is missing.

Code-and-fix (ad hoc development)

Code-and-fix is the simplest possible process: write some code, then edit it until it seems to meet the requirements, then deliver. There are no separate requirements, design or test phases. It is "ad hoc", meaning improvised for the situation rather than planned.

Surprisingly, it worked in the 1940s and 50s, and the slides give four reasons why:

1. Systems were small.
2. Developers were exceptionally able, often with higher degrees.
3. Developer, client and user were often the same person, so there were few requirements problems: you can't misunderstand yourself.
4. Programs often ran only once, so there was little need for maintenance or version control.

At scale it fails, and Boehm (1988) explains how. The useful way to read his list is that each failure created the need for one of the phases later processes introduced:

Check yourselfWhich were reasons code-and-fix worked in the 1940s–50s, according to the slides? (Select all that apply.)

1. Programs often ran only once.
2. Compilers caught most design errors.
3. Developer, client and user were often the same person.
4. Systems were small.
5. Requirements were written down formally.

A, C and D. The fourth reason on the slides is that developers were exceptionally able, often with higher degrees. B and E are invented: there were no formal requirements (that is the point of code-and-fix), and nothing about compilers appears in the list.

The 1960s software crisis exam

The cause of the crisis was growth. Computers became far more powerful, programs and user expectations grew with them, and the methods for building software couldn't keep up. Dijkstra (1972) put it memorably: when there were no machines, programming was "no problem at all"; once there were gigantic computers, programming became a gigantic problem. Kimble points to the economics behind this: hardware costs fell while software costs rose.

The symptoms (slides) were that most large projects shipped late or not at all, went catastrophically over budget, didn't work, or all three. The readings add that debugging took longer than writing the code, and that the code was almost impossible to maintain.

The response came at the 1968–69 NATO Software Engineering Conferences, held in Garmisch, Germany, in 1968 and in Rome in 1969. Attendees included Dijkstra, Hoare, Gill, Perlis and Naur. The term "software crisis" was coined there, and "software engineering" came into common use. The phrase was chosen deliberately to provoke: the point was that software should rest on the theory and discipline of the established engineering fields. One famous remark from the conferences (paraphrased) captures the mood: we build systems the way the Wright brothers built aeroplanes, by pushing one off a cliff, letting it crash, and starting again.

The outcome was a resolution to replace craft-style code-and-fix with disciplined, phased processes, the first of which was the waterfall.

Check yourselfIn an exam answer about the software crisis, sort these into cause, symptom and response: (a) debugging took longer than writing the code; (b) far more powerful computers raised program size and expectations; (c) the 1968 NATO conference in Garmisch; (d) projects went catastrophically over budget; (e) falling hardware costs alongside rising software costs.

Cause: (b) and (e): growth in computing power and expectations outran methods, and the economics flipped (hardware cheaper, software dearer). Symptoms: (a) and (d), along with late, cancelled or non-working projects and unmaintainable code. Response: (c), where "software engineering" came into common use and phased processes were resolved upon.

Waterfall: the Plan-Driven Approach (1970)

The waterfall answers code-and-fix's chaos with order: do each activity once, completely, in a fixed sequence, and write down the result before moving on. It is the classic plan-driven model, meaning the work follows a plan made up front rather than adapting as it goes. Understanding it well matters twice over: it is examined directly, and every later model is described as a fix for one of its weaknesses.

The model exam

The W02 slide splits the waterfall into six phases. Each phase answers one question and produces an output that the next phase works from. Step a project through it.

Notice that testing doesn't appear as a phase on this slide's version. The slides make the point that testing and QA (quality assurance: checking that the work meets its standards) still happen, through the review of every document before the next phase begins. Many textbook versions do draw a separate testing phase; Royce's original, in 2.4, has one.

A more realistic waterfall, with feedback

Real projects don't flow in one direction. An error found in design may reveal a mistake in the analysis; a fault found in implementation may force a design change. So the slides also show "a more realistic waterfall – with feedback", where work loops back, and where changed requirements re-enter at analysis.

Document-driven, and why that is costly

The waterfall is document-driven: what moves the project from one phase to the next is finishing a document, notably the SRS and the design. That gives managers something concrete to check and sign off. But it has a price. When an error is found late and the system must change, every affected document must be updated, and this is very costly.

Problems with documentation (slides). These explain why "just freeze the requirements" rarely holds. Very few real projects are insulated from change, even when customers really know what they want. Business and regulatory environments are beyond the control of developers and customers alike: a new law or a competitor's product can change what is needed. The technical environment (operating systems, libraries, network speed) changes too.

Check yourselfAccording to the slides, the waterfall works badly when… (Select all that apply.)

1. errors are likely in requirements elicitation, analysis or design.
2. the system is large.
3. requirements are hard to work out or likely to change.
4. the technology is mature.

A and C. Size alone isn't on the list (the comparison grid in 2.10 says waterfall suits any size, including large contracted work), and mature technology is a reason for a formal model, not against one.

Check yourself · past exam[PAST EXAM 433-443 1998 Q2, predecessor subject] Briefly describe the benefits of the waterfall process.

The guide's model answer gives seven benefits:

1. It is simple to understand, teach and manage.
2. Its distinct phases, each with deliverables and sign-offs, give clear milestones and visibility of progress.
3. Fixing the requirements early enables estimation, budgeting, fixed-price contracts and resource planning.
4. Doing design before code avoids the decay that code-and-fix suffers.
5. QA reviews at each phase stop errors propagating into later phases.
6. The documentation supports maintenance, staff turnover, outsourcing and audits.
7. It suits stable requirements, mature technology, and regulated or safety work.

What Royce Actually Said (1970)

The slides cite Winston Royce's 1970 paper as the source of the waterfall. The surprise, and a favourite exam trap, is that Royce never used the word "waterfall" and criticised the naive single pass. Knowing what he really argued lets you answer "evaluate the waterfall" questions with more than the usual clichés.

Royce's diagnosis exam

Royce argued that analysis then coding is enough for small programs run by the people who built them, but that for large systems this approach is "doomed to failure". He drew the steps as system requirements, software requirements, analysis, program design, coding, testing and operations, and he hoped that any iteration would stay between adjacent steps. He said he believed in the concept, but that this implementation "is risky and invites failure".

Royce's five fixes exam

Royce didn't abandon the sequence; he added five steps to make it safe. The guide says to memorise them. Step through to see each one bolted onto his model.

The history the slides leave out

Larman & Basili (2003) add some history. Iterative and incremental development (IID), building a system in repeated cycles that each add to it, is not new: it dates back to the 1950s.

Check yourselfWhich statements about Royce (1970) are correct? (Select all that apply.)

1. He named the model "the waterfall".
2. He said analysis-then-coding is fine for small programs run by their builders.
3. He recommended building a pilot of the critical areas first.
4. He argued testing should be minimised because it consumes resources.
5. He called the single-pass implementation "risky".

B, C and E. A is the classic myth: Royce never used the word. D inverts fix 4: testing is the biggest resource consumer and the biggest risk, so it should be planned, controlled and monitored, not minimised.

Check yourself · self-testWhat were Royce's five recommendations, and why does the paper matter?

Royce recommended (1) doing program design first, (2) documenting the design, (3) doing it twice (a pilot), (4) planning, controlling and monitoring testing, and (5) involving the customer. The paper matters because Royce called the single-pass sequence "risky": testing comes last, so problems surface late, with up to 100% overrun. The "waterfall" people attack is the naive version he criticised.

The V-Model

The waterfall's biggest weakness is that testing comes last, so nobody thinks hard about how each thing will be tested until it is too late. The V-model is a waterfall variant that fixes this one problem: it pairs each development phase with a test phase, and plans that test during the development phase. The guide treats it briefly, but its pairing is a favourite short-answer question.

Two terms help. Verification asks "are we building the product right?", i.e. does it match its specification. Validation asks "are we building the right product?", i.e. does it meet the users' real needs. In the V, every test level verifies the artefact opposite it, and the top level, acceptance testing, validates against the user needs. (Part VII covers both in depth.)

Traceability means you can follow a line from each requirement to the design that meets it and to the test that checks it, in both directions. In the V that line is drawn for you: each horizontal pair is a trace. That is why the guide recommends the V-model for safety-critical, embedded and regulated systems with stable requirements, such as medical devices and avionics, where auditors want proof that every requirement was tested.

Check yourself · self-testIn the V-model, which test level checks which artefact? Give one strength and one weakness.

Unit testing checks the module design, integration testing checks the architectural design, system testing checks the system specification, and acceptance testing checks the requirements. One strength is that tests are planned early, so the work is testable and traceable. One weakness is that the model is sequential, so working software arrives late and change is costly.

Check yourselfA team building avionics software with fixed, certified requirements is choosing between the V-model and Scrum. Which suits it better, by the guide, and why in one sentence?

The V-model: requirements are stable and the system is safety-critical and regulated, so early test planning and requirement-to-test traceability are exactly what certification needs, while the V-model's weakness (costly change) matters little when requirements won't change.

The Incremental Model exam

The waterfall makes the customer wait until the very end for anything usable, and all the risk lands at once. The incremental model keeps the up-front requirements but delivers the system in slices, so the most important part is in use early and the risk is spread out.

The idea

In the slides' version, you first capture the project requirements, then build the system as a series of "mini waterfalls", each running through analysis, design, development, testing and deployment, to give Release 1, 2 … n. Each increment is an operational, deliverable part of the product: something users can actually use, not a demo. Basic features come first and supplementary features later, so the product grows from A, to A+B, to A+B+C. A stable architecture (the overall structure: main components and how they connect) must be designed early, so that later increments fit.

Advantages and disadvantages

Three further features round out the model. A stable architecture must be designed early so later increments fit; change requests can be deferred to a later increment; and increments can be overlapped (pipelined, like an assembly line), because their requirements are already known.

Check yourselfWhich are disadvantages of the incremental model on the slides? (Select all that apply.)

1. It needs early definition of requirements to identify the increments.
2. The customer gets nothing usable until the end.
3. There is no iteration within an increment.
4. It cannot accept any change request.

A and C (the third listed disadvantage is that it needs good planning and design). B is the waterfall's problem: incremental delivers operational releases early. D is wrong: change requests can be deferred to a later increment.

Deliver each increment, or keep it internal? exam

A predecessor-subject exam asked about a real trade-off: do you hand each increment to the customer, or treat increments as internal milestones and deliver only at the end?

Check yourself · past exam[PAST EXAM 433-443 1999 Q2, predecessor subject] In the incremental model, discuss the risk vs cost/schedule trade-off of delivering increments to the customer versus keeping them as internal milestones.

• Delivering increments lowers risk: early user feedback catches misunderstood requirements, the customer gets early value, and integration is tested in the real environment. But it raises cost and schedule, because every delivery must be of release quality (testing, installation, documentation, training, support), several versions in the field must be maintained, and the feedback brings change requests and scope creep.
• Keeping increments as internal milestones is cheaper and more predictable, but the requirements and acceptance risk are deferred to the end, as in the waterfall.
• So deliver when requirements risk is high, and keep increments internal when requirements are stable or partial deployment is impractical. A compromise is to demonstrate increments at review milestones.

Check yourself · past exam[PAST EXAM 433-443 1999 Q19.2, predecessor subject] Build A is infrastructure, B is core, and C (advanced) proceeds only if B succeeds. A whole-system SRS is reviewed at T0+4. Each build goes through analysis, design, implementation and test, and is delivered at T0+4, +10 and +16. Characterise the process model.

• This is an incremental, staged-delivery model. Requirements for the whole system are baselined (formally fixed) up front, waterfall-style, with the SRS review at T0+4. The system is then built and delivered in three increments, each a mini waterfall of the four phases with its own acceptance review. The analysis of B and C overlaps A, and C's design starts after B is accepted.
• It is risk-ordered (infrastructure, then core, then advanced), with a spiral-like go/no-go decision at Build B.
• It is not evolutionary, because the requirements come from the SRS, not from feedback on delivered builds.

Evolutionary Development, and Incremental vs Evolutionary exam

Incremental development assumes you know the requirements at the start. Sometimes you simply can't: the users say "I can't tell you what I want, but I'll know it when I see it". Evolutionary development is built for that situation: instead of planning the whole product, you build a first version and let real use tell you what the next version should be.

The model

Boehm's second difficulty deserves unpacking, because each failure case is a realistic situation. The assumption that the system can absorb unplanned evolution breaks down when independently evolved applications must later be integrated (each grew its own way, so they don't fit together); when temporary workarounds harden into fixed constraints, which Boehm calls "information sclerosis" (a quick fix becomes something everything else depends on, so it can no longer be changed); and when new software must gradually replace a poorly modularised old system (you can't evolve away from something you can't take apart).

Incremental versus evolutionary, side by side

The two are easy to confuse, because both deliver in cycles. The root difference is where the requirements come from: incremental partitions requirements known up front; evolutionary discovers them from feedback. Every other difference follows from that one.

Gantt sketches: waterfall, incremental, evolutionary exam

Two predecessor-subject exams (433-443 1999 Q1 and 2000 Q1b) asked students to draw these models as Gantt charts: bar charts with time across the page and one row per task. In each sketch below, the rows are summary tasks (a summary task groups the detailed tasks under it), the gold diamonds are customer-review milestones (zero-length events), and the dates are arbitrary. All three share one time axis, so you can compare when the first delivery arrives.

Check yourselfClassify each project as incremental or evolutionary: (a) a payroll system with a signed SRS, released in three planned slices; (b) a research team's data tool where scientists keep discovering what they need after trying each version; (c) a project where release 2 deliberately redesigns the screens built in release 1 because users disliked them.

(a) Incremental: requirements known up front (the SRS) and partitioned into planned slices. (b) Evolutionary: requirements emerge from using each version. (c) Evolutionary: a cycle that revises earlier functions because of feedback is the evolutionary signature; incremental cycles add planned slices.

Check yourself · past exam[PAST EXAM 433-443 1999 Q1, predecessor subject] Draw Gantt charts for the waterfall, incremental and evolutionary models, with summary tasks and customer reviews as milestones.

Use the three sketches above.

• The waterfall chart has its phases in sequence, with review milestones after requirements, after design, and at acceptance.
• The incremental chart has one requirements and architecture phase, followed by overlapping increment summaries, each ending in a delivery review.
• The evolutionary chart has sequential "version n" summaries, each ending in a customer evaluation that feeds the next cycle.

Check yourself · past exam[PAST EXAM 433-443 2000 Q1 a–d, predecessor subject] (a) Distinguish waterfall, incremental and evolutionary. (b) Draw two Gantt charts contrasting incremental and evolutionary. (c) What is meant by the spiral model (2 sentences)? (d) What tool would you use if the commissioner's goals are unclear or a technology is used for the first time?

• (a) Waterfall does each phase once, with one delivery. Incremental fixes requirements up front, then delivers planned slices that each add function. Evolutionary starts from outline requirements and delivers versions revised from user feedback, so the product emerges.
• (b) Use the charts above, annotated to show the differences: single versus repeated requirements, and overlapping versus sequential cycles.
• (c) Boehm's spiral is a risk-driven iterative process. Each loop sets objectives, alternatives and constraints, resolves the biggest risks (often by prototyping), develops and verifies the next level of product, and plans the next loop after a stakeholder commitment review. (See 2.9.)
• (d) Prototyping: use a throwaway or proof-of-concept prototype, within a risk-driven (spiral) approach. (See 2.8.)

Prototyping and Rapid Prototyping

When the customer can't say exactly what they want, or nobody is sure a technology will work, writing a 200-page SRS just records guesses. Prototyping attacks that problem directly: build something cheap that people can see and try, learn from it, and only then commit to the real thing. It is Royce's "do it twice" (2.4) turned into a model.

Prototyping (slides)

A prototype is an early, partial version of the software built to answer a question. In the prototyping model, you build a prototype to nail down the requirements, and then proceed waterfall-style: prototype, requirements, analysis, design, implementation, maintenance.

Rapid prototyping (slides)

Rapid prototyping evolved from prototyping. A rapid prototype is a working model functionally equivalent to a subset of the product: it really does some of what the final product will do. The approach is client-oriented: the client gives feedback before the team moves on, in a cycle of (1) prototype, (2) review, and (3) refine and iterate.

Two kinds of prototype

Whichever model you use, decide up front which kind of prototype you are building, because the two are built to different standards.

Check yourself · past exam[PAST EXAM 433-443 1998 Q11, predecessor subject] "We already have a working prototype so we just need to iron out some minor problems and the system is ready for delivery." Discuss the role of a prototype and the relationship between the prototyping and spiral models.

• A prototype is a cheap learning tool. It elicits and validates requirements, tests the UI and checks feasibility.
• A throwaway prototype omits non-functional quality (performance, security, error handling), design, documentation and testing. These are not "minor problems", so the right response is to discard it and engineer the system, unless it was built as an evolutionary prototype.
• The prototyping model uses one prototype to fix the requirements and then follows a waterfall. One prototype is often not enough, and that is what inspired the spiral.
• The spiral generalises prototyping. Every cycle analyses risk and builds a prototype (1, 2, 3, then operational) to resolve it, then develops, verifies, plans and reviews. Prototyping is therefore a risk-resolution tool within the spiral.

Check yourselfA team builds a quick UI mock-up in a drag-and-drop tool to settle what screens the users want. The manager now proposes shipping it after "a bit of polish". What kind of prototype is it, and what is missing?

It is a throwaway prototype: built fast to answer a requirements question. Shipping it is the main prototyping pitfall, because it lacks the non-functional requirements (performance, security, error handling), documentation and testing. The right move is to keep the lessons and engineer the real system; it could only be grown into the product if it had been built to production quality from the start (an evolutionary prototype).

The Spiral Model (Boehm 1986; Journal Version 1988) exam

Each model so far is good against one kind of trouble: the waterfall against chaos, prototyping against unclear requirements, incremental against late delivery. Barry Boehm's spiral asks a more general question: what could sink this project right now? Whatever the answer, that is what the next loop of work attacks. A risk here is anything uncertain that could harm the project, such as an unproven technology or a misunderstood requirement (Part IV treats risk in depth).

Risk-driven, not document-driven or code-driven

The spiral diagram has two dimensions. The radial dimension (distance from the centre) is the cumulative cost so far; the angular dimension (how far round you are) is progress through the current cycle. The slides walk round it from the centre ("Start here") through Plan, Risk analysis, Prototype, and Build and validate. In Boehm's own wording, each cycle passes through four quadrants. Step a project round it.

Colours in the stepper match the quadrants: objectives, risk, develop and plan. P1–P3 are prototypes 1–3 and OP the operational prototype.

1. Identify the objectives, alternatives and constraints for this portion of the product.
2. Evaluate the alternatives, find the major risks, and resolve them cost-effectively, by prototyping, simulation, benchmarking or reference checks.
3. Let the remaining risk decide the next step. If UI or performance risk dominates, take an evolutionary or prototyping step. If development risk dominates, take a waterfall-like step (requirements, design, code, test), possibly an incremental one.
4. Plan the next cycle, then hold a stakeholder review so that everyone is committed to the next phase. The project may also be terminated at this point.

Check yourselfPut Boehm's four quadrants in the order a cycle visits them: (a) plan next phases; (b) develop and verify next-level product; (c) determine objectives, alternatives, constraints; (d) evaluate alternatives, identify and resolve risks. Where does the review and commitment happen?

c → d → b → a: objectives, then risk, then develop, then plan. The review and commitment comes at the end of the plan quadrant, before the next cycle starts (on the boundary between quadrants 4 and 1), and it is also where the project can be terminated.

A meta-model: the spiral becomes what the risks require

Because risk decides each step, Boehm describes the spiral as a meta-model: a model for generating models. What it turns into depends on the project's risks.

Documents are risk-driven too. You write detailed documentation for the high-risk parts and defer it for the low-risk ones. That answers the awkward question every document-driven process faces: "how much documentation is enough?" Answer: as much as the risk justifies.

Check yourselfA project to re-host a well-understood payroll system has very clear user requirements and a stable UI, but a tight budget and a fixed go-live date. What does Boehm say the spiral turns into here?

1. Evolutionary development
2. A waterfall
3. Rapid prototyping
4. Code-and-fix

B. Low UI and performance risk with high budget and schedule risk is exactly the profile where the spiral behaves like a waterfall. A would follow from a high risk of getting the UI or user requirements wrong.

Advantages, difficulties and fit

A further problem is that the per-cycle overhead (risk analysis, prototypes, reviews in every loop) makes cost and schedule hard to predict.

Boehm's top-10 software risk list, which feeds the spiral's risk quadrant, is covered in Part IV.

Check yourselfWhich are among Boehm's three named difficulties of the spiral? (Select all that apply.)

1. It relies on risk-assessment expertise.
2. It cannot handle hardware–software systems.
3. It is hard to match to contract software.
4. It never delivers a working system.
5. Its milestones, reviews and status tracking need further elaboration.

A, C and E. B contradicts an advantage (it suits hardware–software systems), and D is false: the last loop develops, tests and installs the system.

The Spectrum and the Comparison Grid exam

You now know seven models. Exam questions rarely ask you to recite one; they ask you to compare them, or to place a project among them. This section gives you two tools for that: a spectrum to locate each model, and a comparison grid to revise from.

From plan-driven to agile

The models sit on a spectrum. Formal models are at the defined, plan-driven end; agile frameworks (Part III) are at the empirical end; and the incremental, evolutionary and spiral models fall in between, each adding some feedback to a plan.

T02 "SDLC summary" exam

Van Lamsweerde's agile assumptions (covered in Part III) mark the limits of agile: a small co-located team, an available user, and a non-critical system. Mission-critical systems such as air traffic control, power plants and banking often break these assumptions, which is one reason formal models survive.

The comparison grid

This grid pulls the models together and is the one to revise from. Read across a row to compare the models on one dimension, or down a column for a quick profile of one model. First, a picture of four of its rows:

Two abbreviations in the grid: V&V is verification and validation (2.5), and a 4GL (fourth-generation language) is a high-level tool for building applications quickly, such as a database query and reporting language.

Check yourselfAccording to the comparison grid, which model's documentation is "risk-driven: as much as needed", and which model has customer involvement only at the "start and acceptance"?

1. Spiral; V-model
2. Agile; waterfall
3. Spiral; waterfall
4. Incremental; V-model

A. The waterfall's involvement is "start and end"; the V-model's is "start and acceptance", because acceptance testing is its customer touchpoint. Agile's documentation is "light, just enough"; risk-driven documentation is the spiral's signature.

Check yourselfWhich models in the grid deliver more than once? (Select all that apply.)

1. Waterfall
2. Incremental
3. V-model
4. Evolutionary
5. Agile

B, D and E. Incremental gives several operational releases, evolutionary several versions, agile an increment every sprint. Waterfall and V-model deliver once, at the end. (The spiral delivers after its final cycle, which may itself be incremental; prototyping usually delivers once.)

Choosing an SDLC for a Project exam

Knowing the models is only half the job; the exam's extended questions ask you to choose one for a given project and justify the choice. This section gives you a checklist of factors, a visual decision guide built from it, the difference between weak and strong arguments, and a seven-step framework for a full "evaluate and recommend" answer.

The decision checklist

1. Requirements clarity and stability. Clear and stable → waterfall or V-model. Mostly clear and early value needed → incremental. Unclear or volatile → prototyping, evolutionary or agile.
2. Technical novelty and risk. New hardware, algorithms or platforms point to the spiral, or to a prototype as a proof of concept.
3. Criticality and regulation. Safety-critical or audit-heavy work calls for V-model or waterfall-style V&V and documentation, or for the spiral. Avoid a purely agile approach for the critical parts.
4. Customer availability. Often available → agile or evolutionary. Available only at fixed points → a plan-driven model, or a spiral with scheduled reviews.
5. Size and distribution. Small, co-located work → agile. Large, multi-team or contracted work → plan-driven, the spiral, or scaled agile.
6. Need for early delivery → incremental or agile.
7. Team experience with the domain, the technology and the process. A spiral needs risk expertise; agile needs self-management.
8. Contract and culture. Fixed price and fixed scope → plan-driven; time-and-materials (the client pays for the work actually done) → iterative; a client with a mandated process → hybrid.
9. Maintenance and handover. If another team will maintain the system, you need more documentation.
10. Predictability required up front → plan-driven.

The mnemonic, from Boehm & Turner's "home grounds" for agile versus plan-driven methods, is size, criticality, dynamism, personnel, culture. "Dynamism" means how much the requirements change; "personnel" means the team's skill and experience.

The decision guide, as a picture

Here is the same checklist laid out so you can scan a scenario against it. For each factor, find the branch that matches the project's facts and note the models it points to. The model that keeps turning up, and whose prerequisites the project meets, is your candidate. 2.12 runs the Medic case through it step by step.

Strong versus weak arguments (T02)

A weak argument describes the SDLC or the project but never connects the two. "Waterfall gives us many phases" leaves the marker asking "so what?"; "Agile perfectly suits the project" leaves them asking "how? why?". A strong argument follows a chain from a project fact to the trade-off.

Check yourselfRewrite this weak argument as a strong one: "The spiral is good because it handles risk." Use this fact: the project depends on a GPS chip the team has never used.

One strong version: "The project depends on a GPS chip the team has never used (fact), so there is a high technical risk that it won't meet accuracy or timing needs, discovered only at integration (risk). The spiral's second quadrant resolves the biggest risks first by prototyping (SDLC feature), so an early loop can benchmark the chip before major investment, and the review at the end of the loop can switch hardware or stop (how it helps). The cost is per-cycle overhead and a less predictable schedule, and it needs someone skilled in risk analysis (trade-off)." The point is the chain, not these exact words.

The "evaluate the SDLC used / recommend an alternative" framework (from A1)

Assignment 1 asked students to evaluate the SDLC a failed project used and recommend an alternative. Its structure is a ready-made plan for the exam's case-study questions:

1. Context and goals. Set out the project's size, novelty, criticality, stakeholders and contract.
2. Identify the SDLC used. If it isn't named, infer it from the evidence and say so. For example, up-front specification, phase sign-offs and one "big bang" delivery imply waterfall.
3. Setbacks. Describe them with specific evidence of delay, cost, scope, quality or cancellation.
4. Causes linked to SDLC practices. Trace each one from cause, to practice, to effect (see the chain below).
5. Better use of the same SDLC. Give fixes tied to each cause. Royce's five steps (2.4) are a ready-made source, and you can add phase-gate reviews, change control and risk management.
6. Alternative SDLC. Recommend one, with a table whose columns are issue, feature of the new SDLC and why it helps. Admit its costs and assumptions, for example that Scrum needs an available Product Owner.
7. Conclude in one or two sentences.

Illustration. For the Surrey Police SIREN project (begun 2009, later abandoned), a good answer infers the process from the documented practices, links the setbacks to them, and justifies an alternative feature by feature, rather than just saying "agile would have been better".

Check yourself · past exam[PAST EXAM 433-443 1998 Q12, predecessor subject] A bank's accounting-systems team (programmers with 7+ years in the domain) wants to try the spiral model, which they have just heard of, for new functionality in an existing system. Discuss the factors that affect process selection, and recommend.

• The factors are those in the checklist above: requirements stability, technical risk, size, criticality, customer availability, team experience with the domain and the process, contract and culture, time pressure, and documentation.
• The recommendation is not to adopt the full spiral here. This is an enhancement of a well-understood system by domain experts, so risk is low and the requirements are fairly clear, which makes per-cycle risk analysis unjustified overhead. The spiral also relies on risk-assessment expertise that the team lacks, and it fits contract work poorly (Boehm).
• Instead, the team should keep their proven process and add Boehm's lightweight risk management plan (top-10 risks reviewed monthly). They should also train staff and pilot the spiral on a novel, high-risk project.

Check yourself · past exam[PAST EXAM 433-443 2002 Q10, predecessor subject] The customer is hesitant, doesn't know the application area and keeps changing their mind. How would you organise the project?

• Use an iterative, empirical life cycle (prototyping, evolutionary or Scrum), not waterfall.
• Start with workshops and mock-ups or prototypes, so that the customer reacts to something concrete.
• Run short iterations, each ending in a demo and review, and deliver the most certain, highest-value core first.
• Have one empowered customer representative, supported by a domain expert or business analyst.
• Keep a prioritised backlog and change control, and get sign-off at each iteration.
• Use a time-and-materials or staged contract rather than a fixed price, and log requirements volatility as a risk.

Check yourself · past exam[PAST EXAM 433-341 2009 Q2, predecessor subject] Port management system: 18 months, new monitoring hardware, port modelling that is hard to estimate. Should it use (A) a modified waterfall with feedback or (B) an iterative model with prototyping? Give benefits and drawbacks, and choose.

	Benefits	Drawbacks
(A) Modified waterfall	Clear phases, documents and milestones; a predictable plan; traceability for a safety-related system.	Hardware and modelling problems surface only at integration and test; feedback is costly; estimates are unreliable.
(B) Iterative with prototyping	Prototypes of the monitoring, model and scheduling resolve technical and requirements risk early; estimates improve with each iteration.	Less predictable up-front cost and schedule; more management; lighter documentation.

Choose B. Technological novelty and estimation uncertainty dominate, and prototyping attacks both; the plan already front-loads prototypes and a feasibility study. Keep strong V&V, though, because ship separation is safety-critical.

Applying It to the Medic Case: Which SDLC and Why

The tutorials' running case is Medic: a virtual-reality surgical simulator for the hospital RVEEH, letting trainee surgeons practise cochlear-implant and temporal-bone surgery, because good-quality cadavers for practice are scarce. The trainee feels the drill through haptic devices (hardware that pushes back on your hand to simulate touch and force) while viewing the anatomy in stereoscopic 3-D. Tutorial 2 asks: which SDLC should the Medic project use? This section works the answer the way the exam wants it: from case facts, to risks, to a model.

Case facts that drive the choice

Each fact below implies a risk or a need, and together they decide the SDLC (Medic case study; T02 recap).

Running Medic through the decision guide

Now take the decision guide from 2.11 and walk Medic's facts through it, factor by factor. Gold rings mark the branch each fact selects.

Evaluating the candidates

What Medic's spiral looks like

Recommending the spiral is only convincing if you can say what its loops would actually contain for Medic:

Check yourself · self-testA Medic team member says "use Scrum because agile suits changing requirements". Critique this and give a stronger evaluation.

The argument is weak because it states a generic feature with no link to the case. A stronger evaluation weighs both sides. For Scrum, the surgeons could give usability feedback each sprint, and spikes (short time-boxed experiments) would let the team learn haptics. Against it, the busy surgeons can't be an always-available Product Owner, strict performance and reliability need up-front analysis, the new hardware brings high technical risk, 12 inexperienced developers exceed one Scrum team, and the RVEEH IT team needs documentation. On balance, a risk-driven spiral fits better.

Check yourselfAn exam version of the Medic case states that two liaison surgeons are available to the team every day. Does the spiral recommendation still stand, and what should your answer say?

It is no longer the only defensible answer. With a customer available day-to-day, the main objection to Scrum (no constantly available Product Owner) falls away, and the guide says an adapted (hybrid) Scrum becomes just as defensible. Your answer should state which facts it relies on, pick one model, and justify it against those facts with its trade-offs (e.g. for adapted Scrum: up-front architecture and performance work and handover documentation still needed; for the spiral: per-cycle overhead and reliance on the managers' risk expertise).

Common Pitfalls and Self-Test

These are the mistakes that cost marks on this topic, collected in one place. Each one is a sentence you might be tempted to write; the fix follows it.

Mixed self-test

Check yourselfWhich statements are correct? (Select all that apply.)

1. The spiral's defining feature is that it repeats the waterfall phases in a loop.
2. Incremental cycles can overlap because their requirements are already known.
3. A throwaway prototype can be shipped once its minor bugs are fixed.
4. Waterfall can be the right choice for regulated, fixed-price work with stable requirements.
5. Evolutionary cycles revise earlier functions in response to feedback.

B, D and E. A is the "waterfall in a circle" pitfall: the defining feature is risk analysis. C is the throwaway-prototype pitfall: it lacks NFRs, documentation and testing, which are not "minor bugs".

Check yourselfA small co-located startup team of five is building a social app for a market nobody fully understands yet; the founder sits with the team daily and features change weekly. Which end of the spectrum, and which factor-checklist items justify it?

The agile (empirical) end. Checklist items: requirements are unclear and volatile (factor 1 → prototyping, evolutionary or agile), the customer is often available (factor 4 → agile or evolutionary), the team is small and co-located (factor 5 → agile), and early delivery matters (factor 6 → incremental or agile). Agile is the model all four point to. The trade-off to admit: the team needs self-management (factor 7), and documentation will be light.

Check yourselfIn one sentence each: what does each of these add to the plain waterfall? (a) Royce's "do it twice"; (b) the V-model; (c) the incremental model; (d) the spiral.

(a) A pilot of the critical areas first, so the delivered system is really the second version (the origin of prototyping). (b) A test level paired with, and planned during, each development phase. (c) Delivery in operational slices through mini waterfalls, after up-front requirements. (d) Explicit risk analysis in every loop, letting the remaining risk decide what kind of step comes next.