The Software Development Life Cycle (SDLC): Phases and Models

Key SDLC terms every developer should know

• Phase: a stage of work with a defined goal, such as testing.
• Artefact: a document or output a phase produces, such as a requirements list, a design diagram or a test report.
• Stakeholder: anyone with an interest in the software, including users, clients, developers and support staff.
• Iteration: one pass through some or all phases that delivers a usable increment of the product.
• Release: a version of the software made available to users.

The SDLC is not a rule book; it is a shared vocabulary that helps a team agree on what happens next and what "finished" means at each stage.

The seven phases of the SDLC and their artefacts

Implementation is where most beginners focus, but problems found in requirements or design are much cheaper to fix than the same problems found after release. Good testing habits, including the techniques in our guide on how to find and fix bugs, run through every phase rather than sitting only at the end.

How the main SDLC models work

Waterfall

Waterfall runs each phase once, in order, and finishes one before starting the next. It suits projects with fixed, well-understood requirements and heavy documentation needs, but it makes late changes expensive because users see working software only near the end.

Iterative and incremental

The team builds a basic version, then repeats the cycle to add and refine features. Each iteration produces something that can be reviewed, so feedback arrives earlier.

Agile and Scrum

Agile is a set of values that favour working software, collaboration and responding to change. Scrum is a popular agile framework: work happens in fixed-length sprints of up to a month, guided by a prioritised product backlog. Its events are sprint planning, the daily scrum, the sprint review and the retrospective, and its roles are the product owner, the Scrum Master and the developers.

Kanban

Kanban has no fixed sprints. Tasks move across a board with columns such as To do, In progress, Review and Done, and the team sets work-in-progress limits on columns so that work flows steadily instead of piling up. It suits support and maintenance teams with a constant stream of requests.

DevOps and CI/CD

DevOps brings development and operations together so the same team builds, releases and runs the software. Continuous integration (CI) automatically builds and tests every change pushed to the shared repository; continuous delivery or deployment (CD) automatically prepares or releases changes that pass. Version control with Git and GitHub sits at the centre of this workflow.

Example walkthrough: a college library app

Imagine a small team building a web app that lets students in a college search the library catalogue and reserve books, using an agile approach with two-week sprints.

1. Planning: the team agrees the goal (online search and reservations), a deadline before the new term and a short risk list, such as messy existing catalogue data.
2. Requirements: they write user stories, for example "As a student, I want to reserve an available book so that I can collect it later", each with acceptance criteria.
3. Design: they sketch wireframes, design tables for books, students and reservations, and decide which pages and endpoints exist.
4. Implementation: in sprint one they build search; in sprint two, reservations. Each change goes through a pull request and code review.
5. Testing: unit tests check the reservation rules, and the librarian tries the app against the acceptance criteria at each sprint review.
6. Deployment: a CI pipeline runs the tests and deploys to a staging server, then to the live server once approved.
7. Maintenance: after launch, students report bugs and request a "notify me" feature, which go into the backlog for the next sprint.

The same phases appear in every sprint, just in a smaller form, which is the main difference between agile and waterfall.

Choosing an SDLC model for your project

Good practice across every model

• Write requirements as testable acceptance criteria, not vague wishes such as "fast" or "user-friendly".
• Keep all code and configuration in version control from the first day.
• Automate tests early so every change is checked the same way.
• Hold short reviews or retrospectives and change the process when something is not working.
• Keep artefacts as light as the project allows; documentation exists to help people, not to fill folders.

Clean, well-organised code makes every phase easier, which is why structuring programs with classes and objects in Python or similar techniques pays off during maintenance.

Practical exercise: plan a small project through the SDLC

1. Pick a small app idea, such as an expense tracker for a hostel room.
2. Write a one-paragraph project brief and five user stories with acceptance criteria.
3. Draw a simple design: the screens and the data you need to store.
4. Create a Kanban board with To do, In progress and Done columns and add a card for each story.
5. Write down how you would test each story and how you would deploy the app.

You are done when you have one artefact for each of the seven phases and can explain which model you chose and why. The PHP Foundation course lets you put a plan like this into practice by building projects in PHP.

Common mistakes

• Starting to code before the requirements are written down and agreed with the people who will use the software.
• Treating testing as a single phase at the end instead of a habit throughout development.
• Calling a project agile while still planning every detail up front and never changing the plan.
• Skipping the deployment and rollback plan until the day of release.
• Ignoring maintenance in the plan, even though software keeps needing fixes and updates after launch.

Frequently asked questions