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 --> ActiveReal-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:
- Effort (person-months).
- Development time (months).
COCOMO (Embedded Mode) Formulas:
- Effort (EM) =
- Time (TM) =
Solution:
- Effort:
- 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-MortemsSCM in Real-World Projects
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%.
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
requestsmodule). - 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:
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).
Risk Assessment:
- Likelihood (Low/Medium/High) × Impact (Cost/Reputation) = Risk Priority.
- Example: High risk = Ncell’s SMS gateway failure during elections.
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.
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
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").
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").
For SCM:
- Draw a simple Git workflow diagram (identification → control → status accounting).
- Mention tools (Git, SVN, Jenkins) and activities (baselining, auditing).
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").
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…