Software EngineeringUnit 216 min read

Software Process Models: Models, Phases, and Real-World Applications

Unit 2 of Software Engineering explores the core software process models (waterfall, iterative, spiral, agile, V-model), their phases, workflows, and trade-offs, with real-world examples from Nepali and global tech (eSewa, Pathao, Google) and exam-focused comparisons.

What is a Software Process Model?

A software process model is a structured framework that defines how software is developed, from initial requirements to final delivery and maintenance. It outlines:

  • Activities (e.g., planning, designing, coding, testing).
  • Roles (e.g., developers, testers, project managers).
  • Artifacts (e.g., documents, code, test cases).
  • Dependencies between activities.

Process models ensure consistency, predictability, and quality in software development. Without a model, projects risk chaos, missed deadlines, or poor user satisfaction.


Why Models Matter: The Chaos vs. Control Trade-off

Chaos (No Model) Control (With Model)
Unplanned, ad-hoc steps Defined phases and milestones
Frequent scope creep Clear requirements and change control
Delays and budget overruns Predictable timelines and costs
Low-quality output Systematic testing and reviews
Example: A startup coding without a plan, missing deadlines. Example: eSewa’s structured release cycles for new features.

1. The Waterfall Model: Linear and Predictable

How It Works

The waterfall model is the oldest and simplest process model. It divides development into sequential phases, where each phase must be completed before the next begins. No going back!

flowchart TD
    A["Requirements"] --> B["System Design"]
    B --> C["Implementation"]
    C --> D["Testing"]
    D --> E["Deployment"]
    E --> F["Maintenance"]

Phases of Waterfall

Phase Key Activities Deliverables
Requirements Gather user needs, define scope. SRS (Software Requirements Specification)
System Design High-level architecture (e.g., modules, databases). System Design Document (SDD)
Implementation Code development (programming). Source Code
Testing Unit, integration, system testing. Test Reports
Deployment Install software in production. Deployed Software
Maintenance Fix bugs, add features post-release. Patch Releases

Worked Example: NTC’s Billing System

Scenario: NTC wants to develop a new billing system for its 10 million subscribers.

  • Phase 1 (Requirements): NTC’s team interviews customers to define features like online payment, usage alerts, and multi-language support.
  • Phase 2 (Design): They design a 3-tier architecture (UI → Application Server → Database).
  • Phase 3 (Implementation): Developers code in Java/Spring Boot.
  • Phase 4 (Testing): Testers verify that a user in Kathmandu can pay via Khalti without errors.
  • Phase 5 (Deployment): Roll out to 1 district first, then nationwide.
  • Phase 6 (Maintenance): Fix a bug where rural users’ signals drop during peak hours.

Why Waterfall?

  • NTC’s stakeholders (government, users) need clear milestones and audit trails.
  • Changes are expensive late in the process (e.g., adding a new feature after deployment costs 10x more).

Advantages

  • Simple to understand and manage.
  • Works well for small, well-defined projects (e.g., a bank’s ATM transaction module).
  • Easy to document and review each phase.

Disadvantages

  • No flexibility: If requirements change mid-project, you must restart phases.
  • Late testing: Bugs found in the testing phase can be costly to fix.
  • Not suitable for dynamic environments (e.g., social media apps like Pathao).

2. Iterative and Incremental Models: Build, Test, Repeat

How They Differ

Iterative Model Incremental Model
Focuses on refining a single product through repeated cycles. Focuses on delivering pieces of the product incrementally.
Example: Improving a game’s AI over 5 iterations. Example: Releasing a messaging app’s core features first (text), then calls, then video.
Risk: May never deliver a complete product. Risk: Early increments may lack integration.

The Iterative Process

flowchart LR
    A["Plan"] --> B["Design"]
    B --> C["Prototype"]
    C --> D["Test"]
    D --> E["Review"]
    E -->|"Improvements"| A

Worked Example: Daraz’s Mobile App

Scenario: Daraz wants to launch a mobile app with fast checkout as a key feature.

  1. Iteration 1: Build a basic checkout flow (login → cart → payment via Khalti).
    • Test with 100 users in Pokhara.
    • Bug: Payment fails for 15% of users → Fix API integration.
  2. Iteration 2: Add guest checkout (no login required).
    • Test with 500 users in Kathmandu.
    • Bug: Slow loading → Optimize images.
  3. Iteration 3: Integrate Daraz Points for discounts.
    • Test with 2,000 users.
    • Success! Roll out nationally.

Why Iterative?

  • Early feedback: Daraz learns user pain points (e.g., slow loading) before full launch.
  • Lower risk: Each iteration is a mini-waterfall, reducing failure costs.

Advantages

  • Flexible: Requirements can evolve.
  • Early delivery: Users get a working product faster.
  • Better quality: Issues are caught in small cycles.

Disadvantages

  • Higher initial cost: Requires planning for multiple cycles.
  • Scope creep: Too many iterations can bloat the project.

3. Spiral Model: Risk-Driven Development

How It Works

The spiral model combines iterative development with risk analysis. Each cycle (spiral) has:

  1. Planning: Define objectives, constraints, and risks.
  2. Risk Analysis: Identify and mitigate risks (e.g., technical, schedule, budget).
  3. Engineering: Develop and test a prototype.
  4. Evaluation: Review with stakeholders.
flowchart TD
    A["Plan"] --> B["Risk Analysis"]
    B --> C["Prototype"]
    C --> D["Evaluate"]
    D -->|"Feedback"| A

Worked Example: NEPSE’s Trading Platform

Scenario: NEPSE needs a new trading platform for Nepal’s stock market.

  • Spiral 1:
    • Risk: "Will traders accept a digital platform?"
    • Action: Build a simulated trading environment for 100 users.
    • Result: Users love the UI but hate the slow order matching → Optimize backend.
  • Spiral 2:
    • Risk: "Will banks integrate payment APIs?"
    • Action: Partner with Global IME Bank to test API connections.
    • Result: Success! Proceed to full development.

Why Spiral?

  • High-risk projects (e.g., financial systems, healthcare apps) need this.
  • NEPSE cannot afford failures—traders lose money if the system crashes.

Advantages

  • Risk-focused: Addresses critical issues early.
  • Flexible: Can switch models if risks change.
  • Stakeholder involvement: Regular reviews keep everyone aligned.

Disadvantages

  • Complex: Hard to manage without experienced teams.
  • Costly: Requires extensive documentation and reviews.
  • Not for low-risk projects (e.g., a university’s internal grade calculator).

4. Agile Model: Flexible and Collaborative

Core Principles (Agile Manifesto)

Agile prioritizes:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

How Agile Works: Scrum Framework

Agile is often implemented via Scrum, which breaks work into 2-4 week sprints.

flowchart LR
    A["Sprint Planning"] --> B["Daily Standup"]
    B --> C["Sprint Work"]
    C --> D["Sprint Review"]
    D --> E["Retrospective"]
    E -->|"Improvements"| A

Roles in Scrum

Role Responsibility
Product Owner Defines features (backlog), prioritizes work.
Scrum Master Removes obstacles, facilitates meetings.
Development Team Codes, tests, and delivers increments.

Worked Example: Pathao’s Rider App

Scenario: Pathao wants to add a real-time traffic reroute feature for riders.

  • Sprint 1 (2 weeks):
    • Goal: Integrate Google Maps API for live traffic data.
    • Tasks:
      • Fetch traffic data every 30 seconds.
      • Update rider’s route if congestion > 50%.
    • Demo: Riders in Thapathali see faster routes during rush hour.
  • Sprint 2 (2 weeks):
    • Goal: Add alternative route suggestions if the primary route is blocked.
    • Tasks:
      • Test with 1,000 riders in Lalitpur.
      • Fix a bug where routes sometimes loop.

Why Agile?

  • Fast feedback: Pathao’s riders test features weekly.
  • Adaptability: If a new competitor (e.g., Yeti) launches, Pathao can pivot quickly.

Advantages

  • Fast delivery: Working software every 2-4 weeks.
  • Customer-centric: Prioritizes user needs over rigid plans.
  • Transparency: Daily standups keep the team aligned.

Disadvantages

  • Requires discipline: Teams must commit to sprint goals.
  • Documentation-light: Can lead to knowledge gaps if not managed.
  • Not for all projects: Hard to apply in regulated industries (e.g., medical devices).

5. V-Model: Testing-Driven Development

How It Works

The V-model is an extension of the waterfall model that links each development phase with a corresponding testing phase. It ensures verification and validation at every step.

flowchart LR
    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"]

Worked Example: Ncell’s USSD Service

Scenario: Ncell wants to launch a USSD-based balance check service.

  • Requirements: Users dial *123# to check balance.
  • System Design: Define how USSD interacts with the billing system.
  • Architecture Design: Choose a load balancer to handle 1M concurrent users.
  • Module Design: Break into:
    • USSD Gateway
    • Billing Database
    • SMS Notification
  • Implementation: Code in Java (backend) and Python (USSD logic).
  • Unit Testing: Test each module (e.g., does the USSD gateway return correct balance?).
  • Integration Testing: Ensure USSD → Database sync works.
  • System Testing: Simulate 100,000 users dialing *123# simultaneously.
  • Acceptance Testing: Ncell’s QA team verifies with real users.

Why V-Model?

  • Critical systems (telecom, banking) cannot afford undetected bugs.
  • Regulatory compliance: Ncell must prove the system works before launch.

Advantages

  • Early testing: Bugs are caught before integration.
  • Structured: Clear mapping between development and testing phases.
  • Good for safety-critical systems (e.g., medical devices, aviation software).

Disadvantages

  • Rigid: Hard to accommodate late changes.
  • Late feedback: Users only see the product at the end.
  • Overkill for small projects (e.g., a student’s portfolio website).

Comparison Table: Process Models

Model Best For Flexibility Risk Handling Documentation Customer Involvement Example Use Case
Waterfall Small, well-defined projects Low Late High Low NTC’s billing system
Iterative Projects needing refinement Medium Medium Medium Medium Daraz’s app improvements
Spiral High-risk, complex projects High Early Very High High NEPSE’s trading platform
Agile (Scrum) Dynamic, customer-focused projects Very High Continuous Low Very High Pathao’s rider app
V-Model Safety-critical, regulated systems Low Early Very High Low Ncell’s USSD service

In the Real World

1. eSewa: Agile for Financial Transactions

  • Process Used: Agile (Scrum).
  • How: eSewa’s team works in 2-week sprints to add features like:
    • QR code payments (Sprint 1).
    • Bill splitting (Sprint 2).
  • Why: Users expect constant updates, and eSewa must stay ahead of competitors like Khalti.
  • Real Impact: During Dashain, eSewa handles 100,000 transactions/hour—Agile helps them scale quickly.

2. Daraz: Iterative for E-Commerce

  • Process Used: Iterative Model.
  • How: Daraz releases core features first (search, cart, checkout), then adds:
    • Wishlist (Iteration 2).
    • Live chat support (Iteration 3).
  • Why: Early iterations validate demand (e.g., if users don’t use the wishlist, Daraz stops developing it).
  • Real Impact: Reduced development cost by 30% compared to building everything at once.

3. NTC: Waterfall for Infrastructure

  • Process Used: Waterfall.
  • How: NTC’s fiber-optic network expansion follows strict phases:
    1. Requirements: Survey 50 districts for demand.
    2. Design: Plan cable routes (e.g., avoid landslide-prone areas).
    3. Implementation: Lay 5,000 km of fiber.
    4. Testing: Verify speeds in 10 pilot districts.
    5. Deployment: Roll out nationwide.
  • Why: No room for error—digging up roads mid-project would cost millions.
  • Real Impact: Ensured 99.9% uptime in Kathmandu’s business districts.

Exam Tip

How This Unit is Examined

  1. Definitions: Expect questions like:

    • "Define the spiral model and explain its four phases."
    • "Differentiate between iterative and incremental models." Tip: Memorize the key characteristics (e.g., "Waterfall is sequential; Agile is iterative").
  2. Diagrams: Draw and label:

    • Waterfall, V-model, or spiral flowcharts.
    • Scrum roles (Product Owner, Scrum Master, Dev Team). Tip: Use color-coding (e.g., blue for planning, red for testing) to stand out.
  3. Scenario-Based Questions:

    • "Which model would you use for developing a mobile banking app? Justify."
    • "A project has unclear requirements. Which model is best? Why?" Tip: Relate to real-world examples (e.g., "Agile for Pathao, Waterfall for NTC").
  4. Advantages/Disadvantages:

    • "List 3 disadvantages of the waterfall model."
    • "Why is the V-model suitable for medical software?" Tip: Use the comparison table above to recall pros/cons quickly.
  5. Worked Examples:

    • "Trace the phases of the waterfall model for a university exam system." Tip: Pick a simple system (e.g., a calculator) and map it to the model.

Final Checklist for Full Marks

  • Define each model clearly (1 mark each).
  • Draw and label at least one process diagram (3 marks).
  • Compare two models in a table (4 marks).
  • Apply a model to a real-world scenario (e.g., Ncell, Pathao) (5 marks).
  • Discuss advantages/disadvantages with examples (3 marks).
  • Justify why a model is suitable for a given project (4 marks).

Based on the PU BE Computer (PU) syllabus for Software Engineering (CMP348), unit 2.

Discussion

Loading…