SDLC Guide · 16 short modules
Follow an idea from problem to product—and beyond.
A plain-English route through the software development lifecycle for anyone who works alongside a technical team. Start at the beginning or jump to the part you need.
Begin the guide →Phase 01
Deciding what to build
Start with the problem, the people affected by it, and a shared definition of success.
- 1Software Development Life CycleThe software development life cycle is the name for the repeatable journey from identifying a problem to designing, building, releasing, and improving a software solution.
- 2Product DiscoveryProduct discovery is the work of understanding a user problem and testing whether a proposed solution is useful, usable, and worth building.
- 3Requirements & Acceptance CriteriaRequirements describe what a solution must achieve, while acceptance criteria provide specific, testable conditions for deciding whether a piece of work meets that need.
Phase 02
Planning the solution
Turn the desired outcome into organised, achievable work.
- 4User Stories & TicketsA ticket is a trackable unit of work. A user story is one way to describe that work from the perspective of the person who needs the outcome.
- 5Backlogs, Sprints & AgileA backlog orders potential work. A sprint is a fixed period some teams use to tackle selected work. Agile is a broader approach built around small steps, feedback, and adaptation.
- 6Technical Design & ArchitectureTechnical design describes how a particular solution will work, while software architecture describes the larger structure, boundaries, and long-lasting choices of a system.
Phase 03
Building the software
See how engineers create and review changes without disrupting the live product.
- 7Source CodeSource code is the human-readable set of instructions developers write to make software work. Tools turn or interpret those instructions so a computer can run them.
- 8Development EnvironmentsDevelopment environments are separate places where a team builds, tests, and runs software. Local work usually happens on a developer’s computer; shared test, staging, and production systems usually run on servers.
- 9Version ControlVersion control is a shared, time-stamped history of changes to a project. It lets a team collaborate without losing earlier work.
- 10BranchingA branch is a separate path of saved changes to a project. It lets people work in parallel before combining their work with the main version.
- 11Pull RequestA pull request is a proposal to merge one set of code changes into another. It gives the team a place to review, discuss, and approve the work first.
Phase 04
Proving and releasing it
Build confidence in a change, automate checks, and make it available safely.
- 12Software TestingSoftware testing checks whether a system behaves as expected and helps the team understand the risk of changing it. Different test types catch different kinds of problems.
- 13Continuous Integration & DeliveryCI/CD automates checks when code changes are combined and prepares, or sometimes performs, deployment. It makes frequent, smaller releases easier to manage.
- 14Deployment vs ReleaseDeployment puts a new software version in place. Release lets users access its changes. The two can happen at different times.
Phase 05
Running and improving it
Understand real-world performance, handle problems, and use what the team learns.
- 15Monitoring, Logging & AlertsLogs record events, monitoring tracks the health and behaviour of a system, and alerts notify people when important signals suggest that attention is needed.
- 16Incidents, Rollbacks & IterationAn incident is an unplanned disruption to a live service. Teams work to limit its impact, restore service, and use what they learn to improve the product and process.