Welcome to Alternative Development Approaches!
In your AS 1 studies, you have already encountered the traditional Systems Development Life Cycle (SDLC), often called the Waterfall model. But what happens if a client does not know exactly what they want? Or what if a business needs an app launched in six weeks instead of two years?
This is where alternative development approaches come in. In this chapter, we will explore flexible, user-centred ways of building digital systems: Prototyping, Rapid Application Development (RAD), and Agile Methodologies (including Extreme Programming). Don't worry if these terms sound technical right now—we will break each one down step-by-step!
Quick Syllabus Check: This topic makes up a core part of Unit AS 1: Approaches to Systems Development for CCEA Digital Technology 2650. In the exam, you will often be asked to compare these models or recommend the best approach for a given business scenario.
---1. The Baseline: The Traditional Waterfall Model
To understand why alternative approaches exist, we must first remind ourselves of the traditional approach.
The Waterfall model is a linear-sequential approach. Development flows downwards through distinct stages: Analysis \(\rightarrow\) Design \(\rightarrow\) Implementation (Coding) \(\rightarrow\) Testing \(\rightarrow\) Maintenance & Documentation.
Key Characteristics of Waterfall
• Rigid Stages: Each stage must be fully completed, reviewed, and signed off before the next stage starts.
• Heavy Documentation: Detailed specifications are written at the start and strictly followed.
• Late Working Software: The client does not see or use the software until very late in the lifecycle (during testing/delivery).
Strengths and Limitations of Waterfall
• Strengths: Clear project milestones, easy to manage for simple projects, works well when requirements are completely fixed and understood from day one.
• Limitations: Highly inflexible. If the client changes their mind halfway through, going back to change the design is extremely costly, time-consuming, and difficult.
Everyday Analogy: Think of Waterfall like building a bridge. You must fully calculate and design every single pillar before pouring concrete. You cannot decide halfway through construction that you want the bridge to go to a different island!
Key Takeaway: Waterfall works best when requirements are fixed, clear, and unlikely to change. For fast-paced, modern software projects where requirements change rapidly, we need alternatives.
---2. Approach 1: Prototyping
Prototyping is an iterative approach where developers create an early, simplified, working model of a system (or part of a system) to demonstrate concepts, clarify user needs, and gather rapid feedback.
Why Build a Prototype?
Instead of reading a 100-page written specification, users can click buttons, view screen layouts, and test basic workflows. This makes it much easier for non-technical clients to say, "Yes, that is exactly what I mean" or "No, that button is in the wrong place."
The Two Main Types of Prototyping
1. Evolutionary Prototyping
• The prototype is not thrown away. Instead, it is continuously refined, modified, and expanded stage by stage.
• It eventually grows into the finished, fully working end product.
• Advantage: Work already completed becomes the foundation of the final system.
2. Throwaway (Rapid) Prototyping
• A quick mock-up is constructed purely to test an idea, explore an interface, or clarify ambiguous requirements.
• Once the requirements are clearly understood and agreed upon, the prototype is discarded.
• The actual system is then built from scratch using clean, robust code.
• Advantage: Developers do not carry messy, experimental code into the final system.
Advantages and Disadvantages of Prototyping
• Advantages:
1. Early requirement discovery: Misunderstandings are spotted before expensive coding begins.
2. Active user involvement: Users feel ownership of the system, leading to higher client satisfaction.
3. Reduced risk: Reduces the chance of delivering software that fails to solve the client's problem.
• Disadvantages & Risks:
1. Scope Creep: Because it is easy to suggest changes, clients may constantly request "just one more feature," causing delays and budget overruns.
2. False Expectations: Users might see a working visual interface and assume the entire backend database and security systems are finished.
3. Poor Quality Code: If an unoptimised throwaway prototype is kept and rushed into production, the resulting system can be poorly structured and hard to maintain.
Common Exam Mistake to Avoid: Never say that prototyping is a type of final system testing! Prototyping happens early in the development lifecycle to gather requirements and refine the design.
Key Takeaway: Prototyping puts working models in front of users early. It can be evolutionary (kept and refined) or throwaway (used for clarification and discarded).
---3. Approach 2: Rapid Application Development (RAD)
Rapid Application Development (RAD) is an agile-aligned methodology designed to produce systems much faster than traditional methods by prioritising rapid prototyping, iterative development, and reusable components over lengthy upfront documentation.
Key Features of RAD
• CASE Tools & Code Generators: RAD relies heavily on Computer-Aided Software Engineering (CASE) tools, visual drag-and-drop programming environments, and automated code generators to build screens and databases rapidly.
• Pre-built Modules / Reusable Components: Instead of writing every line of code from scratch, developers assemble existing, pre-tested software building blocks (e.g., standard login systems, payment gateways, search bars).
• Joint Application Design (JAD) Sessions: Intensive, structured workshops where business stakeholders, end-users, and developers collaborate closely in the same room to design and refine system features.
• Timeboxing: The overall project is split into strict, fixed time periods (e.g., 30, 60, or 90 days). The development team focuses on delivering a working module by the end of that fixed time window. If time runs out, features are postponed rather than pushing back the deadline.
When Should a Business Choose RAD?
• When there is an urgent need to get the software to market quickly (fast time-to-market).
• When the system can be split into independent, modular chunks.
• When reusable components and CASE tools are readily available.
• When users and clients are willing and available to attend frequent workshops.
Memory Aid for RAD: Think of C-A-S-T:
• CASE tools & Code generators
• Active user collaboration (JAD workshops)
• Shared / Reusable components
• Timeboxing
Key Takeaway: RAD is built for speed. It uses CASE tools, reusable modules, JAD workshops, and timeboxing to deliver working systems quickly.
---4. Approach 3: Agile Methodologies & Extreme Programming (XP)
Agile is an umbrella term for iterative and incremental development approaches. Rather than delivering one giant system at the very end of a multi-year project, Agile teams deliver small, fully working software updates in short cycles called sprints or iterations (typically lasting 1 to 4 weeks).
The Core Principles of Agile
• Frequent Delivery: Working software is released regularly (in weeks rather than months).
• Collaboration Over Documentation: Daily, close communication between developers and business stakeholders takes priority over writing heavy manuals.
• Embracing Change: Changing requirements are welcomed, even late in development, to ensure the product remains competitive and useful.
Extreme Programming (XP)
Extreme Programming (XP) is a specific Agile methodology that takes beneficial software engineering practices to "extreme" levels. The CCEA specification highlights four key XP practices:
1. Pair Programming
• Two developers work together at a single workstation.
• One developer (the Driver) writes the code.
• The second developer (the Navigator) reviews each line in real time, checks for logic errors, and thinks ahead.
• Benefit: Produces higher-quality code with fewer bugs and spreads knowledge across the team.
2. Test-Driven Development (TDD)
• Automated unit tests are written before the actual program code is written.
• Initially, the test will fail because no code exists yet.
• The developer then writes the minimal code necessary to pass the test.
• Benefit: Ensures all code is thoroughly tested from the ground up and prevents bugs from slipping in unnoticed.
3. Continuous Integration
• Developers do not keep code on their personal computers for weeks. Instead, new code is merged into the main project build multiple times a day.
• Automated tests run immediately upon merging.
• Benefit: Detects integration clashes and errors immediately rather than causing a massive bottleneck at the end of the project.
4. Refactoring
• Restructuring and cleaning up existing code without altering what the program actually does externally.
• Benefit: Removes duplicate code, improves readability, and makes the system easier to maintain and extend in the future.
Key Takeaway: Agile delivers software iteratively in short sprints. Extreme Programming (XP) uses specific quality practices: Pair Programming, Test-Driven Development, Continuous Integration, and Refactoring.
---5. Comparing Approaches: How to Answer Scenario Questions
In your CCEA AS 1 exam, you will frequently be given a scenario (for example, a local hospital booking system, an e-commerce startup, or a banking upgrade) and asked to justify which development approach should be used.
Decision Matrix for the Exam
Choose Waterfall if:
• The requirements are clear, fully understood, and fixed from the start.
• The system is large, safety-critical, or requires extensive formal documentation (e.g., medical device firmware or aviation systems).
• The client has limited time for ongoing weekly meetings.
Choose Prototyping if:
• The client is unsure of what they want, or has difficulty explaining their needs.
• The user interface (UI) and user experience (UX) are crucial and need visual testing.
• Users are available to provide regular feedback on early models.
Choose RAD if:
• The business has a tight deadline and needs a working solution quickly.
• Pre-built components and CASE tools can be utilised.
• The system can be broken down into modular components within fixed timeboxes.
Choose Agile / XP if:
• The business operates in a rapidly changing market where requirements will evolve.
• High code quality and low defect rates are essential (using TDD and Pair Programming).
• Developers and clients can collaborate closely on a daily or weekly basis.
6. Common Exam Pitfalls to Avoid
• Pitfall 1: Giving generic definitions. If an exam question asks about Agile, do not just write "it makes software fast." Mention short iterative sprints, frequent working software releases, and continuous user collaboration.
• Pitfall 2: Forgetting to apply your answer to the scenario. Always link your points back to the case study! If the case study mentions an online retail shop needing a launch before Christmas, explicitly explain how RAD's timeboxing or Agile's sprints meet that strict deadline.
• Pitfall 3: Assuming all prototypes are thrown away. Remember to mention Evolutionary Prototyping, where the prototype is progressively developed into the final release.
7. Quick Review Summary
• Waterfall: Linear-sequential, stage-by-stage, sign-off at each step, best for fixed requirements.
• Evolutionary Prototype: Continuously refined to become the final system.
• Throwaway Prototype: Built quickly to explore/clarify needs, then discarded.
• RAD: Fast development using CASE tools, reusable modules, JAD sessions, and timeboxing.
• Agile: Iterative development in short cycles, welcoming change, delivering frequent working software.
• XP Practices: Pair Programming (two coders, one desk), TDD (tests written first), Continuous Integration (frequent merges), Refactoring (code cleanup).