THE AUTHOR:
What is SDLC?
SDLC stands for Software Development Life Cycle (sometimes called the Software Engineering Life Cycle). It is a structured approach to planning, designing, developing, testing, deploying and maintaining software. Its purpose is to make decisions, responsibilities, dependencies and deliverables clear throughout a project, reducing delivery risk rather than guaranteeing success.
The seven SDLC stages provide a useful framework, not a strictly linear sequence. In an iterative delivery model, discovery, implementation, testing and production feedback can repeat for each feature. Quality, security and privacy checks run across the lifecycle, with validation checkpoints proportionate to product risk. At every stage, teams should know what inputs they need, which outputs they must deliver and who approves the next step.
AI assistants and agents can support research, specifications, prototyping, implementation, testing and operational analysis. The underlying SDLC remains accountable to people: teams set product direction, review risks, approve important decisions and validate results. AI-generated outputs should be checked against the same quality and security standards as other work.
The SDLC is a continuous cycle: maintenance and production feedback inform new ideation and requirements. Validation checkpoints help teams decide whether work is ready to move forward; quality, security and privacy remain relevant throughout.
The seven stages of the Software Development Life Cycle
1. Ideation
The ideation stage establishes why the product should exist, which customer problem it will solve and what success should look like. The team reviews client materials, learns the industry context, examines alternatives and speaks with stakeholders. Early discovery also flags sensitive data, regulatory obligations and other material business risks.
Useful discovery questions include: Who are the users and decision-makers? What outcomes matter to them? Which regulations or operational constraints apply? How will the product be differentiated, adopted and monetized? What assumptions require validation before engineering begins?
AI can help organize research, summarize interview notes, compare potential approaches and generate early concept or prototype options. However, customer evidence, market claims and regulatory interpretations must be checked by the team; stakeholders retain responsibility for choosing priorities.
Typical outputs: product opportunity statement, stakeholder map, target users and needs, high-level concept, competitive context, key assumptions and initial success measures.
2. Requirements
During requirements discovery and business analysis, business analysts, product owners and domain experts translate the initial concept into clear functional and non-functional expectations. Interviews, workshops, observation and prototype reviews help resolve ambiguity.
A software requirements specification (SRS) or an equivalent living feature specification should describe the product intent, scope, workflows, dependencies, constraints, risks and acceptance criteria. It should also capture testable expectations for performance, security, accessibility, privacy, access controls, data retention and data handling where relevant.
AI can help turn agreed inputs into structured draft specifications, identify inconsistencies, suggest edge cases and trace acceptance criteria into test scenarios. These drafts are working aids rather than an authority: product owners and relevant specialists approve requirements, priorities and acceptance conditions.
Typical outputs: reviewed feature or product specification, prioritized backlog, acceptance criteria, prototype and traceability between requirements and planned validation.
3. Design
Design converts approved requirements into a product experience and technical approach. Solution architects define boundaries, data flows, integrations and important technology decisions. UX and UI teams define user journeys, interaction patterns and accessibility expectations. The team also plans how the proposed solution will be tested and operated. Risk-based threat modeling identifies possible attack paths, trust boundaries and privacy risks early enough to influence the design.
For products with a user interface, a shared design system can provide a consistent source for components, patterns and accessibility rules. AI can accelerate draft prototypes and assist architecture or design reviews, while architects and designers validate feasibility, trade-offs, security implications and user experience.
Typical outputs: architecture and data-flow decisions, UI prototypes or designs, design-system conventions, integration contracts, initial threat and risk analysis, and an agreed test strategy.
4. Development
Development turns reviewed specifications and designs into working software. Rather than relying only on large, loosely defined assignments, teams can break a feature into small tasks with clear inputs, expected outputs and acceptance checks. Developers implement, integrate, document and review the resulting changes.
When appropriate, AI assistants or agents can generate implementation drafts, routine tests, documentation and review suggestions. Their work must remain reviewable and verifiable. Automated checks, peer review, secure coding, software composition analysis (SCA), dependency and license checks, secrets scanning, and architecture checks still apply according to product risk; critical changes require the appropriate human approval.
Teams should retain useful decisions, architecture context, recurring errors and approved patterns in shared project knowledge so that lessons are available across future tasks, regardless of which developer or tool performs the work.
Typical outputs: version-controlled implementation, reviewed code changes, automated checks, updated documentation and demonstrable feature increments.
5. Testing
Testing runs throughout delivery, not only after implementation. Quality assurance checks whether the product meets functional requirements, acceptance criteria and relevant non-functional expectations. Findings return to development for correction and revalidation.
Depending on risk and architecture, the test strategy may combine unit tests, integration and API tests, end-to-end user-flow tests, exploratory and regression testing, performance tests, accessibility checks, and security verification. Automated testing is normally a core practice rather than an optional add-on. Security tests should verify defined risk-based criteria, including applicable authentication, authorization and data-protection requirements.
AI can help derive test scenarios from approved specifications, propose boundary cases, analyze failures and draft repeatable tests. Deterministic tools should verify the results, while QA specialists and business stakeholders remain responsible for assessing coverage, usability, unusual cases and user acceptance.
Typical outputs: test results linked to acceptance criteria, defect records, evidence of security and performance checks, user acceptance findings and a release-readiness decision.
6. Deployment
Deployment makes a verified release available to users through a production environment, application store or other distribution channel. It is a transition into real-world operation, not the end of the software life cycle.
A controlled deployment process may use DevOps and CI/CD practices, reproducible builds, environment checks, staged rollout, monitoring, rollback plans and release notes. A release should meet explicit criteria for testing, security, release integrity, reliability and operational readiness. The required human approval depends on business impact and risk.
AI may assist with release summaries, configuration review and analysis of rollout signals. It should not bypass change controls or independently authorize high-risk production changes.
Typical outputs: approved release artifact, deployment record, rollback procedure, operational handover and post-release health checks.
7. Maintenance
After launch, the product needs monitoring, support, vulnerability management, a defined process for triaging and remediating reported vulnerabilities, incident response and planned improvements. Usage data and customer feedback reveal both new opportunities and issues that were not visible before release.
Operations teams use logs, metrics, traces, alerts and runbooks to understand service health. AI can help summarize incidents, find known patterns and recommend corrective actions. For explicitly approved low-risk procedures, predefined automation may perform a step and verify its outcome; ambiguous or high-impact cases must be escalated to people.
Production findings, defect patterns, human corrections and incident lessons should feed back into requirements, architecture, test coverage and shared team knowledge. This closes the SDLC feedback loop and helps teams improve delivery quality over time.
Typical outputs: operational dashboards, incident records, maintained runbooks, prioritized fixes and improvements, and measured reliability or customer outcomes.
SDLC deliverables and approval criteria
Each stage needs a clear owner and enough evidence to proceed. The checkpoints below are examples, not mandatory documentation packages: teams can apply them per feature, release or project based on complexity and risk. Testing and security verification can continue in parallel rather than waiting for formal handoffs.
| Stage | Inputs | Key deliverables | Responsible reviewer | Exit criteria |
| Ideation | Business problem, user evidence, constraints | Opportunity statement, target users, success measures | Business sponsor / product owner | Problem, expected value and main assumptions are agreed |
| Requirements | Validated concept, stakeholder input | Prioritized backlog, testable acceptance and security criteria | Product owner + business analyst | Scope, dependencies and acceptance conditions are reviewable |
| Design | Approved requirements, constraints | UX designs, architecture and data flows, threat model, test approach | Solution architect + design lead; security reviewer as needed | Feasibility, key risks and design decisions are approved |
| Development | Reviewed specs, designs, standards | Version-controlled changes, automated checks, documentation | Engineering lead / code reviewers | Change meets review, build and applicable security checks |
| Testing | Working build, acceptance criteria, risk model | Functional and non-functional test evidence, defect status | QA lead + product owner; security reviewer as needed | Critical criteria pass; residual risks are accepted by authorized owners |
| Deployment | Release candidate, test results, rollout plan | Release record, rollback path, health-check results | Release owner / operations lead | Release controls pass and service health is acceptable |
| Maintenance | Production telemetry, incidents, feedback | Runbooks, fixes, vulnerability responses, prioritized improvements | Service owner / product owner | Issues are resolved or prioritized; insights feed the next cycle |
Approval responsibility depends on team structure and risk: the same person may review several steps in a small team, while regulated products may require separate sign-offs.
AI Governance across the SDLC
Using AI assistants and agents introduces risks that standard code review alone cannot address. Sensitive inputs can leave approved environments, untrusted content can manipulate agent behavior, and agents with broad permissions can make unintended changes. AI governance should therefore apply across all seven stages rather than be added only before release.
Teams should define which client data, source code and credentials may be used with approved AI tools, as well as retention, contractual and privacy requirements. Agents should run with least-privilege access, scoped tools and isolated environments. Direct access to production systems, secrets or sensitive data should be restricted; high-impact actions require explicit human authorization.
AI-generated specifications, code, tests and operational recommendations require independent verification against agreed requirements and security criteria. Keep proportionate records of agent actions and human approvals, review third-party dependencies and licensing, and provide clear escalation, stop and rollback procedures when automation behaves unexpectedly.
Typical controls: approved tool and data-use policy, permissions and execution boundaries, verification and security checks, auditable action records, human approval gates and incident escalation. Secure development practices can be tailored to risk using NIST SSDF 1.1; for web applications, OWASP ASVS 5.0 offers testable application-security requirements.
SDLC models: how to choose the right approach
The seven stages apply across different delivery models. What changes is how work is sequenced, reviewed and revisited.
| Model | Best suited for | Main limitations | Ability to accommodate change |
| Waterfall | Stable, well-defined requirements and formal sign-offs | Late feedback can make changes expensive | Low once a phase is approved |
| Iterative | Products that benefit from early releases and user learning | Needs ongoing prioritization and stakeholder involvement | High between iterations |
| V-model | Systems needing explicit links between requirements and verification | Heavy documentation and validation effort if applied rigidly | Moderate; changes affect corresponding test plans |
| Spiral | Complex or high-risk initiatives with major uncertainties | Risk analysis and governance can be costly | High within risk-driven cycles |
| Big Bang | Small, exploratory prototypes with few external dependencies | Unpredictable scope, quality and cost; weak fit for critical products | Flexible informally, but difficult to control |
SDLC vs. Agile and DevOps: SDLC defines the activities required across a product’s life. Agile provides ways to organize iterative planning, collaboration and feedback. DevOps connects development and operations through automation, shared ownership, monitoring and continuous improvement. Teams can apply Agile practices and DevOps capabilities alongside a suitable SDLC model; they are not mutually exclusive alternatives.
Choose based on requirements volatility, product and security risk, approval obligations, expected release frequency and the speed of stakeholder feedback. A regulated project can still use iterative delivery when validation and traceability remain in place.
Launch your custom software solution within 1–3 months instead of years.
SDLC example: improving an eCommerce checkout
Consider an illustrative feature: reducing friction in a retail checkout flow. Computools’ Dior Data Hub case study documents challenges involving lengthy checkout times, order processing, and scalability. The example below shows how a development team could approach a similar challenge across all seven SDLC stages. It illustrates a possible workflow rather than the exact delivery process used in the Dior project.
1. Ideation: The product team investigates checkout delays and identifies where customers abandon purchases. Stakeholders agree on the business objectives and establish baseline metrics for checkout speed, completion rates, and customer experience.
2. Requirements: Business analysts and the product owner define what the improved checkout must achieve. Acceptance criteria cover successful purchases, order confirmations, clear error messages, prevention of duplicate charges, and relevant payment security and privacy requirements.
3. Design: UX designers map the customer journey and create checkout interface designs. Solution architects define how order processing and payment APIs interact, accounting for potential failures, data protection, and system scalability.
4. Development: Software engineers implement the approved changes, update integrations, and introduce automated checks for successful transactions, processing errors, and duplicate submissions. Code changes undergo review before integration.
5. Testing: QA engineers verify the checkout against agreed acceptance criteria, including functionality, integrations, accessibility, performance, and security. The team resolves critical defects and documents the evidence required for release approval.
6. Deployment: The release and DevOps teams deploy the verified changes through an approved pipeline. They monitor transaction errors, checkout performance, and conversion signals, with rollback procedures available if serious issues arise.
7. Maintenance: Operations and product teams track checkout performance, purchase completion rates, customer feedback, and production incidents. Their findings guide bug fixes, optimization priorities, and future improvements.
This example demonstrates how the seven SDLC stages connect business objectives with engineering decisions and measurable results. Each stage produces evidence for the next, while production feedback informs further development.
SDLC metrics: DORA, reliability and business outcomes
A well-run SDLC connects delivery activity to evidence of quality, reliability and business value. The current DORA software delivery metrics use five measures rather than the former four-metric shorthand:
| DORA dimension | Metric | What it reveals |
| Throughput | Change lead time | Time from code commit to successful production deployment |
| Throughput | Deployment frequency | How often the team deploys changes |
| Throughput | Failed deployment recovery time | How long service recovery takes after a deployment failure |
| Instability | Change fail rate | Share of deployments that require immediate remediation |
| Instability | Deployment rework rate | Share of deployments made to address an unexpected production issue |
DORA is useful for diagnosing delivery bottlenecks and unstable releases, but faster deployment alone does not prove the product is improving. Pair these metrics with product quality (escaped defects, recurring issues), service reliability (availability, latency, SLO attainment), user outcomes (task completion, conversion, retention) and economics (cost per feature or cost of operating the service).
Define a baseline and consistent measurement window before changing the process. Compare metrics within the same service and operating context rather than using deployment frequency alone to rank unrelated teams. If AI assistants or agents are involved, evaluate their impact on cycle time, rework, quality, reliability and operating cost, not the number of AI-generated artifacts. Computools applies these principles to its AI-Based Product Factory, which connects specifications, AI-assisted engineering, verification and human ownership throughout product delivery.
Computools
Software Solutions
Computools is an IT consulting and software development company that delivers innovative solutions to help businesses unlock tomorrow.
