Topic 4 of 9 · Lab V
SDLC Model Selection
The six stages of the software development life cycle, the waterfall, iterative, V, spiral, agile and prototyping models, and how to choose one with a weighted comparison matrix.
← → move between slides · F full screen · M slide list
Before we start
Why this matters
Two teams build the same library system. One plans everything up front and tests at the end; the other shows the librarian a working screen every two weeks. Which one is right?
It depends on the project: how clear the requirements are, how risky it is, and how often the customer can give feedback. Choosing the process is a design decision in its own right.
In this topic you learn the main SDLC models and a systematic way to pick one — and to defend the choice in your report.
Outline · Lab V
Topics in this chapter
Select a topic to jump to the slide that explains it.
Concept 1 of 13
What the SDLC is
The Software Development Life Cycle is the process a software organisation follows to plan, build, test, deliver and maintain software. Its aim: high-quality software that meets or exceeds customer expectations, on time and within cost.
The SDLC and its stages
The six stages
| Stage | What happens | Output |
|---|---|---|
| 1. Planning & requirement analysis | Senior team members gather input from the customer, sales, market surveys and domain experts; plan quality assurance; identify risks; study feasibility. | Feasibility report, project plan |
| 2. Defining requirements | Document the requirements and get them approved by the customer. | SRS |
| 3. Designing the architecture | Propose one or more designs, review them for risk, robustness, modularity, budget and time; choose one. | DDS (Design Document Specification) |
| 4. Building / developing | Write the code following the DDS and the coding guidelines, using compilers, interpreters and debuggers. | Source code |
| 5. Testing | Report, track, fix and retest defects until the product meets the SRS. (In modern models testing happens in every stage.) | Tested product, test reports |
| 6. Deployment & maintenance | Release, often first to a limited segment for user acceptance testing (UAT); then maintain it. | Released system, updates |
Concept 3 of 13
Waterfall model
Concept 3 of 13
Waterfall model (cont.)
Phases run one after another; the next starts only when the previous one is signed off. Phases do not overlap. Described by Winston Royce (1970), who actually warned against using it without feedback.
Strengths
- simple to understand and manage
- clear milestones and documents
- good when requirements are fixed
Weaknesses
- no working software until late
- costly to change requirements
- high risk for long or unclear projects
Use it when the requirements are very well known, clear and fixed, and the technology is familiar.
The models
Iterative (incremental) model
The models
Iterative (incremental) model (cont.)
Start with a simple implementation of part of the requirements, then enhance it in repeated cycles until the full system is built. Each iteration may change the design and adds new functions.
Strengths
- working software early
- easier to test small increments
- changes can enter later iterations
Weaknesses
- needs a good overall architecture up front
- more management effort
- total cost can grow
Use it when the main requirements are clear, the system is large, and changes are expected in future.
The models
V-model
The models
V-model (cont.)
An extension of waterfall where the test for each phase is planned at the same time as that phase: verification on the left arm, validation on the right, joined by coding at the bottom.
Strengths
- testing is planned from day one
- defects found early
- strong for safety- and money-critical systems
Weaknesses
- rigid, like waterfall
- no early prototype
- changes are expensive
Use it when requirements are clear, simple and stable and high reliability is essential (banking, medical).
The models
Spiral model
The models
Spiral model (cont.)
A project passes repeatedly through four quadrants — determine objectives, identify and resolve risks, develop and test, plan the next iteration. Each loop usually produces a prototype.
Strengths
- explicit risk analysis every loop
- suits large, expensive, risky projects
- users see prototypes
Weaknesses
- complex to manage
- needs risk-analysis expertise
- too heavy for small projects
Use it when the project is large, risk and cost evaluation are important and frequent releases or prototypes help.
The models
Agile model
The models
Agile model (cont.)
“Agile” means swift and versatile. Work is broken into small iterations (sprints) of 1–4 weeks with constant customer feedback, following the Agile Manifesto (2001): individuals and interactions, working software, customer collaboration and responding to change.
Scrum, the most used agile framework, has a Product Owner, a Scrum Master and developers; a product backlog; and events: sprint planning, daily scrum, sprint review, retrospective.
Strengths
- adapts to changing requirements
- frequent working releases
- close customer contact
Weaknesses
- needs an available customer
- less documentation
- hard to fix cost and scope up front
The models
Prototyping model
The models
Prototyping model (cont.)
A working model of the system is built quickly and shown to users to discover what they really want. The prototype is refined until approved, then the real product is engineered.
Strengths
- users see and try the system early
- uncovers missing requirements
- reduces misunderstanding
Weaknesses
- users may mistake the prototype for the product
- can encourage endless changes
- prototype code is often thrown away
Use it when requirements are unclear, especially for the user interface.
Concept 9 of 13
Comparing the models
| Waterfall | V-model | Iterative | Spiral | Agile | Prototyping | |
|---|---|---|---|---|---|---|
| Requirements | fixed | fixed | mostly known | can evolve | evolving | unclear |
| Customer involvement | start & end | start & end | each release | each loop | constant | constant |
| Risk handling | low | medium | medium | high | medium | medium |
| Working software | at the end | at the end | early | prototypes | every sprint | prototype early |
| Cost of change | high | high | medium | medium | low | low |
| Documentation | heavy | heavy | medium | heavy | light | light |
| Best for | small, stable | safety-critical | large, planned | large, risky | changing needs | UI-heavy, unclear |
Choosing a model
The weighted comparison matrix
- Choose criteria that matter for your project (well-known requirements, risk, user testing, security…).
- Give each a priority (weight). The manual’s weights add up to 30.
- For each model, mark Yes if it supports the criterion.
- A model scores the sum of the weights where it says Yes.
- Choose the highest score — and justify it in words.
Interactive
The lab manual’s matrix for the ATM system
Interactive
The lab manual’s matrix for the ATM system (cont.)
Interactive
Which model fits your project?
Choosing a model
Justifying the choice in your report
A good justification has four parts:
- The matrix with criteria, weights and totals.
- The winning model and its score.
- Why the top-weighted criteria matter for this system.
- How you will adapt the model (e.g. “V-model, with a UI prototype in week 4”).
Example paragraph
“We selected the V-model (22 of 30 points). Our library system’s requirements were fixed after two interviews with the librarian, and fine calculation and member data must be reliable and secure — the two criteria we weighted most. The V-model plans a test for every design phase, which suits our testing phase in weeks 7–9. Spiral tied at 22, but its risk-analysis loops are heavier than an 11-week student project needs.”
Worked example 1 of 3
Worked example 1
Show the solution
Worked example 2 of 3
Worked example 2
Show the solution
Worked example 3 of 3
Worked example 3
Show the solution
Practice
Practice (1 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Practice
Practice (2 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Check yourself
Quiz
Resources
Further learning
Hand-picked material to go deeper. Links open in a new tab.
Resources
Further learning (cont.)
Summary
Summary
- The SDLC has six stages: planning, requirements (SRS), design (DDS), building, testing, deployment and maintenance.
- Waterfall and V-model suit fixed requirements; the V-model plans a test for every phase.
- Iterative delivers growing versions; spiral adds a risk-analysis loop for large risky projects.
- Agile uses short sprints and constant feedback; prototyping discovers unclear requirements.
- Choose with a weighted matrix: criteria phrased so Yes is good, honest weights, recomputed totals.
- Justify the choice in words and say how you will adapt the model.