Software Maintenance: Need, Importance & Software Evolution Explained
The story does not end when software is released. Real users, new rules and changing technology bring new work. Let us understand that work through one simple college result portal.
Open chapter map · What will you learn?
What is software maintenance? First understand the basic idea
Imagine that a college has launched a result portal. Students can log in and see their marks. The portal is working, so the team releases it. After a week, one subject shows the wrong total. Later, the university changes its grading rule. A year later, thousands of students use the portal at once and the result page becomes slow.
Should the college throw away the portal and build a new one for every such change? Usually no. The team studies the existing system, makes a controlled change, tests it, and releases an updated version. That work is software maintenance.
Definition you can write: Software maintenance is the systematic modification of an existing software product to correct faults, adapt it to changes, improve its qualities or functions, and preserve its usefulness and integrity.
The word maintenance may sound like only repairing a broken program. In Software Engineering it has a wider meaning. Teams also improve working software and prepare it for future changes. Maintenance planning can begin before release; the actual change work continues throughout the product's life.
It may involve code, tests, configuration, interfaces, requirements, user help and documentation. Routine server operation, such as taking a backup every night, is related to running the service but is not itself a software modification. This distinction helps you write a precise exam answer.
Correct it
Subject total is calculated incorrectly.
Adapt it
A new university API must be used.
Improve it
The report takes too long to open.
Prevent it
An old library will soon be unsupported.
Why is software maintenance needed?
Think of software as a service used by real people, not as an assignment submitted once. New situations appear after release. Some were missed in testing; others did not exist when the software was built. The need for maintenance comes from these changes.
Real data reveals a wrong marks formula that sample test data did not expose. The defect must be investigated and corrected.
Students ask for subject-wise downloads or the college changes how grades are displayed. The product must continue to serve them.
An operating system, browser, database, payment service or connected API changes. Existing software may need an update to remain compatible.
A page works but loads slowly during result day. The team improves performance without changing the purpose of the page.
An outdated component may become unsafe or hard to support. Planned updates reduce the chance of a later failure.
University policy, accessibility expectations or legal requirements may change. The system needs the relevant, approved changes.
Notice the difference: a bug fix responds to a problem in the product; adapting to a new API responds to a change around the product. Both are maintenance, but they solve different needs. When a new rule is requested, requirement change management helps record and assess it before the team modifies code.
Importance of software maintenance
“Why needed?” asks what causes the work. “Why important?” asks what value the work gives. This small difference often improves a 5-mark answer.
Correcting defects helps students see accurate marks and protects trust in the portal.
Adaptation keeps the portal usable when connected systems and college rules change.
Improvement can make pages faster, clearer and easier to use.
Preventive work can remove known weak points before they cause serious trouble.
A carefully maintained product can serve users for longer without unnecessary rebuilding.
Impact checks, version records and tests reduce the chance that one fix breaks another feature.
Maintenance is an investment, but it still needs sensible priorities. A small cosmetic change and a marks-calculation defect do not carry the same urgency. The team should consider users affected, risk, cost, and the consequences of waiting.
Types of software maintenance, explained without confusion
Many semester books teach four main types: corrective, adaptive, perfective and preventive. First identify the problem the team is trying to solve. Then the type becomes easy.
Corrective maintenance
Meaning: modify the delivered software to fix a discovered fault.
Ask: What existing behaviour is incorrect?
Portal example: A student scored 86, but the total page shows 68 because two columns were mixed. Fix the calculation and check affected reports.
Adaptive maintenance
Meaning: modify software so it remains usable in a changed environment.
Ask: Which external rule, platform or interface changed?
Portal example: The university replaces its marks API. The portal updates the connection and data mapping to work with the new API.
Perfective maintenance
Meaning: enhance a delivered product to improve its performance, usability, documentation or other quality.
Ask: How can we improve the current experience?
Portal example: The result page works, but loads slowly for thousands of students. Improve the query and page response.
Preventive maintenance
Meaning: make a change now to remove a latent problem or reduce future failure risk.
Ask: What likely issue can we prevent?
Portal example: Replace an unsupported dependency and add tests before an update breaks result generation.
Correct the fault · Adapt to outside change · Polish the working product · Prevent the next problem.
| Type | Main reason | Result-portal example | Time focus |
|---|---|---|---|
| Corrective | Found fault | Repair wrong total | Existing problem |
| Adaptive | Changed environment | Support new university API | New external condition |
| Perfective | Improve quality or use | Speed up result page | Better current product |
| Preventive | Avoid future issue | Replace risky old dependency | Possible future problem |
Advanced exam note: The four-type list is common in teaching. The IEEE Computer Society's newer SWEBOK guide also discusses additive maintenance separately for adding functionality, and emergency maintenance for an urgent temporary action. If your question asks for the four traditional types, write the four explained above. If it asks for the newer classification, mention these additional categories and follow your syllabus wording.
Two differences students often mix up
Corrective vs preventive: corrective fixes a defect after it is discovered in use; preventive handles a latent fault or risk before it causes a live failure. Replacing a library can be preventive if done before a problem, but the exact category depends on why the change was requested.
Adaptive vs perfective: adaptive responds to a change outside the product, such as a new API; perfective improves what users experience or how well the product works. A single change request can contain both. In an exam, state the main reason and explain your choice.
How does the software maintenance process work?
A responsible team does more than “open code and fix it.” It records the request, understands the existing product, checks the effect of a change, tests the result and tracks the released version.
- 1RecordWhat happened? Who is affected?
- 2UnderstandReproduce or study the request.
- 3AnalyseCheck impact, risk and priority.
- 4ChangeUpdate code and related records.
- 5TestCheck fix and older features.
- 6ReleaseDeploy, monitor and document.
Step 1 · Record the request clearly
A report such as “marks wrong” is too vague. Record the student record used for the check, expected total, actual total, page or report, software version, and how many students may be affected. Handle real student data according to the organisation's privacy rules.
Step 2 · Understand the existing system
Read the rule, code and tests. Reproduce the fault if possible. The result may come from a calculation, a database field, an API mapping or a PDF report. Changing the first suspicious line without understanding the flow can create another defect.
Step 3 · Perform impact analysis
Impact analysis means finding what else the proposed change may affect: related features, data, interfaces, tests, documents, time, cost and risk. For the marks example, the team checks the dashboard, downloadable report, rank list and notifications. It decides priority before implementation.
Step 4 · Make the approved change
Update the necessary code and, when needed, the requirement, design notes, test cases and user instructions. Keep the change reviewable and record it in version control. A fix without updated tests or documentation becomes difficult for the next maintainer.
Step 5 · Test the change and nearby behaviour
First check that the reported case now shows the correct total. Then repeat relevant older tests to see whether the fix has broken a working feature. This is regression testing. A marks-calculation change may affect a PDF, result filter and rank list even if their screens were not edited.
Step 6 · Release and watch the result
Deploy the approved version, communicate the change where useful, monitor errors and be ready to revert if a serious issue appears. Close the request only after the team checks the intended result.
Result page shows 68 instead of 86 for a verified marks record.
Dashboard, PDF report and rank list use the same total field.
Fix the field mapping; test correct totals and all three outputs before release.
This is why maintenance uses requirements, design, testing and change control again, but on an existing product. To understand why modular design reduces the spread of a change, see coupling and cohesion in software design.
What is software evolution, and how is it related to maintenance?
Software evolution is the gradual change of a software product across its lifetime. The result portal we use today may have different features, rules and internal structure from the first released version. Many small and large maintenance changes produce that evolution.
Students view marks after login.
Wrong total is fixed.
New grading rule is supported.
Report loads faster.
Old integration is replaced.
Analyse one request, change the existing product, test it, and release the update.
Observe how the same product grows and adapts across many releases.
Software does not physically wear down like a machine part. Yet it can become less suitable because people expect new things, surrounding technology changes, and the code becomes harder to understand after repeated changes. That is why evolution needs planning, tests and maintainable design.
Two useful ideas from Lehman's software-evolution work
A software product used in a changing real-world environment needs changes to remain satisfactory. If the grading rule changes and the portal does not, users cannot depend on it.
Repeated additions can make a system harder to understand unless the team actively simplifies and improves its structure. Good maintenance makes room for such work.
These ideas explain a practical rule: do not only add features; keep the software understandable enough to change again. For a particular product, the team still needs evidence to decide which changes are worthwhile.
Maintenance, reengineering and replacement are not identical
Maintenance covers controlled changes to the existing system. Reengineering may restructure a larger part of it to improve its qualities while preserving needed behaviour. Replacement means moving to a different product or rebuilding it when keeping the old one is no longer the best option. Large reengineering work can be part of a long-term maintenance plan.
Why is maintenance difficult, and how can a team make it easier?
Changing an existing product has one extra constraint: users already depend on its current behaviour. The team must improve one part while keeping the other parts trustworthy.
The original developers may have left and documents may be missing. Read the code, trace inputs and outputs, and write down what is learned.
A small result-field change may affect reports and ranking. Use impact analysis and clear module boundaries.
A new fix can damage an older feature. Keep meaningful automated and manual tests for important user journeys.
Unsupported tools and integrations may be harder to update. Plan upgrades before an urgent failure forces them.
The team has limited capacity. Prioritise by impact and risk; record whether effort goes to defects, adaptation or improvement.
Quick fixes without tests or clear design can make later work slower. Refactor the risky area when the expected benefit justifies it.
Meaning of maintainability: how easily the product can be understood and changed safely. Clear modules, sensible names, tests, version history and useful documentation help. They do not remove the need to investigate each change.
Maintenance is not automatically a fixed percentage of total cost for every project. Its effort depends on product age, design, team knowledge, changes in the environment and user demands. In an exam, explain the reasons instead of writing an unsupported universal number.
Exam-ready answers, practice and quick revision
Define software maintenance.
Software maintenance is the modification and support of an existing software product to correct faults, adapt to a changing environment, improve the product and prevent future problems. It helps the software remain useful after release.
Explain the need and importance of software maintenance.
Software maintenance is needed because software is used in a changing environment after release. Real use may reveal defects, users may request improvements, connected technology may change, and security or performance risks may appear. For example, a college result portal may need a marks-calculation fix and later an update for a new university API.
Maintenance is important because it keeps the service correct, reliable, usable and relevant. It protects the value of the existing product and reduces the risk of future failure. A good maintenance process records each request, checks its impact, makes a controlled change, tests related functions and documents the new version. Thus the product can continue serving users instead of being rebuilt for every change.
Explain software maintenance, its types, process and relationship with software evolution.
Introduction: Software maintenance is the systematic modification of existing software so that it continues to satisfy users while preserving its integrity. It starts as part of life-cycle planning and becomes especially visible after the software is delivered. For example, a college result portal may require fixes, compatibility updates and performance improvements after launch.
Need and importance: Maintenance is needed when hidden defects are found, user requirements change, external systems or rules change, or software quality must improve. It keeps the product reliable and useful, controls risk and helps the organisation gain more value from the software already built.
Types: (1) Corrective maintenance repairs a discovered fault, such as a wrong marks total. (2) Adaptive maintenance keeps software usable in a changed environment, such as a new university API. (3) Perfective maintenance improves a working product, such as making the result page faster. (4) Preventive maintenance reduces a future risk, such as replacing an unsupported component before it causes a failure.
Process: The team records a change request, understands the existing system, analyses impact and priority, implements the approved change, tests the changed and related functions, and releases and documents the result. Regression testing is essential because an update to one module may affect another feature.
Software evolution: Over many releases, these controlled changes gradually alter the product. This long-term development is software evolution. Maintenance describes the change activities; evolution describes how the product develops over time. Complexity can increase during evolution unless the team keeps the design understandable and testable.
Conclusion: Maintenance keeps existing software dependable today and able to meet tomorrow's needs. A good answer can end with the flow: Record → Understand → Analyse → Change → Test → Release.
Check your understanding: name the type and the reason
- Portal displays 68 instead of 86 because of a wrong calculation. Corrective: a present fault is fixed.
- University changes the data format of its marks API. Adaptive: an external interface has changed.
- Result page works but takes 20 seconds to load. Perfective: a working feature is improved.
- Team replaces an unsupported library before it causes an outage. Preventive: a likely future problem is reduced.
Quick revision: one glance before the exam
Controlled change to existing software.
Defects, user needs, environment and risk change.
Corrective, adaptive, perfective, preventive.
Check what else a proposed change may affect.
Check that older working features still work.
Long-term product change across releases.
Frequently asked questions
Does software maintenance mean only fixing bugs?
No. Bug fixing is corrective maintenance. Maintenance also adapts software to new conditions, improves a working product and prevents future problems.
When does software maintenance start?
Maintenance planning and preparation can begin before delivery. Many visible maintenance requests arise after the product is in use.
What is the difference between software maintenance and software evolution?
Maintenance is the set of activities used to modify and support an existing product. Evolution is the way that product changes over many versions and over time.
Is adding a new feature perfective maintenance?
Traditional four-type teaching may include user enhancements under perfective. The newer SWEBOK classification also names additive maintenance separately for added functionality. Use the classification requested by your syllabus.
