Software Quality Management: Metrics, Models, Testing & Assurance

Core Concepts: What is Software Quality?

Software quality is the degree to which a software product satisfies stated and implied needs (ISO/IEC 25010). It is not just about "bug-free" code but about meeting functional (what it does) and non-functional (how well it does it) requirements. Quality is measurable, predictable, and enforceable through systematic processes.

Quality Characteristics (ISO/IEC 25010)

Quality is broken into 8 high-level characteristics, each with sub-characteristics. Visualize them as layers in a quality pyramid:

Example: For eSewa, performance efficiency (fast transaction processing) and security (confidentiality of user data) are critical. For Pathao, usability (easy driver-passenger matching) and reliability (availability during peak hours) matter most.

1. Software Quality Metrics

Metrics quantify quality attributes. Common metrics include:

Worked Example: Suppose Khalti wants to measure the quality of its payment gateway module. They track:

• Defect Density: 3 defects per 1,000 LOC in the payment module (acceptable if industry average is 5).
• Response Time: 95% of transactions complete in <1.5s (meets SLA).
• Security Vulnerabilities: 0 critical CVEs in the last audit.

2. Software Cost Estimation Models

Estimating cost and effort is critical for project planning. The COCOMO (Constructive Cost Model) is the most widely used.

COCOMO Model Types

COCOMO Formula (Basic Model)

Effort (in person-months) = $2.4\times (KLOC{)}^{1.05}$ where KLOC = Thousands of Lines of Code.

Example: Estimate effort for a banking app with 50K LOC: $$\text{Effort}=2.4\times (50{)}^{1.05}=2.4\times 57.4\approx 138\text{ person-months}$$ Interpretation: The team needs ~11.5 person-years (138/12) to develop the app.

COCOMO Cost Drivers (Intermediate Model)

Real-World Tie-In: Nepal Rastra Bank (NRB) uses COCOMO to estimate the cost of developing core banking systems. For a module with:

• High reliability (cost driver = 1.15)
• Large database (cost driver = 1.05)
• Experienced team (cost driver = 0.90) The adjusted effort becomes: $$\text{Effort}=2.4\times (KLOC{)}^{1.05}\times 1.15\times 1.05\times 0.90$$

3. Software Testing Techniques

Testing ensures quality by identifying defects. Two primary approaches:

A. Black-Box Testing

Tests functionality without knowing internal code.

• Input: Requirements/SRS.
• Output: Test cases based on equivalence partitioning or boundary value analysis.
• Example: Testing Daraz’s checkout flow without seeing the code.

Worked Example: NTC’s billing system requires testing for:

• Invalid mobile numbers (e.g., "9800000000" vs. "9812345678").
• Boundary values (e.g., 0 minutes, 1 minute, 24 hours for prepaid data).

B. White-Box Testing

Tests internal logic (requires code access).

• Input: Source code.
• Output: Test cases based on code coverage (statement, branch, path).
• Example: Checking if Khalti’s transaction log correctly records every payment.

Worked Example: Pathao’s driver assignment algorithm has a critical path:

if (driver_available AND distance < 5km AND rating > 4.5):
    assign_ride()
else:
    search_next_driver()

Test cases:

1. driver_available=True, distance=3km, rating=4.6 → Should assign.
2. driver_available=False, distance=2km, rating=5.0 → Should search next.

4. Risk Management in Software Engineering

Risk is any event that could negatively impact a project. The risk management process is cyclic:

Steps in Risk Management

1. Risk Identification

   • Brainstorming, checklists, expert judgment.
   • Example: "Database migration might fail during peak hours."

2. Risk Analysis

   • Qualitative: High/Medium/Low probability + impact.
   • Quantitative: Probability × Impact = Risk Score.
   • Example:

     Risk	Probability	Impact	Score (P×I)
     Server downtime	High (0.8)	High (0.9)	0.72
     Third-party API failure	Medium (0.5)	Medium (0.6)	0.30

3. Risk Prioritization

   • Focus on high-score risks first.

4. Risk Mitigation

   • Avoid: Don’t use a risky technology (e.g., avoid untested libraries).
   • Transfer: Outsource to experts (e.g., hire a DevOps team for cloud setup).
   • Reduce: Add redundancy (e.g., backup databases for Ncell’s billing system).
   • Accept: Low-impact risks (e.g., minor UI delays).

5. Risk Monitoring

   • Track risks in tools like Jira or MS Project.

Real-World Example: Nepal Stock Exchange (NEPSE) manages risks in its trading platform:

• Risk: "Cyberattack during market hours."
• Mitigation:
  • Redundant servers (failover).
  • Penetration testing (quarterly).
  • Backup trading system (manual override).

5. Quality Assurance (QA) vs. Quality Control (QC)

Capability Maturity Model Integration (CMMI)

A 5-level maturity model for process improvement:

When to Use Staged Representation?

• Use staged if:
  • Organization is new to CMMI.
  • Budget is limited (focus on one area at a time).
• Avoid staged if:
  • Project is large and complex (e.g., national ID system like Citizen’s Charter).

6. Good Programming Practices for Quality

Follow these to reduce defects and improve maintainability:

A. Code-Level Practices

• Modularity: Break code into small, reusable modules (e.g., UserAuth, PaymentGateway).
• DRY (Don’t Repeat Yourself): Avoid duplicate code.
• Meaningful Naming: calculateTax() > func1().
• Comments & Documentation: Explain why, not just what.
• Error Handling: Use exceptions (e.g., try-catch in Java/Python).

B. Design-Level Practices

• Loose Coupling: Modules should depend on abstractions, not each other.
  • Bad: OrderService directly calls PaymentService.
  • Good: OrderService uses IPaymentGateway interface.
• High Cohesion: Each module should do one thing well.
  • Bad: UserModule handles login, payments, and notifications.
  • Good: Separate AuthModule, PaymentModule, NotificationModule.

Example: Daraz’s order processing system:

• High Cohesion: InventoryModule only manages stock.
• Low Coupling: OrderModule communicates via API, not direct function calls.

graph LR
  A["High Cohesion Example"] -->|"InventoryModule"| B((Circle))
  C["Low Coupling Example"] -->|"OrderModule"| D((Circle))
  B -->|"API"| D
  E["Spaghetti Code"] -->|"Tight Coupling"| F((Circle))
  F -->|"Direct Calls"| G((Circle))

7. Computer-Aided Software Engineering (CASE) Tools

CASE tools automate parts of software development to improve quality.

Types of CASE Tools

Benefits of CASE Tools

• Reduces errors (e.g., automated code generation).
• Improves documentation (e.g., UML diagrams auto-updated).
• Saves time (e.g., test case generation).
• Enforces standards (e.g., coding guidelines via IDE plugins).

Real-World Example: Ncell uses Jira + Confluence (CASE-like tools) for:

• Requirements tracking (Confluence).
• Automated testing (Jira + Xray for test management).
• Code reviews (GitHub/GitLab integration).

In the Real World

1. eSewa’s Transaction System

   • Quality Metric Used: Security (confidentiality, integrity).
   • How: Every transaction is logged with timestamps and encrypted. White-box testing checks for SQL injection vulnerabilities.
   • Risk Mitigation: Redundant servers in case of downtime.

2. Daraz’s Order Fulfillment

   • Quality Metric Used: Performance (response time ≤2s for 95% of orders).
   • Testing Technique: Load testing (simulate 10,000 concurrent users).
   • COCOMO Application: Estimated effort for the checkout module was 80 person-months (based on 30K LOC).

3. NTC’s Network Management

   • Quality Model: CMMI Level 4 (quantitative metrics for network uptime).
   • Risk Management: Monthly penetration tests to find vulnerabilities before hackers do.
   • Good Practice: Modular design (separate modules for billing, authentication, and routing).

4. Nepal Rastra Bank’s Core Banking System

   • Quality Assurance: Formal code reviews before deployment.
   • Testing: Black-box testing for user flows (e.g., loan approval).
   • CASE Tool: IBM Rational for UML modeling and requirements traceability.

Exam Tip

1. COCOMO Questions:

   • Always show the formula and calculate step-by-step.
   • For part (b), compare black-box vs. white-box using a table (as above).
   • Example Answer Structure:

     "The COCOMO model estimates effort as $E=a\times (KLOC{)}^b$. For the intermediate model, 15 cost drivers adjust this estimate. For a banking app with 50K LOC and high reliability (cost driver = 1.15), the adjusted effort is calculated as follows: [steps]."

2. Risk Management:

   • Draw the state diagram (as above) and label all steps.
   • Real-world tie-in: Always relate to Nepalese examples (e.g., NTC, NRB, eSewa).

3. Testing Techniques:

   • Black-box: Give 2 test cases (equivalence + boundary).
   • White-box: Show code coverage (e.g., "branch coverage achieved 90%").
   • Comparison Table: Use a 2-column table for black-box vs. white-box.

4. CMMI:

   • Define all 5 levels in a table (as above).
   • Staged vs. Continuous: Explain when to use each (budget vs. complexity).

5. Good Practices:

   • Modularity: Show a diagram of loosely coupled modules.
   • Cohesion/Coupling: Use real examples (e.g., Daraz’s modules).

6. CASE Tools:

   • List 3 types (upper, lower, integrated) with examples.
   • Benefits: Mention automation and standardization.

Final Pro Tip:

• Memorize the ISO 25010 quality characteristics (use the mindmap above).
• Practice COCOMO calculations with different KLOC values.
• Relate every concept to Nepalese tech companies (e.g., NTC, NRB, eSewa). Examiners love local examples!