📋 The Ultimate Software Engineering SDLC & Methodologies Interview Guide
From Beginner to Most Expert – Master Waterfall, Agile, Scrum, Kanban, DevOps, Lean, and every software development lifecycle model. Walk into your interview with real‑world scenario confidence.
📘 SDLC Fundamentals Beginner
SDLC is a systematic process for planning, creating, testing, and deploying software. It provides a structured framework to produce high‑quality software that meets customer expectations, within time and budget estimates. Common phases: requirements, design, implementation, testing, deployment, and maintenance.
It reduces project risks, improves quality, ensures stakeholder alignment, and provides a predictable roadmap. Without SDLC, projects often suffer from scope creep, budget overruns, and missed deadlines.
1. Planning – feasibility, scope, resources. 2. Requirements – gather and document. 3. Design – architecture, UI/UX. 4. Implementation – coding. 5. Testing – verification & validation. 6. Deployment – release to production. 7. Maintenance – ongoing support.
A methodology is a set of principles and practices (e.g., Scrum). A framework is a more prescriptive, often partially complete structure that you fill with your own code (e.g., Angular). SDLC methodologies guide the process; frameworks guide implementation.
The V‑Model adds a testing phase for each development stage, forming a V shape. For every design phase, a corresponding test plan is created early. This emphasizes verification and validation and reduces late defect discovery.
Assesses whether a project is viable. Components: technical feasibility, economic feasibility (cost‑benefit), operational feasibility, and legal/regulatory feasibility. It prevents wasted investment on unworkable ideas.
Functional: what the system does (features). Non‑functional: how the system performs (scalability, security, usability). Both are critical; missing NFRs often cause project failure.
A description of how a user interacts with a system to achieve a goal. Includes main flow, alternate flows, and exceptions. It ensures all scenarios are considered.
Verification: "Are we building the product right?" (reviews, walkthroughs). Validation: "Are we building the right product?" (testing with real users). Both are needed for quality.
Combines iterative development with risk analysis. Each spiral cycle includes: determine objectives, identify and resolve risks, develop and test, plan the next iteration. Heavy emphasis on risk management. Good for large, high‑risk projects.
Uncontrolled expansion of requirements. Control with a clear scope statement, change control board, and stakeholder alignment. Agile handles it through prioritization in the backlog.
Delivering the system in small, usable portions. Each increment adds functionality. Allows early feedback and risk reduction.
Prototype is a throw‑away model for learning. MVP (Minimum Viable Product) is a shippable product with just enough features to satisfy early customers and gather feedback.
Use interviews, surveys, workshops, and observation. Create user stories and personas. Prioritize using MoSCoW (Must have, Should have, Could have, Won't have).
Maps requirements to design, code, and tests. Ensures every requirement is implemented and tested; helps in impact analysis and compliance.
A project has a defined start and end, producing a unique output. A product is a good or service that is continuously evolved and maintained. Agile focuses on product mindset.
Bridge between stakeholders and development team. Elicits, analyzes, documents, and validates requirements. Helps prioritize and ensures business value.
Formal change request process. Impact analysis on cost, schedule, and quality. Approval from change control board. Waterfall is not designed for frequent changes; this often leads to conflict.
Complete detailed design before coding. Pro: clarity, reduces later changes. Con: inflexible, assumes requirements are stable. Often associated with Waterfall.
Suboptimal code or design decisions made for speed that require future rework. In Agile, it's tracked and prioritized in the backlog. In Waterfall, it may accumulate due to lack of refactoring.
A meeting after a project or sprint to discuss what went well, what didn't, and how to improve. Fosters continuous improvement and team learning.
Iterative builds the whole system in rough layers, refining each iteration. Incremental delivers pieces of functionality one by one. Often used together (e.g., Agile).
The longest sequence of dependent tasks that determines the project duration. Any delay on the critical path directly delays the project. Used in Gantt charts.
Identify, analyze, plan mitigation, and monitor risks. Proactive approach reduces surprises. Example: technology risk, resource risk, requirement volatility.
A milestone is a significant event or checkpoint (zero duration). A deliverable is a tangible output (document, working software). Milestones mark delivery of key deliverables.
💧 Waterfall Model Intermediate
Linear sequential phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Each phase must be completed before the next begins. Appropriate for projects with stable, well‑understood requirements (e.g., regulatory systems, construction).
Simple to understand, easy to manage due to rigid structure, clear milestones and deliverables, well‑documented, and works well for small, predictable projects.
No working software until late, difficult to accommodate changes, high risk and uncertainty, testing at the end leads to costly fixes, and poor customer involvement.
Formally, through a change control process. Changes are discouraged; if accepted, they require revisiting completed phases, which is costly and time‑consuming.
When requirements are fixed, the technology is well‑known, the project is short, and the customer does not need to see intermediate versions. Examples: a simple payroll system with clear regulations.
Heavy emphasis. Every phase produces detailed documentation (SRS, design documents, test plans). This ensures knowledge transfer and future maintenance, but can become a burden.
All testing is done after the entire system is built. Defects found late are expensive to fix. This is a common Waterfall pitfall.
By introducing early test planning for each development phase, it reduces the risk of discovering requirements or design flaws during final testing.
Waterfall for upfront planning and final deployment, with Scrum in the middle for development. Used in large enterprises that need governance but want Agile flexibility for coding.
By tracking completed phases and milestones (e.g., "Design document approved"). Often uses Gantt charts with percent complete. Can be misleading if quality isn't verified.
Re‑estimate, add resources (Brooks' law caution), reduce scope, or consider crashing/fast‑tracking phases. Communicate honestly with stakeholders.
A point after which requirements cannot be changed without formal approval. Essential in Waterfall to prevent scope creep. Often leads to tension with business.
Rigorous reviews at each phase (requirements walkthrough, design inspection), testing according to plan, and adherence to standards. QA is a separate phase.
SRS captures what the system must do (customer view). FDD describes how the system will do it (technical view, architecture, modules).
Use a throw‑away prototype during requirements phase to clarify ambiguous needs, then proceed with formal Waterfall phases. This validates understanding early.
🔄 Agile & Scrum Most Popular
Agile is an iterative, incremental approach that values individuals, working software, customer collaboration, and responding to change. Unlike Waterfall, it delivers frequently, welcomes change, and involves the customer throughout.
Four values: individuals over processes, working software over documentation, customer collaboration over contract, responding to change over plan. The 12 principles expand on these, emphasizing early delivery, face‑to‑face conversation, and sustainable pace.
Scrum is a lightweight framework for Agile. Pillars: Transparency (everyone sees the work), Inspection (frequent checking), Adaptation (adjust based on inspection). The framework consists of roles, events, and artifacts.
Product Owner: maximizes value, manages backlog. Scrum Master: coaches the team, removes impediments, ensures Scrum is understood. Development Team: self‑organizing, delivers increments.
A time‑boxed iteration (usually 1‑4 weeks) during which a potentially releasable increment is created. Duration is consistent for a given team. Shorter sprints provide faster feedback.
Sprint Planning, Daily Scrum (stand‑up), Sprint Review (demo), Sprint Retrospective, and the Sprint itself. Each has a specific purpose and timebox.
A concise description of a feature from the user's perspective. Example: "As a customer, I want to reset my password so I can regain access." Acceptance criteria: given valid email, system sends reset link; given invalid email, error message shown.
An ordered list of everything needed in the product. The Product Owner owns and prioritizes it, ensuring items are clear and the team understands the top items.
A shared checklist that ensures a product backlog item is truly complete (e.g., coded, tested, documented). Creates transparency and quality. Without it, work may appear done but isn't.
The amount of work a team completes in a sprint (e.g., story points). Used for forecasting, not for comparing teams. Helps Product Owner plan releases.
Scrum uses time‑boxed sprints with fixed roles and ceremonies. Kanban is flow‑based, no prescribed iterations, focuses on limiting work in progress (WIP). Both are Agile.
Shows remaining work over time. Helps track progress toward the sprint goal. A flat line indicates blocked work; a steep line indicates fast progress or underestimated work.
Address through the Scrum Master. Understand root cause (skill, motivation, external issues). Coach and support. The team self‑organizes; peer accountability is key. Avoid blame.
A time‑boxed investigation to reduce uncertainty or gather knowledge. Not a feature; output is learning. Use when the team cannot estimate a story without research.
Scrum Master is a servant‑leader, coach for the Scrum process, removes impediments, but does not assign tasks or manage the team. Project Manager traditionally controls scope, budget, and timeline.
Story points measure relative effort/complexity/uncertainty, abstracted from time. They remain stable even if team velocity changes. Hours are absolute and can lead to micromanagement.
A framework for applying Agile at enterprise scale. Coordinates multiple teams via Agile Release Trains. Needed when a single Scrum team isn't enough; but adds overhead and complexity.
Make it visible in the backlog. Allocate a percentage of sprint capacity to refactoring. Use the definition of Done to prevent new debt. Retrospectives help identify systemic causes.
"We do Scrum, but we don't do retrospectives." Partial adoption that undermines the framework. It often hides underlying problems and prevents real agility.
Start with training, appoint a Scrum Master, begin with a pilot project. Adapt gradually. Management must understand and support the cultural shift. Expect resistance; celebrate small wins.
Remind about the sprint goal and the cost of context switching. If the change is critical, the Scrum Master facilitates a discussion; the team may cancel the sprint (rare). The PO should respect the sprint boundary.
A meeting after sprint review where the team inspects itself and creates an improvement plan. Technique: Start/Stop/Continue – each member writes sticky notes and discusses.
Definition of Ready: a checklist ensuring a user story is actionable (clear, estimable, testable). It's a quality gate before sprint planning. Definition of Done is for completed work.
Break epics into smaller, deliverable stories using patterns: by workflow steps, by business rules, by data variations. Estimate the smaller stories. Use planning poker for consensus.
Pig (committed) – team members who are accountable. Chicken (involved) – stakeholders, managers. Only pigs can talk during the daily scrum. A humorous way to explain roles.
Rotate meeting times to be fair, use video and collaborative tools, invest in communication, and consider having each site as a separate Scrum team with integration sprints.
XP is an Agile methodology focused on engineering practices: pair programming, TDD, continuous integration, simple design. Scrum provides the management framework; XP fills the technical practices.
Independent, Negotiable, Valuable, Estimable, Small, Testable. A checklist to ensure stories are well‑formed and ready for development.
A tiny, end‑to‑end implementation of a system that connects all architectural components. It proves the architecture works early and provides a foundation for growth.
Automated testing (unit, integration, UI), CI/CD, code reviews, pairing, and a strong Definition of Done. Quality is built in, not inspected later.
A single objective for the sprint that provides focus. Set collaboratively during sprint planning. It guides the team if trade‑offs are needed.
Invite them to the daily scrum as observer (but they should not interrupt) or schedule a separate short sync. Use CI/CD to provide continuous visibility.
Actively listen, clarify the issue, and facilitate resolution. May involve coordinating with other teams, management, or external vendors. Empowers the team to solve problems themselves where possible.
Use the average velocity of the last few sprints to predict how much can be taken in the next sprint. Simple, effective, and adaptive.
A meeting where representatives from multiple Scrum teams share progress and coordinate dependencies. Not an official Scrum event but a common scaling technique.
As Scrum Master, gently remind about the timebox and format. Facilitate to ensure everyone speaks. The team can agree on a "talking stick" rule.
Estimates become more accurate as the project progresses. Agile reduces uncertainty by delivering small increments, gathering real feedback, and re‑planning frequently.
Dual‑track development: a discovery track ahead of development, or design spikes within the sprint. Designers embed into the team. Use low‑fi prototypes for early validation.
Vision is the long‑term aspirational goal (the "why"). The backlog is the tactical list of work to achieve the vision. The vision provides coherence.
Outcomes over outputs: faster time‑to‑market, higher customer satisfaction, improved team morale, reduced defect rates. Use metrics like lead time, cycle time, and eNPS.
📊 Kanban & Lean Process Optimization
Kanban is a flow‑based method focusing on visualizing work, limiting WIP, and measuring cycle time. No fixed iterations. Scrum has sprints and roles. Kanban is more evolutionary.
Visualize workflow, limit work in progress (WIP), manage flow, make policies explicit, implement feedback loops, improve collaboratively.
Constraints on how many items can be in a given state at once. They prevent multitasking, reveal bottlenecks, and improve flow. Without WIP limits, Kanban is just a to‑do list.
Shows the number of items in each workflow state over time. Widening bands indicate growing queues. A bottleneck appears as a band that expands. Helps predict completion.
Lead time: from request to delivery. Cycle time: from work started to completion. Kanban teams aim to reduce cycle time and make it predictable.
Use an expedite lane with its own WIP limit. Only one item at a time. The team swarms to resolve it. Policies define what qualifies as expedite.
Derived from Toyota Production System. Focus on eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building integrity, and seeing the whole.
Partially done work, extra features, relearning, handoffs, delays, task switching, defects. Lean aims to minimize these.
A visual map of all steps from idea to production, with time values. Identifies delays and waste. Used to design a more efficient future state.
Work is pulled by the team when capacity is available, rather than pushed by a manager. Kanban boards with WIP limits enable pull. Contrasts with traditional task assignment.
⚙️ DevOps & CI/CD Culture & Automation
DevOps is a cultural and technical movement that unifies development and operations. It extends Agile by including deployment, monitoring, and feedback loops. Aims for continuous delivery.
Developers merge code frequently, verified by automated build and tests. It detects integration issues early, reduces risk, and speeds up delivery. Without CI, merging becomes painful.
Continuous Delivery ensures every change is releasable, but deployment to production is manual. Continuous Deployment automatically deploys every passing change to production. CD is the highest level of automation.
Defining CI/CD pipeline stages in a version‑controlled file (Jenkinsfile, GitLab CI YAML). Enables peer review, reproducibility, and easy scaling.
Decouples deployment from release. Code can be deployed but dark (off). Allows testing in production, canary releases, and instant rollback. Requires discipline.
Move testing activities earlier in the lifecycle (unit tests, static analysis). Prevents defects from propagating downstream. Reduces cost and time.
Managing infrastructure through code (Terraform, Ansible). Ensures consistency, versioning, and automation. Eliminates manual configuration drift.
Use database migration tools (Flyway, Liquibase) to version schema changes. Apply migrations as part of the pipeline. Ensure backward compatibility.
Two identical production environments. Only one is live. Deploy to inactive, test, then switch router. Instant rollback by switching back. Requires double the infrastructure.
Gradually shift traffic to a new version (e.g., 5% → 100%). Monitor for errors and performance. If issues arise, rollback. Tools: service mesh, load balancer.
📏 Project Management & Estimation Planning & Control
Project manager controls scope, budget, timeline, and assigns work. Scrum Master serves the team and process, removes impediments, and does not manage the team. Agile often doesn't have a traditional PM role.
Constructive Cost Model uses size (lines of code) to estimate effort, cost, and schedule. Basic, Intermediate, and Detailed versions. Uses historical data and constants.
Bar chart showing tasks over time, with dependencies. Excellent for Waterfall project planning and tracking. Not ideal for dynamic Agile environments.
Team members secretly select a card representing effort, then reveal simultaneously. Discuss discrepancies and re‑vote. Combines individual thinking with group wisdom; avoids anchoring.
Effort: person‑hours/days required. Duration: calendar time to complete, considering parallel work and waiting. A 10‑day effort task may take 20 days duration due to dependencies.
Shows completed work and total scope. If scope increases, the total line goes up. More transparent than burndown for scope changes.
Use average velocity of recent sprints to predict future capacity. Simple and data‑driven. Adjusts automatically if team changes.
Document listing risks, probability, impact, mitigation, and owner. Reviewed regularly. Essential for proactive risk management in any methodology.
Negotiate scope (fixed date, variable scope) or add resources (with caution). Use Agile to prioritize must‑haves; deliver the highest value by the deadline.
A document that formally authorizes the project. Contains objectives, scope, stakeholders, high‑level risks, and budget. Aligns everyone at the start.
🧬 Hybrid & Advanced Models Expert
Combines elements of different methodologies. Example: Water‑Scrum‑Fall (Waterfall for requirements & deployment, Scrum for development). Used to fit organizational constraints.
Evaluate requirements stability, team size, project complexity, risk, and stakeholder involvement. Use a decision matrix. There is no one‑size‑fits‑all.
A hybrid framework that extends Scrum with additional lifecycle phases (inception, construction, transition). Provides guidance for enterprise‑scale Agile.
Agile methods tailored by team size and criticality. Crystal Clear (small teams), Crystal Orange (larger). Emphasize people, interaction, and frequent delivery.
Iterative method focused on building features in short, two‑week cycles. Uses a feature list, planning by feature, and design by feature. More structured than Scrum.
Use frameworks like SAFe, LeSS, or Nexus. Requires alignment, architectural runway, and coordination roles. Often introduces more ceremony; keep teams as small and autonomous as possible.
🎭 Real‑World Scenarios
As Scrum Master, assess impact, coordinate volunteers, follow incident process. If no one available, escalate to management. Retrospectively, discuss a sustainable on‑call rotation.
Explain the cost of context switching and impact on sprint goal. If truly urgent, the Product Owner may cancel the sprint (rare). Or negotiate to swap out an equivalent amount of work.
🧪 Hands‑On Labs
Create columns: Backlog, To Do, In Progress (WIP 3), Review, Done. Move a sample story through and observe flow.
Practice estimating with planning poker, setting a sprint goal, and creating a sprint backlog. Timebox to 30 minutes.
💻 Process Exercises
As a user, I want to reset my password so that I can regain access. AC: given valid email, link sent; link expires in 1 hour; new password must meet complexity rules.
Given tasks A(2d), B(3d) after A, C(1d) after A, D(2d) after B and C. Critical path: A→B→D = 7 days.
🚀 Career & Trends (Q121‑Q250+)
Servant leader and coach for an Agile Release Train. Facilitates program‑level events, manages risks, and ensures continuous improvement.
Difficult. Usually requires a separate maintenance phase or project. Ideally, enforce code reviews and standards; but Waterfall doesn't naturally accommodate refactoring.
Two developers work together at one computer. Benefits: higher quality, knowledge sharing, fewer defects. An XP practice often adopted in Agile teams.
Integrate documentation into the Definition of Done. Use lightweight, living documents. Tools can generate documentation from code or tests.
Not a formal framework, but a story of how Spotify organized around squads, tribes, chapters, and guilds. Emphasizes culture and autonomy. Often misused as a blueprint.
No comments:
Post a Comment
Thanks for your valuable comment...........
Md. Mominul Islam