The software development lifecycle (SDLC) is the sequence of phases a team follows to plan, build, test, release and maintain software. Every project has one, written down or not. In TekRevol’s judgment, a regulated medical device and a first-version app follow the same stages, but not in the same order.
A shared SDLC lets a team see what is done, what comes next and what is still unknown, which helps on any custom software development project. This guide explains what the SDLC is, then covers the main models and methodologies, the stages, the benefits and challenges, and how to choose the right model.
What is the software development life cycle (SDLC)?
The software development life cycle (SDLC) is the order of work every software project passes through, whatever model or methodology the team uses. It answers a simple question: in what order does the work happen, and who approves each step? In software engineering, the SDLC process is the common frame that planners, developers, testers and operations staff share.
The SDLC is a structure for the work, not a tool or a single document. A project plan lists dates and tasks, while the SDLC defines the stages those tasks belong to and the checkpoint at the end of each one.
You will see both “lifecycle” and “life cycle” in use, and they mean the same thing. The acronym is sometimes expanded as “systems development life cycle”, which in our reading usually points to information systems beyond software. This guide covers the software version.
Is the SDLC waterfall or Agile? It is neither. Waterfall and Agile are two ways of running the SDLC: Waterfall runs each stage once, in order, while Agile repeats the stages in short cycles.
Source: TekRevol’s own framing of how stages, models and methodologies relate.
The diagram shows how the terms fit together. The stages sit at the base, a model sets their order, and a methodology governs how the team works day to day. Teams use the word Agile for both the delivery model and the day-to-day methodology. This is TekRevol’s reading.
Which SDLC models do software teams use?
An SDLC model sets how the stages are sequenced, in a single pass or in repeating loops. Software teams commonly use six software development life cycle models, often shortened to SDLC models: Waterfall, V-Model, Iterative, Incremental, Spiral and Agile. The table shows how each one runs and where it fits.
| Model | How the stages run | Where it fits |
| Waterfall | Each stage runs once, in strict order, with sign-offs between them | Fixed scope and frozen requirements |
| V-Model | Waterfall with a matching test stage for every design step | Certification-heavy or safety-critical work |
| Iterative | Repeated build, evaluate and improve passes on one product | Large systems whose requirements firm up through use |
| Incremental | Finished modules are built and shipped one at a time | Products that can launch in useful parts |
| Spiral | Loops run in risk order, tackling the biggest unknown first | High-stakes projects with technical uncertainty |
| Agile | All stages repeat in short cycles, each producing releasable software | Evolving products with engaged stakeholders |
The table is a summary of our guide to software development models, which covers nine in total, including Prototype and RAD, and compares what each costs and when they combine.
In TekRevol’s judgment, Waterfall and the V-Model are sequential, so they find a wrong requirement late, when changing it is expensive. Also in TekRevol’s judgment, the repeating models find it early, but they need stakeholders who can review work every cycle, and they make a fixed budget harder to promise.
SDLC methodologies and how they differ from models
An SDLC methodology describes how a team organizes its work inside the sequence a model sets. The model answers “in what order”, and the methodology answers “how does the team work day to day”. The terms are used loosely across the industry, so the table pins each one down.
| Term | The question it answers | Example |
| SDLC | Which stages does every project pass through? | Planning through maintenance |
| Model | In what order do the stages run? | Waterfall, Spiral |
| Methodology | Which philosophy guides how the team works? | Agile, DevOps |
| Framework | What is a specific version of that philosophy? | Scrum, SAFe |
| Practice | Which technique does the team use day to day? | Pair programming, stand-ups |
The Model row is TekRevol’s own framing. The other rows follow our guide to software development methodologies, which compares nine of them in depth. Check what a vendor means by these words before you sign a statement of work, because the same word can describe either a model or a methodology.
Agile is the clearest example of a methodology with a stated philosophy. The Agile Manifesto’s principles ask teams to deliver working software every few weeks, no more than a couple of months apart, and to prefer the shorter interval.
DevOps extends the SDLC past the handoff to operations by automating testing and releasing through a continuous integration and delivery pipeline. In TekRevol’s judgment, most Agile teams use it alongside a framework such as Scrum.
What are the seven stages of software development?
Software moves through seven stages: planning, requirements analysis, design, development, testing, deployment and maintenance. The table shows what happens in each stage and the output it typically produces. The outputs are typical and our summary of common practice.
| Stage | What happens | Typical output |
| 1. Planning | Scope, goals, budget and feasibility are set | Project plan and a go or no-go decision |
| 2. Requirements analysis | Needs are gathered from users and stakeholders and written down | Requirements specification |
| 3. Design | Architecture, data model, interfaces and user experience are defined | Design documents and prototypes |
| 4. Development | Engineers write and review the code | Working code in version control |
| 5. Testing | The team checks the software against the requirements and fixes defects | Test results and a release decision |
| 6. Deployment | The software is released to users | A live release and a rollback plan |
| 7. Maintenance | The team fixes defects and keeps the software supported and up to date | Patches and updated releases |
In practice the stages overlap. An Agile team runs all seven inside each short cycle, while a Waterfall team finishes each stage before starting the next.
Testing in the SDLC also reaches back past its own stage. In our judgment, test planning should start in requirements analysis, because a requirement that cannot be checked is not finished.
Most descriptions stop at maintenance, yet software eventually retires. In our judgment, a plan for retiring it, covering data migration and notice to users, belongs in the planning stage. We cover each stage in detail, including deliverables and sign-offs, in our guide to the seven phases of the SDLC.
Benefits of following an SDLC
Why the SDLC is important comes down to visibility: following it gives a team a shared order of work, which makes progress and risk easier to see. The table lists five benefits and what each looks like in practice. These are our judgment, based on how the stages work, not measured results.
| Benefit | What it looks like in practice |
| Visibility | Stakeholders can see which stage a project is in and what comes next |
| Better planning | Each stage has an output, so estimates attach to real deliverables |
| Earlier risk detection | Requirements and design reviews catch problems before code exists |
| Clear ownership | Each stage has named owners and a sign-off, so handoffs are explicit |
| Easier audits and onboarding | Stage outputs form a record that reviewers and new team members can follow |
These benefits depend on following the stages, not on documenting them. A team that writes a requirements document nobody reads gets none of them.
The benefits also vary by model. A Waterfall team gains predictable dates and scope, while an Agile team gains early feedback from real users. In our judgment, the benefit your project needs most should influence which model you choose.
Common SDLC challenges and how to fix them
Most SDLC problems come from picking the wrong model or skipping a stage, not from the SDLC itself. The table pairs each common challenge with a fix. It is our judgment, except where a source is named.
| Challenge | Why it happens | Fix |
| Requirements change mid-build | A sequential model assumes they are fixed | Use an Iterative or Agile model, or add a change process with a named owner |
| Testing gets squeezed | Earlier stages run late and the release date stays fixed | Test during development, and cut scope before cutting test time |
| Security arrives late | Most SDLC models do not address security in depth | Add secure development practices to every stage |
| Handoffs fail | Stage outputs are vague, so the next team guesses | Define each stage’s output and sign-off in writing |
| Contract and model disagree | A fixed-price contract punishes the changes an Agile team expects | Write the model into the statement of work, with a rule for handling scope changes |
| Documentation falls behind | Under deadline pressure, documents are the first thing cut | Make updating the stage output part of the definition of done |
The security row has a source. The NIST Secure Software Development Framework (SP 800-218, version 1.1, February 2022) says most SDLC models do not address software security in depth, so secure practices have to be added to each model. In TekRevol’s judgment, that makes security a task in every stage, not a test at the end.
In our judgment, you can tell a model problem from an execution problem by asking whether a different model would have prevented it. If requirements keep changing under Waterfall, the model is wrong. If an Agile team still has no usable requirements, a stage is being skipped.
How do you choose the right SDLC model?
Choose the model by six factors: the cost of a defect (physical harm or a regulatory breach), whether the core technology is proven, whether stakeholders can describe what they want before they see something, whether requirements are locked or will evolve, whether the product can launch in useful pieces or must arrive whole, and whether stakeholders are engaged throughout or available only at milestones. We call the check below the TekRevol Model Fit Check.
Read the rows in order and stop at the first one that is true for your project. The TekRevol Model Fit Check condenses the decision tree in our software development models guide, and it is our judgment, not a standard.
| If this is true | Start with | Why |
| 1. A defect could cause physical harm or a regulatory breach | V-Model | Certification evidence outranks every other concern |
| 2. The core technology is unproven and “can this be built?” is still a live question | Spiral for the risky part, then Iterative or Agile | The biggest unknown gets tackled first |
| 3. Stakeholders cannot describe what they want until they see something | A prototype first, then pick from the rows below | Requirements you can trust come from something people have seen |
| 4. Requirements are locked under a signed scope | Waterfall | Sequential stages fit work that will not move |
| 5. Requirements will evolve and the product can launch in useful pieces | Incremental | Each piece ships when it is finished |
| 6. Requirements will evolve, the product must arrive whole and stakeholders are engaged throughout | Agile | Short cycles absorb change |
| 7. Requirements will evolve, the product must arrive whole and stakeholders are available only at milestones | Iterative | Reviews happen when stakeholders can attend |
A very short deadline with users available every week points to RAD instead, which our models guide covers. In our judgment, if two rows seem true, take the higher one, because it addresses the costlier risk. If no row fits, a hybrid is reasonable, as long as you write down which stages follow which model.
Two examples, both our illustrations. A team building control software for a medical device answers yes at row 1 and lands on the V-Model. A product team building a customer app that must launch whole, with the product owner in the room weekly, passes rows 1 to 5 and lands on Agile at row 6.
In TekRevol’s judgment, the most common mistake is choosing a model because it is popular. A locked-scope, audited project can fit Waterfall or the V-Model better.
How TekRevol runs custom software projects
If you have run the Fit Check and two rows still seem true, get a second opinion before you commit to a model. TekRevol is a software development company, and its custom software development team builds in two-week agile sprints and tests for functionality, performance, security and usability before launch. Its process begins with Discover and ends with Training & Support.
In TekRevol’s judgment, whichever company you hire, ask for the development model and the stage sign-offs in writing before you commit. Bring your requirements and ask for the recommended model and its stage sign-offs in writing.
Start with a Free Consultation.
