Spm unit v-software maintenance-intro

SPM-UNIT - VSOFTWARE MAINTENANCE

Prof. Kanchana Devi

2

Software Maintenance - Introduction

Prof. Kanchana Devi

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

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

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

Prof. Kanchana Devi

5

Maintenance Activities & Characteristics

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

Prof. Kanchana Devi

6

7

Software Maintenance Planning

Prof. Kanchana Devi

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

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.

Prof. Kanchana Devi

9

Reengineering

Prof. Kanchana Devi

10

Metrics for Source Code 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

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.

Prof. Kanchana Devi

12

Length N N = n1 log2 n1 + n2 log2 n2

Program Volume V = N log2 (n1+n2)

Prof. Kanchana Devi

13

Software Reliability 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

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.

Prof. Kanchana Devi

15

Traditional Methods For Improving Software Reliability 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.

Prof. Kanchana Devi

16

Reliability Problems They depend fundamentally on human

reasoning and judgments They do not provide guarantees

Prof. Kanchana Devi

17

Measuring Reliability 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

Prof. Kanchana Devi

18

Software Reliability Models 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.

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

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).

)],[in failures of #()(

f

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

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?

Prof. Kanchana Devi

23

Choice of ModelBasic Model:

• 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)

Prof. Kanchana Devi

24

Logarithmic Model

• 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 .