Part 1: Importance of Software Engineering
Understanding why software engineering is a disciplined, principled approach to building software
1.1
Problem Solving Activity
💡Core Concept
Software engineering is fundamentally a problem-solving discipline — engineers analyse real-world problems, decompose them into manageable parts, and produce software solutions that satisfy stakeholder requirements.
📖Key Terminology
- Problem Domain The real-world context in which the problem exists (e.g., banking, healthcare).
- Solution Domain The space of software constructs used to solve the problem.
- Decomposition Breaking a large problem into smaller, tractable sub-problems.
- Abstraction Hiding unnecessary detail to focus on essential structure.
- Requirements A precise specification of what the system must do.
⚙️Mechanism / Process
- Understand the problem — Elicit and document requirements from stakeholders.
- Define the problem — Formulate a precise problem statement with constraints.
- Decompose — Split into sub-problems (functions, modules, components).
- Design solutions — Propose alternative approaches for each sub-problem.
- Evaluate & select — Pick the best-fitting solution considering cost, time, and risk.
- Implement & verify — Code the solution and test against requirements.
⚖️Pros and Cons
- Systematic approach reduces ambiguity
- Decomposition improves team collaboration
- Encourages reuse of known solutions
- Problem may be ill-defined at the start
- Stakeholder disagreements delay analysis
- Over-decomposition leads to complexity
🔍Example
Real-world example
Building an Online Examination System: the problem is "students can't take exams remotely." Decomposition yields sub-problems — user authentication, question bank management, timer enforcement, auto-grading, and result reporting. Each is solved independently and integrated.
⚠️Exam Pitfalls
- Pitfall: Confusing "problem domain" with "solution domain" — the problem domain is about the business/user; the solution domain is about software constructs.
- Pitfall: Thinking problem-solving is only about coding — it includes analysis, design, and validation too.
- Trick Q: "Is SE purely a problem-solving activity?" — No, it also involves modelling, knowledge acquisition, and rationale-driven decision-making.
1.2
Modelling Activity
💡Core Concept
Modelling is the creation of abstract representations of a system — both what it must do (functional models) and how it is structured (design models) — to reason about it before building it.
📖Key Terminology
- Model A simplified, abstract view of the system emphasising certain aspects.
- UML Unified Modelling Language — standard notation for SE models.
- Functional Model Describes what the system does (use-case diagram, DFD).
- Structural Model Describes system structure (class diagram, ER diagram).
- Behavioural Model Describes dynamic behaviour (sequence diagram, state diagram).
⚙️Mechanism / Process
- Identify what to model — system boundary, actors, data flows.
- Choose the right model type — functional, structural, or behavioural.
- Create graphical notation using UML diagrams, DFDs, ERDs.
- Validate the model with stakeholders to ensure correctness.
- Refine incrementally as more is understood about the system.
⚖️Pros and Cons
- Communicates design to non-technical stakeholders
- Detects inconsistencies early
- Serves as documentation blueprint
- Models can become out-of-sync with code
- Over-modelling wastes time
- Requires training in UML/notation tools
🔍Example
Library Management System
A Use Case Diagram models actors (Student, Librarian) and use cases (Issue Book, Return Book, Search Catalogue). An ER Diagram models entities (Book, Member, Transaction) and their relationships.
⚠️Exam Pitfalls
- Pitfall: Students think modelling = only UML diagrams. Modelling also includes DFDs, ER diagrams, state machines, and more.
- Trick Q: "A model is the system." — False. A model is an abstraction, not the system itself.
- Pitfall: Confusing structural and behavioural models — class diagram = structural; sequence diagram = behavioural.
1.3
Knowledge Acquisition Activity
💡Core Concept
Software engineering is a knowledge-intensive activity — engineers must continuously acquire domain knowledge (about the problem), technical knowledge (about tools and methods), and organisational knowledge (about teams and processes).
📖Key Terminology
- Domain Knowledge Understanding of the application area (e.g., finance, healthcare).
- Tacit Knowledge Informal, experience-based knowledge hard to document.
- Explicit Knowledge Documented, formalised knowledge in manuals or specs.
- Knowledge Elicitation Gathering knowledge from domain experts via interviews or observation.
- Organisational Memory Collective knowledge stored in documents, wikis, and codebases.
⚙️Mechanism / Process
- Identify knowledge gaps — What does the team not yet know about the problem?
- Elicit from stakeholders — Interviews, workshops, surveys, observation.
- Research existing solutions — Literature review, design patterns, prior projects.
- Formalise and document — Convert tacit knowledge into explicit specifications.
- Share & review — Peer review, code review, knowledge base updates.
⚖️Pros and Cons
- Leads to better requirements capture
- Reduces rework due to misunderstandings
- Builds institutional memory
- Domain experts may be unavailable
- Tacit knowledge is hard to extract
- Knowledge can become stale quickly
🔍Example
Hospital Management System
A team conducts 10 hours of interviews with doctors, nurses, and admin staff (knowledge elicitation). They also study HIPAA compliance documents (explicit knowledge) and observe how nurses track patient vitals manually (tacit knowledge capture).
⚠️Exam Pitfalls
- Pitfall: Assuming knowledge acquisition = only requirements gathering. It also covers architectural knowledge, process knowledge, and organisational culture.
- Trick Q: "Tacit knowledge is more valuable than explicit knowledge." — Neither is universally superior; both are needed.
1.4
Rationale Driven Activity
💡Core Concept
Every SE decision must be justified with explicit reasoning (rationale). Capturing why a design choice was made — including rejected alternatives — is as important as capturing what was built.
📖Key Terminology
- Design Rationale The reasoning behind a design decision.
- Decision Log A record of key decisions, their options, and the reasoning chosen.
- Trade-off A deliberate compromise between two conflicting quality attributes.
- ADR Architecture Decision Record — a lightweight document capturing an architectural decision.
- Stakeholder Argument Justification framed in terms of stakeholder value.
⚙️Mechanism / Process
- Identify a decision point — Where must a design/technology/process choice be made?
- List alternatives — Enumerate all viable options.
- Evaluate against criteria — Cost, performance, maintainability, risk.
- Select and justify — Record the chosen option with explicit reasons.
- Document rejected alternatives — Explain why they were not chosen (avoids revisiting later).
⚖️Pros and Cons
- Reduces repeated debates on settled decisions
- Helps new team members understand architecture
- Supports future maintenance decisions
- Recording rationale adds overhead
- Decisions become harder to reverse
- Rationale may become outdated
🔍Example — ADR
Architecture Decision Record
Decision: Use PostgreSQL over MySQL.Options: MySQL, PostgreSQL, MongoDB.
Rationale: PostgreSQL's ACID compliance and JSON support better fit our need for complex transactions. MongoDB was rejected due to weak ACID guarantees; MySQL lacked full JSON query support.
⚠️Exam Pitfalls
- Pitfall: Confusing rationale with requirements — requirements say what; rationale says why.
- Trick Q: "Rationale is only needed for architectural decisions." — No; it applies to process, tool, and design decisions too.
1.5
Umbrella Activities
💡Core Concept
Umbrella activities are cross-cutting concerns that span all SDLC phases — they are not tied to any single phase but must be performed throughout the entire project lifecycle.
📖Key Terminology
- Umbrella Activity An activity performed across all SDLC phases, not confined to one stage.
- SQA Software Quality Assurance — systematic activities ensuring quality standards are met.
- SCM Software Configuration Management — tracking and controlling changes to software.
- Risk Management Identifying, assessing, and mitigating project risks throughout.
- Project Tracking Continuously monitoring progress against the project plan.
⚙️The 8 Umbrella Activities (Pressman)
- Project Tracking & Control — Monitor schedule, cost, quality continuously.
- Risk Management — Identify risks early; revisit at every phase.
- Software Quality Assurance (SQA) — Apply quality checks at each milestone.
- Technical Reviews — Peer reviews, inspections throughout development.
- Software Configuration Management (SCM) — Version control and change management from day 1.
- Reusability Management — Identify and manage reusable assets continuously.
- Measurement & Metrics — Collect and analyse metrics at every phase.
- Work Product Preparation — Documents, models, and data created throughout the project.
⚖️Pros and Cons
- Provides continuous quality oversight
- Early risk identification reduces failures
- SCM prevents version conflicts
- Adds overhead to every phase
- Requires dedicated resources and tooling
- Easy to skip under schedule pressure
🔍Example
6-month e-commerce project
Risk management conducted at kick-off and revisited monthly. Git/version control (SCM) used from the first commit. Code reviews (technical reviews) happen after every feature. Test cases written alongside code (SQA). All phases.
⚠️Exam Pitfalls
- Most common mistake: Confusing umbrella and framework activities — Framework activities (requirements, design, code, test) are phase-specific; umbrella activities span ALL phases.
- Trick Q: "Testing is an umbrella activity." — No! Testing is a framework activity. SQA is the umbrella activity.
- Exam fact: Pressman lists 8 umbrella activities — memorise them: tracking, risk, SQA, reviews, measurement, SCM, reusability, work product preparation.
1.6
Software Engineering Challenges
💡Core Concept
SE faces persistent challenges from the inherent complexity, invisibility, and changeability of software — unlike physical engineering, software has no material constraints but has unbounded logical complexity.
📖Key Terminology
- Legacy Systems Old systems that are costly to maintain but hard to replace.
- Heterogeneity Systems must work across diverse platforms, languages, and environments.
- Software Crisis The difficulty of writing correct, on-time, on-budget software (coined 1968).
- Security & Trust Increasingly critical as software controls critical infrastructure.
- Scale The challenge of engineering extremely large systems (millions of LOC).
⚙️Key Challenges (Sommerville)
- Heterogeneity — Software must integrate across different hardware, OS, and legacy systems.
- Business & Social Change — Requirements change rapidly due to business evolution and globalisation.
- Security & Trust — Critical systems must be secure against attacks; trust must be established.
- Scale — Methods for small systems don't scale to systems with millions of users.
- Aging Software (Legacy) — Maintaining and evolving systems not designed for change.
⚖️Impact vs. Mitigation
- Agile methods handle changing requirements
- Middleware/APIs handle heterogeneity
- DevSecOps embeds security throughout
- Projects still commonly over budget or late
- Security vulnerabilities remain pervasive
- Technical debt accumulates in aging code
🔍Example — CHAOS Report
Standish CHAOS Report 1994
31.1% of projects cancelled, 52.7% cost 189% of original estimate, only 16.2% completed on time and on budget. Modern metrics show improvement but problems persist (2020 CHAOS: ~31% project failure rate).
⚠️Exam Pitfalls
- Pitfall: Listing only "changing requirements" as a challenge. Expect 4–5 distinct challenges in the answer (heterogeneity, scale, security, legacy, social change).
- Trick Q: "The software crisis has been solved." — No; it has been mitigated by SE practices but not eliminated.
1.7
Software Development Life Cycle (SDLC)
💡Core Concept
The SDLC is a structured process defining the phases a software system passes through from initial conception through retirement, providing a framework for planning, creating, testing, and delivering software.
📖Key Terminology
- Phase A distinct stage of the SDLC with defined inputs, activities, and outputs.
- Milestone A checkpoint signalling the completion of a major phase.
- Deliverable A tangible artifact produced at each phase (SRS, design doc, code, test report).
- Baseline A formally reviewed and approved version of a deliverable used as a reference.
- Iteration One cycle through some or all SDLC phases (in iterative models).
⚙️Classical SDLC Phases
Planning
→
Requirements
→
Design
→
Implementation
→
Testing
→
Deployment
→
Maintenance
- Planning — Feasibility study, resource estimation, project schedule.
- Requirements Analysis — SRS document capturing functional and non-functional requirements.
- System Design — HLD (architecture) and LLD (module-level) design documents.
- Implementation — Coding in the chosen language and framework.
- Testing — Unit, integration, system, and acceptance testing.
- Deployment — Release to production environment.
- Maintenance — Bug fixes, enhancements, and adaptations over the system's lifetime.
⚖️Pros and Cons
- Clear structure with defined deliverables per phase
- Easy to manage and track progress
- Well-understood by all stakeholders
- Rigid linear flow struggles with changing requirements
- Working software delivered late in the cycle
- Maintenance phase is most expensive (~60–80% of total cost)
🔍Example
Numerical context
The maintenance phase consumes approximately 60–80% of total software cost over the product lifetime. For a ₹50 lakh project, up to ₹40 lakh may be spent on maintenance over 5 years — highlighting why maintainability must be designed in from day 1.
⚠️Exam Pitfalls
- Pitfall: SDLC and process model are not the same — SDLC is the set of phases; a process model (Waterfall, Spiral etc.) is the order and method for executing those phases.
- Trick Q: "SDLC ends at deployment." — No; maintenance is the longest and most expensive phase.
Part 2: Process Models
Different frameworks for organising and executing the SDLC phases
2.1
Waterfall Model
💡Core Concept
The Waterfall model is a linear, sequential process model where each phase must be fully completed before the next begins — like water flowing over a falls, there is no going back.
📖Key Terminology
- Sequential Model Phases executed in strict order with no overlap.
- Phase Exit Criteria Conditions that must be met before moving to the next phase.
- Sign-off Formal stakeholder approval of a phase's deliverable.
- Big Design Up Front All design completed before any coding begins.
⚙️Phases
Requirements
↓
System Design
↓
Implementation
↓
Verification
↓
Maintenance
- Gather and freeze all requirements in an SRS document.
- Produce HLD and LLD design documents; get stakeholder sign-off.
- Code all modules according to the frozen design.
- Perform testing (unit → integration → system → acceptance).
- Deploy and enter maintenance mode for bug fixes and enhancements.
⚖️Pros and Cons
- Simple, easy to understand and manage
- Well-defined milestones and deliverables
- Good for projects with stable requirements
- Extensive documentation produced
- No working software until very late
- Inflexible to requirement changes
- Testing happens too late to catch design defects
- Not suitable for complex, high-risk projects
🔍Example
NASA Space Shuttle software
Requirements were frozen years in advance, each phase rigorously reviewed and signed off, and no code was written until design was complete. Suitable because requirements were stable and failure was catastrophic.
⚠️Exam Pitfalls
- Trick Q: "Waterfall has no feedback loops." — The original Royce (1970) paper actually included feedback loops; "pure" waterfall with zero feedback is a misconception.
- Pitfall: Saying Waterfall is always bad — it is well-suited for fixed, well-understood requirements (defence, embedded systems).
- Pitfall: Confusing Verification and Validation — Verification = "did we build the product right?"; Validation = "did we build the right product?"
2.2
Incremental Model
💡Core Concept
The Incremental model delivers the system in multiple releases (increments), each adding more functionality, so a working partial product is available early and grows toward the full system.
📖Key Terminology
- Increment A usable version of the system delivering a subset of features.
- Core Product The first increment containing the most critical requirements.
- Staggered Delivery Multiple increments delivered at different times.
⚙️Mechanism / Process
- Plan all increments — Prioritise features into increments 1, 2, 3…
- Develop Increment 1 (core product) — Requirements → Design → Code → Test → Deploy.
- Customer uses Increment 1 and provides feedback.
- Develop Increment 2 — Builds on Increment 1; incorporates feedback.
- Repeat until the full system is delivered.
⚖️Pros and Cons
- Working software early in development
- Customer feedback improves later increments
- Reduced risk of total project failure
- Requires good architectural planning upfront
- Later increments may require redesign
- Total cost may be higher due to rework
🔍Example — 3-increment e-commerce
E-commerce platform
Increment 1: Product listing + user registration + checkout.Increment 2: Payment gateway + order tracking.
Increment 3: Reviews, recommendations, loyalty programme.
The store operates after Increment 1 and improves with each release.
⚠️Exam Pitfalls
- Pitfall: Confusing Incremental with Iterative — Incremental adds new features each cycle; Iterative refines the same features.
- Trick Q: "The first increment must be a full system." — False; it is the core product (minimum viable functionality).
2.3
Prototype Model
💡Core Concept
The Prototype model builds a quick, preliminary working version of the system to clarify requirements and get early user feedback — the prototype may be discarded (throwaway) or evolved into the final product (evolutionary).
📖Key Terminology
- Throwaway Prototype Built solely to gather requirements; discarded after evaluation.
- Evolutionary Prototype Refined incrementally into the final product.
- Horizontal Prototype Wide but shallow — demonstrates UI without backend logic.
- Vertical Prototype Deep but narrow — fully implements one feature end-to-end.
⚙️Mechanism / Process
- Gather initial requirements — Quick, incomplete understanding of needs.
- Build prototype — Rapid development of a working but incomplete system.
- User evaluation — User interacts with prototype and provides feedback.
- Refine prototype — Incorporate feedback; repeat steps 2–3 if needed.
- Finalise requirements — Once satisfied, build the final product (or evolve the prototype).
⚖️Pros and Cons
- Clarifies vague requirements early
- Reduces risk of building the wrong system
- Detects usability issues before final build
- Users may mistake prototype for final product
- "Creeping featurism" — users keep adding requirements
- Poor-quality prototype code may persist
🔍Example
Banking mobile app UI prototype
A Figma prototype built in 3 days. After 5 rounds of testing with 10 users, the team discovered the fund-transfer flow needed 8 screens but users expected ≤3 taps. Requirements revised before any code written — saving ~40 developer-hours of rework.
⚠️Exam Pitfalls
- Trick Q: "Prototyping is always throwaway." — No; evolutionary prototyping retains the prototype as the final product.
- Pitfall: Thinking prototyping replaces requirements analysis — it supplements it to clarify unclear requirements.
- Pitfall: Confusing horizontal and vertical — horizontal = all screens, no logic; vertical = one feature, full depth.
2.4
V Model (Verification & Validation)
💡Core Concept
The V Model extends Waterfall so that each development phase on the left has a corresponding testing phase on the right, forming a "V" — testing is planned concurrently with development, not after it.
📖Key Terminology
- Verification Static checking — "Are we building the product right?" (reviews, inspections).
- Validation Dynamic testing — "Are we building the right product?" (running tests).
- Unit Testing Tests individual modules; planned during detailed design.
- Integration Testing Tests component interfaces; planned during architectural design.
- System Testing Tests the whole system; planned during requirements phase.
- UAT User Acceptance Testing — validates against user requirements.
⚙️V-Model Structure
Requirements Analysis ←──────────→ Acceptance Testing
System Design ←──────────→ System Testing
Arch. Design ←──────────→ Integration Testing
Detailed Design ←──────────→ Unit Testing
↓
Implementation (coding)
- Requirements → Acceptance Test Plan written simultaneously.
- System Design → System Test Plan written simultaneously.
- Architectural Design → Integration Test Plan written simultaneously.
- Detailed Design → Unit Test Cases written simultaneously.
- Coding at the bottom of the V.
- Ascend right side: Unit → Integration → System → Acceptance testing.
⚖️Pros and Cons
- Test planning starts early — defects found sooner
- Clear traceability from requirements to tests
- Well-suited for safety-critical systems
- Still inflexible to requirement changes
- No working software during development
- Not suitable for iterative or complex projects
🔍Example
Medical device software
FDA-regulated infusion pump firmware: the system design specifies "deliver 0.1 mL doses with ±2% accuracy" and the corresponding system test verifies this before regulatory submission. Each design spec has a paired verification protocol.
⚠️Exam Pitfalls
- Most common mistake: Confusing Verification and Validation — Verification = reviews/static analysis (no code runs); Validation = executing tests against the actual running system.
- Trick Q: "V Model has more testing than Waterfall." — Not necessarily more tests, but testing is planned earlier and mapped to each phase.
- Pitfall: Unit testing is at the bottom of the V (closest to coding), not at the top.
2.5
Spiral Model
💡Core Concept
The Spiral model (Boehm, 1988) combines iterative development with systematic risk management — the project spirals outward through repeated cycles, each involving planning, risk analysis, engineering, and customer evaluation.
📖Key Terminology
- Spiral Loop One complete cycle through the four quadrants.
- Risk Analysis Identifying and mitigating risks before committing to the next loop.
- Risk-Driven The model's primary driver — each decision guided by risk reduction.
- Radial Axis Represents cumulative cost as the spiral moves outward.
- Angular Axis Represents progress through each loop.
⚙️Four Quadrants per Loop
- Planning (Q1) — Determine objectives, alternatives, and constraints for this loop.
- Risk Analysis (Q2) — Identify and evaluate risks; build prototypes to reduce uncertainty.
- Engineering (Q3) — Develop and test the product for this spiral.
- Customer Evaluation (Q4) — Review with customer; plan next spiral if needed.
⚖️Pros and Cons
- Best risk management of all models
- Suitable for large, complex, high-risk projects
- Combines prototyping with systematic development
- Flexible to requirement changes
- Expensive — risk analysis requires expertise
- Complex to manage; unsuitable for small projects
- Difficult to determine when to stop spiralling
🔍Example
Defence systems (US DoD STARS programme)
Loop 1 prototyped the UI to validate usability. Loop 2 prototyped the database schema. Loop 3 prototyped network integration. Full development only began after all major risks were retired.
⚠️Exam Pitfalls
- Trick Q: "Spiral model is best for all projects." — No; it is best for large, high-risk, long-duration projects.
- Most common mistake: Listing Spiral phases as "Plan, Design, Code, Test." — Correct quadrants: Planning, Risk Analysis, Engineering, Customer Evaluation.
- Pitfall: Spiral ≠ Iterative model — Spiral's defining feature is risk analysis in every loop.
2.6
Rapid Application Development (RAD) Model
💡Core Concept
RAD is a high-speed adaptation of the Waterfall model that uses component-based construction and parallel teams to compress the development cycle — delivering a working system in 60–90 days.
📖Key Terminology
- CBSE Component-Based Software Engineering — assembling systems from reusable components.
- Parallel Teams Multiple independent teams working on different modules simultaneously.
- Time-boxing Fixed, short deadlines (e.g., 60–90 days) for delivery.
- JAD Sessions Joint Application Development workshops — intensive sessions compressing requirements gathering.
- CASE Tools Computer-Aided Software Engineering tools (code generators, UI builders).
⚙️RAD Phases
Business Modelling
→
Data Modelling
→
Process Modelling
→
App Generation
→
Testing & Turnover
- Business Modelling — Define the business information flow.
- Data Modelling — Identify data objects and relationships (ER modelling).
- Process Modelling — Transform data objects according to business functions.
- Application Generation — Build components using CASE tools; reuse existing components.
- Testing & Turnover — Test new components; pre-tested reused components reduce effort.
⚖️Pros and Cons
- Very fast delivery (60–90 days)
- Reuse reduces development effort
- Encourages customer involvement
- Requires large, skilled team
- Not suitable for non-modularisable systems
- Unsuitable for high technical risk projects
🔍Example
Payroll management system
Team A builds the employee module, Team B builds salary calculation, Team C builds reporting — all in parallel using pre-built payroll component libraries. Integration in the final 2 weeks. Total: 60 days vs. 6 months sequential.
⚠️Exam Pitfalls
- Trick Q: "RAD is always faster than Waterfall." — Only when requirements are well understood, components exist, and a large skilled team is available.
- Pitfall: Confusing RAD with Agile — RAD uses parallel teams and CASE tools for speed; Agile uses iterative sprints for adaptability.
- Exam fact: RAD is only feasible for modularisable systems. Monolithic systems cannot benefit from parallel development.
2.7
Agile Model
💡Core Concept
Agile is an iterative, incremental, people-centred approach that prioritises working software over documentation, customer collaboration over contract negotiation, and responding to change over following a fixed plan.
📖Key Terminology
- Agile Manifesto 4 values and 12 principles published in 2001 defining the Agile philosophy.
- Sprint / Iteration A fixed-duration cycle (1–4 weeks) producing a potentially shippable increment.
- User Story A requirement from the user's perspective: "As a [user], I want [feature], so that [benefit]."
- Product Backlog A prioritised list of all desired features.
- Scrum Most popular Agile framework — uses sprints, stand-ups, and retrospectives.
- XP Extreme Programming — emphasises TDD, pair programming, and continuous integration.
- Velocity Amount of work a team completes per sprint.
⚙️Scrum Process
- Product Backlog — Product Owner lists and prioritises all features as user stories.
- Sprint Planning — Team selects backlog items for the upcoming sprint (1–4 weeks).
- Daily Scrum (15 min stand-up) — What did I do? What will I do? Any blockers?
- Sprint Review — Demo the increment to stakeholders; gather feedback.
- Sprint Retrospective — Team reflects: what went well, what to improve.
- Repeat from step 2 until the product is complete or project ends.
⚖️Pros and Cons
- Handles changing requirements gracefully
- Frequent delivery of working software
- High customer satisfaction and involvement
- Early defect detection via continuous testing
- Hard to predict total cost and timeline
- Requires experienced, self-organising team
- Minimal documentation can cause issues
- Scope creep risk if backlog not managed
🔍Example
Spotify's Agile model
Organised into Squads (small Scrum teams), Tribes, Chapters, and Guilds. Each Squad owns a feature area, runs 2-week sprints, and deploys independently — enabling 10–15 production deployments per day.
⚠️Exam Pitfalls
- Most common mistake: "Agile means no documentation." — The Manifesto says "working software over comprehensive documentation" — documentation still exists, just not excessive.
- Trick Q: "Scrum and Agile are the same." — Agile is a philosophy; Scrum is a framework that implements Agile principles.
- Pitfall: Listing only Scrum as an Agile framework — XP, Kanban, SAFe, Crystal are also Agile frameworks.
- Must-know: The 4 Agile Manifesto values: (1) Individuals & interactions over processes & tools; (2) Working software over comprehensive documentation; (3) Customer collaboration over contract negotiation; (4) Responding to change over following a plan.