What a Software Development Life Cycle Is
Chapter Thirteen
Syllabus topic Module 1, "Software Development Life Cycle (SDLC): Overview of SDLC"
Pages 73 to 76 of 622
In one line
A software development life cycle is the sequence of stages a piece of software passes through, from the first idea to the day it is switched off, and an SDLC model is a particular way of arranging those stages.
In the wording a student can write in an examination: a life cycle is the "evolution of a system, product, service, project or other human-made entity from conception through retirement" (ISO/IEC/IEEE 12207:2026). A life cycle model is a "framework of processes and activities concerned with the life cycle that can be organized into stages, acting as a common reference for communication and understanding" (the same standard). The typical phases of software development are feasibility, requirements, design, implementation, testing, deployment and maintenance; models such as waterfall, the V-model, spiral and agile arrange these phases differently.
Why life cycle models exist
Building ExamReg involves a dozen people over months: the exam cell that knows the rules, a business analyst who writes them down, designers, programmers, testers, the IT cell that runs the servers. Without an agreed shape for the work, each of them decides privately when their part starts and what they hand over, and the handovers fail. A life cycle model is that agreed shape: which activities happen, in what order or in what cycles, and what each produces for the next.
The ISTQB syllabus puts it precisely: an SDLC model "defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically." The model is not the work itself; it is the map everyone reads from.
The phases every life cycle contains
Whatever the model, the same kinds of work have to be done. Models differ in how they order and repeat them, not in whether they exist.
Figure 13.1 The phases of a software development life cycle, with maintenance feeding back into requirements
| Phase | What happens | Standard definition, where one exists | Work product |
|---|---|---|---|
| Feasibility | Decide whether the system is worth building | A feasibility study is a "study to identify and analyze a problem and its potential solutions in order to determine their viability, costs, and benefits" (ISO/IEC 2382:2015) | Feasibility report |
| Requirements | Find out and write down what the system must do | Requirements analysis is the "process of studying user needs to arrive at a definition of system, hardware, or software requirements" (ISO/IEC/IEEE 24765:2017) | Requirements specification |
| Design | Decide how the system will do it: architecture, modules, data, interfaces | Software design is the "use of scientific principles, technical information, and imagination in the definition of a software system to perform pre-specified functions with maximum economy and efficiency" (ISO/IEC/IEEE 24765:2017) | Design documents |
| Implementation | Write the code, and the developers' own unit tests | (coding) | Source code, unit tests |
| Testing | Integrate and test the system against its requirements | (the testing fundamentals and test documents of Chapters One to Twelve) | Test reports, fixed defects |
| Deployment | Put the system into use | Deployment is the "stage of a project in which a system is put into operation and transition issues are resolved" (IEEE 2675-2021) | The released system, user guides |
| Maintenance | Correct, improve and adapt it after release | Maintenance is the "process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment" (ISO/IEC 25051:2014) | Fixes, changes, new releases |
What a Software Development Life Cycle Is
The arrow from maintenance back to requirements in the figure is the part students forget. A system that is used gets changed, and every change runs through requirements, design, code and test again. For most successful software, far more of its life is spent in that loop than in the first build.
The families of models
The ISTQB syllabus groups the models into three families, and adds the agile methods that sit alongside them.
| Family | How it arranges the phases | Examples (ISTQB v4.0.1) | Chapter |
|---|---|---|---|
| Sequential | One phase after another, each finished before the next begins | Waterfall model, V-model | Fourteen and Fifteen |
| Iterative | The phases are repeated in cycles, each refining the product | Spiral model, prototyping | Sixteen |
| Incremental | The product is built and delivered in pieces, each adding capability | Unified Process | Sixteen |
| Agile methods and practices | Short iterations, incremental delivery, change welcomed | Scrum, Kanban, extreme programming, test-driven, behaviour-driven and acceptance test-driven development | Seventeen |
The standard vocabulary defines the sequential model's defining property precisely. ISO/IEC/IEEE 24765:2017 describes the waterfall model as one in which the phases "are performed in that order, possibly with overlap but with little or no iteration", and incremental development as a technique in which requirements, design, implementation and testing "occur in an overlapping, iterative (rather than sequential) manner, resulting in incremental completion of the overall software product."
Why the choice of model matters to a tester
This is a testing paper, and the SDLC appears on its syllabus because the model decides how testing is done. The ISTQB syllabus lists what the choice of SDLC affects: the "Scope and timing of test activities", the "Level of detail of test documentation", the "Choice of test techniques and test approach", the "Extent of test automation" and the "Role and responsibilities of a tester".
In practice the differences are large:
- In a sequential model, testers review requirements and design tests early, but "dynamic testing cannot be performed early in the SDLC", because the code arrives late (ISTQB).
- In iterative and incremental models each iteration delivers something that runs, so "both static testing and dynamic testing may be performed at all test levels" in every iteration, and frequent delivery "requires fast feedback and extensive regression testing".
- In agile development, change is expected throughout, so "lightweight work product documentation and extensive test automation to make regression testing easier are favored", and much manual testing uses experience-based techniques.
What a Software Development Life Cycle Is
Chapter Eighteen, on the role of testing in each phase, takes the phases one by one from the tester's side.
Worked example: ExamReg release 2.0, phase by phase
| Phase | What ExamReg release 2.0 needed | Where testing was already at work |
|---|---|---|
| Feasibility | Can the college move the paper exam form online before the November session, within the IT cell's budget? | Testers estimated the effort to test fee rules and the last-day load |
| Requirements | The fee rules, eligibility rules, backlog papers, hall ticket format, 500 simultaneous users on the last day | Reviewing the rules found the missing answer for negative days late (Chapter One, on what software testing is) |
| Design | Five modules, a fee service, an adapter to the payment gateway, the hall ticket generator | Test levels planned against the design; integration order chosen |
| Implementation | Code for each module, with developers' unit tests | Static analysis and code reviews |
| Testing | Integration, system and acceptance testing | The test plan of Chapter Eleven |
| Deployment | Install on the production server one week before the form opens | Smoke test in production; the load test report |
| Maintenance | Release 2.1 in March for the next session's rule change | Regression testing of everything the change touches |
Choosing a model
No model is right for every project, which is the SDLC form of the principle that testing is context dependent. The usual considerations, stated as practice:
| If the project has ... | ... a sensible choice is | Because |
|---|---|---|
| Stable, well-understood requirements and a fixed contract | Sequential (waterfall or V-model) | Planning once is efficient, and the V-model pairs every phase with its test |
| High technical or business risk | Spiral | Each cycle begins by resolving the biggest risk |
| Requirements users cannot state until they see something | Prototyping or incremental | Early working versions draw out the real requirements |
| Changing requirements and an available customer | Agile (for example Scrum) | Short cycles absorb change and deliver value early |
| Safety or regulatory evidence to produce | V-model, often inside a larger iterative plan | Every requirement is traced to a test that verifies it |
What it does not mean
The SDLC is not a single fixed sequence. It is a set of kinds of work; the model decides the order and the repetition.
The life cycle does not end at deployment. Maintenance is usually the longest part of a product's life, and every change passes through the phases again.
Testing is not only one phase of the SDLC. It appears as a phase in the table, but test activities run alongside every phase (principle 3, early testing, and Chapter Eighteen).
What a Software Development Life Cycle Is
"Agile" does not mean without a life cycle. Agile teams still do requirements, design, coding, testing and deployment, in short cycles instead of long phases.
Quick revision
- Life cycle: evolution of a system from conception through retirement (ISO/IEC/IEEE 12207:2026).
- Life cycle model: a framework of processes and activities organised into stages, a common reference for everyone (ISO/IEC/IEEE 12207:2026).
- Generic phases: feasibility, requirements, design, implementation, testing, deployment, maintenance; maintenance loops back.
- Families (ISTQB): sequential (waterfall, V-model), iterative (spiral, prototyping), incremental (Unified Process), plus agile methods (Scrum, Kanban, XP, TDD, BDD, ATDD).
- The SDLC decides the scope and timing of testing, documentation detail, techniques, automation and the tester's role.
- Choose by requirement stability, risk, customer availability and the evidence required.
Test yourself
1. Define the software development life cycle and a life cycle model. The life cycle is the evolution of a software system from conception through retirement. A life cycle model is a framework of processes and activities organised into stages, acting as a common reference for communication and understanding, such as the waterfall or spiral model.
2. List the phases of the SDLC with the work product of each. Feasibility (feasibility report), requirements (requirements specification), design (design documents), implementation (source code and unit tests), testing (test reports and fixed defects), deployment (the released system and user guides), maintenance (fixes, changes and new releases).
3. Name the three families of SDLC models with an example of each. Sequential, such as the waterfall model and the V-model; iterative, such as the spiral model and prototyping; incremental, such as the Unified Process. Agile methods such as Scrum combine iteration and increments.
4. How does the choice of SDLC model affect testing? Give three effects. It sets the scope and timing of test activities, the level of detail of test documentation, the choice of techniques and approach, the extent of automation, and the tester's role. For example, in a sequential model dynamic testing comes late, while in agile development automated regression testing runs every iteration.
5. Why is maintenance drawn as a loop back to requirements? Because a system in use keeps changing, and each change must again be specified, designed, coded and tested; for most software this loop makes up most of its life.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself, or the past papers, for the same subject.