Software Reviews & Maintenance: Processes, Techniques & Challenges

TAKEAWAYS:

• Software reviews systematically inspect artifacts (code, docs, designs) using techniques like walkthroughs, inspections, and checklists to catch defects early.
• Maintenance types (corrective, adaptive, perfective, preventive) address different lifecycle needs, with corrective fixing bugs and perfective improving performance.
• Configuration management tracks versions, changes, and baselines using tools like Git, SVN, and CMMI to ensure consistency across releases.
• Maintenance challenges include legacy system constraints, evolving requirements, and technical debt—mitigated via modular design and incremental updates.
• Metrics like mean time to repair (MTTR) and defect density quantify maintenance effectiveness.
• Real-world impact: Poor maintenance costs $1T+ annually globally (Gartner), while proactive reviews reduce defects by 60–90% (IEEE).

Core Concepts: Definitions and Scope

What is Software Review?

Software review is a structured evaluation of software artifacts (requirements, designs, code, tests) by stakeholders to identify defects, improve quality, and ensure compliance with standards. Unlike testing (which executes code), reviews examine static artifacts for logical errors, inconsistencies, or violations of best practices.

stateDiagram-v2
    [*] --> ReviewPlanning: "1. Plan Review"
    ReviewPlanning --> ArtifactSelection: "Select artifacts (e.g., code, docs)"
    ArtifactSelection --> ReviewMeeting: "Schedule meeting"
    ReviewMeeting --> DefectLogging: "Identify defects"
    DefectLogging --> FixTracking: "Track fixes"
    FixTracking --> Closure: "Close review"
    Closure --> [*]

Key Attributes of Effective Reviews:

• Early detection: Catches defects before testing (costs 100x less to fix early).
• Stakeholder involvement: Includes developers, testers, and domain experts.
• Documentation: Records findings, actions, and resolutions.
• Automation support: Tools like SonarQube or CodeClimate flag issues pre-review.

Types of Software Reviews

Worked Example: eSewa Payment Gateway Review

Scenario: eSewa’s team reviews a new transaction validation module before its monsoon season (high usage period).

1. Inspection Setup:
   • Moderator: Lead developer.
   • Reader: QA engineer (reads code line-by-line).
   • Recorder: DevOps engineer (logs defects in JIRA).
   • Checklist: Focus on SQL injection risks, timeout handling, and audit logs.
2. Defects Found:
   • Missing input sanitization in API endpoints (risk: $50K+ fraud loss in 2022).
   • Race condition in concurrent transactions (could corrupt ledger).
3. Outcome:
   • 3 critical fixes implemented before release.
   • MTTR: 4 hours (vs. 24 hours if found in production).

In the Real World

1. Khalti’s Fraud Detection System

   • Idea Used: Technical reviews + automated inspections.
   • How: Khalti’s team uses static code analysis tools (e.g., Checkmarx) to scan for vulnerabilities in their payment processing code before every deployment. In 2023, this prevented a $2M fraud attempt by catching a buffer overflow in a legacy module.

2. Daraz’s Order Fulfillment Queue

   • Idea Used: Configuration management + version tracking.
   • How: Daraz’s order processing system uses GitLab CI/CD to manage different versions of their inventory update scripts. During the Dashain sale (2023), a misconfigured script caused stock overcounting. The configuration audit trail helped trace the issue to a merged PR from 3 weeks prior, allowing a quick rollback.

3. NTC’s Network Monitoring Tools

   • Idea Used: Management reviews + metrics.
   • How: NTC’s fiber optic network uses monthly reviews to evaluate packet loss rates and latency spikes. In 2022, a management review identified that old Cisco routers were causing 30% higher latency in Kathmandu-Pokhara routes. This led to a phased hardware upgrade, reducing outages by 40%.

Software Maintenance: Types and Processes

Types of Maintenance

Software maintenance is classified into four categories, each addressing different lifecycle needs:

mindmap
  root((Software Maintenance))
    Corrective
      "Fixes bugs reported by users"
      Example: Patch for WhatsApp zero-day exploit (2023)
    Adaptive
      "Updates for new environments (OS, hardware, regulations)"
      Example: NEPSE’s system upgrade for **SEBI’s new compliance rules**
    Perfective
      "Improves performance, usability, or features"
      Example: Google Maps’ **real-time traffic rerouting algorithm**
    Preventive
      "Reduces future maintenance costs (refactoring, documentation)"
      Example: Facebook’s **code modernization from PHP to Hack**

Maintenance Process Model

The IEEE Std 1219 defines a 7-step maintenance process:

1. Problem/Request Identification: Logged via tickets (e.g., JIRA, ServiceNow).
2. Analysis: Determine root cause (e.g., is it a bug, feature request, or environment issue?).
3. Design: Propose changes (e.g., UML diagrams for refactoring).
4. Implementation: Code changes with version control (Git).
5. Testing: Regression testing to ensure no new defects.
6. Migration: Deploy to staging → production (e.g., Blue-Green deployment).
7. Feedback: Gather user feedback and log for future cycles.

Worked Example: Ncell’s App Crash Fix

Scenario: Ncell’s mobile app crashes when users try to recharge with a promo code.

1. Problem Identification:
   • Ticket: "App crashes on promo code input (Error: NullPointerException)".
   • Priority: P1 (Critical) due to revenue loss.
2. Analysis:
   • Root cause: Missing null check in the promo validation API.
   • Defect Density: 1 defect per 500 lines of code (high for this module).
3. Fix:
   • Added input validation in the Java backend:

     if (promoCode == null || promoCode.isEmpty()) {
         throw new IllegalArgumentException("Promo code cannot be empty");
     }
     

4. Testing:
   • Automated tests (JUnit) verified the fix.
   • Manual UAT by 100 users confirmed stability.
5. Deployment:
   • Canary release to 10% of users → no crashes reported.
   • Full rollout in 48 hours.

Configuration Management (CM) and Version Control

Why CM Matters

Configuration management ensures consistency, traceability, and reproducibility across software versions. Without CM:

• Inconsistent builds (e.g., Daraz’s order processing fails due to mismatched database schemas).
• Lost changes (e.g., a critical security patch overwritten by a feature branch).
• Compliance risks (e.g., NTC failing ISO 9001 audits due to undocumented changes).

CM Process Steps

Version Control Systems (VCS) Comparison

Worked Example: Pathao’s Ride Dispatch System

Scenario: Pathao’s dispatch algorithm fails during peak hours in Kathmandu.

1. CM Audit:
   • Issue: The latest version (v3.2) had a buggy load-balancing rule.
   • Root Cause: A merge conflict in the driver assignment branch was not tested.
2. Rollback Plan:
   • Git Bisect identified the failing commit.
   • Reverted to v3.1 while fixing the conflict.
3. Prevention:
   • Enforced pre-merge testing via GitHub Actions.
   • Added automated load tests for peak hours.

Challenges in Software Reviews and Maintenance

Common Issues

1. Legacy Systems:

   • Problem: Monolithic codebases (e.g., NEPSE’s old trading system) with no documentation.
   • Impact: High maintenance cost ($/line of code).
   • Solution: Incremental refactoring (e.g., strangler pattern).

2. Technical Debt:

   • Problem: Shortcuts taken for quick releases (e.g., Khalti’s 2021 hack due to unpatched vulnerabilities).
   • Metrics:
     • Debt Ratio: Technical Debt / Project Value (e.g., 0.3 = 30% of budget spent on fixing old issues).
     • Interest Rate: Cost of not fixing debt (e.g., $10K/month for Khalti’s unpatched APIs).

3. Evolving Requirements:

   • Problem: User needs change (e.g., Daraz adding "same-day delivery").
   • Solution: Agile maintenance (short cycles, Sprint reviews).

4. Stakeholder Misalignment:

   • Problem: Developers vs. Business disagree on priorities (e.g., NTC’s fiber upgrades delayed by budget cuts).
   • Solution: Joint Application Development (JAD) sessions.

Mitigation Strategies

Metrics for Reviews and Maintenance

Key Metrics

Worked Example: Banking System Maintenance Metrics

Scenario: A Nepalese bank’s loan processing system has:

• Total LOC: 50,000
• Defects in last quarter: 120
• Time to fix critical bugs: Avg. 6 hours

Calculations:

1. Defect Density: $\frac{120\text{ defects}}{50,000\text{ LOC}}=0.0024\text{ defects/LOC}$ → 2.4 defects/KLOC (below target of 5).
2. MTTR: $\frac{6\text{ hours}}{10\text{ critical bugs}}=0.6\text{ hours/bug}$ → 36 minutes/bug (below target of 4 hours).
3. Review Effectiveness:
   • Defects found in review: 90
   • Defects found in testing: 30 → $\frac{90}{120}\times 100=75\%$ (meets target).

Action: Increase review coverage to 90% to reduce testing costs.

Exam Tip

How to Score Full Marks

1. Definitions:

   • Always define terms precisely (e.g., "Software review is a formal evaluation of software artifacts by stakeholders to identify defects and improvements").
   • Example: For "inspection," mention roles (moderator, reader, recorder) and checklists.

2. Diagrams:

   • Draw mermaid diagrams for processes (e.g., review steps, maintenance types).
   • Label all components (e.g., in a state diagram, show transitions like "ReviewPlanning → ArtifactSelection").

3. Real-World Examples:

   • Link theory to Nepalese companies (e.g., "Like Khalti, eSewa uses technical reviews to prevent fraud by scanning for SQL injection vulnerabilities").
   • Use metrics (e.g., "NTC’s MTTR of 2 hours for network outages shows effective maintenance").

4. Comparison Tables:

   • Contrast review types (e.g., walkthrough vs. inspection) or maintenance types (e.g., corrective vs. perfective).

5. Worked Examples:

   • Solve a mini-case (e.g., "Calculate defect density for a 20KLOC system with 80 defects").
   • Relate to local scenarios (e.g., "How would you apply configuration management to Daraz’s order system?").

6. Common Pitfalls:

   • ❌ Vague answers: Avoid "Reviews help improve quality" → Instead, "Formal inspections reduce defects by 60–90% by catching issues in the design phase."
   • ❌ Ignoring tools: Always mention tools (e.g., "Git for version control", "SonarQube for static analysis").
   • ❌ Skipping metrics: Exams often ask for calculations (e.g., "Compute MTTR for 5 bugs fixed in 20 hours").

Sample Exam Questions & Answers

Q1: "Explain the software review process with a diagram." Answer: Key Points:

• Roles: Moderator, reader, recorder, author.
• Techniques: Checklists, IEEE Std 1028.
• Outcome: Defect report with priority levels.

Q2: "How does configuration management help in software maintenance?" Answer:

• Traceability: Tracks who changed what (e.g., "Commit abc123 by DevX introduced a bug").
• Consistency: Ensures all environments (dev, test, prod) use the same version.
• Compliance: Meets ISO/IEC 12207 standards.
• Example: "NTC uses SVN to manage router firmware versions to avoid configuration drift."

Q3: "Calculate the defect density for a system with 50 defects and 10,000 lines of code." Answer: $$\text{Defect Density}=\frac{50}{10,000}=0.005\text{ defects/LOC}$$ → 5 defects/KLOC (acceptable if target is <10).

Final Checklist for Exams

✅ Define all key terms (review, maintenance, CM). ✅ Draw at least one diagram (process, state, or comparison). ✅ Use Nepalese examples (eSewa, Khalti, NTC). ✅ Show calculations for metrics (defect density, MTTR). ✅ Discuss tools (Git, SonarQube, JIRA). ✅ Compare (e.g., walkthrough vs. inspection, corrective vs. perfective maintenance).