Software Dev Processes & Models

TAKEAWAYS:

• Software processes define how projects are planned, developed, and maintained, with waterfall (sequential) and iterative (repeated cycles) as core approaches.
• Prototyping and spiral models balance risk and flexibility, while agile (e.g., Scrum) delivers small, frequent updates.
• Requirements-driven vs. change-driven processes suit static vs. evolving needs (e.g., eSewa’s payment gateways vs. Daraz’s dynamic inventory).
• Model-driven architecture (MDA) automates system design via abstract models, reducing manual coding errors.
• Process selection depends on project size, risk, and stakeholder needs (e.g., NTC’s infrastructure updates vs. Pathao’s real-time dispatch).
• Process models are not rigid; hybrid approaches (e.g., waterfall + agile) are common in practice.

1. Introduction to Software Development Processes

Software development processes define how software is planned, designed, built, tested, and maintained. They provide a structured approach to manage complexity, risks, and resources. Processes can be categorized based on:

• Approach: Sequential (waterfall) vs. iterative (spiral, agile).
• Focus: Requirements-driven (waterfall) vs. change-driven (agile).
• Flexibility: Rigid (waterfall) vs. adaptive (agile).

Why it matters: A poorly chosen process leads to budget overruns, delays, or low-quality software (e.g., failed government IT projects in Nepal). The right process aligns with project goals, stakeholder needs, and technical constraints.

2. Waterfall Model

The waterfall model is a linear, sequential approach where each phase (requirements → design → implementation → testing → deployment → maintenance) must be completed before moving to the next.

Phases of Waterfall Model

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

When to Use Waterfall

Advantages

• Clear milestones: Easy to track progress.
• Documentation-heavy: Good for audits (e.g., NEPSE trading systems).
• Predictable costs: Fixed scope reduces budget surprises.

Disadvantages

• Rigid: Changes late in the process are costly (e.g., Pathao’s ride-sharing algorithms).
• Late testing: Bugs found in testing may require rework of earlier phases.
• Not suitable for dynamic environments: Fails when requirements evolve (e.g., WhatsApp’s feature updates).

Worked Example: NTC’s Fixed Network Rollout

NTC uses waterfall for fiber-optic cable laying in remote areas:

1. Requirements: Survey terrain, get permits.
2. Design: Route planning, equipment specs.
3. Implementation: Physical cable installation.
4. Testing: Signal integrity checks.
5. Deployment: Connect to exchange centers.
6. Maintenance: Troubleshoot outages.

Why waterfall? The project has a fixed scope (cable length, nodes) and high upfront costs (excavation, permits).

3. Prototyping Model

The prototyping model builds a working model of the software early to validate requirements and gather feedback. It is ideal for user interfaces (UI) or complex interactions (e.g., Daraz’s checkout flow).

Stages of Prototyping

graph TD
    A["Initial Requirements"] --> B["Quick Prototype"]
    B --> C["User Feedback"]
    C --> D["Refine Requirements"]
    D --> E["Final Development"]

Types of Prototypes

Advantages

• Early user feedback: Reduces misalignment (e.g., Khalti’s wallet UI tests).
• Risk reduction: Identifies flaws before full development.
• Flexible: Adapts to changing needs.

Disadvantages

• Scope creep: Prototypes may expand into full projects.
• Maintenance overhead: Throwaway prototypes require rework.
• Not for all domains: Poor fit for safety-critical systems (e.g., aviation software).

Worked Example: Khalti’s Wallet UI

Khalti built a throwaway prototype to test:

• User flow: "Scan QR → Select amount → Confirm payment."
• Error handling: What if the QR is invalid?
• Performance: Load times on low-end phones.

Outcome: The prototype revealed that users struggled with the QR scanner, leading to a redesign before full development.

4. Spiral Model

The spiral model combines iterative development with risk analysis. It breaks the project into spirals, each with:

1. Planning: Define objectives, constraints, alternatives.
2. Risk analysis: Identify and mitigate risks.
3. Engineering: Develop and test a portion of the system.
4. Evaluation: Review with stakeholders.

graph TD
    A["Start"] --> B["Planning"]
    B --> C["Risk Analysis"]
    C --> D["Engineering"]
    D --> E["Evaluation"]
    E --> F["Next Spiral"]
    F -->|"Repeat"| B

When to Use Spiral

Advantages

• Risk management: Addresses uncertainties early.
• Flexible: Adapts to feedback in each spiral.
• Structured: Combines iterative and waterfall elements.

Disadvantages

• Complex: Requires skilled risk analysts.
• Time-consuming: Multiple reviews slow progress.
• Costly: Higher overhead than agile.

Worked Example: NEPSE’s Trading System Upgrade

NEPSE used the spiral model to:

1. Spiral 1: Test a simulated trading engine for high-frequency trading.
   • Risk: Latency issues → Solution: Optimized database queries.
2. Spiral 2: Integrate real-time market data feeds.
   • Risk: Data corruption → Solution: Added checksum validation.
3. Spiral 3: Deploy to limited users for beta testing.

Result: The system now handles 10,000+ trades/sec with minimal downtime.

5. Agile Model

Agile is an iterative, incremental approach where software is developed in small, time-boxed iterations (sprints, typically 2–4 weeks). Key principles:

• Customer collaboration over contract negotiation.
• Working software over comprehensive documentation.
• Responding to change over following a plan.

Agile Frameworks

Agile Process

graph TD
    A["Product Backlog"] --> B["Sprint Planning"]
    B --> C["Sprint: Dev/Test"]
    C --> D["Sprint Review"]
    D --> E["Retrospective"]
    E -->|"Feedback"| B

Advantages

• Flexibility: Adapts to changing requirements (e.g., WhatsApp’s new features).
• Customer involvement: Regular demos ensure alignment.
• Early delivery: Working software in weeks, not years.

Disadvantages

• Documentation light: May lack traceability for audits.
• Requires discipline: Needs skilled teams to avoid chaos.
• Not for all domains: Poor fit for safety-critical systems (e.g., medical devices).

Worked Example: WhatsApp’s Feature Rollout

WhatsApp uses agile (Scrum) to release features like:

1. Sprint 1: Add end-to-end encryption to calls.
   • Task: Integrate Signal Protocol.
2. Sprint 2: Implement group call controls.
   • Task: UI for muting participants.
3. Sprint 3: Add voice changes (e.g., "robot voice").
   • Task: Audio processing backend.

Outcome: Features roll out monthly, with 90% user satisfaction in surveys.

6. Model-Driven Architecture (MDA)

MDA is a software development paradigm that uses abstract models to generate code, reducing manual errors. It separates:

• Computation Independent Model (CIM): High-level business logic (e.g., "Process payment").
• Platform Independent Model (PIM): Technical design (e.g., "Use REST API").
• Platform Specific Model (PSM): Implementation details (e.g., "Java Spring Boot").

graph TD
    A["CIM: Business Logic"] --> B["PIM: Technical Design"]
    B --> C["PSM: Implementation"]
    C --> D["Generated Code"]

Advantages

• Reduces redundancy: One model → multiple implementations.
• Faster development: Less manual coding.
• Consistency: Ensures all platforms follow the same logic.

Disadvantages

• Tool dependency: Requires MDA tools (e.g., IBM Rational).
• Learning curve: Teams must learn modeling languages (e.g., UML).
• Overhead: Modeling takes time upfront.

Worked Example: Bank Loan Processing System

A bank uses MDA to:

1. CIM: "Calculate EMI based on principal, rate, tenure."
2. PIM: "Use a loan calculator service."
3. PSM: Generate Java and Python implementations.

Result: The same logic powers online portals and mobile apps with zero code duplication.

7. Comparison of Software Development Models

8. Choosing the Right Process Model

Select a model based on:

1. Project size: Small → Agile; Large → Spiral/Waterfall.
2. Requirements stability: Stable → Waterfall; Evolving → Agile.
3. Risk level: High → Spiral; Low → Waterfall.
4. Stakeholder involvement: High → Agile; Low → Waterfall.

Example Decision Tree:

graph TD
    A["Start"] --> B{"Requirements Stable?"}
    B -->|"Yes"| C{"Project Size Small?"}
    C -->|"Yes"| D["Waterfall"]
    C -->|"No"| E["Spiral"]
    B -->|"No"| F{"High Risk?"}
    F -->|"Yes"| G["Spiral"]
    F -->|"No"| H["Agile"]

In the Real World

1. eSewa’s Payment Processing

   • Idea: Uses agile (Scrum) for its payment gateway.
   • How: Releases updates every 2 weeks (e.g., adding UPI support).
   • Why: Customer feedback drives changes (e.g., "Add 'pay later' option").

2. Daraz’s Order Fulfillment

   • Idea: Uses Kanban (agile) for its order pipeline.
   • How: Visualizes stages: "Received → Packed → Shipped → Delivered."
   • Why: Tracks bottlenecks (e.g., "Last-mile delivery delays").

3. NTC’s 5G Rollout

   • Idea: Uses spiral model for network upgrades.
   • How: Each spiral tests a new frequency band before full deployment.
   • Why: Mitigates risks like interference with existing 4G.

Exam Tip

• Waterfall: Always link to fixed, low-risk projects (e.g., NTC, banks).
• Agile: Highlight customer collaboration and short iterations (e.g., WhatsApp, Daraz).
• Spiral: Emphasize risk analysis in each cycle (e.g., NEPSE, NTC 5G).
• MDA: Explain how one model generates multiple platforms (e.g., bank loan systems).
• Comparison: Use a table to contrast models (as above).
• Diagrams: Always draw process flows (e.g., waterfall phases, spiral cycles).
• Real-world link: For every model, name one Nepali/global app using it.

Common Pitfalls:

• ❌ Calling agile "just Scrum" (it’s a broader paradigm).
• ❌ Forgetting to mention risk analysis in spiral.
• ❌ Describing waterfall without clear phase transitions.

High-Scoring Answer Structure:

1. Define the model (1 line).
2. List phases/stages (bullet points + diagram).
3. Give 1–2 advantages/disadvantages.
4. Link to a real example (Nepali or global).
5. Compare with another model (e.g., "Unlike waterfall, agile...").