-
Notifications
You must be signed in to change notification settings - Fork 135
SE 02 Software Development Life Cycle
Part of the Software Engineering Principles series
The Software Development Life Cycle (SDLC) is a structured process that guides the creation of software from initial concept through to active use and eventual retirement. It defines the phases of work, the artefacts produced at each stage, and the criteria for moving from one phase to the next.
Without an SDLC, development degenerates into ad-hoc activity: requirements are assumed, testing is skipped, and deployment is a surprise. With one, a team can plan, estimate, coordinate, and deliver predictably.
Every SDLC model, regardless of style, covers the same fundamental phases:
Understand what needs to be built and why. Gather requirements from stakeholders, analyse them for completeness and consistency, and document them in a form that developers can act on.
Key outputs: User Requirement Specification (URS), Software Requirement Specification (SRS), use cases or user stories.
Common pitfalls:
- Requirements that describe solutions rather than problems
- Requirements so vague they cannot be verified ("the system must be fast")
- Requirements gathered from only one stakeholder group
Translate requirements into a blueprint for the system. Design decisions made here — architecture, data model, module boundaries, integration points — are expensive to reverse later.
Key outputs: Architecture diagram, database schema, API contracts, UI wireframes.
Distinction between levels:
- High-level design — What are the major components and how do they relate?
- Low-level design — How will each component be implemented internally?
Write the software according to the design. This is where developers spend most of their visible time, though quality outcomes depend far more on the quality of the preceding phases.
Key practices: Code reviews, coding standards, incremental commits, feature branches.
Verify that the software works correctly and meets its requirements. Testing should begin as early as possible — finding a defect in requirements costs far less than finding it after deployment.
Types of testing:
- Unit testing — individual functions and classes
- Integration testing — components working together
- System testing — the complete system end to end
- User acceptance testing (UAT) — stakeholders verify requirements are met
Release the software to the environment where it will be used. This includes installation, configuration, data migration, and user training.
Key concerns: Rollback planning, environment parity, change communication.
Operate and improve the software after deployment. Maintenance accounts for the majority of total software cost over a system's lifetime — typically 60–80%.
Types of maintenance:
- Corrective — fixing defects
- Adaptive — adjusting to environment changes (OS upgrades, new regulations)
- Perfective — improving performance, usability, or code quality
- Preventive — refactoring to reduce future defect risk
Different project contexts call for different approaches to sequencing these phases.
The original formal model. Each phase is completed fully before the next begins.
Requirements → Design → Implementation → Testing → Deployment → Maintenance
Strengths:
- Simple to understand and manage
- Each phase has clear deliverables
- Works well when requirements are stable and fully understood upfront
Weaknesses:
- Very late discovery of problems — testing happens after all coding is done
- Costly to accommodate changing requirements
- Working software not delivered until near the end
Best suited for: Regulated environments with fixed requirements (e.g., embedded systems for medical devices).
Build the system in small increments, each delivering a working subset of functionality. Each iteration repeats a mini-waterfall cycle.
[Plan → Design → Build → Test] × N iterations
Strengths:
- Working software delivered early and regularly
- Feedback from real use informs subsequent iterations
- Risk is spread across the project rather than concentrated at the end
Weaknesses:
- Requires more discipline in integration and regression testing
- Architecture can drift without deliberate attention
Combines iteration with explicit risk analysis. Each spiral loop assesses risks before proceeding with the next phase of development.
Strengths: Excellent for high-risk, large-scale projects.
Weaknesses: Complex to manage; overkill for smaller projects.
A family of iterative approaches guided by the 2001 Agile Manifesto. Agile prioritises:
- 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 most widely used Agile framework is Scrum, which is covered in SE-14: Agile and Scrum.
An extension of Waterfall where each development phase is paired with a corresponding testing phase.
Requirements ←————————————→ Acceptance Testing
System Design ←————————→ System Testing
Architecture ←——————→ Integration Testing
Module Design ←——→ Unit Testing
Implementation
Strengths: Testing is planned alongside development, not as an afterthought.
Best suited for: Safety-critical systems where traceability between requirements and tests is mandatory.
| Model | Requirements clarity needed | Delivery speed | Change tolerance | Best for |
|---|---|---|---|---|
| Waterfall | High (upfront) | Slow | Low | Fixed-scope regulated projects |
| Iterative | Medium | Medium | Medium | Phased feature delivery |
| Spiral | High (risk focus) | Slow | Medium | High-risk, large projects |
| Agile | Low (evolves) | Fast | High | Products with changing requirements |
| V-Model | High (upfront) | Slow | Low | Safety-critical systems |
Requirements are the foundation on which everything else is built. Poorly written requirements cause more project failures than any technical shortcoming.
| Characteristic | Meaning |
|---|---|
| Complete | Covers all necessary behaviour, including error cases |
| Correct | Accurately reflects what the stakeholder actually needs |
| Unambiguous | Has exactly one interpretation |
| Verifiable | Can be tested — there is a way to confirm it is met |
| Consistent | Does not conflict with other requirements |
| Feasible | Achievable within the constraints of the project |
| Traceable | Linked to its source and to the design/test artefacts that satisfy it |
A concise statement of a requirement from the user's perspective:
As a [role], I want to [capability] so that [benefit].
Example:
As a pharmacy dispenser, I want to scan a barcode to look up a medicine, so that I can process prescriptions without manual typing errors.
Acceptance criteria are added to make the story verifiable:
- Given a valid barcode, the system returns the correct medicine and current stock level
- Given an unknown barcode, the system displays an appropriate error message
Research consistently shows that defect cost increases dramatically the later in the SDLC it is found:
| Phase defect discovered | Relative cost to fix |
|---|---|
| Requirements | 1× |
| Design | 5× |
| Coding | 10× |
| Testing | 20× |
| Production | 100× |
This is the strongest argument for investing in requirements quality, design review, and early testing — not as bureaucracy, but as cost reduction.
Previous: SE-01: Introduction to Software Engineering
Next: SE-03: Object-Oriented Programming