Software EngineeringUnit 416 min read
Software Dev Models & Methodologies: Waterfall, Agile, Spiral, V-Model, RAD, Prototyping
Unit 4 of Software Engineering explores the 6 core software development methodologies (Waterfall, Agile, Spiral, V-Model, RAD, Prototyping), their workflows, trade-offs, and real-world applications in Nepalese tech (eSewa, Daraz, Ncell). It covers when to use each model, risk management in iterative vs. sequential appr
Core Concepts: What is a Software Development Methodology?
A software development methodology is a structured framework that guides the planning, design, implementation, testing, and maintenance of software. It defines:
- Process flow (sequential vs. iterative)
- Roles & responsibilities (who does what)
- Deliverables (documents, code, tests)
- Tools & techniques (e.g., UML, Agile boards)
Why do we need methodologies? Without a methodology, projects risk:
- Scope creep (uncontrolled feature additions)
- Missed deadlines (no clear milestones)
- Poor quality (no systematic testing)
- Budget overruns (no cost estimation)
stateDiagram-v2
[*] --> MethodologyChoice: Start
MethodologyChoice --> Waterfall: Sequential, rigid
MethodologyChoice --> Agile: Iterative, flexible
MethodologyChoice --> Spiral: Risk-driven, iterative
MethodologyChoice --> VModel: Verification-focused
MethodologyChoice --> RAD: User-driven, fast
MethodologyChoice --> Prototyping: User feedback early
Waterfall --> Design --> Implementation --> Testing --> Maintenance
Agile --> Sprint1: 2-4 weeks
Sprint1 --> Review --> Sprint2
Spiral --> Plan --> RiskAnalysis --> Develop --> Evaluate
RAD --> JointApplicationDesign --> Prototyping --> Testing
Prototyping --> BuildPrototype --> UserFeedback --> Refine1. Waterfall Model: The Classic Sequential Approach
Definition: A linear, phase-based model where each phase must be completed before the next begins. Phases:
- Requirements
- Design
- Implementation
- Testing
- Deployment
- Maintenance
How It Works (Trace Example: NTC’s Online Payment System)
Assume NTC wants to build a system for online bill payments. Here’s how Waterfall applies:
| Phase | Activity | Deliverable | Example for NTC |
|---|---|---|---|
| Requirements | Gather user needs via surveys, interviews. | SRS Document | "Users must pay bills via Khalti/eSewa" |
| Design | Create system architecture (UI, database, APIs). | UML Diagrams | "Database stores user ID, bill ID, amount" |
| Implementation | Write code in phases (frontend, backend, integration). | Source Code | Python/Django backend for Khalti API |
| Testing | Unit, integration, system testing. | Test Reports | "Test 1000 transactions for errors" |
| Deployment | Release to production. | Live System | NTC website goes live |
| Maintenance | Fix bugs, add features. | Patch Notes | "Add QR code payment in 2025" |
Advantages
- Simple to understand and manage.
- Clear milestones (easy for stakeholders).
- Works well for small, well-defined projects (e.g., a bank’s loan calculator).
Disadvantages
- No going back: If requirements change mid-project, costly.
- Late testing: Bugs found only in the testing phase.
- Not flexible: Poor for dynamic environments (e.g., Daraz’s daily sales).
Phases of the Waterfall Model with arrows showing sequential flow (Image: Peter Kemp / Paul Smith, CC BY 3.0, via Wikimedia Commons)
2. Agile Methodology: Iterative and Flexible
Definition: A non-linear, iterative approach where work is divided into small sprints (2–4 weeks). Key principles (from the Agile Manifesto):
- Individuals and interactions > Processes and tools.
- Working software > Comprehensive documentation.
- Customer collaboration > Contract negotiation.
- Responding to change > Following a plan.
Core Practices in Agile
| Practice | Description | Example in Pathao Driver App |
|---|---|---|
| Sprints | Fixed-length iterations (e.g., 2 weeks). | Sprint 1: Basic ride booking; Sprint 2: Payment API |
| Daily Standups | 15-minute team syncs: "What did I do? What will I do? Blockers?" | Devs discuss "Khalti API integration stuck" |
| Backlog Grooming | Prioritizing user stories (features) in a product backlog. | "Add electric scooter support" → Top priority |
| Retrospectives | Team reflects on what worked/improved. | "Why did Sprint 3 have 5 bugs? Better test coverage." |
| Continuous Delivery | Code is always in a deployable state. | Pathao updates app daily with fixes |
Agile Frameworks
| Framework | Key Idea | Used by |
|---|---|---|
| Scrum | Roles (Scrum Master, Product Owner), sprints, daily standups. | Google, WhatsApp |
| Kanban | Visual workflow (To Do, In Progress, Done) with WIP limits. | Daraz customer support |
| Extreme Programming (XP) | Pair programming, test-driven development (TDD), frequent releases. | Ncell app development |
| Lean | Eliminate waste (e.g., unnecessary features). | Startups like F1Soft |
Worked Example: Agile vs. Waterfall for eSewa
| Scenario | Waterfall Approach | Agile Approach |
|---|---|---|
| User Request | "Add fingerprint login" after 6 months. | "Add fingerprint in Sprint 2" |
| Change Impact | Redesign entire system. | Update only authentication module. |
| Testing | Test once at the end. | Test after every sprint. |
| Risk | High (users may leave if delayed). | Low (feedback early). |
3. Spiral Model: Risk-Driven Iterations
Definition: Combines Waterfall’s structure with Agile’s iterations, focusing on risk analysis at each cycle. Best for high-risk projects (e.g., medical software, space systems).
4 Phases per Spiral Cycle
flowchart TD
A["Plan"] --> B["Risk Analysis"]
B --> C["Engineering"]
C --> D["Evaluate"]
D -->|"Repeat"| AExample: NEPSE Trading System
| Spiral Cycle | Activity | Risk Addressed | Deliverable |
|---|---|---|---|
| 1 | Gather requirements. | Market volatility risk. | Initial SRS |
| 2 | Prototype trading UI. | User confusion risk. | Clickable prototype |
| 3 | Build backend (APIs, database). | Security risk (hacking). | Secure API contracts |
| 4 | Full system + user testing. | Performance risk (slow during peak). | Load-tested system |
Advantages
- Handles uncertainty well (e.g., regulatory changes in banking).
- Early risk identification (e.g., Ncell’s 4G rollout risks).
- Flexible (can pivot based on feedback).
Disadvantages
- Complex to manage (requires expert risk analysts).
- Costly (multiple prototypes).
4. V-Model: Verification and Validation
Definition: An extension of Waterfall with testing phases aligned with development phases. Each development phase has a corresponding testing phase.
flowchart TD
A["Requirements"] --> B["System Design"]
B --> C["Architecture Design"]
C --> D["Module Design"]
D --> E["Implementation"]
E --> F["Unit Testing"]
F --> G["Integration Testing"]
G --> H["System Testing"]
H --> I["Acceptance Testing"]
I --> J["Maintenance"]Example: Daraz Order Fulfillment System
| Development Phase | Testing Phase | Activity |
|---|---|---|
| Requirements | Acceptance Testing | Validate "order within 24 hours" with users. |
| System Design | System Testing | Test entire order flow (cart → payment → delivery). |
| Module Design | Integration Testing | Test payment module + inventory module. |
| Implementation | Unit Testing | Test "calculate shipping cost" function. |
Why Use V-Model?
- Early testing: Bugs found in design phase (not coding).
- Traceability: Each requirement maps to a test case.
- Regulatory compliance: Critical for banks, healthcare (e.g., CIBIL credit score system).
5. Rapid Application Development (RAD)
Definition: Fast delivery using prototyping, reusable components, and user feedback. Ideal for short-term projects (e.g., a university exam portal).
Key Techniques
- Joint Application Design (JAD): Workshops with users to define requirements.
- Prototyping: Build a throwaway model to validate ideas.
- Reusable Components: Use libraries (e.g., Bootstrap for UI).
Example: Kathmandu Traffic Management App
| Step | Activity | Tool Used |
|---|---|---|
| 1 | JAD Workshop with traffic police. | Miro whiteboard |
| 2 | Build prototype (shows real-time traffic). | React + Google Maps API |
| 3 | User testing with 1000 drivers. | Firebase analytics |
| 4 | Deploy MVP in 3 districts. | AWS |
Advantages
- Speed: Deliver in weeks/months (vs. years in Waterfall).
- User-centric: Constant feedback (e.g., Pathao’s ride-sharing).
Disadvantages
- High initial cost (prototyping tools).
- Not scalable for large systems (e.g., Ncell’s core network).
6. Prototyping Model: Build → Test → Refine
Definition: Build a working model early, get user feedback, and refine. Used for UI/UX-heavy apps (e.g., eSewa’s new feature).
Types of Prototypes
| Type | Description | Example |
|---|---|---|
| Paper Prototype | Sketches on paper. | WhatsApp’s early UI mockups. |
| Low-Fidelity | Clickable wireframes (no backend). | Daraz’s "Add to Cart" flow. |
| High-Fidelity | Fully interactive (like real app). | Ncell’s MyAccount dashboard. |
Example: Khalti’s New Feature (Auto-Pay Bills)
- Build: Create a prototype showing "Auto-pay electricity bill every month."
- Test: Show to 50 users → "Add a reminder notification."
- Refine: Update prototype → "Now includes SMS alerts."
In the Real World
1. eSewa: Agile + Prototyping
- Problem: Needed to add QR code payments quickly.
- Solution: Used Agile sprints (2-week cycles) and high-fidelity prototypes to test with merchants.
- Result: Feature launched in 3 months (vs. 1 year with Waterfall).
2. Daraz: RAD for Flash Sales
- Problem: Daily sales require fast UI updates.
- Solution: RAD model with reusable components (e.g., discount banner templates).
- Result: New sale pages deployed in hours.
3. Ncell: Spiral Model for 5G Rollout
- Problem: High risk of network congestion in Kathmandu.
- Solution: Spiral cycles to test 5G in Thapathali before city-wide rollout.
- Result: Identified interference issues early and fixed them.
4. NTC: Waterfall for Billing System
- Why Waterfall?: Requirements were stable (no frequent changes).
- Outcome: System built in 18 months with no major rework.
Cost Estimation: COCOMO Model
The Constructive Cost Model (COCOMO) estimates effort, cost, and schedule based on lines of code (LOC) and project size.
3 COCOMO Variants
| Variant | Description | Formula Example |
|---|---|---|
| Basic | Simple effort estimation. | Effort = |
| Intermediate | Adds 15 cost drivers (e.g., team experience, complexity). | Effort = |
| Advanced | Detailed phase-wise estimation. | Used for DoD projects. |
COCOMO II (Modern Version)
COCOMO II has 3 project classes:
- Organic: Small team, familiar tech (e.g., a bank’s loan app).
- Semi-Detached: Medium complexity (e.g., Daraz’s logistics tracker).
- Embedded: High complexity (e.g., Ncell’s core network).
Worked Example: Estimating a Pathao Driver App
| Parameter | Value | Calculation |
|---|---|---|
| KLOC | 5000 | Estimated lines of code. |
| EAF (Effort Adjustment Factor) | 1.2 | Team experience = 1.1, Complexity = 1.05 |
| Effort (Person-Months) | ≈ 180 person-months | |
| Schedule (Months) | ≈ 12 months |
Interpretation:
- Team size: 15 devs working for 12 months.
- Cost: If salary = $500/month → $90,000.
Comparison Table: Methodologies
| Model | Best For | Flexibility | Risk Handling | Documentation | Example Use Case |
|---|---|---|---|---|---|
| Waterfall | Small, stable projects. | Low | Late | High | NTC billing system |
| Agile | Dynamic, user-centric projects. | High | Early | Low | Pathao app updates |
| Spiral | High-risk projects. | Medium | Very Early | Medium | Ncell 5G rollout |
| V-Model | Regulated industries (banking). | Low | Medium | Very High | CIBIL credit system |
| RAD | Fast MVP delivery. | High | Medium | Low | Daraz flash sale pages |
| Prototyping | UI/UX-heavy apps. | High | Early | Medium | eSewa QR code feature |
Exam Tip
What Examiners Look For
- Definitions: Know the key phases of each model (e.g., Waterfall’s 6 phases).
- Comparisons: Be ready to contrast Agile vs. Waterfall (flexibility, testing, risk).
- Real-World Links: Connect models to Nepali tech (e.g., "Why would Daraz use RAD?").
- Diagrams: Draw flowcharts (e.g., Spiral model) or V-Model alignment.
- COCOMO: Memorize the formula and EAF factors (e.g., team experience = 1.1).
- Prototyping: Explain paper vs. high-fidelity prototypes with examples.
Common Mistakes to Avoid
- Mixing terms: Don’t say "Agile is Waterfall with iterations."
- Ignoring context: Always justify why a model is chosen (e.g., "Spiral for high-risk projects").
- Skipping math: In COCOMO, show calculations (even if simplified).
- Overlooking tools: Mention Jira for Agile, UML for Waterfall.
Practice Questions (Self-Check)
Short Answer:
- Differentiate cohesion and coupling in modular design.
- List 3 cost drivers in COCOMO II.
Long Answer:
- Explain how Pathao would use Agile to develop a new feature (e.g., "Auto-fare split for group rides"). Include sprints, backlog, and risks.
- Draw the V-Model for a bank’s ATM system and label all phases.
Scenario-Based:
- NTC wants to build a real-time traffic monitoring system. Which model would you choose? Justify with advantages/disadvantages of your choice.
Based on the TU BCA syllabus for Software Engineering (CACS253), unit 4.
Discussion
Loading…