There are two formal definitions of software maintenance, which are as under-
- IEEE, 1993 :-
Software maintenance is modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.
- ISO/IEC Standard 12207 :-
A set of software maintenance activities that occur when software undergoes modifications to the code and associate documentation due to a problem or need for improvement or adaptation.
The first definition is similar to hardware maintenance, car servicing, where a product is checked for errors or additional tasks are given after it is sold.
In contrast, the second definition includes software maintenance as an essential aspect of the entire life cycle of a software product, beginning early development.
Software maintenance specifies the activities following the delivery of the initial working version of the software system. Must be maintained in the system from the beginning i.e., maintenance should be taken into consideration during the entire development. Although maintenance does not have the most complex aspect of software production.
Maintenance includes portions of all other stages of the software process. After receiving a maintenance request, the first step is to identify what type of maintenance is required. Sometime, the problem is with the user- not the software.
In the case of software products, one would be more interested in updating the product so that it would adapt to changes in its environment or hardware, rather than reducing it and replacing it with another new product. Hence, software products also require maintenance for keeping them up to date with their surroundings for their best application.
Process:Assign change number, Classify modification request, Accept or reject change, Prioritize.
Control:Uniquely identified modification request, Enter modification request repository.
Output:Validated modification request, Validated process determinations.
Input:Project document, Repository information, Validated modification request.
Process:Feasibility analysis, Detailed analysis.
Control:Conduct technical review, Verify test strategy, Verify whether the documentation is updated or not, Identify security issues.
Output:Feasibility report, Detailed analysis report, Updated requirements, Preliminary modification list, Test strategy.
Input:Project document, Source code, Databases, Analysis phase output.
Process:Create test cases, Revise requirements, Revise implementation plan.
Control:Software inspections/reviews, Verify design.
Output:Revised modification list, revised detailed analysis, Updated test plans.
Input:Source code, system documentation, Results of design phase.
Process:Software code, Unit test, Test preparation review.
Output:Updated software, Updated design documents, Updated test documents, Updated user documents, Test preparation review report.
Input:Updated software documentation, Test preparation review report, Updated system.
Process:Functional test, Interface testing, Test preparation review
Control:Software code listings, Modification request, Test documentation.
Output:Test system, Test reports.
Input:Test preparation review report, Fully integrated system, Acceptance test plans, Acceptance test cases, Acceptance test procedures.
Process:Acceptance test, Interoperability test
Output:Acceptance test report.
Control:Version description document.
Output:Version description document.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.