| Phase | Typical output | Typical owners | Planning use |
|---|---|---|---|
| Planning | Project plan, feasibility report | Project managers, senior engineers, stakeholders | Settle scope and feasibility before committing build effort. |
| Requirements | Software requirement specification (SRS) | Business analysts, product owners | Put user pain points and performance needs in writing so every later phase has a reference. |
| Design | Design document covering architecture decisions and implementation details | Engineers, with stakeholders reviewing | Schedule a review of the document before coding starts. |
| Development | Source code, executable application | Frontend, backend and full-stack developers | Let project and product managers prioritise and unblock work. |
| Testing | Tested software, from unit tests up to end-to-end integration tests | Developers and, in some organisations, QA engineers | Decide which test layers each release needs. |
| Deployment | Live application | DevOps engineers, release managers | Route releases through a CI/CD pipeline rather than manual steps. |
| Maintenance | Patches, updates, new versions | Support engineers, developers | Keep capacity for monitoring and fixes after launch. |
Outputs and roles follow the stage breakdown in GeeksforGeeks’ SDLC guide, with design review and testing layers from the University of Michigan’s SDLC overview.
The phases of the software development life cycle run from planning and requirements through design, development, testing, deployment and maintenance; IBM counts seven phases and the University of Michigan lists six steps.
For the surrounding engineering topics, start from the software development guide.
What the phases mean for your decisions
The SDLC is the methodology a team follows to plan, design, implement, test and maintain software. Its practical value is that each phase forces a decision that is expensive to make late. These are the ones the evidence supports most clearly.
- Write requirements down before design begins. The University of Kansas SDLC standard requires a detailed Functional Requirements Document in its requirements phase, and says a risk analysis should be done between the requirements and design phases. Teams without a formal standard can still borrow both habits (University of Kansas).
- Treat the design document as a review gate. Michigan describes the design phase’s output as a design document that outlines architecture decisions and is reviewed by engineers and stakeholders. Disagreements surface on paper instead of in code.
- Keep QA independent of the builders. Kansas says representatives separate from the development group should conduct internal quality assurance testing. This suits teams large enough to staff it; smaller teams should at least have someone other than the author check each change.
- Remove test scaffolding before production. The Kansas standard says all tools, code or access mechanisms used for development or testing must be removed before the move to production.
- Plan the way back as well as the way out. If a release causes errors in production, teams can start a rollback to the last known safe code version, according to the University of Michigan. Decide who can trigger it before launch day.
- Budget for maintenance as a permanent phase. Unlike the other phases, Kansas says maintenance ends only when the system is decommissioned, and it calls for penetration testing at scheduled intervals.
How each phase works
Industry-standard development phases are defined by ISO/IEC 15288 and ISO/IEC 12207, according to the University of Kansas standard. Its minimum required phases are System Initiation, Requirements Analysis, System Design, System Construction (Procurement), Testing and Acceptance, Implementation, and Maintenance. IBM adds the useful principle that each phase has its own objectives and deliverables, and those deliverables guide the next phase.
Planning and requirements gathering
Planning produces a project plan and a feasibility report, with project managers, senior engineers and stakeholders involved. Requirements gathering then turns intent into a specification. Michigan describes the phase as speaking to users and understanding their pain points, then documenting software specifications that reflect those needs and the performance requirements. GeeksforGeeks names the output a Software Requirement Specification, owned by business analysts and product owners. IBM frames the same stage as detailed requirement documentation that follows an initial project plan.
Design and architecture
Design translates the specification into a structure. GeeksforGeeks calls its output a Design Document Specification covering high-level and low-level design, and IBM calls it a software design document. Architecture choices such as service boundaries belong here; the trade-offs are compared in Microservices Architecture Patterns: Practical Choices For Scalable, Resilient Systems In 2026 – Interestingdevelopment.
Development
In implementation, the developers responsible for a feature write new code or update existing code. Frontend, backend and full-stack developers produce source code and an executable application, according to GeeksforGeeks, and IBM describes the deliverable as a functional prototype. Project and product managers help here by prioritising work and unblocking developers, a role highlighted by Michigan.
Testing
Testing often involves multiple layers, from unit testing of individual, atomic functions up to end-to-end integration tests, and some organisations employ QA engineers for it. IBM describes the result as refined software. Choose layers according to risk: unit tests give fast feedback on small functions, while end-to-end tests confirm that the assembled system behaves as users expect. Deeper coverage of test types and timing is in SDLC Testing: A Practical Guide To Ensuring Quality Throughout The Software Life Cycle (2026) – Interestingdevelopment.
Deployment
Deployment pushes code from a developer’s local environment through a CI/CD pipeline all the way to the production environment. GeeksforGeeks notes that continuous integration and continuous deployment pipelines make releases faster and more reliable, and assigns the work to DevOps engineers and release managers. The deliverable, in IBM’s wording, is software made available to users.
Maintenance
Maintenance is continuous monitoring of production services. Its outputs are patches, updates and new versions, handled by support engineers and developers. When a new issue or use case appears, Michigan notes, the whole SDLC process starts again, which is why the cycle is a loop rather than a line.
Waterfall, Agile and other models
Models do not remove phases; they change how often and in what order the phases happen. GeeksforGeeks says the SDLC typically has six or seven stages depending on the development model used, and lists Waterfall, Agile, V-Model, Spiral, Incremental and RAD as common models. freeCodeCamp summarises the shared backbone as requirement analysis, design, implementation, testing and evolution.
- Waterfall: finishes all parts of a phase before moving on to the next. freeCodeCamp traces it to construction and manufacturing and does not recommend it for larger, longer projects. It fits work where requirements can be fixed up front and the sequence is easy to audit.
- Agile: emphasises small, incremental releases with ongoing release cycles and stakeholder feedback. Each increment passes through a compact version of the same phases, so requirements and testing happen continuously rather than once.
- Iterative approaches: developers create, test and deploy early versions quickly and at low cost, then refine them. This suits teams that expect requirements to shift as users react to working software (University of Michigan).
Pick the model first, then adapt the table above: with Waterfall each row is a stage gate, and with Agile each row is a recurring activity inside every increment.
Frequently asked questions
Is Agile a replacement for the SDLC?
No. Agile is one of several models for running the SDLC, alongside Waterfall, V-Model, Spiral, Incremental and RAD. The underlying activities of planning, building, testing and maintaining remain.
Which tools run a CI/CD pipeline?
Michigan names GitLab and Jenkins as tools for pushing code through a CI/CD pipeline to production.
Who performs user acceptance testing?
The University of Kansas standard assigns user acceptance testing to representatives of the user group, separate from the internal QA testing done by people outside the development group.
Why do guides disagree on the number of phases?
Guides group the same work differently. IBM lists seven phases, Michigan combines testing with integration and ends on operationalisation and maintenance across six steps, and Kansas names seven required phases that include procurement.
