CSC364 Software Engineering

Software EngineeringUnit 89 min read

Software Maintenance & Evolution: Types, Models, Risks & SCM

Unit 8 of Software Engineering covers the lifecycle beyond deployment—corrective, adaptive, perfective, and preventive maintenance; COCOMO effort estimation; software configuration management (SCM) activities; risk analysis in maintenance; and real-world examples from eSewa, Ncell, and NEPSE. Includes visuals of versio

TAKEAWAYS:

  • Maintenance types are classified by purpose (corrective, adaptive, perfective, preventive) and differ in cost/benefit trade-offs—corrective is the most resource-intensive due to emergency fixes.
  • COCOMO model estimates effort (person-months) and time for organic/embedded projects using KLOC (thousands of lines of code) and mode-specific formulas.
  • Software Configuration Management (SCM) tracks versions, baselines, and changes using tools like Git; its activities (identification, control, status accounting, auditing) prevent chaos in evolving systems.
  • Risk analysis in maintenance identifies threats (e.g., legacy tech obsolescence, unplanned changes) and uses mitigation strategies like prototyping or incremental updates.
  • Prototyping (evolutionary vs. throwaway) reduces risk by validating requirements early—eSewa’s mobile app updates use evolutionary prototyping for iterative feature additions.
  • Ethics in maintenance requires transparency (e.g., Ncell’s data privacy fixes) and balancing stakeholder needs with technical debt.

What is Software Maintenance?

Software maintenance is the modification of a software product after delivery to correct faults, improve performance, or adapt to a changing environment. It accounts for 50–80% of total software lifecycle costs (IEEE). Unlike development, maintenance focuses on existing systems and must balance stability vs. evolution.

Why Maintenance Matters

stateDiagram-v2
    [*] --> Active: System in use
    Active --> Fault: Bug reported
    Active --> Change: New requirements
    Active --> Enhance: Performance needs
    Active --> Prevent: Security patch
    Fault --> Corrective: Fix bug
    Change --> Adaptive: Update features
    Enhance --> Perfective: Optimize code
    Prevent --> Preventive: Add safeguards
    Corrective --> Active
    Adaptive --> Active
    Perfective --> Active
    Preventive --> Active

Real-world example: When NEPSE’s trading platform migrated from a monolithic to a microservices architecture (2020–2022), it required adaptive maintenance to integrate new APIs while ensuring backward compatibility for existing brokers.


Types of Software Maintenance

Maintenance is classified by goal and trigger. The four primary types are:

Type Definition Trigger Example (Nepal) Cost Impact
Corrective Fixes faults found in production. Bug reports, crashes. eSewa app crashes during Dashain sales (2023) due to high transaction load. High (emergency fixes).
Adaptive Adapts software to changes in environment (OS, hardware, regulations). New laws, tech upgrades. Ncell’s USSD service updated to support Nepal’s new telecom licensing rules (2022). Medium (planned updates).
Perfective Improves non-functional attributes (performance, usability, security). User feedback, benchmarks. Daraz’s mobile app optimized for low-bandwidth areas in rural Nepal. Medium (iterative).
Preventive Prevents future problems (refactoring, documentation, security patches). Audit findings, tech debt. Khalti’s PCI-DSS compliance updates to prevent fraud. Low (proactive).

Worked Example: COCOMO Effort Estimation for Maintenance

Problem: A banking system (320 KLOC) needs maintenance in embedded mode (e.g., core banking software). Calculate:

  1. Effort (person-months).
  2. Development time (months).

COCOMO (Embedded Mode) Formulas:

  • Effort (EM) =
  • Time (TM) =

Solution:

  1. Effort:
  2. Time: Interpretation: The bank must allocate ~2066 person-months (e.g., 10 developers × 20 months) for maintenance, with corrective maintenance likely dominating due to high-stakes transactions.

Software Configuration Management (SCM)

SCM ensures consistency, traceability, and control over software changes. Its four key activities are:

mindmap
  root((SCM Activities))
    Identification
      Versioning
      Baselines
    Control
      Change Requests
      Approval Workflows
    Status Accounting
      Metrics (e.g., lines changed)
      Audit Trails
    Auditing
      Compliance Checks
      Post-Mortems

SCM in Real-World Projects

  1. eSewa’s Payment Gateway:

    • Tool: GitLab CI/CD.
    • Process: Every transaction-related code change is peer-reviewed and automatically tested before merging to main.
    • Outcome: Reduced downtime during festivals (e.g., Tihar) by 40%.
  2. NTC’s Fiber Optic Network Upgrades:

    • Challenge: Managing legacy and new software for different regions.
    • Solution: SCM tracks configuration files per district, ensuring rollback capability.

Why SCM is Required:

  • Avoids "DLL Hell": Conflicts when multiple versions of a library are used (e.g., Python requests module).
  • Regulatory Compliance: Banks (e.g., NMB Bank) must audit changes for audit trails.
  • Disaster Recovery: Restore to a known baseline after a crash (e.g., NEPSE’s 2018 outage).

Risk Management in Maintenance

Maintenance introduces unique risks due to legacy dependencies and unpredictable changes. The risk analysis stage involves:

  1. Risk Identification:

    • Technical: Obsolescence (e.g., COBOL systems in NTC’s billing software).
    • Operational: Downtime during updates (e.g., Pathao’s driver app crashes).
    • Security: Vulnerabilities in third-party libraries (e.g., Log4j in Daraz’s backend).
  2. Risk Assessment:

    • Likelihood (Low/Medium/High) × Impact (Cost/Reputation) = Risk Priority.
    • Example: High risk = Ncell’s SMS gateway failure during elections.
  3. Mitigation Strategies:

    • Prototyping: Test changes in a staging environment (e.g., Khalti’s sandbox).
    • Incremental Updates: Roll out features gradually (e.g., eSewa’s QR code updates).
    • Automated Testing: Use CI/CD pipelines to catch regressions.

risk management matrix**Prioritizing risks in software maintenance (Image: Peter Gladdish, CC BY 4.0, via Wikimedia Commons)


Prototyping in Maintenance

Prototyping validates requirements before full implementation, reducing rework costs. Two models:

Model Definition Use Case Example (Nepal)
Evolutionary Prototypes evolve into the final product. Systems with unclear requirements. eSewa’s mobile app: Started as a prototype in 2016, iteratively added features.
Throwaway Prototypes are discarded after validation. High-risk projects (e.g., new algorithms). NTC’s 5G network planning: Prototyped in a lab before nationwide rollout.

Advantages of Prototyping:

  • Reduces miscommunication between stakeholders (e.g., NEPSE traders and developers).
  • Lowers maintenance costs by catching flaws early.

Disadvantages:

  • Throwaway prototypes waste resources if requirements stabilize.
  • Evolutionary prototypes may accumulate technical debt.

Exam Tip: How to Score Full Marks

  1. For COCOMO Questions:

    • Always state the mode (organic/embedded/semi-detached) and use the correct formula.
    • Show step-by-step calculations (e.g., exponentiation first, then multiplication).
    • Interpret the result (e.g., "This indicates a large project requiring 20+ developers").
  2. For Maintenance Types:

    • Define each type clearly (1 mark).
    • Give a Nepalese example (e.g., "Ncell’s adaptive maintenance for Jio integration").
    • Compare two types (e.g., "Corrective is reactive; perfective is proactive").
  3. For SCM:

    • Draw a simple Git workflow diagram (identification → control → status accounting).
    • Mention tools (Git, SVN, Jenkins) and activities (baselining, auditing).
  4. For Risk Management:

    • Use a matrix to show risk prioritization.
    • Link risks to real scenarios (e.g., "Pathao’s risk of driver app crashes during peak hours").
  5. For Prototyping:

    • Differentiate evolutionary vs. throwaway with a table.
    • Relate to a local case (e.g., "eSewa’s app used evolutionary prototyping").

Based on the TU BSc CSIT syllabus for Software Engineering (CSC364), unit 8.

Discussion

Loading…