What Is SDLC? Stages, Models and Agent-Driven Changes

SDLC, the software development life cycle, is the set of stages that turns an idea into working software and keeps it running after release.

You have an app idea, a list of features, and someone ready to write code. But who checks whether the features solve the right problem? Who decides when the software is safe to release? SDLC gives your team a way to answer those questions before mistakes reach users.

What SDLC Means and Why Teams Use It

Building software is a bit like building a house. You wouldn't pour the foundation before drawing plans, and you wouldn't move in before an inspection. You also need someone to repair the roof after you move in.

Software needs that same care. A developer can build a booking form quickly, but the team still needs to agree on what patients can book, how staff manage appointments, and what happens when something fails.

More than a coding checklist

Each stage produces something another person can check: a requirements list, a design, test results, or a release decision. Managers use these records to estimate costs, assign owners, and decide whether the team should continue.

The history helps explain that role. As described in this history of software development processes, Winston Royce published a detailed seven-phase sequence in 1970, while Thomas Bell and Thomas Thayer helped popularize the waterfall label in 1976. Royce's paper didn't use that label, and he warned against a rigid, single-pass process.

The lifecycle also became a governance tool. The National Academies account describes a milestone in 1985, when the U.S. Department of Defense adopted a phased software-development standard for contractors.

Practical rule: A stage isn't finished just because someone stopped working on it. It needs an output that the next person can inspect.

So, what is SDLC in everyday terms? It's the whole job of making and caring for software, not just writing code. SDLC describes the work to manage. Waterfall, agile, and DevOps describe different ways to organize it.

The Seven Stages of the Software Development Life Cycle

The stages are requirements, analysis, design, implementation, testing, deployment, and maintenance. Their outputs connect: the design guides implementation, and requirements guide testing.

Teams group these activities differently. Some put planning first and combine analysis with requirements, as the diagram does. The important thing is to cover the work, not force every team to use identical labels.

Follow a dental booking app

1. Requirements. The clinic wants patients to book online. The product owner writes acceptance criteria, meaning clear conditions the feature must meet. For example, a patient must receive confirmation after booking.
2. Analysis. The team checks cost, scheduling-system access, and business rules. Patients can't reserve the same appointment slot, even if they click at the same moment.
3. Design. Engineers choose the database, login approach, and booking flow. They decide how the system reserves a slot safely. A software design review process helps catch weak assumptions before implementation.
4. Implementation. Developers write the booking form, appointment service, and database changes. They store code in version control and submit pull requests for review.
5. Testing. Testers and developers check normal bookings, competing requests, and failed payments if the clinic takes deposits. They also check whether a failed payment leaves a slot incorrectly reserved.
6. Deployment. The release engineer puts the approved build into production. The team checks that booking works in the live environment and prepares a rollback if it doesn't.
7. Maintenance. The team fixes bugs, updates dependencies, and watches for failures. Appointment reminders become a new change that goes through the relevant stages.

Keep a checkable output

The seven SDLC stages, their questions and outputs

The security column isn't an extra phase. NIST's Secure Software Development Framework organizes secure development into four practice groups: preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.

For the clinic, that means deciding who may view patient details before coding, checking dependencies during development, and protecting the released build. Finding an unsafe design early lets the team change it before patients use it.

Write down each stage's output before handing work over. Keep requirements connected to designs, pull requests, and tests so reviewers can check what was delivered.

Who Owns Security at Each Stage

A security check without an owner is easy to miss. Product, engineering, release, and operations teams need clear responsibilities, rather than assuming the security team will catch everything.

NIST's secure-development guidance notes that few SDLC models address security in enough detail and recommends integrating secure-development practices into each lifecycle implementation.

Assign the work and the evidence

Treat preparation, software protection, secure production, and vulnerability response as ownership checks. Each needs a responsible person, even when the same engineer covers several roles.

For the clinic's payment integration, the architect records payment-related threats. The developer checks the payment library, and a named maintainer receives vulnerability alerts after release.

Every security check needs a named owner and a recorded output. A missed check should become visible at handover, not during an incident.

How Teams Arrange the Stages Across Waterfall, Agile and DevOps

The same lifecycle can run as one long pass, a set of loops, a sprint rhythm, or a continuous flow. Waterfall closes each phase before the next begins. Iterative approaches repeat the activities in smaller cycles, so teams can learn from working software.

Agile adds frequent customer feedback and short planning cycles. DevOps connects development and operations through shared responsibility, automated delivery, and production monitoring. These approaches can overlap inside one product.

Compare the working patterns

How four delivery models run the SDLC stages

Iterative development repeats planning, risk analysis, engineering, and customer evaluation in cycles. Returning to earlier work can be the model working as designed, especially when each cycle produces evidence that changes the next decision.

Decide what sends work back

Treat the lifecycle as a control system for uncertainty. Before work advances, ask what you learned and whether an earlier decision still holds.

• Failed acceptance test: If the clinic's cancellation rule is unclear, return to requirements rather than guessing in code.
• Security finding: If patients can access another patient's booking, revisit the access-control design.
• Production behavior: If patients abandon the form at login, review the product assumptions and user flow.
• Changed constraint: If the clinic changes its scheduling provider, reopen the integration design.

Record the finding, the affected decision, and who approves the revision. A Kanban board for blocked work can make return paths visible instead of hiding rework inside an implementation ticket.

A team building payments in a regulated market might use formal gates for compliance design and short sprints for the interface. That combination can be deliberate. Pick the arrangement that reveals costly rework earliest, not the one with the most popular name.

How Agent-Driven SDLC Differs From Traditional Work

In a traditional workflow, developers usually write the first draft of designs and code, then peers review it. In an agent-driven workflow, an agent drafts from an approved specification and checks its output before a person reviews it.

Automation is already common. In 2024, 67% of respondents said their software development lifecycle was mostly or completely automated, according to GitLab's Global DevSecOps Report, which surveyed more than 5,000 DevSecOps professionals worldwide. That finding measures automation, not autonomous agent adoption.

Compare the handoffs

The table contrasts a manual-first workflow with a governed agent workflow. These are working patterns, not limits on what either approach can do.

Traditional versus agent-driven SDLC

Keep approval separate from generation

Cheap generation doesn't make a vague specification safer. An agent can implement the wrong cancellation policy across the interface, database, and tests before anyone notices the misunderstanding.

A sound human-in-the-loop agent workflow pauses where a person must make a decision. Approving a design is different from accepting a generated summary that says the design passed.

For the clinic, an agent builds the approved change and opens a pull request. We recommend preview deployments with a URL for each pull request, so you can inspect the live result using Loupe's live review widget. A reviewer can try booking and cancelling instead of judging the interface only from code.

Faster drafting makes approval points more important, not less. Don't let a passing agent check silently become permission to release.

People still need to approve product intent, accept architectural and security risks, and authorize release. Agents can prepare evidence and suggest fixes, but accountable humans decide whether the result is acceptable.

Measure Your SDLC and Take the First Steps

Measure one service first. Mixing unrelated teams can hide a slow review queue in one service behind frequent releases from another.

Use these definitions consistently:

• Deployment frequency: How often changes reach production.
• Lead time for changes: Time from a change entering version control to successful production deployment.
• Time to recover: Time to restore service after a failed deployment.
• Change failure rate: Share of deployments needing immediate intervention, such as a rollback or hotfix.

Read speed and stability together

IBM's explanation of DORA metrics presents the following performance bands, including elite deployment frequency of multiple times per day and change-failure rates of 0–15%.

DORA performance bands for SDLC health

Don't treat a band as a release quota. Rising deployment frequency alongside a rising failure rate suggests the team is moving faster than its checks can support. Long lead time with a stable failure rate calls for investigating review queues, environments, and approvals.

DORA's metrics guidance supports measuring delivery outcomes together. Collect pull-request timestamps, CI results, deployment events, incidents, and rollback records so you can locate delays rather than guess.

Start with a small baseline

1. Map your actual stages. Compare them with the lifecycle activities above. Include informal work such as release approval.
2. Name gate owners. Record who can approve or stop work and what evidence they need.
3. Measure a baseline. Track lead time and change failure rate for one service over two weeks before changing the workflow.
4. Write security checks. Use the stage table as a starting point, then assign owners.
5. Try a small agent-built change. Count review rounds and failed deployments before expanding its scope.

Keep repository rules explicit. Our loupe project link command writes .loupe/lifecycle.md, the repository profile every stage skill reads. It holds gate commands, pull-request rules, column names, and epic branch rules.

Read that file, correct its guesses, and commit it. A worker sees only what you push. The command also writes .loupe.yaml, which holds the project ID; commit it so everyone in the repository reaches the same project.

Before advancing any work, ask: Who approves it, what evidence do they need, and what happens if it fails?

---

Loupe organizes coding-agent work across design, implementation, and review, with explicit human checkpoints. Visit Loupe to explore a workflow that keeps approved designs, agent actions, and review decisions connected.