Program Maintenance
Software doesn’t end when it ships. After deployment, programs need ongoing attention—fixing bugs users discover, adapting to new environments, adding requested features, and handling emergencies. Maintenance typically consumes the largest portion of a program’s total lifecycle cost. Understanding maintenance types, documentation practices, and system modeling tools is essential for anyone involved in software development.
Types of Program Maintenance
Corrective Maintenance
Corrective maintenance fixes bugs and defects found after deployment. Despite thorough testing, users inevitably discover problems in real-world conditions that testing didn’t cover. A calculation might produce wrong results for edge cases, a form might crash when certain fields are left blank, or a report might format incorrectly for specific data patterns. Corrective maintenance is reactive—you’re responding to problems rather than preventing them. It requires reproducing the bug, identifying the root cause in code, implementing a fix, and testing to ensure the fix doesn’t introduce new problems.
Adaptive Maintenance
Adaptive maintenance modifies software to work in a changed environment. When Windows releases a major update, some programs need modifications to remain compatible. Database upgrades, new hardware, regulatory changes (like new tax rules), and organizational restructuring all trigger adaptive maintenance. The software’s core functionality doesn’t change—it’s adapted to new external conditions. This type of maintenance is predictable in that environmental changes are often announced in advance, giving developers time to prepare.
Perfective Maintenance
Perfective maintenance enhances software based on user feedback and evolving needs. Users might request a new report format, faster search, or a more intuitive interface. Performance optimization—making the program run faster or use less memory—also falls here. Unlike corrective maintenance, nothing is technically broken. The software works as originally designed, but users want more from it. Perfective maintenance often represents the largest share of maintenance work because user expectations continuously evolve.
Emergency Maintenance
Emergency maintenance is unplanned, urgent corrective work for critical failures. The payroll system crashes on payday. The website goes down during peak traffic. A security vulnerability is actively being exploited. Emergency maintenance requires immediate response, often with limited time for thorough analysis. Quick fixes might introduce technical debt—shortcuts that work now but need proper solutions later. Having good documentation and well-structured code makes emergency maintenance less chaotic.
Problem Areas in Program Maintenance
Several factors make maintenance difficult. Poorly written original code with no comments, unclear variable names, and tangled logic is hard to understand and modify safely. Missing or outdated documentation forces maintainers to reverse-engineer the program’s intent. Staff turnover means the people maintaining code rarely wrote it. Testing modifications thoroughly is challenging—a fix in one area might break something unrelated. Dependencies between modules mean changes cascade unpredictably. Legacy systems using outdated technologies limit what modern developers can do.
Cost Issues in Software Maintenance
Maintenance costs are driven by program complexity, code quality, documentation quality, and the frequency of change requests. Studies consistently show maintenance consuming 60-80% of total software costs. Poorly designed software costs far more to maintain than well-designed software. Investing in clean code, thorough testing, and comprehensive documentation during initial development reduces long-term maintenance costs significantly. The cheapest bug to fix is one that never reaches production.
Impact of Software Errors
Software errors range from minor inconveniences to catastrophic failures. A typo in a displayed message is minor. A calculation error in financial software can cost millions. Medical device software errors can endanger lives. The earlier an error is detected, the cheaper it is to fix. An error found during requirements costs perhaps $100 to fix; the same error found in production might cost $10,000 or more, considering user impact, emergency response, and reputation damage.
Program Documentation
Requirements and Importance
Documentation serves multiple purposes: it helps developers understand existing code, guides users in operating the software, assists administrators in deploying and configuring systems, and provides auditors with compliance evidence. Without documentation, knowledge lives only in people’s heads—and people leave. Good documentation enables: new team members to come up to speed quickly, maintenance programmers to understand code they didn’t write, users to solve their own problems, and management to make informed decisions about the system.
Types of Documentation
User documentation explains how to use the software—installation guides, user manuals, quick-start guides, and FAQs. Technical documentation explains how the software works—architecture overviews, API references, code comments, and design documents. System documentation covers the overall system—hardware requirements, network configuration, database schemas, and deployment procedures. Process documentation records development processes—coding standards, testing procedures, and change management workflows.
Program Specification
A program specification precisely defines what the program should do. It includes functional specifications (features and behavior), data specifications (what data the program handles), interface specifications (how users and other systems interact with it), and performance specifications (speed, capacity, reliability requirements). The specification serves as a contract between developers and stakeholders—“this is what we agreed the program will do.”
System Flowcharts
A system flowchart shows the flow of data through an entire system, including manual processes, computer processes, and data stores. Unlike program flowcharts (which show logic within a single program), system flowcharts show how multiple programs, files, and processes interact.
Standard elements: Rectangles represent processes (computer or manual). Parallelograms represent input/output. Cylinders or open rectangles represent data stores (files, databases). Arrows show data flow direction. Document symbols represent printed output. Manual operation symbols represent human activities.
A system flowchart for order processing might show: customer submits order form (document) → data entry operator enters order (manual process) → order validation program (process) → validated orders stored in database (data store) → invoice generation program (process) → printed invoice (document).
Data Flow Diagrams (DFD)
A Data Flow Diagram models how data moves through a system. DFDs focus on what the system does with data rather than how it does it. They use four symbols:
Process: A circle or rounded rectangle representing a transformation of data. Each process has a name and number. Data Flow: An arrow showing data movement between processes, stores, and external entities. Each arrow is labeled with the data it carries. Data Store: Parallel lines or an open rectangle representing where data is held (a file, database, or even a physical filing cabinet). External Entity: A rectangle representing something outside the system that sends or receives data (a customer, another system, a government agency).
DFD Leveling
DFDs use leveling to manage complexity. The Context Diagram (Level 0) shows the entire system as a single process, with external entities and data flows into and out of the system. It provides the highest-level view. Level 1 decomposes the single process into major sub-processes. Level 2 decomposes each Level 1 process further. You continue decomposing until each process is simple enough to specify directly. Each level must be consistent—data flowing into a parent process must appear in the child diagram.
Guidelines for Drawing DFDs
Label all data flows with meaningful names. Number processes consistently (1.0, 1.1, 1.2 for Level 1 decomposition of process 1). Don’t show control flow (decisions)—DFDs show data movement only. Ensure data conservation: data entering a process must either leave it or be stored. Avoid overcrowding: if a diagram has more than 7-9 processes, decompose further. Every process must have at least one input and one output data flow.