Types of Software Maintenance: Corrective, Preventive & Perfective Maintenance
Three changes can happen in the same software, but for three very different reasons. Once you learn to ask why the change is being made, the names become easy to remember.
Why do these three types feel confusing?
Students often memorise three definitions and then get confused in an example question. The reason is simple: all three types can involve changing code and running tests. The action can look similar. The purpose is different.
One example for the whole chapter: A college library uses software to issue books, record return dates, calculate late fees and let students search for books. The system has already been released and is used every day.
Exam shortcut: Wrong now = corrective. Risk later = preventive. Better experience = perfective. Write the reason along with the type; that is stronger than writing only a label.
Corrective maintenance: repair a discovered fault
Definition for exams: Corrective maintenance is the modification of delivered software to correct a discovered fault or failure.
A fault is a problem in the product, such as wrong logic. A failure is incorrect behaviour seen when the system runs. For example, a condition in the fee calculation may be wrong, and a student then sees a fee that should not exist.
Library example, step by step
The library rule says: returning a book on the due date has no late fee. A student returns a book on that date, but the system charges ₹10. The behaviour disagrees with the approved rule. The team records the case, finds a boundary-condition error in date comparison, fixes it and retests the calculation.
On the due date → ₹0 late fee.
On the due date → ₹10 charged.
Make actual behaviour match the existing rule.
Notice that the college did not request a new fee policy. The current software is implementing its existing policy incorrectly. That is why the change is corrective.
What should the team test after the fix?
- Return before the due date → no fee.
- Return exactly on the due date → no fee.
- Return one day late → the approved one-day fee.
- Check that the receipt, account balance and fee report agree.
The due-date case proves the reported bug is fixed. The other cases help catch side effects. Fixing one condition and then checking nearby old behaviour is a practical form of regression testing.
More corrective examples: login rejects a valid password because of a code defect; a PDF shows the wrong total; a search button crashes when the search box is empty. In every case, compare the observed behaviour with the behaviour that was already expected.
Preventive maintenance: remove a risk before it becomes a live failure
Definition for exams: Preventive maintenance modifies delivered software to deal with a latent fault or known risk before it causes a failure in normal use.
Latent simply means hidden or not yet producing a visible live problem. Preventive work is done because the team has a reason to expect trouble. It is not random rewriting “just in case.”
Library example, step by step
A review finds that the fee module accepts a return date even when the date value is invalid. So far, students have supplied valid dates and no live error has been reported. But a future import from another system might send an invalid date and create an incorrect fee. The team adds date validation and test cases before that situation reaches users.
No reported incorrect fee from this date issue.
An invalid date could produce a wrong fee later.
Block bad input and test the risky path now.
The system is already delivered, but the team is acting before a live failure. That makes this a clear preventive example.
Useful preventive work
- Replace a component that is approaching the end of support.
- Add validation and tests for a known but untriggered risky path.
- Separate tangled code so a future change is less likely to damage an unrelated feature.
- Review security-sensitive code and remove a confirmed weakness before it is exploited.
Preventive work is especially useful when failure would affect many users or valuable data. The team should still estimate effort and test that the preventive change has not changed valid behaviour.
Important distinction: If users have already observed the wrong fee and the team repairs that fault, the work is corrective. If the team finds a hidden risk and addresses it before it fails in use, it is preventive. Always read the exact wording of an exam scenario.
Good module boundaries also make preventive changes easier to isolate. The coupling and cohesion chapter explains why a focused module with fewer unnecessary dependencies is easier to maintain.
Perfective maintenance: improve software that already works
Definition for exams: Perfective maintenance improves a delivered software product to make it more useful or improve qualities such as performance, usability, readability and maintainability.
The key point is that the current feature already performs its basic job. Users want it to perform that job better. This does not mean the software becomes perfect or free of all defects.
Library example, step by step
Students can search for a book and get the correct result. However, during busy hours the results appear very slowly. The team measures the current response, improves the search query and index, and checks the response again under a comparable load. The search purpose stays the same; the experience improves.
Correct books are found, but the search feels slow.
Improve the query, index and result display.
Compare response time and check result accuracy.
This is perfective because the main reason is quality improvement. A team can also simplify a confusing screen or improve documentation so staff understand the system better.
How to prove the improvement is real
- Choose the quality to improve: speed, clarity, accessibility or ease of change.
- Record the starting condition, such as response time under a defined load.
- Make the change and measure under similar conditions.
- Check that search accuracy and other working features still remain correct.
Without a starting point, “we made it faster” is only an opinion. A simple before-and-after check makes the result meaningful.
When user feedback asks for an improvement, write down what “better” means. The requirement documentation and change-management chapter shows how to turn a vague request into a clear, testable requirement.
Corrective vs preventive vs perfective maintenance
The most useful comparison is not “what code changed?” It is what problem the team was trying to solve. The same code file can be touched for different maintenance types at different times.
| Point | Corrective | Preventive | Perfective |
|---|---|---|---|
| Main purpose | Repair an observed fault | Reduce a future failure risk | Improve a working product |
| Typical trigger | User report or failed test after delivery | Review, risk finding or approaching obsolescence | User feedback or a measurable quality goal |
| Present state | Expected behaviour is currently wrong | Risk exists, but live failure has not occurred | Basic behaviour works, but could be better |
| Library example | Due-date return wrongly charged | Invalid-date path fixed before harm | Working book search becomes faster |
| Main evidence | Reported case now passes | Risky case covered; valid behaviour preserved | Quality improves; results remain correct |
| Simple phrase | Fix what failed | Stop what may fail | Improve what works |
Memory trick: Corrective looks at a current error. Preventive looks at a future risk. Perfective looks at a better experience. Remember these three questions, and you can rebuild the definitions in the exam without memorising a paragraph word for word.
Where does adaptive maintenance fit?
Adaptive maintenance is another commonly taught category. It changes software so it remains usable when the environment outside the software changes. For example, the college replaces the library database with a new system and the app updates its integration. The old feature may have worked correctly in the old environment; the external change creates the need to adapt.
This chapter focuses on the three types named in the title. If an exam asks for all four traditional types, add adaptive to your answer. The IEEE Computer Society's newer SWEBOK classification also identifies additive and emergency maintenance. Category names can depend on the classification your course follows.
How do you identify the right type in an exam scenario?
Practice: classify these situations
Corrective. The current output is already incorrect.
Preventive. The team acts on a known latent risk.
Perfective. Usability improves.
Adaptive. The outside environment changed.
Usually preventive when replaced to avoid future failure; explain the reason.
It may involve perfective and corrective work. Separate the performance goal from the crash defect.
Scenario F shows why a single-word answer is not always enough. Describe the specific fault and the improvement separately. The category depends on the purpose of each change request.
What changes in the team's process for each type?
Every maintenance change needs understanding, impact analysis, implementation, testing and release. But the evidence you collect is different for the three types.
- CORRECTIVEReproduce faultRecord expected and actual behaviour.
- CORRECTIVEFix causeChange the faulty logic.
- CORRECTIVEProve repairRetest case and nearby features.
- PREVENTIVEIdentify riskShow why a future failure is plausible.
- PREVENTIVERemove weaknessValidate, update or simplify.
- PREVENTIVEProve safetyCover risky path and preserve old behaviour.
- PERFECTIVESet a goalDefine what “better” means.
- PERFECTIVEImprove productChange quality or user experience.
- PERFECTIVECompare resultMeasure improvement and retest correctness.
The exact failing input now gives the expected result; neighbouring cases still pass.
The predicted risky input is safely handled; normal inputs continue to work.
The chosen quality measure improves; functional results remain correct.
For all three, perform impact analysis. A library fee change can affect receipts, student balances, notifications and reports. Review the connected parts before release. A simple record should say who requested the change, why it was made, which version contains it, and how it was checked.
Priority is not the same as type. A serious corrective defect may be urgent. A preventive security risk may also be urgent. A perfective improvement may be scheduled for a later release. Decide urgency from impact and risk, not from the maintenance label alone.
Exam-ready answers and quick revision
Define corrective, preventive and perfective maintenance.
Corrective fixes a discovered fault in delivered software. Preventive removes a latent fault or risk before it causes a live problem. Perfective improves an existing working product, such as its speed, usability or maintainability.
Differentiate the three types with examples.
Software maintenance changes an existing software product after it has been delivered. The three types differ mainly in the reason for the change.
Corrective maintenance repairs a fault that has already been discovered. If a library app charges a late fee for a book returned on the due date, the team fixes the incorrect fee rule. Preventive maintenance deals with a hidden weakness before users experience a failure. If a review finds that invalid dates could produce incorrect fees, the team adds validation and tests before such data reaches the live system. Perfective maintenance improves software that already performs its task. If book search gives correct results but is slow, the team improves its performance.
Thus corrective means fix what failed, preventive means avoid what may fail, and perfective means improve what works.
Explain corrective, preventive and perfective maintenance in detail.
Introduction: Software maintenance is the controlled modification of an existing software product so that it remains correct and useful. Changes may be needed because a fault is found, a future risk is identified, or users need better quality. The reason for the change determines the maintenance type.
Corrective maintenance: This repairs a fault found after delivery. Suppose a college library system charges ₹10 when a book is returned exactly on the due date, although the approved rule says the charge must be zero. The team reproduces the problem, finds the date-comparison error, changes the logic and checks due-date and nearby cases. Corrective work aims to restore expected behaviour.
Preventive maintenance: This deals with a latent fault or known risk before it creates a failure in normal use. Suppose a review finds that invalid date values are not checked, although all current student records are valid. The team adds input validation and tests the risky path now. This reduces the chance of a wrong fee later. Planned replacement of a component nearing the end of support can also be preventive when its purpose is to avoid future failure.
Perfective maintenance: This improves an already working product. Suppose students can search for books and get correct results, but the page loads slowly. The team measures the current response, improves the query, measures it again and confirms that search results remain accurate. The purpose is better performance and experience, not repair of a wrong result.
Comparison and conclusion: Corrective responds to a current fault, preventive addresses a future risk, and perfective improves working software. All three require impact analysis, testing, version records and a safe release. If the question asks for the full traditional list, also write adaptive maintenance, which responds to an external environment change.
Last-minute revision cards
Observed wrong result → repair.
Known future risk → prevent.
Working but weak experience → improve.
Outside environment changed → adjust.
Find affected modules, data and tests.
Confirm older features still work.
Frequently asked questions
What is the main difference between corrective and preventive maintenance?
Corrective repairs an already discovered fault. Preventive addresses a latent fault or risk before it causes a live failure. The timing and reason for the change matter.
Does perfective mean the software becomes perfect?
No. It means improving an existing product, such as its performance, usability or maintainability. The word does not promise a defect-free product.
Can one maintenance request belong to two types?
Yes. A slow screen that also crashes may need a corrective crash fix and a perfective speed improvement. Record the separate goals clearly.
Why is adaptive maintenance mentioned if the title focuses on three types?
Many semester courses teach four traditional types. Adaptive means updating software to work with a changed external environment. Mention it when an exam asks for all four.
Is refactoring always preventive maintenance?
No. It depends on the reason. Refactoring to remove a known latent risk may be preventive. Refactoring to improve readability or maintainability can be perfective. Explain the goal in your answer.
