1.
SDLC (Software Development Life Cycle)
Definition
Software Development Life Cycle (SDLC) is a structured process used to develop high-
quality software systematically from planning to maintenance.
Its goals are:
Deliver high-quality software
Meet customer requirements
Finish within budget and time
Reduce risks
Phases of SDLC
Planning
↓
Requirement Analysis
↓
Design
↓
Implementation (Coding)
↓
Testing
↓
Deployment
↓
Maintenance
Phase 1: Planning
Purpose:
Identify project goals
Estimate cost
Estimate resources
Assess risks
Determine feasibility
Activities:
Budget planning
Team formation
Timeline estimation
Deliverables:
Project Plan
Feasibility Report
Phase 2: Requirement Analysis
Purpose:
Understand exactly what customer wants.
Activities:
Meet stakeholders
Gather requirements
Analyze requirements
Prioritize features
Documents:
SRS (Software Requirement Specification)
Example:
Customer says:
"I need an online shopping website."
Requirements become:
User Login
Add to Cart
Payment Gateway
Order Tracking
Phase 3: Design
Purpose:
Convert requirements into architecture.
Types:
High-Level Design (HLD)
Describes:
Overall architecture
Modules
Database
APIs
Example
Frontend
↓
Backend
↓
Database
Low-Level Design (LLD)
Describes:
Classes
Functions
Algorithms
Data Structures
Phase 4: Coding
Developers implement the design.
Example
[Link]
[Link]
[Link]
Phase 5: Testing
Purpose:
Find defects before release.
Testing includes:
Unit Testing
Integration Testing
System Testing
Acceptance Testing
Phase 6: Deployment
Software is installed on customer machines or cloud.
Examples:
Deploy website
Publish Android App
Upload API
Phase 7: Maintenance
After release:
Fix bugs
Improve performance
Add new features
Example:
Version 1.0
Version 1.1
Version 2.0
Advantages
Organized development
Better quality
Easier management
Lower risk
Disadvantages
Documentation overhead
Can become slow
Di icult if requirements change frequently
2. Verification vs Validation
One of the most frequently asked interview questions.
Verification
Question:
"Are we building the product correctly?"
Checks:
Documents
Design
Code
Reviews
No execution required.
Examples:
Code Review
Walkthrough
Inspection
Validation
Question:
"Are we building the correct product?"
Checks:
Whether software satisfies customer needs.
Execution required.
Examples:
Software Testing
User Acceptance Testing
Easy Trick
Verification
WITHOUT execution
Validation
WITH execution
Comparison
Verification Validation
Product built correctly? Correct product?
Static Dynamic
No execution Execution required
Prevent defects Detect defects
During development After development
3. Software Testing
Definition:
Testing is the process of finding defects by executing software.
Goal:
Ensure software works correctly.
Levels of Testing
Unit Testing
Tests one function/module.
Example:
calculateSalary()
Integration Testing
Tests interaction between modules.
Example:
Login
Dashboard
Database
System Testing
Entire application tested.
Example:
Amazon website.
Acceptance Testing
Done by customer.
Confirms software meets business needs.
Types
Functional Testing
Checks functionality.
Example:
Can user login?
Non-functional Testing
Checks:
Performance
Security
Reliability
Scalability
4. Black-box Testing
Tester doesn't know internal code.
Tests:
Inputs
Outputs
Example
Calculator
Input:
2+3
Expected:
Tester never sees code.
Advantages
No programming knowledge
User perspective
Disadvantages
Limited coverage
Hidden code not tested
5. White-box Testing
Tester knows internal code.
Tests:
Loops
Conditions
Branches
Statements
Example
if(age>=18)
vote();
else
reject();
Need test cases for both branches.
Advantages
High coverage.
Finds hidden bugs.
Disadvantages
Needs programming knowledge.
Black-box vs White-box
Black-box White-box
No code knowledge Code knowledge required
Functional Structural
User view Developer view
Input-output Internal logic
6. Equivalence Partitioning
Purpose:
Reduce number of test cases.
Idea:
Group similar inputs into partitions.
One value from each partition is enough.
Example
Age:
18–60 valid
Others invalid
Partitions
<18
18-60
>60
Test:
10
25
70
Instead of testing every age.
Advantages
Fewer test cases.
Saves time.
7. Equivalence Class Partitioning
Same concept as Equivalence Partitioning.
Each partition is called an Equivalence Class.
Example
Marks:
0–100
Classes
Negative
0-100
Above 100
Representative tests:
-5
50
120
8. Boundary Value Analysis (BVA)
Most defects occur at boundaries.
Instead of middle values,
Test:
Minimum
Maximum
Just below
Just above
Example
Age:
18–60
Test
17
18
19
59
60
61
Why?
Programmers often make mistakes using:
>
>=
<
<=
Comparison
Equivalence Boundary
Middle values Edge values
Fewer tests More e ective
Entire ranges Boundaries
9. Agile Model
Modern SDLC model.
Software developed in small iterations.
Example
Sprint 1
Sprint 2
Sprint 3
Release
Each sprint:
2–4 weeks.
Agile Principles
Customer collaboration
Continuous delivery
Fast feedback
Adapt to changes
Advantages
Flexible
Faster delivery
Frequent releases
Disadvantages
Hard to estimate cost
Requires active customer involvement
10. Waterfall Model
Oldest SDLC model.
Sequential.
Requirements
Design
Coding
Testing
Deployment
Cannot go backward easily.
Advantages
Simple.
Well documented.
Disadvantages
Requirements cannot change easily.
Testing happens late.
11. Spiral Model
Risk-driven model.
Each cycle has:
Planning
Risk Analysis
Development
Testing
Repeat.
Best for:
Large projects
High-risk projects
Advantages
Excellent risk management
Disadvantages
Expensive
Complex
12. Prototype Model
Build a prototype first.
Customer reviews prototype.
Then final software developed.
Example
Mobile App
↓
Dummy Screens
Customer Feedback
Actual App
Advantages
Better understanding
Less misunderstanding
Disadvantages
Customer may think prototype is final product
13. V-Model
Extension of Waterfall.
Every development phase has a matching testing phase.
Requirements
↘
Acceptance Testing
System Design
↘
System Testing
Architecture
↘
Integration Testing
Module Design
↘
Unit Testing
Coding
Advantages
Early testing
High quality
Disadvantages
Rigid
Poor for changing requirements
14. Requirements Engineering
Process of gathering and managing software requirements.
Steps:
Requirement Gathering
Requirement Analysis
Specification
Validation
Management
Types:
Functional Requirements
Example:
Login
Payment
Non-functional Requirements
Example:
Performance
Security
Availability
Good Requirements
Should be:
Complete
Correct
Clear
Testable
Consistent
Unambiguous
15. Software Design
Converts requirements into technical implementation.
Goals:
Maintainability
Reusability
Scalability
Performance
Types
High-Level Design (HLD)
Includes:
Architecture
Database
APIs
Modules
Low-Level Design (LLD)
Includes:
Classes
Methods
Algorithms
Data structures
Design Principles
High cohesion
Low coupling
Modularity
Abstraction
Encapsulation
16. Software Maintenance
After software is released, changes continue throughout its lifetime. This phase is
called Software Maintenance.
Types of Maintenance
1. Corrective Maintenance
Fixes bugs discovered after deployment.
Example: A payment gateway fails during checkout due to a coding error.
2. Adaptive Maintenance
Modifies the software to work in a changed environment.
Example: Updating an application to support a new operating system or browser
version.
3. Perfective Maintenance
Enhances existing functionality or performance based on user feedback.
Example: Improving application speed or adding a dark mode feature.
4. Preventive Maintenance
Improves code quality to reduce future issues.
Example: Refactoring legacy code, optimizing database queries, or updating
deprecated libraries.
Maintenance Life Cycle
Issue Report
↓
Problem Analysis
↓
Design the Fix
↓
Implement Changes
↓
Testing
↓
Deploy Updated Version
Challenges
Understanding legacy code
Maintaining backward compatibility
Managing technical debt
Keeping documentation up to date
Ensuring updates do not introduce regressions
SDLC Models Comparison
Model Best For Advantages Disadvantages
Stable, well-defined Simple, structured, well Di icult to
Waterfall
requirements documented accommodate changes
Frequently changing Flexible, fast feedback, Requires continuous
Agile
requirements iterative delivery customer involvement
Large, high-risk Excellent risk
Spiral Expensive and complex
projects management
Early user feedback, Prototype may be
Unclear or evolving
Prototype better requirement mistaken for the final
requirements
understanding product
Projects requiring high Testing planned from the Inflexible when
V-Model
quality and verification beginning requirements change