about maintenance

1. 5. Maintenance
By:-Gourav Kottawar

2. Maintenance
 Maintenance can be defined as actions necessary
for retaining or restoring a piece of equipment, machine
or system to the specified operable condition
to achieve its maximum useful life.
 Software maintenance denotes any changes made to a
software after it has been delivered to the customer.
 Software maintenance is about correcting the faults,
improving the performance & adapting the software
system to a new environment.
By:-Gourav Kottawar

3. Types of Maintenance
 There are four main types of system maintenance.
They are as follows:
1. Adaptive maintenance
2. Corrective maintenance
3. Perfective maintenance
4. Preventive maintenance
By:-Gourav Kottawar

4. Adaptive Maintenance
 Adaptive maintenance involves making changes to an information
system to evolve its functionality to changing business needs or to
migrate to a different operating environment.
 An adaptive maintenance project is like a mini-SDLC project, and
that adaptive maintenance can be even more difficult than new
systems development because the enhancements must work within
the constraints of an existing system.
 Adaptive maintenance is usually less urgent than corrective
maintenance because business and technical changes typically occur
over some period of time.
 Adaptive maintenance is generally a small part of an organization’s
maintenance effort, but does add Value to the organization.
By:-Gourav Kottawar

5. Corrective Maintenance
 Corrective maintenance refers to changes made to repair defects
in the design, coding, or implementation of the system. Most
corrective maintenance problems surface soon after installation.
 When corrective maintenance problems surface, they are
typically urgent and need to be resolved to continue normal
business activities.
 Corrective maintenance adds little or no value to an
organization; it simply focuses on removing defects from an
existing system without adding new functionality.
 But, of all types of maintenance, corrective maintenance
accounts for as much as 75% of total maintenance activity.
By:-Gourav Kottawar

6. Perfective maintenance
1. This is performed to improve or maintain program
efficiency.
2. Modifying program data structure is one way to
improve overall program efficiency.
3. Another way to improve efficiency is to modify
expensive parts of a system, improving loops, test
comparisons, calls to external procedures &
evaluation of algebraic expressions illustrates ways
of improving overall speed of processing.
4. E.g., write a macro to handle repetitive tasks.
By:-Gourav Kottawar

7.  Preventive maintenance involves changes made to a
system to reduce the chance of future system failure.
Preventive Maintenance
By:-Gourav Kottawar

8. The maintenance process
By:-Gourav Kottawar

9. Change requests
 Change requests are requests for system changes
from users, customers or management
 In principle, all change requests should be carefully
analysed as part of the maintenance process and
then implemented
 In practice, some change requests must be
implemented urgently
 Fault repair
 Changes to the system’s environment
 Urgently required business changes
By:-Gourav Kottawar

10. Change implementation
By:-Gourav Kottawar

11. Emergency repair
By:-Gourav Kottawar

12. Maintenance Process
Gather change requirements
Analyse change requirements
Devise code change strategies
Apply code change strategies to the old
code
Update documents Integrate & test
By:-Gourav Kottawar

13. Maintenance Cost
 Cost estimation is the art of approximating the
probable cost of something based on the information
available at that time.
 Software engineering imposes more cost to maintain
the software than it does to develop it.
 For systems with a longer life, maintenance costs are
several times greater than the development costs.
By:-Gourav Kottawar

14.  Team stability
 Maintenance costs are reduced if the same staff are involved with
them for some time
 Contractual responsibility
 T- he developers of a system may have no contractual
responsibility for maintenance so there is no incentive to design
for future change
 Staff skills
 Maintenance staff are often inexperienced and have limited
domain knowledge
 Program age and structure
 As programs age, their structure is degraded and they become
harder to understand and change
Maintenance cost factors
By:-Gourav Kottawar

15. Methods to Estimate Maintenance Cost
 The two common methods to estimate maintenance
cost are:
1. Belady & Lehman Model
2. Boehm Model
By:-Gourav Kottawar

16. 1. Belady & Boehm model
 This model specifies that the effort & cost increase exponentially in case
if poor software development approach is used & the team that
developed the system is no longer available to handle the maintenance
of the system. This same situation can be shown by the basic equation
as:
M=P+Ke(c-d)
M= total efforts imposed
P= productive efforts that involves analysis, design, coding, testing &
evaluation.
K= an empirically determined constant
e= exponentiation
c= complexity measure due to lack of good design & documentation.
d= degree to which maintenance team is familiar with the software.
By:-Gourav Kottawar

17. 1. Belady & Boehm model(cont)
 Here the value of ‘c’ increases if the software is
developed using unstructured development process.
 The value of ‘d’ is low, if the software is maintained
without proper understanding of the structure,
function & purpose of the software.
By:-Gourav Kottawar

18. Example
 The development effort for a software project is 500 person
months. The empirically determined constant (K) is 0.3.
The complexity of the code is quite high and is equal to 8.
Calculate the total effort expended (M) if
 (i) maintenance team has good level of understanding of
the project (d=0.9)
 (ii) maintenance team has poor understanding of the
project (d=0.1)
By:-Gourav Kottawar

19. Solution
 Development effort (P) = 500 PM
 K = 0.3
 C = 8
(i) maintenance team has good level of understanding
of the project (d=0.9)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.9)
= 500 + 363.59 = 863.59 PM
By:-Gourav Kottawar

20. Solution
(ii) maintenance team has poor understanding of the
project (d=0.1)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.1)
= 500 + 809.18 = 1309.18 PM
Hence it is clear that effort increases exponentially, if
poor software engineering approaches are used &
understand ability of the project is poor.
By:-Gourav Kottawar

21. 2. Boehm Model
 Dr. Barry Boehm proposed the Delphi method to
estimate cost. It is useful in assessing the difference
between past projects & new ones for which no
historical precedent is needed.
 Advantages:
1. Little or no historical data needed.
2. Suitable for new or unique projects.
By:-Gourav Kottawar

22. 2. Boehm Model(Cont…)
 Boehm proposed a formula for estimating the
maintenance cost.
 Boehm used a quantity called Annual Change Traffic
(ACT) which signifies that:
the fraction of a s/w products source
instructions which undergo changes during a
year either through addition, deletion or
modification is shown by the equation below:
ACT= KLOC added +KLOC deleted
KLOC total
By:-Gourav Kottawar

23. 2. Boehm Model(Cont…)
 Where KLOC added is the total kilo lines of source
code added during maintenance.
 Where KLOC deleted is the total kilo lines of source
code deleted during maintenance.
 The Annual Change Traffic (ACT) is multiplied with
the total development cost to arrive at the
maintenance cost
 Maintenance Cost= ACT * Development Cost
By:-Gourav Kottawar

24. 2. Boehm Model(Cont…)
 The Annual Maintenance Effort (AME) in person-
months can be calculated as:
AME= ACT * SDE
Where,
SDE= s/w development effort in person-months
ACT= Annual Change Traffic
By:-Gourav Kottawar

25. Example
Annual Change Traffic (ACT) for a software system is
15% per year. The development effort is 600 PMs.
Compute estimate for Annual Maintenance Effort
(AME). If life time of the project is 10 years, what is
the total effort of the project ?
By:-Gourav Kottawar

26. Solution
The development effort = 600 PM
Annual Change Traffic (ACT) = 15%
Total duration for which effort is to be calculated = 10
years
AME = ACT x SDE
= 0.15 x 600 = 90 PM
Maintenance effort for 10 years = 10 x 90 = 900 PM
Total effort = 600 + 900 = 1500 PM
By:-Gourav Kottawar

27. Role of Documentation
 They should act as a communication medium
between members of the development team.
 They should be a system information repository to be
used by maintenance engineers.
 They should provide information for management to
help them plan, budget and schedule the software
development process.
 Some of the documents should tell users how to use
and administer the system.
By:-Gourav Kottawar

28. Types of Documentation
 The documentation produced falls into two classes:
1. Process documentation: These documents record
the process of development and maintenance. Plans,
schedules, process quality documents and organizational
and project standards are process documentation.
2. Product documentation This documentation
describes the product that is being developed. System
documentation describes the product from the point of
view of the engineers developing and maintaining the
system; user documentation provides a product description
that is oriented towards system users.
By:-Gourav Kottawar

29. Process Documentation
 Process documentation falls into a number of categories:
1. Plans, estimates and schedules These are
documents produced by managers which are used to
predict and to control the software process.
2. Reports These are documents which report how
resources were used during the process of development.
3. Standards These are documents which set out how the
process is to be implemented. These may be developed
from organizational, national or international standards
By:-Gourav Kottawar

30. 4. Working papers These are often the principal
technical communication documents in a project. They
record the ideas and thoughts of the engineers working
on the project, are interim versions of product
documentation, describe implementation strategies
and set out problems which have been identified.
5. Memos and electronic mail messages These
record the details of everyday communications
between managers and development engineers.
By:-Gourav Kottawar

31. Product Documentation
 Product documentation is concerned with describing
the delivered software product. Unlike most process
documentation, it has a relatively long life.
 Product documentation includes user
documentation which tells users how to use the
software product and system documentation
which is principally intended for maintenance
engineers.
By:-Gourav Kottawar

32. User Documentation
 Users of a system are not all the same. The producer
of documentation must structure it to cater for
different user tasks and different levels of expertise
and experience. It is particularly important to
distinguish between end-users and system
administrators:
By:-Gourav Kottawar

33.  End-users use the software to assist with some task. This
may be flying an aircraft, managing insurance policies,
writing a book, etc. They want to know how the software
can help them. They are not interested in computer or
administration details.
 System administrators are responsible for managing the
software used by end-users. This may involve acting as
an operator if the system is a large mainframe system, as
a network manager is the system involves a network of
workstations or as a technical guru who fixes end-users
software problems and who liaises between users and the
software supplier.
By:-Gourav Kottawar

34.  The functional description of the system outlines the
system requirements and briefly describes the
services provided. This document should provide an
overview of the system. Users should be able to read
this document with an introductory manual and
decide if the system is what they need.
By:-Gourav Kottawar

35.  The system installation document is intended for
system administrators.
 It should provide details of how to install the system
in a particular environment.
 It should contain a description of the files making up
the system and the minimal hardware configuration
required.
By:-Gourav Kottawar

36.  The introductory manual should present an
informal introduction to the system, describing its
‘normal’ usage. It should describe how to get started
and how end-users might make use of the common
system facilities.
 It should be liberally illustrated with examples.
 Inevitably beginners, whatever their background and
experience, will make mistakes. Easily discovered
information on how to recover from these mistakes
and restart useful work should be an integral part of
this document.
By:-Gourav Kottawar

37.  The system reference manual should describe the
system facilities and their usage, should provide a
complete listing of error messages and should
describe how to recover from detected errors. It
should be complete.
By:-Gourav Kottawar

38.  A more general system administrator’s guide should
be provided for some types of system such as
command and control systems. This should describe
the messages generated when the system interacts
with other systems and how to react to these
messages. If system hardware is involved, it might
also explain the operator’s task in maintaining that
hardware.
By:-Gourav Kottawar

39. System Documentation
 System documentation includes all of the documents
describing the system itself from the requirements
specification to the final acceptance test plan.
 Documents describing the design, implementation
and testing of a system are essential if the program is
to be understood and maintained.
 Like user documentation, it is important that system
documentation is structured, with overviews leading
the reader into more formal and detailed
descriptions of each aspect of the system.
By:-Gourav Kottawar

40.  For large systems that are developed to a customer’s
specification, the system documentation should
include:
1. The requirements document and an associated
rationale(basis/justification).
2. A document describing the system architecture.
3. For each program in the system, a description of the
architecture of that program.
4. For each component in the system, a description of
its functionality and interfaces.
By:-Gourav Kottawar

41.  Program source code listings. These should be
commented where the comments should explain complex
sections of code and provide a rationale for the coding
method used.
 Validation documents describing how each program is
validated and how the validation information relates to
the requirements.
 A system maintenance guide which describes known
problems with the system, describes which parts of the
system are hardware and software dependent and which
describes how evolution of the system has been taken
into account in its design.
By:-Gourav Kottawar