Lovely Professional

University

TERM PAPER
Of
Principles of Software Engineering

TOPIC: - CSM

[Categories of Software Maintenance]

Submitted to: Submitted by:

Ms. Shaina Dhingra Pramod
Ku.Tiwari
Lecturer, LSM Roll no. - B44
LPU Reg.No-
10901147
 Anu
Chauhan
Roll no.-
B48
Reg.No-
10902214
Sec. -
S1906
MBA
-IT

Index
1. Declaration Page no: 3

2. Acknowledgement Page no: 4

3. Preface Page no: 5

4. Introduction Page no: 6

5. Categories of Software maintenance Page no: 6

6. The Significance of Software Maintenance Page no: 7

7. Process of Software Maintenance Page no: 8

8. Maintenance Management Page no: 10

9. Reverse Engineering Page no: 12

10. Re-Engineering Page no: 12

11. Legacy System Page no: 13

12. Waterfall Model Page no: 14

13. Conclusion Page no: 22

14. References Page no: 23

DECLARATION

I, Pramod Kumar Tiwari & Anu Chauhan student of Lovely Professional

University have completed the Project on:

CSM: Categories of Software Maintenance

The information given in this project is true to the best of my knowledge.

(PRAMOD Ku. TIWARI)

(ANU CHAUHAN)
ACKNOWLEDGEMENT

First of all I would like to thank the Lovely Professional University and take
the opportunity to do this project as a part of the MBA-IT.

Many people have influenced the shape and content of this project, and
many supported me through it. I express my sincere gratitude to
Ms. Shaina Dhingra for assigning me a project on Principles of
Software Engineering, which is an interesting and exhaustive subject.

He has been an inspiration and role model for this topic. His guidance and
active support has made it possible to complete the assignment.

I also would like to thank my Friends who have helped and encouraged me
throughout the working of the project.

Last but not the least I would like to thank the Almighty for always helping
me.
 PREFACE

This project is undertaken to fulfil the project work component of the M.B.A
programme in 2nd Semester. My project guide from L.P.U is Lect. Ms.
Shaina Dhingra.

This term paper is based on the Computer and Introduction of the CSM .
 INTRODUCTION-

Software Development has many phases. These phases include Requirements

Engineering, Architecting, Design, Implementation, Testing, Software Deployment, and
Maintenance. Maintenance is the last stage of the software life cycle. After the product
has been released, the maintenance phase keeps the software up to date with environment
changes and changing user requirements.

“Software maintenance is the process of modifying a software system or component after

delivery to correct faults, improve performances or other attributes, or adapt to a changed
environment.”

“Software maintenance is the totality of activities required to provide cost-effective

support to a software system. Activities are performed during the pre-delivery stage as
well as the post-delivery stage. Pre-delivery activities include planning for post delivery
operations, supportability, and logistics determination. Post-delivery activities include
software modification, training, and operating a help desk.”

DESCRIPTION OF THE NATURE OF THE PHASE-

This section will cover what the software maintenance phase is about. As briefly seen in
the introduction, software maintenance is not limited to the correction of latent faults.
The term software maintenance usually refers to changes that must be made to software
after they have been delivered to the customer or user. The definition of software
maintenance by IEEE is as follows:
The 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. The
following subsections will discuss different types of software maintenance, the
significance and the characteristics of software maintenance.

CATEGORIES OF SOFTWARE MAINTENANCE-

There are four types of maintenance according to Lientz and Swanson:

1. Corrective Maintenance.
2. Adaptive Maintenance.
3. Perfective Maintenance
4. Preventive Maintenance.

1. CORRECTIVE MAINTENANCE :

Corrective maintenance deals with the repair of faults or defects found. A defect can
result from design errors, logic errors and coding errors .
Design errors occur when, for example, changes made to the software are incorrect,
incomplete, wrongly communicated or the change request is misunderstood.

2. ADAPTIVE MAINTENANCE :

Adaptive maintenance consists of adapting software to changes in the environment,

such as the hardware or the operating system. The term environment in this context
refers to the totality of all conditions and influences which act from outside upon the
system, for example, business rule, government policies, work patterns, software and
hardware operating platforms.

3. PERFECTIVE MAINTENANCE :

Perfective maintenance mainly deals with accommodating to new or changed user

requirements. Perfective maintenance concerns functional enhancements to the
system and activities to increase the system’s performance or to enhance its user
interface. A successful piece of software tends to be subjected to a succession of
changes, resulting in an increase in the number of requirements.
Examples of perfective maintenance include modifying the payroll program to
incorporate a new union settlement, adding a new report in the sales analysis system,
improving a terminal dialogue to make it more user-friendly, and adding an online
help command .

4. PREVENTIVE MAINTENANCE :

Preventive maintenance concerns activities aimed at increasing the system’s

maintainability, such as updating documentation, adding comments, and improving
the modular structure of the system. The long-term effect of corrective, adaptive and
perfective changes increases the system’s complexity. Software evolution is now
widely used in the software maintenance community. For example, The Journal of
Software Maintenance added the term ‘evolution’ to its title to reflect this transition.

THE SIGNIFICANCE OF SOFTWARE MAINTENANCE-

As software systems age, it becomes increasingly difficult to keep them ‘up and
running’without maintenance. The following stories show the significance of the
software maintenance phase in the software development life cycle.

COSTS AND CHALLENGES :

However one decides to categorize the maintenance effort, it is still clear that
software maintenance accounts for a huge amount of the overall software budget for
an information system organization. Software maintenance was characterized as an
“iceberg” to highlight the enormous mass of potential problems and costs that lie
under the surface. Although figures vary, several surveys [1, 2, 7, 10, 34, 46, 54, 56,
58] indicate that software maintenance consumes 60% to 80% of the total life cycle
 costs; these surveys also report that maintenance costs are largely due to
enhancements (often 75–80%), rather than corrections.
Several technical and managerial problems contribute to the costs of software
maintenance. Among the most challenging problems of software maintenance are:
program comprehension, impact analysis, and regression testing.

One of the major challenges in software maintenance is to determine the effects of a

proposed modification on the rest of the system. Impact analysis [6, 64, 35, 81] is the
activity of assessing the potential effects of a change with the aim of minimizing
unexpected side effects. The task involves assessing the appropriateness of a
proposed modification and evaluating the risks associated with its implementation,
including estimates of the effects on resources, effort and scheduling. It also involves
the identification of the system’s parts that need to be modified as a consequence of
the proposed modification. Of note is that although impact analysis plays a central
role within the maintenance process, there is no agreement about its definition and the
IEEE Glossary of Software Engineering Terminology [40] does not give a definition
of impact analysis.

MODEL-
A typical approach to software maintenance is to work on code first, and then making
the necessary changes to the accompanying documentation, if any. This approach is
captured by the quick-fix model, shown in figure 4, which demonstrates the flow of
changes from the old to the new version of the system [8]. Ideally, after the code has
been changed the requirement, design, testing and any other form of available
documents impacted by the modification should be updated. However, due to its
perceived malleability, users expect software to be modified quickly and cost-
effectively. Changes are often made on the fly, without proper planning, design,
impact analysis, and regression testing. Documents may or may not be updated as the
code is modified; time and budget pressure often entails that changes made to a
program are not documented and this quickly degrades documentation. In addition,
repeated changes may demolish the original design, thus making future modifications
progressively more expensive to carry out.

PROCESSES-
Several authors have proposed process models for software maintenance. These models
organize maintenance into a sequence of related activities, or phases, and define the order
in which these phases are to be executed. Sometimes, they also suggest the deliverables
that each phase must provide to the following phases.

IEEE and ISO have both addressed software maintenance, the first with a specific
standard and the latter as a part of its standard on life cycle processes. The next two
sections describe the maintenance processes defined by these two documents.
1- IEEE-1219 :

The IEEE standard organizes the maintenance process in seven

phases, as demonstrated in figure. In addition to identifying the phases and their order
of execution, for each phase the standard indicates input and output deliverables, the
activities grouped, related and supporting processes, the control, and a set of metrics.
The phase also includes activities to determine whether to accept or reject the request
and to assign it to a batch of modifications scheduled for implementation.

ANALYSIS :
This phase devises a preliminary plan for design, implementation, test,
and delivery. Analysis is conducted at two levels: feasibility analysis and detailed
analysis. Feasibility analysis identifies alternative solutions and assess their impacts
and costs, whereas detailed analysis defines the requirements for the modification,
devises a test strategy, and develop an implementation plan.

DESIGN :
The modification to the system is actually designed in this phase. This
entails using all current system and project documentation, existing software and
databases, and the output of the analysis phase. Activities include the identification of
affected software modules, the modification of software module documentation, the
creation of test cases for the new design, and the identification of regression tests.

IMPLEMENTATION :
This phase includes the activities of coding and unit testing,
integration of the modified code, integration and regression testing, risk analysis, and
review. The phase also includes a test-readiness review to asses preparedness fort
system and regression testing.

REGRESSION/SYSTEM TESTING :
This is the phase in which the entire system is
tested to ensure compliance to the original requirements plus the modifications. In
addition to functional and interface testing, the phase includes regression testing to
validate that no new faults have been added. Finally, this phase is responsible for
verifying preparedness for acceptance testing.

DELIVERY :
This is the phase in which the modified systems is released for
installation and operation. It includes the activity of notifying the user community,
performing installation and training, and preparing and archival version for backup.

2- ISO-12207-
While the standard IEEE-1219 is specifically concerned with
software maintenance, the standard ISO-12207 deals with the totality of the processes
comprised in the software life cycle.
The standard identifies seventeen processes grouped into three broad classes:
primary, supporting, and organizational processes. Processes are divided into
constituent activities each of which is further organized in tasks.

PROCESS IMPLEMENTATION :
This activity includes the tasks for developing plans
and procedures for software maintenance, creating procedures for receiving,
recording, and tracking maintenance requests, and establishing an organizational
interface with the configuration management process.

PROBLEM AND MODIFICATION ANALYSIS :

The first task of this activity is concerned
with the analysis of the maintenance request, either a problem report or a
modification request, to classify it, to determine its scope in term of size, costs, and
time required, and to assess its criticality. It is recommended that the maintenance
organization replicates the problem or verifies the request. The other tasks regard the
development and the documentation of alternatives for change implementation and
the approval of the selected option as specified in the contract.

MODIFICATION IMPLEMENTATION :
This activity entails the identification of the
items that need to be modified and the invocation of the development process to
actually implement the changes. Additional requirements of the development process
are concerned with testing procedures to ensure that the new/modified requirements
are completely and correctly implemented and the original unmodified requirements
are not affected.

MAINTENANCE REVIEW/ACCEPTANCE :
The tasks of this activity are devoted to
assessing the integrity of the modified system and end when the maintenance
organization obtain the approval for the satisfactory completion of the maintenance
request. Several supporting processes may be invoked, including the quality
assurance process, the verification process, the validation process, and the joint
review process.

SOFTWARE RETIREMENT :
The last maintenance activity consists of retiring a
software system and requires the development of a retirement plan and its notification
to users.

MAINTENANCE MANAGEMENT-

Management is “the process of designing and maintaining an environment in which

individuals, working together in groups, accomplish efficiently selected aims” . In the
case of maintenance the key aim is to provide cost-effective support to a software
system during its entire lifespan. Management is concerned with quality and
productivity, that imply effectiveness and efficiency. Management consists of five
separate functions- planning, organizing, staffing, leading and controlling.

PLANNING :
Planning consists of selecting missions and objectives and
predetermining a course of actions for accomplishing them. Commitment of human
and material resources and scheduling of actions are among the most critical activities
in this function.

ORGANIZING :
Organizing is the management function that establishes an intentional
structure of roles for people to fill in an organization. This entails arranging the
relationships among roles and granting the responsibilities and needed authority.

STAFFING :
Staffing involves filling the positions in the organization by selecting
and training people. Two key activities of this function are evaluating and appraising
project personnel and providing for general development, i.e. improvement of
knowledge, attitudes, and skills.

LEADING :
Leading is creating a working environment and an atmosphere that will
assist and motivate people so that they will contribute to the achievement of
organization and group goals.

CONTROLLING :
Controlling measures actual performances against planned goals
and, in case of deviations, devises corrective actions. This entails rewarding and
disciplining project personnel.

 Software maintenance organizations can be designed and set up with three

different organizational structures: functional, project, or matrix.

FUNCTIONAL ORGANIZATIONS :
Functional organizations are hierarchical nature.
The maintenance organization is broken down into different functional units, such as
software modification, testing, documentation, quality assurance, etc. Functional
organizations present the advantage of a centralized organization of similar
specialized resources.

PROJECT ORGANIZATIONS :
Project organizations are the opposite of the functional
organizations. In this case a manager is given the full responsibility and authority for
conducting the project; all the resources needed for accomplishing the project goals
are separated from the regular functional structure and organized into an autonomous,
self-contained team. The project manager may possibly acquire additional resources
from outside the overall organization.

MATRIX ORGANIZATIONS :
Matrix organizations are a composition of functional
and project organizations with the objective of maximizing the strengths and
minimizing the weaknesses of both types of organizations. Figure 15 shows a matrix
organization; the standard vertical hierarchical organization is combined with an
horizontal organization for each project. The strongest point of this organization is
that a balance is struck between the objectives of the functional departments and
those of the projects. The main problem is that every person responds to two
managers, and this can be a source of conflicts. A solution consists of specifying the
roles, responsibility and authority of the functional and project managers for each
type of decisions.

REVERSE ENGINEERING-
Software reverse engineering originated in software maintenance. Reverse
engineering as a process is difficult to define in rigorous terms because it is a new and
rapidly evolving field. Traditionally, reverse engineering has been viewed as a two
step process: information extraction and abstraction. Information extraction analyses
the subject system artifacts – primarily the source code – to gather row data, whereas
information abstraction creates user-oriented documents and views. Tilley and Paul
propose a preliminary step that consists of constructing domain-specific models of the
system using conceptual modeling techniques.

The IEEE Standard for Software Maintenance suggests that the process of reverse
engineering evolves though six steps: dissection of source code into formal units;
semantic description of formal units and creation of functional units; description of
links for each unit (input/output schematics of units); creation of a map of all units
and successions of consecutively connected units (linear circuits); declaration and
semantic description of system applications, and; creation of an anatomy of the
system. The first three steps concern local analysis on a unit level (in the small),
while the other three steps are for global analysis on a system level (in the large).
Reverse engineering process into the following three sequential phases: Goals,
Models, and Tools.

RE-ENGINEERING-

“Software Re-engineering is any activity that: (1) improves one’s understanding of

software, or (2) prepares or improves the software itself, usually for increased
maintainability, reusability, or evolvability.”

Software re-engineering has proven important for several reasons. Arnold identifies
seven main reasons that demonstrate the relevance of re-engineering:
“Re-engineering can help reduce an organization’s evolution risk;
Re-engineering can help an organization recoup its investment in software;
Re-engineering can make software easier to change;
Re-engineering is a big business;
Re-engineering capability extends CASE toolsets;
Re-engineering is a catalyst for automatic software maintenance;
Re-engineering is a catalyst for applying artificial intelligence techniques to solve
software re-engineering problems.”

LEGACY SYSTEM-

A scenario that highlights the high cost of software maintenance is legacy systems.
These are systems developed over the past 20/30 years (or even more) to meet a
growing demand for new products and services. They have typically been conceived
in a mainframe environment using non-standard development techniques and obsolete
programming languages. The structure has often been degraded by a long history of
changes and adaptations and neither consistent documentation nor adequate test suites
are available.

Four factors that have been successfully used to asses the value of a legacy system
and make informed decisions are: obsolescence, deterioration, decomposability, and
business value.

OBSOLESCENCE :
Obsolescence measures the ageing of a system due to the progress
of software and data engineering and the evolution of hardware/software platforms.
Obsolescence induces a cost which results from not taking advantage of modern
methods and technologies which reduce the burden of maintaining a system.

DETERIORATION :
Deterioration measures the decreases of the maintainability of a
system (lack of analyzability, modifiability, stability, testability, etc.) due to the
maintenance operations the system has undergone in its lifespan. Deterioration
directly affects the cost of maintaining a system.

DECOMPOSABILITY :
Decomposability measures the identifiability and independence
of the main components of a system. All systems can be considered as having three
components: interfaces, domain functions, and data management services. The
decomposability of a system indicates how well these components are reflected in its
architecture.

BUSINESS VALUE :
Business Value measures the complexity of the business process
and rules a system, or system’s component, implements and their relevance to achieve
efficiency and efficacy in the business operation.
Software plans
and requirements

Specification

Design

Coding

Integration and
Testing

Operation and
Maintenance

Waterfall model
 Unscheduled Scheduled

Corrective
Reactive Emergency Adaptive

Proactive Perfective

IEEE categories of software maintenance

ISO categories IEEE categories

Emergency maintenance

Problem resolution

Corrective maintenance

interface modification

Adaptive maintenance

functional expansion or
performance improvement

perfective maintenance
 The quick-fix Model

The iterative-enhancement Model

 The full-reuse Model

An example of maintenance model

The IEEE Maintenance Process

The ISO Life Cycle Process

 The ISO Maintenance Process

The Function of Project Management

 A Functional Organizational

Reverse Engineering and Re-Engineering

A Life Cycle Model for legacy System
CONCLUSION-

This article has overviewed software maintenance, its strategic problems, and the
available solutions. The underlying theme of the article has been to show that technical
and managerial solutions exist that can support the application of high standards of
engineering in the maintenance of software. Of course, there are open problems and more
basic and applied research is needed both to gain a better understanding of software
maintenance and to find better solutions.

Nowadays, the way in which software systems are designed and built is changing
profoundly, and this will surely have a major impact on tomorrow’s software
maintenance. Object technology, commercial-off-the-shelf products, computer supported
cooperative work, outsourcing and remote maintenance, Internet/Intranet enabled systems
and infrastructures, user enhanceable systems, are a few examples of areas that will
impact software maintenance. Currently there is a debate on the nature and the essence of
software maintenance. Indubitably, the traditional vision of software maintenance as a
post-delivery activity dates back to the seventies and is strictly related to the waterfall life
cycle models.
References:

 http://en.wikipedia.org/wiki/Software_maintenance

 http://www.google.co.in/url?sa=t&software maintenance

 http://portal.acm.org/citation.cfm?id=859273

 http://www.tethermedia.com/maintenance_projects.htm