Software Engineering Basics: SDLC, Models, Cohesion/Coupling, and Quality

TAKEAWAYS:

• Understand the Software Development Life Cycle (SDLC) and its phases: planning, analysis, design, implementation, testing, deployment, and maintenance.
• Compare three process models (waterfall, spiral, agile) and know when to use each.
• Define cohesion (how tightly related a module’s tasks are) and coupling (how tightly modules depend on each other) and their impact on software quality.
• Learn how software quality attributes (correctness, reliability, usability, efficiency) are achieved through good design principles.
• Apply software engineering best practices (modularity, abstraction, reusability) in C programming.

What is Software Engineering?

Software engineering is the systematic application of engineering principles to the design, development, maintenance, testing, and evaluation of software. Unlike ad-hoc programming, it ensures software is reliable, maintainable, and scalable.

Why is Software Engineering Important?

• Reduces errors: Structured processes catch bugs early.
• Saves time and cost: Reusable modules and clear documentation speed up development.
• Improves maintainability: Well-designed code is easier to update and debug.

Software Development Life Cycle (SDLC)

The SDLC is a structured process that guides software development from inception to retirement. It consists of 7 key phases:

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

Phases of SDLC

Software Process Models

A software process model defines the workflow, activities, and deliverables for software development. Three major models are:

1. Waterfall Model

flowchart LR
    A["Planning"] --> B["Analysis"]
    B --> C["Design"]
    C --> D["Implementation"]
    D --> E["Testing"]
    E --> F["Deployment"]
    F --> G["Maintenance"]

• Sequential phases: Each phase must complete before the next begins.
• Best for: Small projects with clear, unchanging requirements.
• Advantages:
  • Simple and easy to manage.
  • Well-documented phases.
• Disadvantages:
  • No going back: Changes in later phases are costly.
  • Rigid: Not suitable for dynamic requirements.

Example in Nepal:

• Nepal Electricity Authority (NEA) uses a waterfall-like approach for billing system updates because requirements (e.g., meter readings, tariffs) change slowly.

2. Spiral Model

flowchart LR
    A["Planning"] --> B["Risk Analysis"]
    B --> C["Design & Prototype"]
    C --> D["Customer Feedback"]
    D -->|"Iterative"| A

• Iterative and risk-driven: Each loop (spiral) refines the product.
• Best for: High-risk projects (e.g., defense systems, medical software).
• Advantages:
  • Early risk identification.
  • Flexibility to incorporate changes.
• Disadvantages:
  • Complex and costly (requires expert risk analysis).
  • Time-consuming for small projects.

Example in Nepal:

• Ncell’s app development uses a spiral model to test new features (e.g., mobile banking) in stages before full rollout.

3. Agile Model

flowchart LR
    A["Requirements"] --> B["Design"]
    B --> C["Development"]
    C --> D["Testing"]
    D -->|"Short cycles"| A

• Iterative and incremental: Work is divided into small sprints (2-4 weeks).
• Best for: Fast-changing requirements (e.g., startups, e-commerce).
• Advantages:
  • Flexible: Adapts to changes quickly.
  • Customer feedback early.
• Disadvantages:
  • Requires discipline (daily stand-ups, sprint planning).
  • Documentation may lag.

Example in Nepal:

• Pathao’s ride-hailing app uses Agile to release updates weekly (e.g., new payment methods, driver features).

Cohesion and Coupling

Two critical design principles that affect maintainability and reusability.

Cohesion

Definition: The degree to which a module’s tasks are related.

• High cohesion = Module does one thing well.
• Low cohesion = Module does many unrelated things.

Visual Example:

classDiagram
    class HighCohesionModule {
        +calculateInterest(rate: float, principal: float) float
    }
    class LowCohesionModule {
        +sortData()
        +printReport()
        +validateInput()
    }
    HighCohesionModule --> "Does one thing well" HighCohesionModule
    LowCohesionModule --> "Does many unrelated things" LowCohesionModule

Why High Cohesion Matters:

• Easier to debug and maintain.
• Modules can be reused without side effects.

Coupling

Definition: The degree of interdependence between modules.

• Low coupling = Modules are independent.
• High coupling = Modules depend heavily on each other.

Visual Example:

flowchart LR
    A["Module A (High Coupling)"] -->|"Modifies Module B's data"| B["Module B"]
    C["Module C (Low Coupling)"] -->|"Sends only 'price'"| D["Module D"]

Why Low Coupling Matters:

• Easier to modify or replace modules.
• Reduces bugs (changes in one module don’t break others).

Software Quality Attributes

Good software must satisfy non-functional requirements (quality attributes):

Real-World Applications

1. eSewa (Payment System)

• SDLC Phase: Uses Agile for rapid updates (e.g., new payment methods).
• Cohesion: Each module has a single responsibility (e.g., processPayment(), validateUser()).
• Coupling: Modules exchange only necessary data (e.g., amount, transactionID).

2. Daraz (E-Commerce)

• Process Model: Spiral for high-risk features (e.g., fraud detection).
• Quality Attribute: Efficiency (fast database queries for product searches).

3. NTC (Electricity Billing)

• SDLC: Waterfall (stable requirements, slow-changing regulations).
• Coupling: Low coupling between billing module and customer service module.

Worked Example: Loan Interest Calculator (Banking System)

Problem: A bank wants a module to calculate monthly loan interest with high cohesion and low coupling.

Bad Design (Low Cohesion, High Coupling)

// Low cohesion: Does too many things
void loanModule(float principal, float rate, int months) {
    // Input validation
    if (principal <= 0) printf("Invalid principal!\n");

    // Calculate interest (badly coupled with input)
    float interest = principal * rate * months / 100;

    // Print results (mixed responsibilities)
    printf("Monthly payment: %.2f\n", (principal + interest) / months);
}

Issues:

• Low cohesion: Validates input, calculates interest, and prints results.
• High coupling: Mixes logic with I/O.

Good Design (High Cohesion, Low Coupling)

// High cohesion: One task per function
float calculateMonthlyInterest(float principal, float rate, int months) {
    return (principal * rate * months) / 100;
}

void printLoanDetails(float principal, float interest) {
    printf("Principal: %.2f\n", principal);
    printf("Total Interest: %.2f\n", interest);
}

int main() {
    float principal = 100000, rate = 8.5;
    int months = 12;
    float interest = calculateMonthlyInterest(principal, rate, months);
    printLoanDetails(principal, interest);
    return 0;
}

Improvements:

• High cohesion: Each function does one thing.
• Low coupling: Functions exchange only necessary data (principal, rate, months).

Exam Tip

1. SDLC: Always list all 7 phases in order. Mention deliverables for full marks.
2. Process Models:
   • Waterfall: Sequential, rigid.
   • Spiral: Risk-driven, iterative.
   • Agile: Sprint-based, flexible.
   • Compare 2 models in exams (e.g., "Waterfall vs. Agile").
3. Cohesion/Coupling:
   • Define both, then give examples (e.g., "High cohesion = calculateTax()").
   • Low coupling is always better—explain why.
4. Real-World Links:
   • Relate eSewa/Khalti to Agile/low coupling.
   • Relate NTC to Waterfall/stable requirements.
5. Diagrams:
   • Draw SDLC flowchart or cohesion/coupling tables for visual marks.

Summary Checklist

Before the exam, ensure you can: ✅ List and explain all 7 SDLC phases. ✅ Compare Waterfall, Spiral, and Agile models. ✅ Define cohesion and coupling with examples. ✅ Explain why high cohesion and low coupling improve software quality. ✅ Relate real-world systems (eSewa, NTC, Daraz) to software engineering concepts.