Software Development Life Cycle (SDLC) Cheat Sheet
Software Development Life Cycle (SDLC) Cheat Sheet: Phases, Models, Testing & Best Practices
The Software Development Life Cycle (SDLC) is a structured process used to plan, design, build, test, deploy, and maintain software applications.
It helps teams deliver software that meets business requirements, maintains quality, manages risks, and stays within practical time and budget constraints.
This cheat sheet covers SDLC phases, popular development models, Agile and Scrum, software testing, DevOps, documentation, project risks, and essential interview questions.
1. What Is SDLC?
SDLC stands for Software Development Life Cycle. It describes the activities involved in creating and maintaining software, from the initial idea through retirement.
Why SDLC Matters
Provides a structured development process.
Clarifies business and technical requirements.
Helps teams estimate time, cost, and resources.
Improves software quality.
Identifies risks earlier.
Supports testing and documentation.
Encourages controlled releases.
Makes ongoing maintenance more manageable.
SDLC is not a single programming method. Teams can implement its activities through different models, including Waterfall, Agile, iterative development, and DevOps-oriented workflows.
2. The Main SDLC Phases
A common SDLC model contains seven phases. Organizations may combine, rename, or repeat some of these activities.
Phase | Purpose | Typical deliverables |
|---|---|---|
1. Planning | Define the problem, objectives, scope, feasibility, and resources | Project plan, feasibility assessment |
2. Requirements analysis | Understand user needs and system expectations | Requirements document, user stories |
3. Design | Plan the architecture, data, interfaces, and components | Architecture diagrams, design specifications |
4. Development | Implement the software | Source code, builds |
5. Testing | Verify functionality, quality, security, and performance | Test cases, defect reports |
6. Deployment | Release software into the target environment | Release package, deployment records |
7. Maintenance | Monitor, fix, improve, and support the software | Patches, updates, support records |
Phase 1: Planning
The team establishes why the software is needed and whether the project is practical.
Typical activities:
Define the business problem.
Identify stakeholders.
Estimate cost and timeline.
Evaluate technical feasibility.
Identify major risks.
Define project scope.
Establish success criteria.
Example: A business plans a customer portal and determines its budget, required features, target users, and expected launch date.
Phase 2: Requirements Analysis
The team documents what the system must do and the constraints it must satisfy.
Requirements commonly include:
Functional requirements.
Non-functional requirements.
Business rules.
User roles and permissions.
Data requirements.
Security and privacy expectations.
Performance and availability expectations.
Functional requirement: A user can reset a forgotten password.
Non-functional requirement: Password-reset requests should be processed within an agreed response-time target under specified load conditions.
Phase 3: Design
The team translates requirements into a technical solution.
Design activities may cover:
System architecture.
Database schema.
User interface.
API contracts.
Authentication and authorization.
Data flows.
Security controls.
Integration with other systems.
Deliverables can include architecture diagrams, database designs, wireframes, and interface specifications.
Phase 4: Development
Developers implement the solution using appropriate programming languages, frameworks, and tools.
Typical activities include:
Writing code.
Reviewing code.
Managing versions with Git.
Integrating components.
Following coding standards.
Running automated checks.
Documenting important technical decisions.
Phase 5: Testing
Testing checks whether the software behaves as expected and identifies defects.
Teams may test individual components, integrated systems, complete workflows, security controls, and performance under load.
Testing should begin as early as practical rather than being postponed entirely until development ends.
Phase 6: Deployment
Deployment makes a software version available in its intended environment.
Activities can include:
Preparing infrastructure.
Configuring environment variables.
Applying database migrations.
Releasing the application.
Verifying the release.
Monitoring errors.
Preparing rollback or recovery procedures.
Phase 7: Maintenance
After release, the team supports and improves the software.
Maintenance may include bug fixes, security patches, compatibility updates, performance improvements, and new features.
The lifecycle continues as requirements and operating conditions change.
3. Common SDLC Models
An SDLC model describes how development activities are organized and performed.
Model | How it works | Suitable situations |
|---|---|---|
Waterfall | Work proceeds through relatively distinct sequential phases | Stable requirements and predictable delivery |
V-Model | Development phases are paired with corresponding testing activities | Projects requiring structured verification and validation |
Iterative | The solution is refined through repeated cycles | Requirements or designs need gradual improvement |
Incremental | The product is delivered in functional portions | Features can be released in manageable increments |
Spiral | Development cycles emphasize risk analysis and mitigation | Complex projects with significant risks |
Agile | Work is delivered and reviewed in short, adaptive cycles | Changing requirements and frequent feedback |
DevOps-oriented delivery | Development and operations collaborate through automation and continuous feedback | Products requiring frequent, reliable releases |
No model is universally best. Teams should select an approach based on requirements, risks, regulations, dependencies, delivery needs, and stakeholder involvement.
4. Waterfall Model
The Waterfall model organizes work into sequential phases, with each phase generally completed before the next begins.
Typical Sequence
Requirements → Design → Development → Testing → Deployment → Maintenance
Advantages
Clear phases and milestones.
Predictable documentation structure.
Easier to define deliverables when requirements are stable.
Can support formal approval processes.
Disadvantages
Changes may be expensive later.
Feedback can arrive late.
Working software may take longer to reach users.
Incorrect early assumptions can affect the entire project.
Example
A project with stable specifications and contractual documentation requirements may benefit from a more sequential approach.
However, even Waterfall projects can include reviews, prototypes, and early testing to reduce uncertainty.
5. Agile Development
Agile is an approach to software development that emphasizes collaboration, working software, feedback, and adapting to change.
Instead of waiting for the entire product to be completed, teams deliver and evaluate smaller increments.
Common Agile Principles in Practice
Deliver useful software frequently.
Collaborate with customers and stakeholders.
Respond to changing requirements.
Review outcomes regularly.
Improve team processes continuously.
Prioritize work according to value and risk.
Agile does not mean abandoning planning or documentation. It means adapting planning and documentation to the needs of the project.
6. Scrum Fundamentals
Scrum is a framework frequently used to implement Agile development.
Scrum Accountabilities
Accountability | Main responsibility |
|---|---|
Product Owner | Maximizes product value and manages the Product Backlog |
Scrum Master | Helps establish Scrum and improve team effectiveness |
Developers | Create a usable product increment during each Sprint |
Scrum Events
Event | Purpose |
|---|---|
Sprint | Fixed-length period for creating a usable increment |
Sprint Planning | Establishes the Sprint Goal and plans the work |
Daily Scrum | Helps Developers inspect progress toward the Sprint Goal |
Sprint Review | Inspects the outcome and considers future adaptations |
Sprint Retrospective | Identifies improvements to team effectiveness |
Common Scrum Artifacts
Product Backlog: Ordered list of work needed to improve the product.
Sprint Backlog: Sprint Goal, selected Product Backlog items, and the plan for delivering them.
Increment: Usable addition to the product that meets the Definition of Done.
A Sprint commonly lasts one month or less. Many teams use shorter Sprints to obtain feedback more frequently.
Important Agile Terms
User story: A concise description of a user need.
Example: “As a customer, I want to reset my password so that I can regain access to my account.”
Acceptance criteria: Conditions that a feature must satisfy to be accepted.
Sprint: A fixed-length Scrum event in which the team works toward a Sprint Goal.
Backlog: An ordered collection of work items.
Definition of Done: Shared criteria describing when work meets the required quality standard.
7. Software Requirements
Requirements provide a basis for design, implementation, and testing.
Functional Requirements
Describe what a system should do.
Examples:
Users can create accounts.
Customers can search products.
Administrators can manage permissions.
The system generates monthly reports.
Non-Functional Requirements
Describe qualities, constraints, or operating expectations.
Examples:
Response-time targets.
Availability requirements.
Security requirements.
Accessibility requirements.
Scalability expectations.
Maintainability standards.
Good Requirement Characteristics
A useful requirement should be:
Clear.
Specific.
Testable.
Feasible.
Consistent with other requirements.
Traceable to a business or user need.
Avoid vague requirements such as “the application should be fast.” Define measurable targets and the conditions under which they will be evaluated.
8. Software Design Fundamentals
Software design defines how components work together to satisfy requirements.
Common Design Concepts
Architecture: The high-level organization of the system.
Modularity: Dividing software into components with clear responsibilities.
Separation of concerns: Keeping different responsibilities appropriately separated.
Abstraction: Hiding unnecessary implementation details behind a simpler interface.
Encapsulation: Controlling access to an object's internal state and implementation.
Scalability: The ability to handle increasing demand through suitable architectural changes.
Maintainability: How easily software can be understood, corrected, and modified.
Common Architecture Styles
Architecture | Description |
|---|---|
Monolithic | Major application components are deployed as one application |
Layered | Organizes responsibilities into layers |
Microservices | Divides an application into independently deployable services |
Event-driven | Components communicate through events |
Serverless | Uses managed services to execute code or provide capabilities without requiring customers to manage the underlying server infrastructure directly |
Microservices and serverless architectures are not automatically better than simpler designs. Complexity, operational needs, team skills, and business requirements should guide architecture decisions.
9. Software Testing Types
Testing evaluates software behavior and helps identify defects.
Testing type | Purpose |
|---|---|
Unit testing | Tests individual functions or components |
Integration testing | Tests interactions between components |
System testing | Tests the complete system against requirements |
End-to-end testing | Tests complete user workflows |
Regression testing | Checks whether changes have broken existing functionality |
Smoke testing | Performs basic checks to establish whether a build is sufficiently stable for further testing |
Sanity testing | Performs focused checks after a limited change or fix |
Acceptance testing | Evaluates whether the system meets agreed acceptance needs |
Performance testing | Evaluates response times, throughput, and behavior under load |
Load testing | Evaluates behavior under expected or specified workloads |
Stress testing | Evaluates behavior beyond normal operating conditions |
Security testing | Identifies weaknesses and evaluates security controls |
Usability testing | Evaluates how effectively users can interact with the software |
Accessibility testing | Checks whether people with different abilities can use the system |
The exact boundaries between testing categories can vary across organizations.
Example Testing Scenario
For a password-reset feature:
Unit testing checks individual validation functions.
Integration testing checks the email service and reset-token storage.
End-to-end testing checks the complete reset workflow.
Security testing checks token expiration, authorization, and abuse resistance.
Accessibility testing checks whether the form can be used with assistive technologies.
10. Verification vs. Validation
These terms describe different quality questions.
Verification: Does the product meet its specified requirements?
Validation: Does the product satisfy the intended user need and purpose?
For example, a checkout page might pass tests confirming that every button behaves according to the specification. User testing may still reveal that customers cannot understand the checkout process.
Both verification and validation are important.
11. Bug and Defect Management
A defect is a problem in software that causes actual behavior to differ from expected behavior.
Typical Defect Workflow
Identify the problem.
Reproduce it.
Record the expected and actual results.
Document the environment and steps.
Assess severity and priority.
Assign the issue.
Investigate and fix the cause.
Retest the fix.
Perform regression testing where appropriate.
Close the issue after verification.
Severity vs. Priority
Severity describes the impact of a defect.
Priority describes how urgently the team should address it.
A high-severity issue may have high priority, but the two concepts are not identical. Business deadlines, exposure, workarounds, and affected users can influence priority.
Useful Bug Report Fields
Summary.
Steps to reproduce.
Expected result.
Actual result.
Environment.
Screenshots or relevant logs.
Severity.
Priority.
Reproducibility.
Assigned owner.
Resolution and verification notes.
12. DevOps, CI, and CD
DevOps promotes collaboration between software development and IT operations, supported by automation, monitoring, and continuous improvement.
Continuous Integration (CI)
Developers integrate code changes frequently. Automated builds and tests help detect integration problems early.
Continuous Delivery
Changes are built, tested, and prepared for release so they can be deployed when the organization chooses.
Continuous Deployment
Changes that pass the required automated controls can be deployed to production automatically.
Continuous delivery and continuous deployment are related but distinct practices.
Common DevOps Practices
Automated testing.
Build pipelines.
Infrastructure as code.
Automated deployments.
Monitoring and alerting.
Centralized logging.
Version control.
Reproducible environments.
Rollback and recovery planning.
DevOps does not eliminate the need for security, approvals, testing, or operational responsibility.
13. Software Security Throughout the SDLC
Security should be integrated throughout planning, design, development, testing, deployment, and maintenance.
Secure Development Practices
Planning: Identify sensitive data, security requirements, and likely threats.
Design: Define authentication, authorization, data protection, and trust boundaries.
Development: Follow secure coding practices and review dependencies.
Testing: Test access controls, input handling, and security assumptions.
Deployment: Protect secrets and use secure configurations.
Maintenance: Patch vulnerabilities, monitor activity, and respond to incidents.
Essential Security Controls
Least-privilege access.
Multifactor authentication for important accounts.
Parameterized database queries.
Server-side input validation.
Appropriate output encoding.
Secure session management.
Encryption where appropriate.
Dependency updates.
Logging and monitoring.
Backup and recovery plans.
Security requirements should be appropriate to the system's risks and the information it handles.
14. Documentation in Software Development
Documentation helps developers, testers, users, and operators understand the system.
Common Documentation Types
Document | Purpose |
|---|---|
Business requirements document | Describes business needs and objectives |
Software requirements specification | Documents functional and non-functional requirements |
Architecture document | Explains system structure and major design decisions |
API documentation | Describes endpoints, parameters, authentication, and responses |
Test plan | Defines testing scope, strategy, resources, and approach |
Test cases | Describe specific conditions and expected outcomes |
User documentation | Explains how to use the software |
Deployment guide | Documents release and configuration procedures |
Runbook | Describes operational procedures and troubleshooting |
Release notes | Summarizes changes, fixes, and known limitations |
Documentation should remain accurate and useful. A large document that no longer reflects the actual system can be more harmful than concise, maintained documentation.
15. Common SDLC Risks and Mistakes
Common Mistakes
Beginning development without understanding requirements.
Underestimating project complexity.
Ignoring non-functional requirements.
Delaying testing until the end.
Skipping code reviews.
Neglecting security.
Releasing without monitoring.
Failing to maintain backups.
Ignoring user feedback.
Making changes without evaluating their impact.
Maintaining outdated documentation.
Treating deployment as the end of the lifecycle.
How to Reduce Risk
Clarify requirements before committing to major work.
Break large tasks into manageable increments.
Identify high-risk areas early.
Test critical functionality continuously.
Review code and architectural decisions.
Automate repetitive quality checks.
Plan deployments and recovery.
Monitor production behavior.
Gather stakeholder feedback.
Review lessons learned and improve the process.
16. Common SDLC Metrics
Metrics can help teams understand quality, delivery, and operational performance.
Metric | What it measures |
|---|---|
Lead time for changes | Time from a change being initiated or committed, depending on the chosen definition, until delivery |
Deployment frequency | How often the team deploys changes |
Change failure rate | Proportion of deployments that require remediation or cause a failure, according to the team's definition |
Mean time to recovery | Average time required to restore service after a failure, based on the defined measurement |
Defect rate | Frequency of defects relative to a defined unit or period |
Test coverage | Portion of specified code or requirements exercised by tests |
Escaped defects | Defects discovered after a release or outside the intended testing stage |
Availability | Proportion of time a service is available according to a defined measurement |
Metrics need consistent definitions and context. For example, high test coverage does not necessarily mean that tests are effective or that the software is defect-free.
17. SDLC Quick Reference
Phase or practice | Main purpose |
|---|---|
Planning | Define objectives, scope, feasibility, and resources |
Requirements | Establish expected system behavior and constraints |
Design | Plan architecture, interfaces, data, and components |
Development | Implement the solution |
Testing | Verify quality and expected behavior |
Deployment | Release the software |
Maintenance | Support and improve the system |
Waterfall | Sequential phase-oriented approach |
Agile | Adaptive development with feedback |
Scrum | Framework using Sprints, defined accountabilities, events, and artifacts |
Unit testing | Tests individual components |
Integration testing | Tests component interactions |
Regression testing | Checks for unintended effects of changes |
CI | Frequent integration supported by automated checks |
Continuous delivery | Keeps changes ready for release |
Continuous deployment | Automatically deploys qualifying changes |
DevOps | Collaboration and automation across development and operations |
18. SDLC Interview Questions
What is SDLC?
SDLC is a structured approach to planning, building, testing, deploying, and maintaining software.
What are the main SDLC phases?
Common phases are planning, requirements analysis, design, development, testing, deployment, and maintenance.
What is the difference between Waterfall and Agile?
Waterfall generally organizes work into sequential phases, while Agile emphasizes iterative delivery, feedback, and adapting to change.
What is Scrum?
Scrum is a framework for developing and sustaining products through Sprints, defined accountabilities, events, and artifacts.
What is the difference between functional and non-functional requirements?
Functional requirements describe what a system should do. Non-functional requirements describe qualities and constraints, such as performance, security, and availability.
What is the difference between verification and validation?
Verification checks conformance to specified requirements; validation checks whether the solution meets its intended purpose and user needs.
What is regression testing?
Regression testing checks whether a change has unintentionally broken existing functionality.
What is the difference between severity and priority?
Severity describes the impact of a defect. Priority indicates how urgently it should be addressed.
What is CI/CD?
CI/CD refers to practices and automation for integrating, testing, preparing, and potentially deploying software changes.
Why is maintenance important?
Maintenance keeps software secure, reliable, compatible, and useful after release.
Why should security be integrated into SDLC?
Addressing security throughout development helps identify risks earlier and reduces the likelihood of releasing vulnerable software.
19. SDLC Practical Checklist
Before Development
Define the business problem.
Identify stakeholders and users.
Document functional requirements.
Define non-functional requirements.
Assess feasibility, cost, and risks.
Establish success criteria.
During Development
Follow coding standards.
Use version control.
Review changes.
Test components.
Protect secrets and sensitive data.
Update relevant documentation.
Before Release
Complete required testing.
Resolve or document important defects.
Review security controls.
Confirm deployment readiness.
Verify backups and recovery arrangements.
Prepare monitoring and rollback procedures.
After Release
Monitor errors and performance.
Gather user feedback.
Apply security updates.
Review incidents.
Maintain documentation.
Plan future improvements.
Conclusion
The Software Development Life Cycle provides a framework for turning an idea into reliable, maintainable software. Understanding its phases, development models, testing practices, security controls, and deployment processes helps teams manage complexity and deliver useful products.
For beginners, focus first on the seven common SDLC phases, then learn Waterfall, Agile, Scrum, software testing, and CI/CD. Connecting these concepts to a real project will help you understand how software moves from requirements to production and ongoing maintenance.
