Open almost any SDLC guide and you will see a circle. Useful? Yes. Complete? Not quite. The difficult part is deciding whether the team knows enough to move on, or is about to fund the next stage on a hopeful guess.
A software development life cycle gives business, product, and engineering people a shared pause point: “Do we have enough evidence for the next commitment?” Sometimes that evidence is a requirement somebody has accepted. Elsewhere it is an architecture review, a build, test results, or production data. The artifact changes. The need for evidence does not.
The seven-phase picture helps, though real projects rarely follow it neatly. Intelisoft starts by watching a working day, not by drafting a feature inventory. That view can change requirements or release-one scope.
Key points
- The common SDLC phases: planning, requirements, design, development, testing, deployment, and maintenance.
- A useful SDLC deliverable can be inspected. "We discussed it" is not one.
- Agile and DevOps change when the work happens. They bring teams back to it in shorter loops.
- QA and security start before release week.
- Before a handoff, put the decision on one line. Then show today's evidence, name the approver, and say what would stop the work.
What is the software development life cycle
Figure 1. Seven SDLC stages with reviewable outputs and feedback loops. Custom visual by Intelisoft.
The seven phases of the software development life cycle
Names vary. Some teams also fold two phases together. Even so, most business and engineering groups recognize the 7 phases of software development life cycle work shown here. Use the SDLC phases as a map, not a one-way route. Nothing depends on the number being seven. A shared vocabulary is the useful bit. The table turns the software development life cycle stages into decisions and inspectable outputs.
| Phase | Decision | Core deliverable |
|---|---|---|
| Planning | Should we solve this problem now? | Business case, scope boundary, feasibility notes, risk list |
| Requirements | What must the product do, and what cannot move? | Prioritized requirements, acceptance criteria, non-functional constraints |
| Design | How will the product work within its environment? | Architecture decisions, data model, integration contracts, UX flows |
| Development | Can the design become reviewable working increments? | Source code, builds, unit tests, code-review evidence |
| Testing | Which risks remain, and are they acceptable? | Test evidence, defects, UAT results, release recommendation |
| Deployment | Can the team release, observe, and recover safely? | Release assets, rollback plan, runbook, monitoring |
| Maintenance | What should change now that users depend on the product? | Operational data, incidents, patches, backlog, updated documentation |
01
Planning defines the investment case
During planning, an attractive idea has to survive an investment decision. A final feature list can wait. What cannot wait are plain answers:
- Who has the problem?
- How painful is it?
- What result would be measurable?
- Which dependency could block the work?
- What are we explicitly not building?
This is where awkward constraints should come out. Data residency may rule out an otherwise attractive approach. A device may be impossible to replace. Procurement may have a hard date. A clinical workflow may not tolerate another login. One discovery can invalidate weeks of roadmap polishing, which is exactly why it belongs here.
Requirements turn the problem into testable behavior
Requirements should make the problem concrete enough that design and testing have something to work against.
“The system must be easy to use”
Closer to something the team can validate
“A nurse can complete the task in the existing workflow without opening a second system”
Intelisoft spends time on workflow discovery here. People describing a familiar process from memory tend to skip its odd cases. Watch the job being done and those exceptions, and the improvised fixes around them, show up. That is usually where the software has to fit.
03
Design makes expensive choices visible
Choosing architecture by naming fashionable components gets the order backward. Start with the behavior the product needs under the constraints already uncovered. Identity and data flow matter. So do integrations, failure behavior, performance, audit trails, deployment, and future change.
The best design artifact is not necessarily large. It should reveal a bad assumption without becoming a document everyone avoids. An API contract may settle one choice. A different choice may need an architecture decision record, sequence diagram, threat model, or rough prototype.
Development produces reviewable increments
In development, the chosen design becomes working software. If a reviewer cannot grasp an increment, it is probably too large. Reviews and unit tests show what was checked. Dependency controls, automated checks, and CI fill in the rest. Delay those checks and rework gets costly.
Code that works only on one machine is not ready for the next decision. Neither is generated code that nobody owns. Another engineer should be able to understand the increment, run it, review it, and repeat the agreed checks.
Testing measures the risk that remains
Testing has a wider brief than defects. Passing functional checks does not make a build pleasant to use. It may slow under real traffic, fail to recover, or reach production through an unsafe release. The useful checks depend on the product. The release question does not: can the team accept the risk that remains?
Sometimes the key evidence is an integration test. Elsewhere it may be load data, a security check, a recovery drill, accessibility review, or user acceptance. A filled template proves little. The useful question is whether the evidence justifies this release.
06
Deployment makes release and recovery observable
"Push to production" is not a deployment plan. A workable plan answers three things.
How does the change go in?
How will anyone see its health?
If release goes wrong, where is the exit?
For one product, the exit may be a feature flag. Another may need a staged release, blue-green deployment, or a manual fallback. Pick the mechanism by asking how much a bad release would cost, and prove that the team can use it before launch.
07
Maintenance turns production into planning evidence
Maintenance is not the queue left behind after the “real” project. Production tells the team what users actually do, which integration breaks first, where incidents gather, and which supposedly vital features see little use. Feed that evidence back into planning.
Why the SDLC is a circle
That loop is why the software development life cycle stages are better drawn as a circle than as a finish line.
The Intelisoft SDLC decision gate
At each meaningful handoff, Intelisoft pauses for four questions. Which decision is on the table? What evidence do we have, not expect to have later? Whose call is it to accept the work or return it? Which fact would justify the next spend? A small team might answer with a prototype, a short ADR, or a test report. In regulated work, the evidence trail will be longer. The test is usefulness, not ceremony.
Figure 2. The Intelisoft SDLC decision gate. Custom visual by Intelisoft.
SDLC decision gate matrix
Planning
Gate 1 of 7
Business question
Is the outcome worth funding?
Engineering activity
Feasibility and risk discovery
Deliverable
Business case and scope
Owner
Sponsor
Exit criterion
Outcome, boundary, budget, and major risks accepted
Common failure
Feature list without a measurable problem
Requirements
Gate 2 of 7
Business question
What must be true for users and the business?
Engineering activity
Workflow analysis and specification
Deliverable
Acceptance criteria and constraints
Owner
Product owner
Exit criterion
Requirements are testable, ranked, and owned
Common failure
Vague requirements or silent exceptions
Design
Gate 3 of 7
Business question
Can the solution meet the constraints?
Engineering activity
Architecture, UX, data, integration, threat modeling
Deliverable
Decision records and models
Owner
Technical lead
Exit criterion
Major trade-offs and risks are explicit
Common failure
Architecture chosen by habit
Development
Gate 4 of 7
Business question
Is the increment reviewable and reproducible?
Engineering activity
Coding, review, unit testing, CI
Deliverable
Working build and review evidence
Owner
Engineering lead
Exit criterion
Build passes agreed checks and is understood
Common failure
Large unreviewable batches
Testing
Gate 5 of 7
Business question
Is the remaining risk acceptable?
Engineering activity
Functional, integration, security, performance, UAT
Deliverable
Test evidence and recommendation
Owner
QA lead and business approver
Exit criterion
Critical criteria pass; residual risk is accepted
Common failure
Pass counts without risk context
Deployment
Gate 6 of 7
Business question
Can we release, observe, and recover?
Engineering activity
Release automation, migration, monitoring, rollback
Deliverable
Runbook and release package
Owner
Release owner
Exit criterion
Rollback and health signals are verified
Common failure
No owner or reversal path
Maintenance
Gate 7 of 7
Business question
What should change based on production evidence?
Engineering activity
Monitoring, support, patching, incident learning
Deliverable
Operational review and backlog
Owner
Product and operations owners
Exit criterion
Learning is assigned and prioritized
Common failure
Incidents are fixed but not learned from
Client checkpoint template
Use the checklist at a handoff, not after it. Check a box only when the evidence exists and the named owner has actually looked at it.
Can everyone point to the single decision being made?
Is one named person allowed to accept the result or send it back?
Can the reviewer open the evidence today, rather than hear that it is coming?
Would the exit rule actually prevent weak work from moving on?
Are assumptions, exclusions, and open risks easy to find?
The next owner knows what they are receiving and what remains open.
Which SDLC deliverables should the client receive
Nobody hires a software team for the paperwork. Still, the client must be able to see the scope, inspect quality, manage risk, and operate the product after handover. SDLC deliverables carry that evidence. A two-page decision record may be enough; missing operational knowledge is not.
Planning
Why the work matters, where scope ends, how success is measured, and which risks or dependencies could change the plan
01
Requirements
Ranked behavior, user flows, acceptance criteria, non-functional constraints, and explicit exclusions
02
Design
Architecture and data-flow decisions, integration contracts, threat and risk notes, prototype where useful
03
Development
Repository access, review record, build instructions, dependency inventory, automated test results
04
Testing
Test plan and evidence, defect status, UAT outcome, security and performance findings, release recommendation
05
Deployment
Release plan, environment configuration, migration steps, monitoring, runbook, rollback or fallback
06
Maintenance
Support ownership, service health measures, incident record, patch plan, backlog, current documentation
07
Not sure what evidence your next phase needs?
Tell us where your product is in the life cycle. We will help work out what must be known before the next commitment.
How to choose an SDLC model
Choose the SDLC model by finding the uncertainty most likely to hurt the project. Are requirements moving? Is one integration unusually costly? Must every requirement trace to a test? Will user feedback arrive slowly? The answers tell the team where it needs tight control and where it can iterate. Whichever model wins, ownership and evidence still matter.
What is your biggest uncertainty?
Waterfall
Useful when
Requirements are stable and formal approvals matter
Main limitation
Late feedback makes a wrong assumption expensive
Agile iterations
Useful when
Priorities change and users can review work often
Main limitation
Weak product ownership turns iteration into churn
V-model
Useful when
Quality-critical work needs requirement-to-test traceability
Main limitation
Documentation can outpace useful feedback
Spiral
Useful when
Technical or operational risk is unusually high
Main limitation
Risk analysis costs more and needs experienced owners
DevOps
Useful when
Teams release frequently and operations can respond quickly
Main limitation
Automation accelerates a weak process as well as a strong one
Hybrid
Useful when
Some components need formal control while others benefit from iteration
Main limitation
Unwritten rules make the process inconsistent
Regulated and non-regulated products need different evidence
Put a marketing platform beside a quality-critical healthcare product: both may use the same software development life cycle phases, but their evidence burdens differ. In regulated work, a requirement may need a clear line to its risk control, approved change, and verification test. That trace belongs to delivery, not paperwork afterwards.
A healthcare setting alone does not make every app a medical device; intended use and applicable rules decide.
| Area | Non-regulated product | Regulated or quality-critical product |
|---|---|---|
| Requirements | Prioritized and testable | Approved, versioned, and traceable |
| Risk | Product and operational risk register | Formal risk-management evidence linked to controls |
| Testing | Risk-based functional and non-functional evidence | Documented verification and validation with traceability |
| Change | Product approval and release controls | Controlled change history and impact assessment |
| Operations | Monitoring, support, and incident learning | Post-market or operational evidence required by the product context |
Security and QA run across the lifecycle
"Few software development life cycle (SDLC) models explicitly address software security in detail."
NIST designed its Secure Software Development Framework to fit the development approach already in use. Microsoft’s Security Development Lifecycle makes the same practical point: security and privacy requirements begin before implementation, then follow the product through design, verification, release, and response.
Figure 3. Security and quality activities span every phase. Custom visual by Intelisoft.
| Stage | Security and quality evidence |
|---|---|
| Planning | Data sensitivity, risk context, regulatory constraints, quality targets, owners |
| Requirements | Security, privacy, performance, availability, recovery, auditability |
| Design | Threat model, trust boundaries, authorization, failure behavior, data protection |
| Development | Secure code review, dependency and secret controls, automated tests |
| Testing | Security findings, performance and recovery results, integration checks, UAT |
| Deployment | Secure configuration, release controls, monitoring, access review, rollback |
| Maintenance | Vulnerability response, patching, dependency updates, incident learning |
Where AI helps and where human review remains essential
AI is already useful for comparing requirements, drafting code, suggesting tests, updating documentation, and sorting incident clues. Accountability, though, cannot be delegated. The 2025 DORA report drew on nearly 5,000 technology professionals. Nine out of ten used AI at work; more than 80% saw productivity improve. Yet 30% had little or no trust in AI-generated code. The report also linked higher AI adoption with weaker delivery stability. Faster output helps only if review, testing, and feedback absorb the pace.
2025 DORA report
~5,000 technology professionals surveyed
Source: 2025 DORA report. Higher AI adoption was also linked with weaker delivery stability.
AI drafts
Inside approved controls
Engineer reviews
Like any other input
Named owner approves
Accountability stays human
Use AI to
Do not use AI to
Requirements
Summarize interviews and flag conflicting requirements
Approve requirements without a product owner
Code
Draft code or tests inside approved engineering controls
Merge generated code without accountable review
Testing
Suggest edge cases and documentation updates
Assume generated tests prove real-world behavior
Operations
Analyze logs and group likely incident causes
Expose sensitive data or bypass access rules
Delivery
Speed up repetitive analysis with traceable inputs
Claim delivery will be faster before measuring the workflow
Intelisoft case example from discovery to rollout
Healthcare
Ambient AI documentation
EHR integration
A multi-specialty care network asked Intelisoft to address a documentation problem. Clinicians were finishing too many notes after visits. Starting with an AI feature list would have been tempting. Intelisoft chose a less glamorous starting point: observe the work.
Before writing the roadmap, the team shadowed several clinical workflows and spoke with clinical and IT stakeholders. That fieldwork showed where the time was actually going, and it changed both the requirements and the integration plan. Intelisoft delivered the first MVP in 10 weeks. The wider rollout took nine months across web, mobile, and EHR-embedded workflows, with Epic and Cerner integrations included.
More than 40 clinics were live within six months. Intelisoft’s project data showed a 65% drop in post-visit documentation time; 92% of AI-generated drafts were accepted with only minor edits.
Figure 4. Ambient AI documentation project from workflow discovery to measured rollout. Source: Intelisoft internal case data.
The lesson is narrower than “AI makes healthcare faster.” Observe the workflow first. Bound the MVP and use it to gather evidence. Do not exile integration to the end; it is part of the product. Scale after the workflow holds up in real use. Those software development life cycle steps were visible to both business and engineering owners.
Software development life cycle best practices
The following SDLC best practices sound ordinary. That is a strength: they survive new tools, frameworks, and delivery fashions. Each one shortens the distance between an assumption and evidence.
01
Write the business outcome before the feature list.
A requirement should lead back to a real user or operational need.
02
Give every phase decision an owner.
Many people may contribute; one person must be able to say yes, no, or revise.
03
Write acceptance criteria while the requirement is still being argued about.
Vague language is cheaper to fix there.
04
Record a consequential architecture choice and the compromise it creates.
A short decision record is often enough.
05
Invite QA and security while the feature can still bend.
A design problem found in release week is an expensive guest.
06
When uncertainty climbs, make the next increment smaller and inspect it earlier.
The shorter loop leaves less to undo.
07
Keep builds reproducible.
Another engineer should be able to run the same checks without borrowing the author’s laptop.
08
Tie test evidence to release risk.
A green dashboard needs scope, context, and somebody willing to accept what remains.
09
Design release health and reversal together.
If nobody can see trouble or stop it, the deployment is not ready.
10
Let production argue back.
An incident, a support pattern, or a surprising usage signal should be able to move the backlog.
Used together, these SDLC best practices make artifacts useful at the moment of decision. The client can govern risk without hovering over engineering work.
Common failure patterns
Failure
What it causes
Correction
Vague requirements
Design debates and acceptance disputes
Rewrite behavior and constraints as testable criteria
No decision owner
Meetings without a final answer
Name one approver for each gate
Security added late
Rework in architecture, data flow, and release
Set security requirements and threat assumptions early
Testing treated as a final phase
Defects and integration problems accumulate
Verify work continuously and keep a release-level test phase
No production observability
Teams discover failures through users
Define health signals, alerts, and owners before release
No rollback path
A bad release becomes a prolonged incident
Test rollback, flags, or manual fallback
Documentation debt
Handover and recovery depend on memory
Update the smallest useful artifact with each decision
What clients say about Intelisoft
Frequently asked questions
Most teams use seven labels: planning, requirements, design, development, testing, deployment, and maintenance. Names may shift or merge. What matters is whether each phase leaves something another person can inspect.
Trace one feature from the first budget discussion to a user’s screen, then into support. That is the SDLC process: decide, build, check, release, and learn. A methodology changes the size and rhythm of those loops.
No. A failed test may send a team back to design; a production incident may reveal a requirement nobody captured. Waterfall puts more distance between those returns. Agile and DevOps make the feedback loop shorter.
SDLC is the set of responsibilities that follows a product throughout its life. Agile plans and reviews those responsibilities in smaller batches. The rhythm changes, not the need for design, testing, release control, and maintenance.
Picture a new project manager opening the repository with no briefing. Can that person see what was accepted, why the architecture looks this way, which tests passed, how to reverse a release, and who owns production? Start there; add formality only where risk earns it.
Often the labels do not change; the chain of evidence does. A regulated product may have to connect a requirement with its risk control, verification result, change record, and approval. Intended use decides how rigorous that chain must be.
DevOps joins the build with production reality. A team can ship a change, watch its health, respond when it misbehaves, and carry that lesson into planning.
Do not attend every stand-up. At each meaningful handoff, agree on four things: the decision ahead, the proof needed, the person who can approve it, and the condition that stops progress. Engineering keeps room to engineer; the client keeps control of risk.
How Intelisoft can help
Sources
Research reviewed October 2, 2026: ISO, IBM, NIST, Microsoft, and Google Cloud DORA. Case figures come from Intelisoft’s company-provided project brief.
