Chapter 1: Introduction to Software Development Life Cycle (SDLC)
1.1 What Is Software Development?
Software development is the disciplined process of conceiving, specifying, designing, programming, documenting, testing, and maintaining applications and frameworks. It transforms business needs into executable logic that runs on computers, servers, mobile devices, and embedded systems. Unlike physical manufacturing, software can be copied at near-zero marginal cost, updated remotely, and extended with plugins or APIs long after the initial release. This flexibility is powerful but also dangerous: without process, teams ship defects, security holes, and unmaintainable code that becomes expensive technical debt.
Professional software engineering relies on the Software Development Life Cycle (SDLC) to impose order on creative work. The SDLC is not a single methodology; it is a conceptual sequence of activities that every project passes through in some form. Even a solo developer fixing a bug implicitly moves through identification, analysis, change, test, and deploy. Large enterprises formalize these steps with templates, approval gates, and tooling. Competitive exams frequently test SDLC phase names, deliverables, and the difference between life cycle and development model.
India's IT sector — from service companies to product startups — hires thousands of graduates who must understand SDLC basics on day one. Whether you join as a developer, tester, business analyst, or support engineer, you will reference requirements, builds, releases, and incidents. SDLC vocabulary is the shared language that lets business and technology align on what "done" means.
1.2 Phases of SDLC Explained
Planning establishes vision, feasibility, budget, and high-level schedule. Stakeholders answer: Should we build or buy? What risks threaten success? Requirements analysis captures functional needs (what the system does) and non-functional needs (how fast, how secure, how usable). Design converts requirements into architecture: databases, services, UI mockups, and integration contracts. Implementation is coding according to standards with version control and code review.
Testing validates behavior against requirements using unit, integration, system, and acceptance tests. Deployment packages the application for production with rollback plans. Maintenance handles corrective changes (bugs), adaptive changes (new regulations), perfective changes (performance), and preventive changes (refactoring). In exams, remember that maintenance often consumes forty to seventy percent of total lifetime cost — a favorite trick question.
Waterfall runs these phases once in order. Agile repeats a miniature SDLC every iteration. Scrum time-boxes iterations into sprints. The phases do not disappear in Agile; they shrink and overlap. A sprint includes refinement (requirements), design discussions, coding, testing, and potentially shipping.
1.3 Stakeholders and Deliverables
Business sponsors fund the project. Product owners prioritize value. Architects guard technical integrity. Developers implement. QA engineers design test strategies. DevOps engineers automate pipelines. Users accept or reject releases. Each phase produces artifacts: charter, SRS, design documents, source code, test cases, release notes, operation manuals. Agile teams may store these in wikis, tickets, and repositories rather than binders, but auditors still ask for traceability.
Poor stakeholder management causes more failures than poor coding. If users are unavailable for acceptance testing, defects escape to production. If sponsors change priorities without adjusting scope, teams burn out. SDLC models differ mainly in how they manage stakeholder feedback loops — early and often (Agile) versus formal sign-off gates (Waterfall).
1.4 Why Models Exist
A development model prescribes how SDLC phases are scheduled, iterated, and governed. Models help organizations scale: new hires learn a standard way of working, metrics become comparable across teams, and tooling aligns with process. Without an explicit model, every manager invents their own hybrid, which confuses reporting and hiring.
This tutorial trilogy — Waterfall, Agile, Scrum — represents the most commonly contrasted approaches in textbooks and interviews. Master SDLC first; models are lenses on the same underlying work.
1.5 SDLC in Government and Banking Exams
Public sector projects often mandate phased delivery with signed documents at each gate — naturally aligning with Waterfall or V-Model. Private product companies emphasize velocity and user feedback — aligning with Agile and Scrum. When answering scenario questions, map the scenario to requirement stability, regulation, and feedback needs before naming a model.
Typical MCQs ask: Which phase comes after design? (Implementation/Coding). Which is longest? (Maintenance). Which model is best for changing requirements? (Agile). Which artifact captures user needs? (SRS or Product Backlog). Build flashcards for these pairs.
1.6 Quality and Risk in the Life Cycle
Quality cannot be inspected only at the end. Defects found in requirements cost pennies to fix; defects found in production cost thousands. SDLC encourages verification early — reviews, prototypes, static analysis, continuous integration. Risk management runs parallel: identify threats (skill gaps, vendor failure, security), mitigate, monitor. Spiral and iterative models make risk explicit; Waterfall assumes risks are addressed in planning; Agile discovers risks each sprint.
Security belongs in every phase: threat modeling in design, secure coding in implementation, penetration testing before release, patching in maintenance. Exams increasingly touch secure SDLC (S-SDLC) even when the question says only "SDLC".
1.7 Tools Supporting SDLC
Modern SDLC is tool-assisted: Jira or Azure DevOps for tracking, Git for version control, Jenkins or GitHub Actions for CI/CD, Selenium or Cypress for automation, Confluence for docs, Docker for environments. Tools do not replace process but enforce it — pull requests require review, pipelines block failing tests, boards visualize flow. Scrum teams live in backlogs and burndown charts; Waterfall teams live in Gantt charts and milestone documents.
1.8 Chapter Summary
SDLC is the universal skeleton of software projects. Models flesh out how teams walk that skeleton. You should now list phases, name stakeholders, cite maintenance cost, and explain that Agile shortens cycles without eliminating discipline. Proceed to Chapter 2 for formal definitions and classification of development models.
1.9 Extended Study — SDLC Variants Worldwide
CMMI and ISO/IEC 12207 standardize process maturity levels used by outsourcing vendors. Indian IT majors advertise CMMI Level 5 to win contracts. Understanding that these standards wrap SDLC activities helps you interpret job descriptions requiring "process orientation".
DevSecOps extends CI/CD with automated security gates. Site Reliability Engineering (SRE) treats operations as software. Both sit on maintenance and deployment phases. Future chapters on Agile and Scrum connect to these modern practices.
1.10 Practice Questions for Self-Assessment
Question 1: List seven SDLC phases in order. Question 2: Which phase produces the SRS? Question 3: Why is maintenance costly? Question 4: Name three stakeholders. Question 5: How does Agile treat SDLC phases differently from Waterfall? Write answers before checking notes — active recall improves retention for competitive exams.
Question 6: Give an example of a non-functional requirement. Question 7: What deliverable proves testing completeness? Question 8: Define traceability. These drill questions mirror SSC, railway, and banking computer awareness papers.
1.11 Real Project Walkthrough
Imagine building an online exam portal like Lakshya Rank: planning defines MVP features (registration, mock tests, results). Requirements specify timers, question types, and admin panels. Design chooses PHP, MySQL, and hosting. Implementation codes pages and APIs. Testing verifies scoring logic. Deployment configures production server. Maintenance adds tutorials and fixes bugs. Every model organizes this journey differently but the work remains.
1.12 Feasibility Study and Project Charter
Before requirements, planning includes feasibility — technical, economic, operational, and schedule feasibility. Can we build it with available skills? Will benefits exceed cost? Will users adopt it? Can we hit the exam date or fiscal year deadline? A project charter captures vision, scope summary, stakeholders, risks, and success metrics. Chartered projects align SDLC effort with organizational strategy instead of random feature requests.
Government and banking IT exams sometimes ask what document authorizes a project — the charter or business case. Waterfall projects freeze charter scope; Agile projects treat charter as north star while details emerge. Either way, skipping feasibility produces failed products nobody uses.
Feasibility also covers legal and compliance: data privacy laws, accessibility standards, audit trails for financial transactions. Non-functional requirements born here shape architecture for years. Students should link feasibility to risk reduction — an SDLC theme recurring in Waterfall risk registers and Agile spikes.
1.13 Functional vs Non-Functional Requirements
Functional requirements describe behaviors: "System shall allow user login with OTP." Non-functional requirements describe qualities: "Login shall complete within two seconds under normal load." Exams frequently test this distinction. Performance, security, usability, reliability, scalability, and maintainability are non-functional categories that cross-cut all features.
Poor non-functional specification causes production disasters — apps that functionally work but crash on launch day due to traffic. SDLC design phase translates non-functionals into architecture: load balancers, caching, encryption, monitoring. Agile teams capture non-functionals as definition-of-done criteria or NFR user stories.
Traceability matrices link requirements to test cases. In Waterfall, matrices are documents; in Scrum, acceptance criteria and automated tests prove coverage. Regulators may sample traceability during audits.
1.14 SDLC Glossary for Exams
SRS — Software Requirements Specification. HLD/LLD — High/Low Level Design. UAT — User Acceptance Testing. CI/CD — Continuous Integration/Continuous Delivery. WIP — Work in Progress. PO — Product Owner. All appear across model discussions. Flashcards with term, definition, and example sentence accelerate recall.
ROI — Return on Investment — justifies projects during planning. TCO — Total Cost of Ownership — includes maintenance, not just build cost. KPI — Key Performance Indicator — measures success post-deployment. Link glossary terms to phases where they matter most.
Review this glossary weekly while studying Waterfall, Agile, and Scrum chapters — vocabulary mastery separates top scorers from average candidates in computer science papers.
Extended Study Notes 1
Professional software teams revisit SDLC fundamentals throughout their careers. Waterfall teaches respect for specification, traceability, and contractual clarity. Agile teaches respect for users, feedback, and responding to change. Scrum teaches respect for sustainable pace, accountability, and delivering working increments every sprint. Treat these models as complementary ideas you apply based on context rather than labels to defend in online debates.
When preparing for competitive exams, practice writing structured answers: define the term, list key characteristics, give a real-world example, and state one advantage plus one limitation. This four-part template works for SDLC, Waterfall, Agile, Scrum, and comparison questions worth five to ten marks each.
Link every concept to observable outcomes: fewer production defects, faster user feedback, audit-ready documentation, or predictable release trains. Examiners prefer outcome-linked explanations over copied definitions from textbooks.
Chapter Practice Test
10 questions — answer all and submit to see your score.