Extended Waterfall Model

This article is a conceptual explanation of the extended waterfall model – including exam questions, core components, and tags.

In a Nutshell

The extended waterfall model retains the clear phases of the classic waterfall, but supplements them with controlled feedback loops between adjacent phases and early prototypes. This allows errors to be detected earlier and risks to be reduced in a targeted manner.

Concise Technical Description

In the extended waterfall, phases continue to run sequentially (requirements → design → implementation → testing → deployment/maintenance), but:

• There are defined feedback jumps to the previous phase if acceptance criteria are not met.
• Test planning and QA are prepared in parallel (e.g., test concept already in analysis/design).
• Prototypes (UI or architecture spikes) are deployed early to validate unclear requirements or technical risks.

Important terms:

• Verification: “Are we building the product right?” (against specification)
• Validation: “Are we building the right product?” (against business purpose)

Also important: baselines, change requests, impact analysis, and traceability from requirements to tests.

Exam-Relevant Key Points

• Sequential phases with controlled feedback loops
• Integrate test planning early (acceptance criteria already in analysis)
• Verification/validation per phase (reviews, walkthroughs)
• Gate decisions with acceptance criteria (IHK)
• Prototyping for risk reduction
• Traceability (requirement → design → code → test)
• Change management + baselines

Core Components

1. Requirements phase (requirements documents, acceptance criteria)
2. System design (context, interfaces, data model)
3. Architecture design (quality goals, decisions, prototypes)
4. Module design (detailed design, interface contracts)
5. Implementation (reviews, static analysis)
6. Test preparation (test concept, test cases, test data)
7. Test execution (unit/integration/system/acceptance)
8. Deployment (migration, operations, documentation)
9. Feedback loops (approved feedback jumps)
10. Configuration/change management (versioning)

Simple Practical Example

Customer portal with external payment interface

Requirements:
- User stories + acceptance criteria
- Business acceptance

System/Architecture design:
- Context diagram + interface contract
- Architecture spike (token handling)
- Gate: architecture release after security review

Implementation + Testing:
- Coding + code review
- Integration test against payment sandbox
- Error -> feedback jump to module design (timeout/retry)
- retest + acceptance + go live

Advantages and Disadvantages

Advantages

• Clear planning and responsibilities
• Earlier error detection (reviews/prototypes)
• Fewer costly late changes
• Good audit trail (audit/IHK)

Disadvantages

• Feedback jumps create coordination overhead
• Higher lead time (specification/test planning)
• Less flexible than highly iterative models

Typical Exam Questions (with Short Answers)

1. Difference between classic vs. extended waterfall? Extended = defined feedback jumps + early QA/prototypes.
2. Role of prototypes? Validate risks early (performance, security, UX).
3. Verification vs. validation? Verification against specification, validation against purpose/benefit.
4. How do you control feedback jumps? Gate decision, impact analysis, change request, retest acceptance.

Learning Strategy

1. Draw phases with artifacts + acceptance criteria.
2. Document feedback jump scenario (integration test → module design).
3. Practice brief comparison of waterfall vs. V-model vs. spiral.
4. Create traceability table (requirement → test case).

Most Important Sources

1. https://en.wikipedia.org/wiki/Waterfall_model
2. https://dl.acm.org/doi/10.1145/360248.360251