Spm unit v-software maintenance-intro

1. SPM-UNIT - V
SOFTWARE MAINTENANCE
Prof. Kanchana Devi

2. Software Maintenance - Introduction
Prof. Kanchana Devi
2
 Modification of a software product after delivery to:
 Correct faults
 Improve performance or other attributes.
 Adapt to a change in the environment.
 A common work of maintenance is that it involves
fixing defects.
 Software maintenance is a very broad activity that
includes
 Error corrections
 Enhancements of capabilities
 Deletion of obsolete capabilities
 Optimization.
Resource: Wikipedia

3. Lehman’s Law
Prof. Kanchana Devi
3
 Maintenance is really evolutionary
development and that maintenance decisions
are aided by understanding what happens to
systems (and software) over time.
Resource: Wikipedia

4. Software Maintenance – Issues &
Side Effects
Prof. Kanchana Devi
4
 There are two main issues:
 Management Issues
 Technical Issues
 Management issues are:
 Alignment with customer priorities
 Staffing, which organization does maintenance
 Estimating costs.
 Technical issues are:
 Limited understanding
 Impact analysis
 Testing
 Maintainability measurement.
Resource: Wikipedia

5. Maintenance Activities &
Characteristics
Prof. Kanchana Devi
5
 Adaptive
 Modifying the system to cope with changes in the software
environment
 Perfective
 Implementing new or changed user requirements which
concern functional enhancements to the software
 Corrective
 Diagnosing and fixing errors, possibly ones found by users
 Preventive
 Increasing software maintainability or reliability to prevent
problems in the future

6. Prof. Kanchana Devi
6

7. Software Maintenance Planning
Prof. Kanchana Devi
7
 Software Maintenance is an integral part,
which requires an accurate maintenance plan.
 It should specify how users will request
modifications or report problems.
 The budget should include resource and cost
estimates.
 It is an admitted fact that approximately 60 to
70% effort is spent on maintenance phase of
software development life cycle.

8. Software Maintenance Processes
Prof. Kanchana Devi
8
 Software preparation and transition activities
 Creation of the maintenance plan;
 The preparation for handling problems
 The follow-up on product configuration management.
 The modification analysis process.
 The implementation of the modification.
 The process acceptance of the modification.
 The migration process is exceptional, and is not
part of daily maintenance tasks. (Platform Change)
 Finally, the last maintenance process, is the
retirement of a piece of software.

9. Reengineering
Prof. Kanchana Devi
9

10. Metrics for Source Code
Prof. Kanchana Devi
10
 There are some measures to calculate the
metrics:
 n1 = number of distinct operators appear in the
program
 n2 = number of distinct operands appear in the
program
 N1 = Total number of operator occurrences
 N2 = Total number of operand occurrences

11. Prof. Kanchana Devi
11
 n1, n2, N1, N2 - These measures are used to
develop expressions for
 The overall length
 Minimum volume for an algorithm
 The actual volume
 The program level
 Language level
 Other features
 Development effort
 Development time
 Even the projected number of faults in the software.

12. Prof. Kanchana Devi
12
 Length N
 N = n1 log2 n1 + n2 log2 n2
 Program Volume
 V = N log2 (n1+n2)

13. Software Reliability
Prof. Kanchana Devi
13
 Categorising and specifying the reliability
of software systems
 Informal Definition:
 Reliability is a measure of how well system users
think it provides the services they require.
 Probability of a software component will
produce an incorrect output
 Software can continue to operate after a bad
result

14. ………
Prof. Kanchana Devi
14
 Software Reliability is the probability of failure-
free software operation for a specified period
of time in a specified environment.
 Software Reliability is also an important factor
affecting system reliability.
 It differs from hardware reliability in that it
reflects the “design perfection”, rather than
manufacturing perfection.
 The high complexity of software is the major
contributing factor of Software Reliability
problems.

15. Traditional Methods For Improving
Software Reliability
Prof. Kanchana Devi
15
 Three main techniques are used in industrial and
open source projects to improve software reliability:
 Manual Testing
 Code Reviews:
 Modifications are reviewed by experienced developers
before being committed to the code base.
 Coding Standards:
 Requiring that all developers adhere to a set of rules when
writing or maintaining code.
 Coding standards can improve source code readability,
making it easier to spot defects, and
 Ban the use of programming idioms that are arguably
dangerous.

16. Reliability Problems
Prof. Kanchana Devi
16
 They depend fundamentally on human
reasoning and judgments
 They do not provide guarantees

17. Measuring Reliability
Prof. Kanchana Devi
17
 A simple measure of reliability can be given as:
 MTBF = MTTF + MTTR , where
 MTBF is mean time between failures
 MTTF is mean time to fail
 MTTR is mean time to repair

18. Software Reliability Models
Prof. Kanchana Devi
18
 error seeding - estimates the number of errors in a program.
 Errors are divided into indigenous errors and induced (seeded) errors. The
unknown number of indigenous errors is estimated from the number of
induced errors and the ratio of the two types of errors obtained from the
testing data.
• Reliability growth
• Measures and predicts the improvement of reliability through the
testing process using a growth function to represent the process.
• Independent variables of the growth function could be time, number of
test cases (or testing stages) and
• The dependent variables can be reliability, failure rate or cumulative
number of errors detected.

19. Prof. Kanchana Devi
19
 Nonhomogeneous Poisson process (NHPP)
 provide an analytical framework for describing
the software failure phenomenon during testing.
 the main issue is to estimate the mean value
function of the cumulative number of failures
experienced up to a certain point in time.
 a key example of this approach is the series of
Musa models

20. Prof. Kanchana Devi
20
 A typical measure (failures per unit time) is the
failure intensity (rate) given as:
 where  = program CPU time (in a time shared
computer) or wall clock time (in an embedded
system).
)
],[infailuresof#
()(





 f

21. Prof. Kanchana Devi
21
 SR Growth models are generally “black box” -
no easy way to account for a change in the
operational profile
 Operational profile: description of the input
events expected to occur in actual software
operation – how it will be used in practice
 consequences are that we are unable to go from
test to field

22. Prof. Kanchana Devi
22
 Many models have been proposed, perhaps the
most prominent are:
 Musa Basic model
 Musa/Okomoto Logarithmic model
 Some models work better than others
depending on the application area and
operating characteristics: i.e. interactive? data
intensive? control intensive? real-time?

23. Choice of Model
Basic Model:
Prof. Kanchana Devi
23
• For studies or predictions before execution and
failure data available
• Using study of faults to determine effects of a new
software engineering technology
• The program size is changing continually or
substantially (i.e. during integration)

24. Logarithmic Model
Prof. Kanchana Devi
24
• System subjected to highly non-uniform
operational profiles.
• Highly predictive validity is needed early in the
execution period. The rapidly changing slope of the
failure intensity during early stages can be better
fitted with the logarithmic Poisson than the basic
model .