Waterfall Model
The Waterfall model is a linear, sequential approach where each phase must be completed before the next begins. Like a waterfall flowing down, progress moves in one direction.
Definition
The Waterfall model is a sequential design process where development flows steadily downwards through distinct phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance.
Key Point
Waterfall Phases (in order):
1. Requirements - Document all system requirements
2. Design - Create system architecture and detailed designs
3. Implementation - Write the actual code
4. Testing - Verify the system works correctly
5. Deployment - Release to users
6. Maintenance - Fix bugs and make updates
• Each phase has specific deliverables
• No overlapping between phases
• Changes are difficult once a phase is complete
1. Requirements - Document all system requirements
2. Design - Create system architecture and detailed designs
3. Implementation - Write the actual code
4. Testing - Verify the system works correctly
5. Deployment - Release to users
6. Maintenance - Fix bugs and make updates
• Each phase has specific deliverables
• No overlapping between phases
• Changes are difficult once a phase is complete
Example
When to use Waterfall:
• Building a bridge control system (safety critical)
• Developing software for medical devices
• Projects with fixed, well-understood requirements
• Regulatory environments requiring extensive documentation
• Construction or manufacturing projects where design must be finalised before building
• Building a bridge control system (safety critical)
• Developing software for medical devices
• Projects with fixed, well-understood requirements
• Regulatory environments requiring extensive documentation
• Construction or manufacturing projects where design must be finalised before building
Agile Methodologies
Agile takes an iterative approach, delivering working software in small increments and adapting to changing requirements throughout development.
Definition
Agile is an iterative approach to software development that emphasises flexibility, collaboration, customer feedback, and rapid delivery of working software in short cycles called sprints (typically 2-4 weeks).
Key Point
Agile Principles:
• Iterative development - Build in small, manageable chunks
• Customer collaboration - Work closely with stakeholders throughout
• Responding to change - Welcome changing requirements, even late in development
• Working software - Deliver functional software frequently
• Self-organising teams - Teams decide how best to accomplish work
• Face-to-face conversation - Most effective form of communication
• Regular reflection and adjustment
• Iterative development - Build in small, manageable chunks
• Customer collaboration - Work closely with stakeholders throughout
• Responding to change - Welcome changing requirements, even late in development
• Working software - Deliver functional software frequently
• Self-organising teams - Teams decide how best to accomplish work
• Face-to-face conversation - Most effective form of communication
• Regular reflection and adjustment
Example
When to use Agile:
• Startup developing a new mobile app (requirements uncertain)
• E-commerce website needing frequent updates
• Projects where customer needs evolve during development
• Innovative products requiring experimentation
• Teams co-located and able to communicate frequently
• Startup developing a new mobile app (requirements uncertain)
• E-commerce website needing frequent updates
• Projects where customer needs evolve during development
• Innovative products requiring experimentation
• Teams co-located and able to communicate frequently
Extreme Programming (XP)
Extreme Programming takes agile principles to the extreme, emphasising technical excellence and close collaboration.
Definition
Extreme Programming (XP) is an agile methodology that emphasises customer satisfaction through continuous delivery of working software, pair programming, test-driven development, and frequent releases in short cycles.
Key Point
XP Practices:
• Pair Programming - Two programmers work together at one computer
• Test-Driven Development (TDD) - Write tests before writing code
• Continuous Integration - Integrate and test code multiple times daily
• Small Releases - Frequent small releases to get rapid feedback
• Simple Design - Keep designs as simple as possible
• Refactoring - Continuously improve code without changing behaviour
• Collective Code Ownership - Anyone can change any code
• On-site Customer - Customer is part of the team, always available
• 40-hour work weeks - sustainable pace
• Pair Programming - Two programmers work together at one computer
• Test-Driven Development (TDD) - Write tests before writing code
• Continuous Integration - Integrate and test code multiple times daily
• Small Releases - Frequent small releases to get rapid feedback
• Simple Design - Keep designs as simple as possible
• Refactoring - Continuously improve code without changing behaviour
• Collective Code Ownership - Anyone can change any code
• On-site Customer - Customer is part of the team, always available
• 40-hour work weeks - sustainable pace
Example
When to use XP:
• Small to medium development teams (2-12 people)
• Projects with vague or changing requirements
• High-risk projects where quality is critical
• Teams with experienced programmers
• Projects where rapid feedback is essential
• Small to medium development teams (2-12 people)
• Projects with vague or changing requirements
• High-risk projects where quality is critical
• Teams with experienced programmers
• Projects where rapid feedback is essential
Spiral Model
The Spiral model combines iterative development with systematic risk analysis, making it ideal for large, complex, or high-risk projects.
Definition
The Spiral model is a risk-driven development process that combines iterative development (prototyping) with systematic aspects of the waterfall model. Development spirals outward in cycles, with each cycle including planning, risk analysis, engineering, and evaluation.
Key Point
Spiral Quadrants (each cycle):
1. Determine objectives - Define goals and constraints for this cycle
2. Risk analysis - Identify and resolve risks
3. Development and testing - Build and verify the prototype/release
4. Planning - Plan the next iteration
• Each loop of the spiral represents a phase
• More complete version produced each cycle
• Risk analysis drives the process
• Can incorporate other methodologies within cycles
1. Determine objectives - Define goals and constraints for this cycle
2. Risk analysis - Identify and resolve risks
3. Development and testing - Build and verify the prototype/release
4. Planning - Plan the next iteration
• Each loop of the spiral represents a phase
• More complete version produced each cycle
• Risk analysis drives the process
• Can incorporate other methodologies within cycles
Example
When to use Spiral:
• Large, complex systems (banking, defence)
• Projects with significant technical risks
• Mission-critical applications where failure is costly
• Projects requiring extensive prototyping
• When risk assessment is a priority
• Development of new product lines
• Large, complex systems (banking, defence)
• Projects with significant technical risks
• Mission-critical applications where failure is costly
• Projects requiring extensive prototyping
• When risk assessment is a priority
• Development of new product lines
Rapid Application Development (RAD)
RAD prioritises rapid prototyping and quick feedback over lengthy requirements gathering, making it ideal for projects with tight deadlines and clear scope.
Definition
Rapid Application Development (RAD) is an approach that emphasises quick development through extensive user involvement, iterative prototyping, and reusing existing components rather than building from scratch.
Key Point
RAD Characteristics:
• User involvement - Users actively participate throughout
• Prototyping - Build working models quickly, refine based on feedback
• Iterative refinement - Continuous improvement based on user input
• Component reuse - Use existing libraries and frameworks
• Automated tools - CASE tools, code generators, visual development
• Parallel development - Multiple teams work on different modules
• Time-boxing - strict deadlines for each phase
• User involvement - Users actively participate throughout
• Prototyping - Build working models quickly, refine based on feedback
• Iterative refinement - Continuous improvement based on user input
• Component reuse - Use existing libraries and frameworks
• Automated tools - CASE tools, code generators, visual development
• Parallel development - Multiple teams work on different modules
• Time-boxing - strict deadlines for each phase
Example
When to use RAD:
• Projects with tight deadlines (3-6 months)
• Well-defined scope with clear user requirements
• User availability for frequent feedback sessions
• Projects using established technology (not bleeding-edge)
• Internal business applications
• Projects where component reuse is possible
• Projects with tight deadlines (3-6 months)
• Well-defined scope with clear user requirements
• User availability for frequent feedback sessions
• Projects using established technology (not bleeding-edge)
• Internal business applications
• Projects where component reuse is possible
Testing During Development
Every methodology includes testing, but at different points. The waterfall lifecycle tests in a single stage after the code has been written. Agile methodologies, extreme programming and RAD test in every iteration, so errors are found sooner.
| Type of testing | What it involves |
|---|---|
| Black box | Checking that given inputs produce the expected outputs, without looking at the code |
| White box | Checking each path through the code, carried out by someone who can see how it is written |
| Alpha | Testing carried out in-house by the development team before the software is released |
| Beta | Testing carried out by real users on a version given to them before the final release |