Coursify

SOFTWARE ENGINEERING

Maintenance Process and Maintenance Models

This section examines the structured process followed during software maintenance and the models used to organize maintenance work, from change request initiation through implementation, validation, and release.

Learning Goals

  • Describe the major phases of a software maintenance process, including problem identification, analysis, design, implementation, testing, and deployment.
  • Trace the lifecycle of a maintenance request from submission to closure, identifying key deliverables and decision points at each stage.
  • Compare commonly used maintenance models in terms of workflow, feedback handling, risk control, and suitability for legacy or evolving systems.
  • Analyze how process standardization improves traceability, accountability, and consistency in maintenance operations.
  • Select an appropriate maintenance process or model for a given software scenario based on system criticality, change frequency, and organizational constraints.

Software Maintenance is a vital phase of the software life cycle, responsible for ensuring that a software system remains functional, reliable, and relevant after its initial deployment. Far from being a simple exercise in "bug fixing," software maintenance is a structured, engineering discipline that encompasses all modifications made to a software product after delivery. The overarching goal of software maintenance is to preserve the business value of the system over time, optimize performance, and manage code evolution while controlling operational costs.

Historically, software maintenance is classified into four primary categories established by Lientz and Swanson:

  1. Corrective Maintenance: Reactive modification to repair discovered software defects (e.g., resolving a null-pointer exception or fixing a race condition).
  2. Adaptive Maintenance: Modifications performed to keep the software usable in a changing environment, such as migrating to a new operating system, database engine, or cloud environment.
  3. Perfective Maintenance: Proactive enhancements that improve system performance, maintainability, or user experience (e.g., refactoring code to reduce complexity or optimizing database queries).
  4. Preventive Maintenance: Also referred to as software re-engineering or active refactoring, this involves modifying software to detect and correct latent faults before they manifest as active failures, enhancing future maintainability.

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩

  2. ISO/IEC/IEEE 14764:2022 - International Standard: Software Engineering - Software Life Cycle Processes - Maintenance. ↩

  3. Lientz & Swanson's Maintenance Survey - Historical categorization of software maintenance effort and industry distributions. ↩

Software Maintenance Models & Processes

The Distribution of Maintenance Effort

Many developers mistakenly believe that corrective maintenance (fixing bugs) consumes the majority of a software team's maintenance budget. However, empirical studies show a very different reality. Barry Boehm's pioneering research in software economics introduced the concept of the Annual Change Traffic (ACTACT), which measures the fraction of software code that changes during a year:

ACT=KLOCadded+KLOCdeletedKLOCtotalACT = \frac{KLOC_{added} + KLOC_{deleted}}{KLOC_{total}}

Where ACTACT represents the proportion of code churn, and KLOCKLOC refers to thousands of lines of code. Based on the ACTACT and the classic Lientz-Swanson study, maintenance effort is highly skewed toward perfecting and adapting the system rather than firefighting bugs.

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩

  2. Lientz & Swanson's Maintenance Survey - Historical categorization of software maintenance effort and industry distributions. ↩

Distribution of Software Maintenance Effort by Category

Based on the classic Lientz and Swanson industry study

The Software Maintenance Life Cycle (SMLC)

To execute maintenance changes systematically without compromising system stability, organizations implement the Software Maintenance Life Cycle (SMLC). The SMLC provides a rigorous sequence of engineering activities that ensures every change is fully analyzed, documented, and verified.

The standard ISO/IEC/IEEE 14764 specifies that the maintenance process connection in software life cycles consists of seven major phases:

  1. Problem Identification: A maintenance request is initiated by a user or an automated system. It is logged, assigned a unique ID, and categorized by type (e.g., corrective or perfective).
  2. Analysis: The maintenance team performs an impact analysis to understand which software components are affected, conducts a feasibility study, and estimates the engineering effort and costs.
  3. Design: High-level and detailed designs are developed for the modification. Crucially, test cases are designed concurrently, including specific safety, security, and regression tests.
  4. Implementation: Developers modify the source code, conduct code reviews, and perform unit testing.
  5. System Testing: The fully integrated system undergoes extensive regression testing to ensure the modifications have not introduced secondary defects.
  6. Acceptance Testing: The customer, end-users, or a designated third-party verifies that the modification meets the requirements specified in the initial request.
  7. Delivery & Release: The updated software is deployed to production, system documentation and user manuals are updated, and a post-implementation review is conducted.

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩

  2. ISO/IEC/IEEE 14764:2022 - International Standard: Software Engineering - Software Life Cycle Processes - Maintenance. ↩

The Software Maintenance Life Cycle (SMLC) Phases

  1. 1
    Step 1

    Upon receiving a request, engineers classify it as corrective, adaptive, perfective, or preventive. They assign a severity level and establish a baseline tracing link between the request and the software configuration repository.

  2. 2
    Step 2

    Maintainers perform static and dynamic analysis to map dependencies. They evaluate how the proposed change will affect existing modules, calculate the estimated effort, and perform a cost-benefit analysis.

  3. 3
    Step 3

    Architects design the changes at both the module and database level. They define the modified interface signatures and establish a comprehensive verification plan, specifying the regression test suite requirements.

  4. 4
    Step 4

    Software engineers write the code changes, maintain coding standards, update local API documentation, and perform unit testing to verify that the changed module functions correctly in isolation.

  5. 5
    Step 5

    The changed components are integrated back into the main branch. Testers run automated regression test suites to verify that the unmodified parts of the system still operate correctly without side effects.

  6. 6
    Step 6

    End users or QA representatives run acceptance test cases to validate that the change satisfies the original business objectives and meets performance criteria.

  7. 7
    Step 7

    The maintenance release is packaged, versioned, and deployed. A formal post-implementation review is conducted to evaluate the maintenance performance and capture lessons learned for future cycles.

Standardizing for Traceability

Adhering to standardized maintenance processes, such as ISO/IEC/IEEE 14764, establishes a robust chain of custody for every code change. This ensures that every line of modified code can be traced back to its originating Change Request (CR), the developer who wrote it, the design document that authorized it, and the test cases that validated it. This high traceability drastically reduces maintenance risks and simplifies audit compliance in regulated industries.

The Change Request (CR) Lifecycle

At the heart of any standardized maintenance process is the Change Request (CR) lifecycle. A CR represents the administrative and technical vehicle that carries a modification from its initial submission to its ultimate deployment and closure.

A critical control point in this lifecycle is the Change Advisory Board (CAB). The CAB is a cross-functional body composed of developers, QA leads, operations managers, and business stakeholders. The CAB reviews the technical impact analysis, cost estimates, and risk assessments of proposed changes to authorize their implementation and scheduling.

The typical timeline of a CR highlights the key deliverables and decision points at each milestone:

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩

The Lifecycle Timeline of a Change Request (CR)

Change Request Submission

Stage 1

The user submits a CR detailing the anomaly or requested enhancement. Key deliverables: Initial CR ticket, system logs, and reproduction steps."

Technical Impact Assessment

Stage 2

Maintainers evaluate the system architecture to identify affected modules. Key deliverables: Impact Analysis Report and estimated labor hours."

CAB Review & Authorization

Stage 3

The Change Advisory Board evaluates business impact, risks, and budgets. Key deliverables: Approval/Rejection status and prioritized backlog position."

Baseline Checkout & Modification

Stage 4

The source code is checked out of the SCM repository. Key deliverables: Modified source code files, unit test reports, and updated design docs."

QA Regression Audit

Stage 5

QA teams execute regression suites and perform code standards audits. Key deliverables: System test reports and compliance certificates."

User Acceptance & Deployment

Stage 6

Users validate the changes, and the release is deployed to production. Key deliverables: Formal sign-off, updated user manuals, and closed CR ticket."

The Hotfix Trap

Organizations often bypass the standard Change Request lifecycle during critical production outages, resorting to the ad-hoc Quick-Fix model. While emergency patches are sometimes necessary, bypassing the Change Advisory Board (CAB) and skipping regression testing introduces a high risk of 'regression cascade'—where a quick bug fix breaks other dependent modules, leading to even greater downtime.

Comparing Software Maintenance Process Models

Software engineering research has produced several distinct models to organize and manage maintenance work. These models vary significantly in their workflows, feedback handling, risk control mechanisms, and suitability for different software paradigms.

  1. Quick-Fix Model: A reactive, firefighting model where bugs are identified and patched directly in the code with minimal design review or impact analysis. It is fast and low-cost initially, but rapidly degrades system architecture.
  2. Iterative Enhancement Model: An evolutionary model that treats maintenance as cyclic development. Each modification cycle involves analyzing the existing system, redesigning the affected components to control complexity, and implementing the changes.
  3. Re-use Oriented Model: A proactive model that assumes the existing system contains high-value components that can be extracted, modified, and integrated into a new architecture, maximizing the reuse of tested assets.
  4. Boehm's Economic Model: A closed-loop management model that focuses on economic principles. It requires cost-benefit analysis for every change, ensuring that maintenance decisions are driven by return on investment (ROIROI) and budget constraints.
  5. Taute's 8-Phase Model: A highly structured, sequential model that guides changes through a strict cycle: Change Request, Estimate, Schedule, Programming, Test, Documentation, Release, and Operation.
  6. Osborne's Model: A management-centric model that highlights communication, quality assurance, and standards audits. It argues that most technical problems in maintenance are due to poor management and coordination.
Maintenance ModelWorkflow StyleFeedback HandlingRisk ControlBest Suited For
Quick-FixDirect, ad-hoc patchingReactive (Bug-by-bug)Extremely LowLegacy systems near retirement; minor emergency patches
Iterative EnhancementEvolutionary, design-firstProactive & ContinuousHigh (Reduces complexity)Long-lived systems undergoing active evolution
Re-use OrientedAsset extraction & modificationComponent-focusedMediumSystems undergoing migration or legacy modernization
Boehm's EconomicClosed-loop economic analysisROI and budget-drivenHigh (Financial focus)Commercial and enterprise software systems
Taute's 8-PhaseSequential, cyclical stepsFeedback at releaseHigh (Procedural control)Highly regulated environments with strict workflows
Osborne's ModelSQA-driven, audit-centricManagement reviewsVery High (Standards-focused)Safety-critical or high-reliability systems

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩ ↩2

  2. Osborne's Model of Software Maintenance - Structural management controls and quality standards in software maintenance engineering. ↩

The Quick-Fix Model is an ad-hoc, firefighting approach centered on patching bugs as rapidly as possible with minimal design overhead. While highly responsive and low-cost in the short term, it neglects long-term architectural health, introducing high risk of code degradation and technical debt.

Workflow: Identify Bug -> Apply Hotfix -> Deploy. Feedback Handling: Purely reactive. Suitability: Legacy systems undergoing retirement or critical emergency hotfixes. Risk Control: Very low; likely to introduce secondary regression defects.

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩

Selecting the Right Maintenance Process Model

Choosing the correct maintenance model depends on specific software scenarios, system criticality, change frequency, and organizational constraints.

Scenario A: Safety-Critical Aerospace System

  • Constraints: Extreme system criticality, zero-tolerance for failure, strict regulatory compliance (e.g., DO-178C).
  • Recommended Model: Osborne's Model or Taute's 8-Phase Model2.
  • Rationale: The strict procedural controls, mandatory Software Quality Assurance (SQA) audits, and comprehensive design reviews minimize the risk of introducing catastrophic defects.

Scenario B: Rapidly Growing SaaS E-Commerce Platform

  • Constraints: High change frequency, actively evolving feature set, long system lifespan, moderate criticality.
  • Recommended Model: Iterative Enhancement Model.
  • Rationale: Treating modifications as evolutionary development cycles controls code complexity, maintains design patterns, and accommodates continuous feedback without letting technical debt build up.

Scenario C: Legacy COBOL Banking Subsystem

  • Constraints: High age, lack of documentation, planned retirement in 18 months, critical bug reported.
  • Recommended Model: Quick-Fix Model (for emergency bugs) or Re-use Oriented Model (if migrating to a modern microservices architecture).
  • Rationale: Re-engineering the entire system is economically unfeasible due to its short remaining lifespan, justifying a temporary quick-fix patch, while any modernization effort should focus on extracting reusable business logic.

Footnotes

  1. Software Maintenance: Concepts and Practice - Grubb, P., & Takang, A. A. (2003). Chapter 5: The Maintenance Process and Chapter 6: Maintenance Process Models. ↩ ↩2 ↩3

  2. Osborne's Model of Software Maintenance - Structural management controls and quality standards in software maintenance engineering. ↩

Software Maintenance Deep-Dive & FAQs

Knowledge Check

Question 1 of 4
Q1Single choice

Which category of software software maintenance describes modifications performed to proactively restructure code and prevent future failures before they occur?

Previous

Next