🗄️ OLD — System Delivery, Maintenance, and Evolution (consolidated)

CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. Covers five distinct syllabus items: System Delivery, Maintenance, Software Documentation, Software Re-Engineering, and Software Evolution.

System Delivery

The handoff of a completed system into live use: deployment planning (staged rollout vs "big bang"), data migration from any prior system, user training, and documentation handover. A poorly planned delivery can undo good engineering work upstream — e.g. deploying without a rollback plan turns a minor bug into an outage.

Software Maintenance — Four Types (memorize verbatim)

• Corrective: fixing bugs/defects found after release.
• Adaptive: adjusting the system to a changed environment — new OS version, new hardware, new regulation.
• Perfective: improving performance or adding minor enhancements requested by users.
• Preventive: re-engineering or refactoring before problems occur, to ease future maintenance (sometimes folded into "perfective" in older texts, but FPSC's syllabus lists it as its own category).

Why Maintenance Is the Most Expensive SDLC Phase

Maintenance typically consumes 60–80% of a system's total lifetime cost — far more than initial development:

• Longest duration: a system is maintained for years, sometimes decades, versus a comparatively short development period.
• Accumulated complexity ("software entropy"/"code rot"): every fix and feature addition after release increases interdependencies, making each subsequent change slower and riskier than the last.
• Lost context: original developers move on; new maintainers must first understand existing code before safely changing it.
• Regression risk: every change requires re-testing not just the new feature but the surrounding system.
• All four maintenance types above recur repeatedly across a mature system's life, compounding the cost.

Software Evolution

Distinct from maintenance in emphasis: evolution treats change as continuous and inevitable, not merely corrective. The standard reference point is Lehman's Laws of Software Evolution — two worth naming specifically:

• Continuing Change: a system that is actively used must keep changing, or it becomes progressively less useful/satisfactory.
• Increasing Complexity: unless work is explicitly done to reduce it, a system's structure becomes more complex as it evolves.

A staged model of evolution is often used to visualize the full lifecycle: initial development → evolution → servicing → phase-out.

🔥

Repeated in past papers: 2026, Q6(a) asked directly "why is maintenance the most expensive phase of the software lifecycle?" — naming all four maintenance types explicitly is what separates a strong answer from a generic "because bugs are expensive" response. See 🔥 Most Repeated — Software Engineering for the full model answer.

Software Documentation (2016)

Written material describing a software system — its requirements, design, code, usage, and maintenance — produced alongside development, not bolted on afterward.

• Process documentation: records the development process itself — project plans, schedules, meeting minutes, standards used, test plans. Mainly useful to the development team and project managers.
• Product documentation: describes the finished product, split into:
  • System documentation: requirements spec, design docs, source code comments, test documentation — for developers and maintainers.
  • User documentation: user manuals, installation guides, quick-reference guides, help systems — for end users.
• Why it matters for maintenance: since maintenance consumes 60–80% of a system's lifetime cost (above), good documentation is what lets a maintainer who didn't build the system understand and safely change it — poor documentation is a direct cause of the "lost context" problem under Maintenance.

⚠️

MCQ trap: a user manual is product/user documentation, not process documentation, even though it's written during the process — the category depends on what it describes, not when it's produced.

Software Re-Engineering

Examining and altering an existing system to reconstitute it in an improved form, and implementing that new form — done without changing what the system does, unlike evolution, which may add new capability.

• Re-engineering activities (a sequence worth naming in order):
  1. Source code translation — converting old/legacy code to a modern language or platform.
  2. Reverse engineering — analysing existing code to recover its design/requirements, often when original documentation is lost.
  3. Program structure improvement — restructuring control flow to be clearer and easier to maintain.
  4. Program modularization — reorganizing scattered/duplicated logic into cohesive, well-defined modules.
  5. Data re-engineering — cleaning up or migrating the system's underlying data to match the improved program structure.
• Vs. refactoring (see Design Concepts page): refactoring is a lightweight, continuous technique used during normal development; re-engineering is a larger, deliberate project applied to an existing — often legacy — system. Refactoring is one technique re-engineering may use, not a synonym for it.
• Why re-engineer instead of rewrite: preserves the business value already embedded in a working legacy system and avoids the cost/risk of a full rewrite, while still escaping the "software entropy" problem discussed under Maintenance.

MCQ Trap

• A new government data-protection law forcing a code change is adaptive maintenance (environment changed), not corrective (nothing was broken) and not perfective (nothing was "improved" by request).
• Re-engineering restructures an existing system without changing its functionality; a question describing added functionality is evolution/maintenance, not re-engineering.