Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Waterfall vs. Iterative vs. Prototyping
Different routes to the same place
Think of planning a wedding. You can plan every detail up front and then carry out the plan (waterfall). You can do it in rounds, venue first, then food, then music, adjusting as you learn (iterative). Or you can book a tasting first so everyone discovers what they actually like before committing (prototyping).
Development models are these same choices, applied to building software. None is “best”; each fits a different situation, and each has typical control risks the exam likes to ask about.
Waterfall
The traditional SDLC. Feasibility, requirements, design, build, test and implementation run in sequence, and each phase is completed and approved before the next one starts.
- Good for: stable, well-understood requirements; regulated environments that need strong documentation and approvals.
- Weaknesses: users see the system only near the end; changing requirements late is costly; a mistake made in requirements may not surface until testing.
The V-model
A variation of waterfall that pairs each design step with the test that will later check it. Tests are planned early, while each step is being written.
Iterative and incremental
The system is built in repeated cycles. Each cycle delivers a usable piece, and requirements get refined as users see results. Agile methods grew out of this idea.
- Good for: getting early feedback, reducing the risk of building the wrong thing, delivering value sooner.
- Weaknesses: needs strong change and configuration control; without an overall design, the architecture can get messy.
Iterative doesn’t mean uncontrolled. Each iteration still needs approval and testing.
Spiral
An iterative model organised around risk. Every cycle goes through planning, risk analysis, engineering and evaluation. It suits large, complex, high-risk projects.
Prototyping
A working model is built quickly so users can see it and react. It’s great for turning “I’ll know it when I see it” into clear requirements. But prototypes are built fast and loose, which creates the risks the exam loves:
- controls, security and audit trails are left out
- the prototype is put into production without proper design, testing and documentation
- scope creep from constant feedback
- users expect the final system to arrive as fast as the prototype did
- weak change control
Example. A business team builds a prototype pricing tool on a low-code platform to agree requirements. Users like it, and it goes live a week later. It has no access roles, no audit trail of price changes and no backup. The auditor reports that the prototype bypassed the SDLC controls.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Approach suited to stable, well-defined requirements | Waterfall |
| Approach that clarifies unclear requirements with users | Prototyping |
| Greatest risk of prototyping | Controls overlooked; prototype put into production |
| Model driven by risk analysis in each cycle | Spiral |
| Main weakness of waterfall | Inflexible to changing requirements; users see it late |
In short
- Waterfall runs phases in sequence, each completed and approved before the next; best when requirements are stable and well understood.
- Iterative and incremental approaches deliver the system in pieces, refining requirements as they go.
- The spiral model is iterative and risk-driven, with risk analysis in each cycle.
- Prototyping builds a working model quickly to clarify requirements with users.
- The V-model pairs each development phase with a test level.
- Prototyping's main risks: controls get overlooked, the prototype becomes the final system, and scope expands.
Exam traps
- Waterfall's main weakness: requirements are fixed early, and changes are expensive later.
- Prototypes often lack security, controls and documentation; they shouldn't go to production as-is.
- In prototyping, users may expect the final system to arrive as fast as the prototype did.
- Iterative doesn't mean uncontrolled: each iteration still needs approval and testing.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Different routes to the same place
Think of planning a wedding. You can plan everything up front and execute the plan (waterfall). You can sort it out in rounds, venue first, then food, then music, adjusting as you go (iterative). Or you can do a tasting first so everyone knows what they actually like (prototyping).
Development models are these same choices, applied to building software.
The V-model