Software Development Life Cycle (SDLC): Phases and a Lightweight Version

The software development life cycle (SDLC) is the sequence of activities that takes software from an idea to something people use, keeps it running, and eventually retires it. Most descriptions use six or seven phases: plan, define requirements, design, build, test, deploy, and operate and maintain. The phases are the same whatever method you follow; what changes between models is how often you go around them. Waterfall goes around once. Agile and DevOps go around every few weeks or every few days, for a small slice of the product each time. A small team does not need a heavy process for this, only a clear answer to one question per phase, and AI agents can now help with almost every phase as long as a person still makes the calls.

What the SDLC covers

The US government’s security glossary is a good reference point because it is deliberately broad. The NIST definition of the system development life cycle↗ (opens in a new tab) is “the scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal.” Two things in that sentence are easy to forget: the life cycle does not end at launch, and it includes turning the system off. Most of a successful product’s life is spent in operation and maintenance.

The SDLC phases

1. Plan. Why build this, for whom, and what is out of scope? The output is a goal, a rough size and a decision to go ahead.
2. Requirements. What must it do, and how will you know it works? The output is a list of requirements or user stories with acceptance criteria.
3. Design. How will it be built? Architecture, data, interfaces and the risky parts. The output is a design note or a technical design document for larger work.
4. Build. Writing the code, reviewing it and merging it. The output is working software in a branch or a build.
5. Test. Does it do what the requirements said, and did anything else break? Unit, integration, regression and acceptance testing all live here.
6. Deploy. Getting it to users safely: release, rollout, release notes and a way back if it goes wrong.
7. Operate and maintain. Monitoring, fixing bugs, patching dependencies, answering support, and deciding when to retire it.

SDLC models: how the phases are arranged

The models differ in order and repetition, not in the phases themselves. NIST’s Secure Software Development Framework↗ (opens in a new tab), SP 800-218, names the common ones: waterfall, spiral, agile and, in particular, agile combined with DevOps practices.

• Waterfall. Each phase once, in order, with a sign-off between phases. Suits stable requirements and fixed-scope contracts. Agile vs waterfall covers when that trade is worth it.
• V-model. Waterfall with a test phase paired to each earlier phase: acceptance tests for requirements, integration tests for design. Common where testing must be traceable to requirements.
• Iterative and incremental. Build the product in slices, each going through design, build and test, so something works early and grows.
• Spiral. Iterations planned around risk: each loop tackles the biggest open risk first, often with a prototype.
• Agile. Short cycles of a few weeks, working software each time, requirements that change as you learn. Scrum and Kanban are the common forms; see project management methodologies compared.
• DevOps. Agile delivery joined to operations: the same team builds, deploys and runs the software, with automated testing and deployment so the cycle can run many times a day.

Security belongs in every phase

Older SDLC diagrams put security in the test phase, which is where it is most expensive to add. The SSDF’s position is that few SDLC models address security in detail, so secure development practices should be integrated throughout whichever model you use. It groups them into four areas: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. CISA’s Secure by Design↗ (opens in a new tab) initiative makes the same point from the vendor’s side, asking makers to build security in during the design phase rather than leaving it to customers to bolt on.

For a small team, that translates into a few habits: a line in each design note about what could go wrong, dependency updates treated as ordinary tasks, secrets kept out of the repository, and a written way to handle a reported vulnerability.

A lightweight SDLC for a small team

You do not need a document per phase. You need each phase to leave a trace somewhere the team will look. Here is a version that fits on one task:

Title:    Let customers save a card for next time
Plan:     Repeat buyers asked for it; out of scope: Apple Pay.
Require:  Saved card appears at checkout; can be removed;
          card number never stored by us.
Design:   Use the payment provider's saved-payment feature;
          store only its reference ID. Risk: stale reference.
Build:    Branch saved-card; PR reviewed by one person.
Test:     Save, reuse, remove, expired card, second browser.
          Regression: guest checkout still works.
Deploy:   Behind a setting; on for staff first, then everyone.
          Release note: one line.
Operate:  Watch payment errors for a week; bug tasks if any.

The plan and requirements become the task’s note, the design is a paragraph in its plan, and the test and deploy lines are the checks someone ticks before it is called done. Larger work gets a proper spec first; spec-driven development is one way to run that. Testing detail belongs in a regression testing checklist, and the operate phase feeds bugs back to the top of the cycle, which the bug life cycle describes.

Where AI agents fit in the SDLC

AI coding agents and assistants can now contribute to every phase. What they should not do is make the decisions that each phase exists to make. A useful split:

• Plan: an agent can summarize customer requests and draft the options. Choosing what to build is a person’s call.
• Requirements: an agent drafts user stories and acceptance criteria from a conversation or a ticket; a person confirms they describe what was meant.
• Design: an agent reads the codebase and proposes an approach, lists affected files and flags risks. A person approves the design before code is written.
• Build: this is where agents do the most today, writing code, running tests and opening pull requests. How to write a task for an AI agent covers what they need to start.
• Test: agents write and run tests well, and can check their own work against the acceptance criteria. Signing off that it works stays with a person; verifying AI-generated work sets out a review process.
• Deploy: agents can prepare release notes and run scripted deploys. Pressing the button on a production release is usually kept for a person.
• Operate: agents triage bug reports, reproduce issues and propose fixes, which then go around the cycle again.

If you build or fine-tune AI models rather than just using them, NIST publishes SP 800-218A↗ (opens in a new tab), which adds practices specific to AI model development to the SSDF across the life cycle.

Where fenbs fits

fenbs is a task board, so it holds the build-test-deploy loop rather than the whole life cycle. Each task has a note for the problem, a plan for how it will be done, a test status with test notes, and an optional size from XS to XL, which covers the lightweight version above without extra documents. Tasks move through To Do, Next Up, In Progress and Completed, and are features, enhancements or bugs, so the operate phase’s bug reports land on the same board as new features. AI assistants connect over MCP and work the same tasks as people, History records who changed what, and the Decisions and rules page holds the rules every connected assistant reads first, such as “a person signs off every production release.” It has no due dates, sprints or release calendar; keep those in your plan.