SDLC and Agile

In short

The Software Development Life Cycle (SDLC) is the structured sequence of phases - feasibility, requirements, design, coding, testing, deployment and maintenance - that a software product passes through from idea to retirement. A process model (waterfall, incremental, spiral, prototype, V model, RAD, agile) decides how those phases are ordered, repeated and overlapped. Agile is the dominant family today: short iterations, working software every few weeks, and change accepted late rather than frozen. This is the opening chapter of every Software Engineering paper, carries direct marks in university exams and in GATE (process models, cost of change, model comparison), and almost every Indian employer - TCS, Infosys, Wipro, Accenture, Cognizant, Capgemini, HCLTech, LTIMindtree, Zoho, Flipkart, PhonePe - asks a fresher to describe Scrum, a sprint and a standup in the HR or managerial round.

Explained

The SDLC phases (common to every model)

1. Feasibility study / project initiation: is the system worth building? Technical, economic (cost-benefit, ROI), operational and legal feasibility. Output: feasibility report, go/no-go.
2. Requirements gathering and analysis: elicit what users need, resolve conflicts, write the SRS (Software Requirements Specification, IEEE 830 / its successor ISO/IEC/IEEE 29148). Output: baselined SRS.
3. Design: high-level design (HLD) - architecture, modules, interfaces, database schema; low-level design (LLD) - algorithms, class and function detail. Output: SDD (software design document).
4. Implementation / coding: modules written to coding standards and unit-tested by developers.
5. Testing / integration: integration, system, performance, security and UAT (user acceptance testing). Output: test reports, defect logs.
6. Deployment / release: installation, data migration, training, go-live (big-bang, phased or pilot rollout).
7. Maintenance: the longest and costliest phase - typically 60-70% of total lifetime cost. Four types: corrective (fix defects), adaptive (new OS, new tax law, new browser), perfective (improve performance or usability) and preventive (refactor to delay decay).
8. Phase-wise effort rule of thumb quoted in texts: requirements + design ≈ 30-40%, coding ≈ 15-20%, testing ≈ 30-40% of development effort. Treat these as indicative ranges, not fixed constants.

Prescriptive (plan-driven) process models

• Waterfall (Royce, 1970): strictly sequential; each phase's output is baselined before the next starts; no going back. Advantages: simple, document-heavy, easy to manage and audit, works when requirements are frozen and well understood. Limits: no working software until late, cost of a requirement change is enormous, high risk, unsuitable for unclear or volatile needs. Still used in defence, aerospace, ISRO-style mission software and regulated fixed-price government tenders.
• Incremental model: requirements are split into increments; each increment goes through design-code-test and delivers usable functionality. First increment is usually the core product. Reduces risk, gives early ROI, but needs a good architecture up front.
• Iterative / evolutionary model: a rough version is built, then repeatedly refined through cycles until acceptable - every cycle revisits all phases.
• Prototype model: build a throwaway or evolutionary prototype to clarify requirements, get user feedback, then build the real system. Risk: users mistake the prototype for the product; developers are tempted to ship the quick-and-dirty code.
• Spiral model (Boehm, 1988): risk-driven meta-model. Each loop has four quadrants - (1) determine objectives, alternatives, constraints; (2) identify and resolve risks (prototyping, simulation, benchmarking); (3) develop and verify the next-level product; (4) plan the next phase and get customer review. Radius of the spiral = cumulative cost; angular sweep = progress. Best for large, expensive, high-risk, long-duration projects; needs genuine risk-analysis expertise and is overkill for small projects.
• V model (verification and validation model): development phases on the left limb, the matching test level on the right - requirements ↔ acceptance testing, system spec ↔ system testing, HLD ↔ integration testing, LLD ↔ unit testing. Test plans are written in parallel with each left-side phase, so defects are found early. Sequential like waterfall, hence the same inflexibility.
• RAD (Rapid Application Development): short cycles (60-90 days), component reuse, CASE tools, heavy user involvement, parallel teams working on modules. Needs modular systems and committed users.
• Big Bang model: code with almost no planning - acceptable only for tiny or academic work.
• Code-and-fix: the anti-model used as the textbook example of how not to work.

The Agile Manifesto and principles

• Published in 2001 by 17 practitioners. Four values (left item valued more, right item still has value):
  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.
• 12 principles in essence: satisfy the customer through early and continuous delivery; welcome changing requirements even late; deliver working software frequently (weeks, not months); business and developers work together daily; motivated, trusted teams; face-to-face conversation; working software is the primary measure of progress; sustainable pace indefinitely; technical excellence and good design; simplicity - maximise work not done; self-organising teams; regular retrospectives to tune behaviour.
• Agile is not "no documentation" and not "no planning" - it is just-enough documentation and continuous replanning. A common exam trap.
• Agile methods family: Scrum, Extreme Programming (XP), Kanban, Crystal, DSDM, Feature-Driven Development (FDD), Lean software development, and scaling frameworks (SAFe, LeSS, Nexus, Spotify model).

Scrum - roles, artefacts, events

• Three roles (accountabilities):
  • Product Owner - owns and orders the product backlog, maximises product value, single voice of the customer.
  • Scrum Master - servant-leader and coach; removes impediments, protects the team, enforces the process. Not a project manager, does not assign tasks.
  • Developers / Development Team - 3-9 members (Scrum Guide now says "typically 10 or fewer"), cross-functional and self-organising; they estimate and commit.
• Artefacts: Product backlog (ordered list of everything wanted, continuously refined/groomed) → Sprint backlog (items selected for this sprint + plan) → Increment (a potentially shippable product). Each has a commitment: Product Goal, Sprint Goal, Definition of Done.
• Events (ceremonies):
  • Sprint: fixed-length iteration, 1-4 weeks (2 weeks most common in Indian service and product firms); no scope change that endangers the Sprint Goal; never extended.
  • Sprint Planning (≤8 h for a 4-week sprint): what, why and how.
  • Daily Scrum / standup (15 min, same time and place): what I did, what I will do, what blocks me - a sync for the developers, not a status report to the manager.
  • Sprint Review (≤4 h): demo the increment to stakeholders, adapt the backlog.
  • Sprint Retrospective (≤3 h): inspect how the team worked; agree concrete improvements.
  • Backlog refinement is an ongoing activity, not a formal event.
• Three pillars: transparency, inspection, adaptation. Five values: commitment, courage, focus, openness, respect.
• User story format: *As a <role>, I want <goal> so that <benefit>.* Quality checked by INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) and sized relatively in story points (often a Fibonacci-like scale 1, 2, 3, 5, 8, 13, 21) using planning poker. Epic → feature → story → task. Acceptance criteria are written per story, often as Given-When-Then.
• Tracking: velocity (story points completed per sprint), sprint burndown (work remaining versus days), release burnup, burn-up/burndown charts in Jira or Azure DevOps.

Kanban, XP and Lean

• Kanban: visualise the workflow on a board (To Do / In Progress / Test / Done), limit work in progress (WIP), manage flow, make policies explicit, improve collaboratively. Pull system with no fixed-length iterations and no mandated roles - continuous flow; best for support, maintenance and operations teams. Metrics: lead time (request to delivery), cycle time (start of work to delivery), throughput, cumulative flow diagram.
• Scrumban: Scrum's cadence and ceremonies with Kanban's WIP limits and pull - common in Indian maintenance/AMS projects.
• Extreme Programming (XP): engineering-heavy agile. Practices: pair programming, test-driven development, continuous integration, small releases, refactoring, simple design, collective code ownership, coding standards, on-site customer, planning game, 40-hour week, metaphor, spike solutions for risky unknowns. Values: communication, simplicity, feedback, courage, respect.
• Lean software development (from Toyota): eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, optimise the whole. Seven wastes include partially done work, extra features, task switching, waiting, handoffs and defects.
• Scaling: SAFe (portfolio-program-team levels, Agile Release Train, PI planning every 8-12 weeks), LeSS, Nexus, Spotify model (squads, tribes, chapters, guilds). Most large Indian delivery accounts for BFSI and retail clients run SAFe.

DevOps, CI/CD and the modern delivery pipeline

• DevOps extends agile past the developer's desk: the same team builds, tests, releases and operates. Pillars often remembered as CALMS - Culture, Automation, Lean, Measurement, Sharing.
• Continuous Integration (CI): every commit is merged to the mainline and automatically built and unit-tested (Jenkins, GitHub Actions, GitLab CI, Azure Pipelines). Continuous Delivery: every build is release-ready. Continuous Deployment: every passing build goes to production automatically.
• Infrastructure as Code (Terraform, Ansible), containers and orchestration (Docker, Kubernetes), monitoring and observability (Prometheus, Grafana, ELK), blue-green and canary releases, feature flags for decoupling release from deployment.
• DORA metrics used to judge delivery performance: deployment frequency, lead time for change, change failure rate, mean time to restore (MTTR).
• Site Reliability Engineering (SRE) adds error budgets and SLO/SLI thinking to operations.

Standards, maturity and the Indian practice context

• CMMI (Capability Maturity Model Integration) levels: 1 Initial, 2 Managed, 3 Defined, 4 Quantitatively Managed, 5 Optimizing. Many Indian IT majors hold CMMI Level 5 appraisals and advertise them in tenders; agile and CMMI coexist (CMMI says *what* to control, agile says *how* to work).
• ISO 9001:2026 (quality management; succeeded the 2015 edition on 16 September 2026), ISO/IEC 12207 (software life cycle processes), ISO/IEC/IEEE 29148 (requirements engineering), ISO/IEC 25010 (product quality model), ISO/IEC 27001 (information security - near-universal in Indian offshore delivery), ISO 13485 / IEC 62304 for medical device software, DO-178C for airborne software.
• Indian legal and regulatory context affecting the life cycle: the Information Technology Act, 2000 (Section 43A, 72A on data protection obligations), the Digital Personal Data Protection Act, 2023 (consent, purpose limitation, breach notification — Rules notified 13 November 2025, with these Data Fiduciary duties applying from 13 May 2027; s.43A and the SPDI Rules apply until then), RBI cyber-security framework and localisation directions for payment data, SEBI system-audit requirements for market intermediaries, CERT-In incident-reporting directions (2022) requiring reporting of specified incidents within 6 hours, and STQC certification for many government e-governance applications. These push security, audit and documentation requirements into the design and testing phases regardless of the model chosen.
• Fixed-price versus time-and-material: classic Indian services contracts were fixed-price with a frozen scope (waterfall-friendly). Agile delivery usually needs T&M, capacity-based or managed-outcome contracts with a change-friendly statement of work - a real reason many offshore projects remain "waterfall at the contract level, agile inside".

Key points

• SDLC - the ordered set of phases from feasibility to maintenance; a process model decides how those phases are arranged.
• Waterfall - sequential, baselined, document-driven; fails when requirements change.
• Incremental - deliver in usable slices; iterative - refine the whole repeatedly; the two are often combined.
• Spiral - risk-driven meta-model, four quadrants per loop, radius = cumulative cost; for large high-risk projects.
• V model - every development phase is paired with its test level; V&V planned early.
• Cost of change - rises steeply with phase in plan-driven models (Boehm's 1:10:100 pattern); agile flattens it with short iterations.
• Maintenance - the costliest phase (~60-70% of lifetime cost); types are corrective, adaptive, perfective, preventive.
• Agile Manifesto - 4 values, 12 principles; working software is the primary measure of progress.
• Scrum - 3 roles, 3 artefacts, 5 events; sprint of 1-4 weeks, timeboxed and never extended.
• Scrum Master ≠ project manager - a coach who removes impediments; the team self-organises.
• Product backlog - single ordered source of work, owned by the Product Owner; the sprint backlog is owned by the developers.
• Definition of Done - the team's shared, non-negotiable completion standard; stops "90% done" items.
• Story points and velocity - relative size, not hours; velocity = points done per sprint, used for forecasting, never for comparing teams.
• Kanban - continuous flow, WIP limits, lead and cycle time; no fixed sprints or prescribed roles.
• XP - pair programming, TDD, CI, refactoring, small releases, on-site customer.
• DevOps / CI-CD - automate build, test and release; measured by the four DORA metrics.
• CMMI Levels 1-5 and ISO/IEC 12207 are the process standards quoted in Indian IT tenders.
• Agile is not undisciplined - it replaces heavy up-front documents with continuous feedback, not with chaos.

Formulas and examples

Example 1 - Release forecast from velocity. A team's last five sprints delivered 28, 32, 30, 26 and 34 story points. The remaining release backlog is 450 points.

• Average velocity = (28+32+30+26+34)/5 = 150/5 = 30 points/sprint.
• Sprints needed = 450/30 = 15 sprints.
• At 2 weeks per sprint = 30 weeks ≈ 7 months.
• Pessimistic (lowest velocity 26): 450/26 = 17.3 → 18 sprints (36 weeks). Optimistic (34): 450/34 = 13.2 → 14 sprints. So the honest answer is a forecast range of 14-18 sprints, not a single date.

Example 2 - Sprint capacity and cost. Six developers, 2-week sprint, 10 working days, 8 h/day, focus factor 0.7. Billing at ₹1,200 per person-hour.

• Gross hours = 6 × 8 × 10 = 480 h.
• Capacity = 480 × 0.7 = 336 productive hours per sprint.
• Cost of one sprint (gross hours billed) = 480 × ₹1,200 = ₹5,76,000.
• If the release takes 15 sprints, cost = 15 × ₹5,76,000 = ₹86,40,000 (about ₹86.4 lakh).
• If average velocity is 30 points, cost per story point = ₹5,76,000/30 = ₹19,200 per point.

Example 3 - Burndown check. Sprint backlog = 40 points, 10 working days. Ideal slope = 40/10 = 4 points/day. At end of day 6 the ideal remaining = 40 − 24 = 16 points; the team actually has 24 remaining.

• Actual burn rate = (40 − 24)/6 = 2.67 points/day.
• Projected remaining at day 10 = 24 − (2.67 × 4) = 24 − 10.7 ≈ 13.3 points not done.
• Required rate to finish = 24/4 = 6 points/day, i.e. 2.25× the current rate. Correct action: raise the blocker in the Daily Scrum and negotiate scope out of the sprint with the Product Owner - not extend the sprint.

Example 4 - Little's Law on a Kanban board. A support team keeps an average WIP of 12 tickets and closes 6 tickets per day.

• Average cycle time = WIP/Throughput = 12/6 = 2 days.
• Halving WIP to 6 at the same throughput gives cycle time = 6/6 = 1 day - the standard argument for WIP limits.
• If the team instead lets WIP rise to 24, cycle time = 24/6 = 4 days with no extra work delivered.

Example 5 - Defect Removal Efficiency. Pre-release testing found 285 defects; customers reported 15 in the first three months.

• DRE = 285/(285+15) × 100 = 285/300 × 100 = 95%. A V-model or shift-left agile pipeline targets DRE above 95%; a late-testing waterfall project often lands at 80-90%.

Where it is used

• IT services and global capability centres - TCS, Infosys, Wipro, HCLTech, Accenture, Cognizant, Capgemini, LTIMindtree and captive GCCs in Bengaluru, Pune, Hyderabad, Chennai, Noida and Kochi run Scrum or SAFe for client applications; freshers join as Agile team members and must know the ceremonies from week one.
• Product companies and start-ups - Zoho, Freshworks, Zerodha, Razorpay, PhonePe, Swiggy, Zomato, CRED run two-week sprints or trunk-based continuous deployment with feature flags.
• BFSI and regulated delivery - banks, NBFCs and insurers combine agile sprints with RBI/SEBI audit, CERT-In reporting and ISO 27001 controls; releases need change-advisory approval, so "agile inside, governed outside".
• Public sector and mission-critical software - ISRO, DRDO, BEL, C-DAC and NIC projects lean on V model and waterfall-style documentation; e-governance applications often need STQC certification before go-live.
• Job roles - software engineer, Scrum Master, Product Owner, business analyst, QA engineer, release/DevOps engineer, delivery manager; certifications commonly asked for are CSM/PSM, SAFe Agilist, PMI-ACP.
• Tooling - Jira, Azure DevOps, Rally and ClickUp for backlog and sprint tracking; Confluence for just-enough documentation; Jenkins, GitHub Actions and GitLab CI for the pipeline.

Interview questions

• Q: Why is waterfall still used if agile is better? A: When requirements are genuinely frozen and the contract, audit or certification regime demands baselined documents - defence, aerospace, some government tenders - waterfall's predictability and paper trail are advantages, not defects.
• Q: What is the difference between iterative and incremental development? A: Incremental adds new functionality slice by slice; iterative refines the same functionality over repeated cycles. Most real projects do both - build a slice, then improve it.
• Q: What makes the spiral model different from other models? A: Risk is the explicit driver: each loop spends a quadrant identifying and resolving the biggest remaining risk through prototyping or analysis before committing to build.
• Q: What is the V model and why is it preferred for safety-critical work? A: It pairs every development phase with a corresponding test level and writes the test plan at the same time as the specification, so verification is designed in and traceability is provable to an auditor.
• Q: Is agile against documentation? A: No. It prefers working software over comprehensive documentation and keeps just enough documentation - architecture decisions, APIs, runbooks - to build, operate and hand over the system.
• Q: How are story points different from hours? A: Story points are a relative measure of size, complexity and uncertainty agreed within one team; hours are absolute. Points let a team forecast using velocity without re-estimating in time units, and they are not comparable across teams.
• Q: What happens if the team cannot finish a story in a sprint? A: The unfinished story is not partially credited - it goes back to the product backlog, is re-estimated if needed, and the sprint is never extended; the retrospective examines why.
• Q: Can the scope of a running sprint change? A: Items may be dropped or swapped by agreement with the Product Owner if the Sprint Goal remains intact, but the goal and the timebox are protected; genuinely urgent work either waits or the sprint is cancelled by the Product Owner.
• Q: What is the Definition of Done and who owns it? A: A shared checklist - coded, unit-tested, reviewed, integrated, documented, acceptance criteria met - owned by the developers (within any organisational standard), applied identically to every item.
• Q: Difference between Scrum and Kanban in one line each? A: Scrum delivers in timeboxed sprints with prescribed roles and a sprint commitment; Kanban is a continuous pull system that controls work in progress and optimises flow time.
• Q: What does a Scrum Master actually do when the project is late? A: Removes impediments, makes the real velocity and risk transparent to stakeholders, and facilitates a scope conversation with the Product Owner - the Scrum Master does not assign tasks or push the team to overtime.
• Q: How do agile and CMMI Level 5 coexist in an Indian IT firm? A: CMMI specifies which processes must be defined, measured and improved; agile supplies the practices. The organisation maps sprint artefacts and metrics to CMMI process areas rather than running two parallel methods.
• Q: What are the DORA metrics? A: Deployment frequency, lead time for change, change failure rate and mean time to restore - the four measures used to judge the delivery capability of a DevOps team.

Common mistakes

• Treating SDLC and waterfall as the same thing - waterfall is one model of the life cycle, not the life cycle itself.
• Claiming agile needs no planning or documentation; interviewers immediately follow up with "then what is backlog refinement and a Definition of Done?".
• Confusing iterative with incremental, and calling the spiral model "just waterfall in a circle" - its defining feature is risk analysis per loop.
• Converting story points into fixed hours, or comparing velocity between teams and using it as a productivity target - it is a forecasting tool only.
• Describing the Scrum Master as the team's manager who assigns work and tracks individuals.
• Extending a sprint, or counting partially finished stories in velocity, instead of returning them to the backlog.
• Forgetting the maintenance phase in exam answers on life-cycle cost, and omitting the four maintenance types.
• In model-comparison questions, listing features without stating the selection criterion - requirement stability, risk level, project size, customer availability and contract type decide the model.

Related topics

Requirements engineering and UML · Software project management and estimation · Software testing basics · Test automation and TDD · Git and version control · Software architecture: monoliths and microservices