Part 1: SDLC Models, Agile & Estimation

1. Classic & Traditional SDLC Models

The Waterfall Model

The foundational, linear-sequential life cycle model where development flows downward through distinct, non-overlapping phases.

• Core Mechanism: Each phase (Requirements, Design, Implementation, Verification, Maintenance) must be 100% complete, documented, and signed off before the next phase begins. There is no turning back without a formal change control process.
• Advantages: Highly structured, easy to manage, and transparent for fixed-scope contracts. Provides clear deliverables and milestones for each phase.
• Disadvantages: Highly rigid; accommodating changes mid-way is extremely expensive. High risk of late-stage failure since working software isn’t visible until the end of the life cycle. Poor fit for complex, long-term, or evolving projects.
• Ideal Use Case: Small, simple projects with strictly defined, static requirements (e.g., migrating a legacy database structure where target schemas are fixed).

The V-Model (Verification & Validation)

An extension of the Waterfall model that maps development phases directly to corresponding testing phases in a V-shaped execution path.

• Core Mechanism: Testing activities are planned and designed in parallel with the development phases before any coding begins. It balances conceptual verification with physical validation.

• Key Distinction:

• Verification: Evaluates static artifacts like documents and designs to ensure the system is being built correctly (“Are we building the product right?”).

• Validation: Executes the actual dynamic system to ensure it meets user needs (“Are we building the right product?”).

• Pros/Cons: Offers excellent quality control and early test planning, but inherits Waterfall’s strict rigidity regarding requirement adjustments.

The Spiral Model

A risk-driven evolutionary model that combines the iterative nature of prototyping with the controlled, systematic aspects of the Waterfall model.

• Core Mechanism: The project progresses through loops (spirals). Each loop represents a phase divided into four distinct quadrants:

1. Determine Objectives: Identify target functionality, constraints, and alternative solutions.
2. Identify & Resolve Risks: Evaluate alternatives and carry out risk mitigation (e.g., building prototypes, running simulations).
3. Development & Testing: Build and verify the next iteration of the software.
4. Plan Next Iteration: Review results with stakeholders and plan the upcoming loop.

• Pros/Cons: Unmatched risk management for massive systems, but requires deep risk-assessment expertise and can be expensive and complex to administer.
• Ideal Use Case: High-risk, large-scale mission-critical systems (e.g., aerospace control systems, medical device software).

Other Traditional Iterative Models

• Incremental Model: The project is broken down into small, manageable chunks (increments). Each increment passes through a full mini-Waterfall cycle, delivering a fully functional portion of the software (e.g., building Module A, then Module B).
• Iterative Model: The system is built globally from day one, starting with a basic implementation of the core architecture. Each subsequent iteration expands the entire system’s depth, refining features based on feedback (e.g., building a low-fidelity version of the whole app, then making it high-fidelity).
• Prototype Model: Focuses on rapidly building a visual, simplified version of the software (a prototype) to elicit feedback from users who struggle to visualize abstract requirements. The prototype can be throwaway (discarded after learning) or evolutionary (refined into the final product).
• Rapid Application Development (RAD): Focuses on rapid prototyping and fast tool-driven code generation over extensive documentation. It relies heavily on powerful development tools, component reuse, and active user workshops (JAD sessions). Highly effective when the system can be easily modularized.
• Big Bang Model: A highly unstructured model with zero formal planning, design, or documentation. Developers simply receive inputs (money, time, an abstract idea) and immediately begin coding. Highly risky and inappropriate for enterprise environments, but useful for solo learning projects, hackathons, or tiny academic experiments.

---

2. Agile & Scrum Frameworks

Agile is a mindset guided by the Agile Manifesto, prioritizing individuals, working software, collaboration, and responsiveness over rigid processes. Scrum is a highly structured framework designed to implement those Agile principles through specific roles, events, and artifacts.

The Scrum Team Roles

• Product Owner (PO): The single individual responsible for maximizing the value of the product. They own the Product Backlog, manage its prioritization, translate stakeholder needs into user stories, and define acceptance criteria.
• Scrum Master (SM): A servant-leader responsible for promoting and supporting Scrum. They coach the team, remove organizational blockers (impediments), protect the team from external disruptions, and facilitate ceremonies.
• Developers/Development Team: The cross-functional, self-organizing professionals who build the increment. They estimate effort, decide how to turn backlog items into working software, and own the technical quality.

Scrum Artifacts

• Product Backlog: An ordered, evolving single source of truth listing everything needed in the product.
• Sprint Backlog: The highly specific set of Product Backlog items selected for the current Sprint, plus a practical plan for delivering the increment.
• Increment: The concrete step toward the Product Goal. It must be thoroughly tested, usable, and meet the team’s explicit Definition of Done (DoD).
• Burndown Chart: A visual tool showing the remaining work versus time left in the current sprint to track progress toward the sprint goal.

Scrum Ceremonies (Events)

All Scrum ceremonies are time-boxed events designed to maximize transparency and enable inspection and adaptation.

Sprint Planning

• Purpose: Define what can be delivered in the sprint and how that work will be achieved.
• Key Inputs: Product Backlog
• Key Outputs: Sprint Goal, Sprint Backlog
• Typical Timebox: Max 2 hours per week of sprint length

Daily Scrum

• Purpose: Sync team activities, inspect progress toward the Sprint Goal, and identify blockers.
• Key Inputs: Daily progress
• Key Outputs: Updated Sprint Backlog, identified blockers
• Typical Timebox: Strictly 15 minutes daily

Sprint Review

• Purpose: Inspect the sprint increment and adapt the Product Backlog based on stakeholder feedback.
• Key Inputs: Completed Increment
• Key Outputs: Updated Product Backlog, stakeholder consensus
• Typical Timebox: Max 1 hour per week of sprint length

Sprint Retrospective

• Purpose: Inspect the team’s processes, relationships, and tools to plan quality and workflow improvements for the next sprint.
• Key Inputs: Team observations
• Key Outputs: Actionable process improvements
• Typical Timebox: Max 45 minutes per week of sprint length

3. DevOps Framework & CI/CD Pipelines

DevOps bridges the historical gap between software development (Dev) and IT operations (Ops) to ensure rapid, continuous delivery of high-quality applications.

• How DevOps Complements SDLC: While Agile focuses on optimizing the creation of software up to the point of being “done,” DevOps extends this automation and collaboration all the way through delivery, deployment, and real-world infrastructure monitoring.

Continuous Integration (CI) vs. Continuous Delivery (CD) vs. Continuous Deployment

• Continuous Integration (CI): The practice of automating the integration of code changes from multiple contributors into a single shared repository. Every push triggers automated builds and unit/integration tests to catch integration errors early.
• Continuous Delivery (CD): An extension of CI where the code changes are automatically built, tested, and staged for a release to production. The actual deployment to the production environment requires a manual human sign-off button.
• Continuous Deployment: The ultimate evolution of the pipeline. Every change that successfully passes all automated testing gates is deployed automatically to production with zero human intervention.

---

4. Architectural Comparison: Scrum vs. Kanban

While both are popular framework variants of the Agile philosophy, they approach workflow and iteration from fundamentally different perspectives.

• Core Operational Metric: Scrum measures progress via Velocity (the number of story points completed per sprint). Kanban measures progress using Cycle Time (how long a single task takes to transition from start to finish) and Lead Time (total time from task creation to completion).
• Work In Progress (WIP) Controls: Scrum limits WIP implicitly by restricting the number of items pulled into a fixed-time sprint backlog. Kanban explicitly limits WIP per workflow column (e.g., maximum 2 tasks allowed in the “In Progress” lane simultaneously) to surface delivery bottlenecks instantly.
• Handling Changes: In Scrum, adding new tasks mid-sprint is heavily discouraged to protect focus. In Kanban, new items can be injected into the backlog at any time; as soon as a slot opens up in the downstream column, the next item is pulled.

---

5. Strategic Architectural Decision Matrix

Choosing the right SDLC framework requires analyzing a project’s distinct variables. Use this decision matrix during interviews to justify a chosen model:

Factor	Waterfall	Spiral	Agile (Scrum)	Kanban
Requirement Clarity	Clear, static, predefined	Evolving, high-risk	Uncertain, rapidly changing	Dynamic, operational shift
Risk Profile	Low architectural risk	Extreme, existential risk	Medium, market/fit risk	Low, continuous operational risk
Customer Involvement	Start & end only	At milestone evaluations	High, active every single sprint	As-needed prioritization
Delivery Model	Single large release	Phased iterations	Fixed 2–4 week increments	Continuous flow of single pieces
Primary Focus	Predictability and compliance	Exhaustive risk mitigation	Rapid feedback and adaptability	Maximum throughput and efficiency

---

6. The Phases of the SDLC (The #1 Starter Question)

Before discussing models, know the classic seven-phase breakdown every model organizes:

Phase	Key Activities	Deliverable
1. Requirement Analysis	Gather & document stakeholder needs	SRS (what the system must do)
2. Feasibility Study	Technical, economic, operational, legal, schedule (TELOS)	Feasibility report
3. Design	Architecture + detailed module design	HLD / LLD, design docs
4. Coding / Implementation	Write code per design & standards	Working code
5. Testing	Unit → integration → system → acceptance	Verified software
6. Deployment	Install & make live in production	Live system
7. Maintenance	Fix, adapt, enhance	Updated releases

• Maintenance consumes the largest cost share (often 60–80% of total).
• Waterfall vs Agile (one-liner): Waterfall = plan everything up front, one big release; Agile = build a little, learn, repeat. Waterfall suits fixed/clear requirements; Agile suits evolving ones.

7. Effort Estimation (COCOMO, FPA, Story Points)

• Story Points (Agile): relative size of a user story (Fibonacci scale 1,2,3,5,8,13). Velocity = story points completed per sprint; used to forecast future sprints.
• FPA (Function Point Analysis): counts user-visible functionality (inputs, outputs, inquiries, files, interfaces), each weighted, to size the system independent of technology/language.
• COCOMO (Constructive Cost Model): estimates effort from KLOC (thousands of lines of code). Basic model: Effort = a × (KLOC)^b where a,b depend on the mode (organic, semi-detached, embedded). E.g. organic: Effort ≈ 2.4 × KLOC^1.05 (person-months).

Rule of thumb: story points for Agile sizing; FPA for function-based, technology-neutral sizing; COCOMO for LOC-based cost modeling. Estimate effort → then schedule/duration, never the reverse.