Section I · Lesson 2

The Software Development Lifecycle

The Software Development Lifecycle (SDLC) is the structured process a team follows to plan, create, test, and deliver software. It defines every stage a feature goes through — from the moment someone writes a requirements document to the moment a user clicks a button in production. The SDLC exists because software development without structure produces inconsistent, unreliable results; it gives teams a repeatable framework so that quality is built in, not bolted on at the end.

The Six Phases of the SDLC

Every SDLC model — no matter how it is labelled — moves through the same six fundamental stages. The difference between models is how long each stage takes, whether stages overlap, and how many times the cycle repeats.

Waterfall: One Big Loop

The Waterfall model treats the SDLC as a single, linear sequence. Each phase completes fully before the next begins. Planning finishes, then requirements are locked, then design is completed, then development starts — and so on. The entire product ships in one large release at the end.

This sounds logical — and for certain categories of work (construction, hardware manufacturing) it is. But for software, it creates a dangerous problem: feedback arrives too late. A requirement written six months ago may no longer reflect what the business actually needs. Bugs discovered only in the final testing phase cost far more to fix than bugs caught the same day they were introduced.

Agile: Many Small Loops

The Agile model runs the SDLC in short cycles called sprints — typically one to two weeks long. Each sprint delivers a working, tested slice of the product. Stakeholders see the result, give feedback, and the team adjusts before building the next slice.

This fundamentally changes the risk profile of software delivery. Instead of one enormous high-stakes release, you have many small low-stakes releases. Each one carries a fraction of the risk. Bugs surface after days, not months. Misunderstood requirements surface after one sprint, not after a full year of work.

Where CI/CD Plugs Into the SDLC

CI/CD does not replace the SDLC — it automates the most repetitive and error-prone parts of it. Specifically, it targets the transition points between phases, because those transitions are where things historically go wrong: code that passed local testing failing in the shared environment, a deployment that works in staging but breaks in production.

As covered in Lesson 1, the CI part takes over the moment a developer pushes code — building it, running tests, and reporting results. The CD part takes over after that — packaging the artifact, promoting it through environments, and either deploying automatically or waiting for a manual approval gate. Together they close the gap between code written and code in front of users.

The Feedback Loop: Why It Changes Everything

The single most important concept in the SDLC is the feedback loop — the time between when an action is taken and when its consequences are known. In a Waterfall project, the feedback loop for a bug can be six months. In an Agile project with CI/CD, that feedback loop collapses to minutes.

This is not a marginal improvement. Research by DORA (DevOps Research and Assessment) consistently shows that the length of the feedback loop is the single strongest predictor of both software delivery performance and organisational stability. The numbers are striking:

The SDLC and DevOps Culture

The SDLC in a traditional organisation is divided by department: business analysts own Planning and Requirements, developers own Implementation, a separate QA team owns Testing, and an operations team owns Deployment. Each handoff is slow, has potential for miscommunication, and creates a culture where people optimise for their own phase rather than the outcome of the whole cycle.

DevOps is the cultural and organisational movement that breaks down these walls. It says that the people who build software should also be responsible for running it in production, monitoring it, and being paged when it breaks. This shared ownership is what makes CI/CD practices stick — when developers can see their code in production within the hour, and when they are responsible for incidents that code causes, the incentive to write well-tested, small, safe changes becomes very personal.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz