Question 5 of 25: Agile Methods — Interest and Dangers
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, May 2014. 3 hours, open book, no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any three (3) questions in Part I, any four (4) in Part II, any three (3) in Part III, any one (1) in Part IV, and any one (1) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 12 questions actually marked (3+4+3+1+1 of 25) each count for 100/12 ≈ 8.3% of the paper. All 25 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — structural/behavioural pattern catalogue (Proxy, Bridge, Strategy, Observer, Template Method, Composite, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics (also underpins the Java/C++ discussion in Part V). Bertrand Meyer's Object-Oriented Software Construction is cited by name where the paper's own vocabulary (design by contract, open–closed principle) originates there; Barbara Liskov's 1987 substitutability paper is likewise cited by name for Question 11.
PART I — General Principles (answer any 3 of 5)
Question 5: Agile Methods — Interest and Dangers (Part I)
Business environments change requirements faster than they can be fully specified up front, and heavyweight upfront specification (classical Waterfall) commits to a detailed requirements document that is frequently obsolete before the system is delivered. Agile methods respond by embracing change: short iterations (typically 1–4 weeks) deliver working, demonstrable software early and often, so real user feedback corrects course long before the full budget is spent building the wrong thing. This reduces the single biggest risk in software projects — building a functionally correct system nobody actually wants — and shortens time-to-market for the highest-value features by prioritizing the backlog continuously rather than committing to a fixed scope at project start.
Dangers
Scaling and coordination. Agile's close, continuous customer collaboration and light documentation assume a small, co-located (or tightly synchronized) team; scaling to large, distributed teams, or to systems requiring formal certification traceability (safety-critical, medical, aviation — directly relevant to EGBC-regulated engineering work), is far harder and usually needs additional scaffolding (SAFe, disciplined architecture ownership) not present in the base method.
Architectural erosion. Without deliberate architectural discipline, rapid feature-by-feature delivery can accumulate technical debt — each sprint optimizes for the current increment, and no phase is explicitly reserved for holistic architecture review, unless the team enforces one itself.
Customer availability dependency. The method assumes a real, continuously available customer representative to clarify requirements each iteration; in fixed-price/contract development this role is often unrealistic, and its absence degrades agile back toward guesswork.
Predictability. Fixed-scope, fixed-price contracts sit uneasily with agile's variable-scope philosophy, since neither total cost nor delivery date is committed up front in the same way a Waterfall plan claims to commit them (even though that Waterfall commitment is itself frequently unreliable in practice).
