1.2.3 Software Development Methodologies
Choosing the right approach to developing software is crucial for project success. Different methodologies suit different types of projects, teams, and requirements.
Definition
Software development methodology is a structured approach to planning, creating, testing, and deploying software. It defines the processes, activities, and deliverables involved in software development.
1.2.3(a) Development Methodologies
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
1.2.3(b) Merits and Drawbacks
Waterfall
Pros & Cons
Pros & Cons:
Best when: Requirements are fixed and well-understood, safety-critical systems
| Advantages | Disadvantages |
|---|---|
| Clear structure and milestones | Inflexible - hard to change requirements later |
| Easy to understand and manage | No working software until late in process |
| Comprehensive documentation | High risk if requirements misunderstood |
| Works well for fixed-requirement projects | Poor for complex or innovative projects |
Agile
Pros & Cons
Pros & Cons:
Best when: Requirements likely to change, innovative projects, customer available
| Advantages | Disadvantages |
|---|---|
| Flexible - welcomes changing requirements | Less predictable timeline and cost |
| Working software delivered frequently | Requires high customer involvement |
| Close customer collaboration | Can lead to scope creep |
| Quick response to feedback | Documentation may be insufficient |
Extreme Programming
Pros & Cons
Pros & Cons:
Best when: Small expert teams, quality-critical projects, volatile requirements
| Advantages | Disadvantages |
|---|---|
| High code quality through practices like TDD | Requires experienced developers |
| Continuous feedback and improvement | Pair programming costly (two salaries) |
| Knowledge sharing through pair programming | Customer must be on-site |
| Low defect rates | Difficult to scale to large teams |
Spiral
Pros & Cons
Pros & Cons:
Best when: Large, complex, high-risk projects (banking, defence)
| Advantages | Disadvantages |
|---|---|
| Systematic risk management | Complex to manage |
| Early detection of problems | Expensive - extensive planning and risk analysis |
| Flexible - can accommodate changes | Not suitable for small projects |
| Suitable for large, complex projects | Requires expertise in risk assessment |
RAD
Pros & Cons
Pros & Cons:
Best when: Tight deadlines, available users, modular architecture, clear scope
| Advantages | Disadvantages |
|---|---|
| Very fast delivery | Requires modularity |
| High user satisfaction through involvement | Heavy dependence on user availability |
| Reduces requirements errors | Not suitable for complex, low-modularity systems |
| Efficient for well-understood problems | May sacrifice quality for speed |
1.2.3(c) Writing and Following Algorithms
An algorithm is a step-by-step procedure for solving a problem or accomplishing a task. Understanding how to write and follow algorithms is fundamental to programming.
Definition
An algorithm is a finite sequence of well-defined, computer-implementable instructions to solve a class of problems or perform a computation.
Key Point
Algorithm Characteristics:
• Finite - Must terminate after a finite number of steps
• Definite - Each step must be precisely defined
• Input - Zero or more inputs
• Output - One or more outputs
• Effective - Operations must be basic enough to be carried out exactly
• Finite - Must terminate after a finite number of steps
• Definite - Each step must be precisely defined
• Input - Zero or more inputs
• Output - One or more outputs
• Effective - Operations must be basic enough to be carried out exactly
Representing Algorithms
Algorithms can be expressed in several ways before being coded:
Key Point
Pseudocode - Structured English-like language for describing algorithms
• Easy to write and understand
• Language-independent
• Focuses on logic, not syntax
Flowcharts - Visual representation using standard symbols
• Diamond = decision
• Rectangle = process
• Oval = start/end
• Arrow = flow direction
Structured English - Simple English statements using indentation
• Easy to write and understand
• Language-independent
• Focuses on logic, not syntax
Flowcharts - Visual representation using standard symbols
• Diamond = decision
• Rectangle = process
• Oval = start/end
• Arrow = flow direction
Structured English - Simple English statements using indentation
Exam Tip
Algorithm Tracing Tips:
• Create a table with columns for each variable
• Work through step-by-step, updating values
• Be careful with loop conditions - check before entering
• Watch for off-by-one errors in array indexing
• If stuck, use small, simple test data
• Verify your trace makes logical sense
• Create a table with columns for each variable
• Work through step-by-step, updating values
• Be careful with loop conditions - check before entering
• Watch for off-by-one errors in array indexing
• If stuck, use small, simple test data
• Verify your trace makes logical sense