# Comparing Software Development Models ## Overview - You need to be able to **compare software development models** and **recommend a model for a given scenario** - Understanding the strengths and weaknesses of each methodology allows you to make informed decisions about which approach suits different project contexts

When comparing models, consider the project's size, stability of requirements, team experience, and need for customer involvement

## Summary Comparison Table - The table below captures the key features, advantages, limitations, and ideal use cases for each development methodology | **Method** | **Tasks and Processes** | **Benefits** | **Drawbacks** | **Suitability** | |------------|------------------------|--------------|---------------|-----------------| | **Waterfall Lifecycle** | Linear stages: Requirements, Design, Coding, Testing, Deployment, Maintenance | Simple, clear stages, well-defined projects | Inflexible, expensive late changes, long development cycle | Well-defined projects with stable requirements | | **Agile (XP)** | Iterative: Planning, Designing, Coding, Testing, Reviewing | Flexible, constant customer involvement, rapid delivery | Scope creep, collaboration dependency, not for large projects | Fast-paced projects with changing requirements | | **Spiral Model** | Cyclic: Planning, Risk Analysis, Engineering, Evaluation | Risk management focus, tailored customer feedback | Complex, expensive, expert risk assessment required | Complex projects needing extensive risk management | | **Rapid Application Development (RAD)** | Phases: Requirements Planning, User Design, Construction, Cutover | Faster development, user feedback, adaptable | Collaboration dependence, less scalable, quality issues | Projects requiring quick delivery with active user participation | ## Key Comparison Factors ### Flexibility vs Structure - **Waterfall**: Rigid sequential structure with minimal flexibility once a phase is complete - **Agile/XP**: Highly flexible with short iterations allowing frequent adjustments - **Spiral**: Moderate flexibility with planned iteration points after each cycle - **RAD**: High flexibility focused on rapid prototyping and user feedback

Flexibility refers to how easily a methodology can accommodate changing requirements during development

### Customer Involvement - **Waterfall**: Minimal involvement after initial requirements gathering - **Agile/XP**: Continuous involvement throughout every sprint - **Spiral**: Regular involvement at evaluation stages of each spiral - **RAD**: Intensive involvement during prototyping and user design phases ### Project Size Suitability - **Waterfall**: Best for medium to large projects with clear requirements - **Agile/XP**: Ideal for small to medium projects - **Spiral**: Suited for large, complex projects - **RAD**: Works well for small to medium projects needing rapid delivery ### Risk Management - **Waterfall**: Limited risk assessment, mainly during initial planning - **Agile/XP**: Continuous risk mitigation through regular testing and feedback - **Spiral**: Explicit risk analysis phase in each cycle, making it the strongest for risk management - **RAD**: Moderate risk management through iterative prototyping

Choosing a methodology with insufficient risk management for a high-risk project can lead to costly failures late in development

### Development Speed - **Waterfall**: Typically slower due to sequential nature - **Agile/XP**: Fast delivery of working increments - **Spiral**: Can be time-consuming due to thorough planning and risk analysis - **RAD**: Fastest delivery through prototyping and parallel development ### Documentation Requirements - **Waterfall**: Extensive documentation at each phase - **Agile/XP**: Minimal documentation, focus on working software - **Spiral**: Moderate to extensive documentation - **RAD**: Limited documentation, emphasis on rapid development ## Choosing the Right Methodology ### Consider these questions: 1. **Are requirements clear and stable?** - If yes → Waterfall may be appropriate - If no → Consider Agile, Spiral, or RAD 2. **How much customer availability do you have?** - High availability → Agile or RAD - Limited availability → Waterfall or Spiral 3. **What is the project's risk level?** - High risk → Spiral Model - Moderate risk → Agile or RAD - Low risk → Waterfall 4. **How experienced is your development team?** - Highly experienced → Agile or RAD work well - Mixed experience → Waterfall provides more structure - Need risk specialists → Spiral Model 5. **What are the time constraints?** - Urgent delivery → RAD or Agile - Flexible timeline → Waterfall or Spiral

Multiple factors interact when selecting a methodology—a project may need rapid delivery (favouring RAD) but also have high risk (favouring Spiral)

## Common Scenarios ### Scenario 1: Banking System Upgrade - **Requirements**: Well-defined, security-critical, high compliance needs - **Best choice**: Waterfall or Spiral - **Reasoning**: Clear requirements and need for thorough testing and documentation favor a more structured approach; if risks are high, Spiral provides better risk management ### Scenario 2: Mobile App for Startup - **Requirements**: Evolving, need for market feedback, limited budget - **Best choice**: Agile or RAD - **Reasoning**: Rapidly changing market conditions and need for user feedback make iterative approaches essential; RAD if speed is critical, Agile for sustained development ### Scenario 3: Medical Device Software - **Requirements**: Safety-critical, regulatory approval needed, high risk - **Best choice**: Spiral Model - **Reasoning**: Explicit risk analysis phases and iterative refinement suit the high-stakes nature and regulatory requirements ### Scenario 4: E-commerce Website Feature - **Requirements**: Adding new functionality to existing system, tight deadline - **Best choice**: RAD or Agile - **Reasoning**: Building on existing infrastructure with need for rapid deployment suggests RAD; if requirements may evolve, Agile provides more flexibility ## Worked Example Analysis ### Question: A software team is adding a new feature to their duplicate file detection software. Some team members suggest extreme programming, while others prefer waterfall. Discuss both methodologies and justify your recommendation. ### Answer Structure: 1. **Introduce both methodologies** - XP: Iterative, flexible approach with continuous feedback - Waterfall: Sequential, structured approach with distinct phases 2. **Compare and contrast** - **Similarities**: Both have testing phases, both aim to deliver working software - **Differences**: XP allows ongoing changes vs. Waterfall's fixed stages; XP emphasizes collaboration vs. Waterfall's documentation 3. **Apply to scenario** - Project context: Adding new feature to existing software - Team composition: Multiple team members available for collaboration - Nature of work: Enhancement rather than entirely new system 4. **Make recommendation with justification** - **Recommended**: Extreme Programming - **Key reasons**: - Flexibility to discover best implementation approach while developing - Ability to quickly adapt if issues are found in existing software - Team can collaborate effectively on integration challenges - Continuous testing ensures new feature doesn't break existing functionality

Think like a building contractor choosing between renovation strategies: fixing up a house room-by-room with flexibility (Agile) vs. planning everything upfront (Waterfall)

### Model Answer Extract: - XP provides the flexibility to keep adjusting things during the project, which is valuable when adding features where the team might discover better implementation approaches - The Waterfall model's strict sequential structure could create difficulties if problems in the existing software are discovered during feature development - Given the need for ongoing improvements and potential feedback loops, XP's iterative approach aligns better with the project requirements - XP allows the team to remain flexible and continuously aligned with user needs, whereas Waterfall's inflexibility could hinder necessary adjustments ## Comparison in Practice ### Example: Building an Online Library System | **Aspect** | **Using Waterfall** | **Using Agile** | **Using Spiral** | **Using RAD** | |------------|---------------------|-----------------|------------------|---------------| | **Timeline** | 12 months sequential | 6 sprints of 2 weeks each | 4 spirals over 10 months | 3 months with prototypes | | **Requirements changes** | Difficult and costly | Expected and manageable | Planned at cycle transitions | Incorporated through user design | | **Testing approach** | At end after integration | Continuous throughout | At each spiral evaluation | During each prototype iteration | | **User feedback** | After full deployment | End of each sprint | After each spiral cycle | Continuously during prototyping | | **Documentation** | Comprehensive upfront | Minimal, evolving | Moderate, per cycle | Limited, focused on essentials | ### Real-world insight: - Think of Waterfall like planning a holiday completely before booking anything—efficient if you know exactly what you want, but inflexible if circumstances change - Agile is like planning a road trip where you decide the next destination based on what you enjoyed most recently - Spiral is like a pilot program where you test a small version, assess what could go wrong, then expand gradually - RAD is like speed-dating for software—quickly prototype ideas, get immediate feedback, iterate rapidly ## Common Exam Approaches ### When asked to recommend a methodology: 1. **Identify key scenario characteristics** - Project size and complexity - Clarity of requirements - Customer availability - Risk level - Time constraints 2. **Eliminate unsuitable options** - Cross out methodologies that clearly don't fit - Example: Don't suggest Waterfall if requirements are explicitly changing 3. **Compare remaining options** - Weigh pros and cons in context - Consider trade-offs 4. **Justify your choice** - Explain why chosen method's strengths match scenario needs - Acknowledge potential drawbacks and explain why they're acceptable

Don't just list features of methodologies—always connect your points back to the specific scenario given

## Hybrid Approaches ### Modern practice note: - Many organizations combine elements from multiple methodologies - Example: "Water-Scrum-Fall" uses Waterfall for planning/deployment but Agile for development - Spiral's risk analysis can be integrated into Agile sprints - RAD's prototyping can complement Waterfall's structured phases ### When to mention hybrids: - For high-mark questions asking for nuanced discussion - When scenario has conflicting requirements (e.g., needs both speed and comprehensive documentation) - To demonstrate deeper understanding beyond basic methodology knowledge