the state of software maintenance written by: norman f. schneidewind presentation by: li, hongfeng

The State of Software Maintenance

Written by: Norman F. Schneidewind

Presentation by: Li, Hongfeng

1. Introduction

People do not pay attention on maintenance

A. Definition

• Maintenance: Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment.

• Maintainability: The ease with which a software system can be corrected when errors or deficiencies occur, and can be expanded or contracted to satisfy new requirements.

B. Why is there a maintenance problem?

1. The programs to be maintained are not well documented .

2. The programs are unstructured. 3. The program do not use the third-normal

form data models and data dictionary for generating the programmer’s data.

We can not do maintenance on a system which was not designed for maintenance.

C. Why Is Maintenance Hard

• We cannot trace the product nor the process that created the product.

• Changes are not adequately documented.

• Lack of change stability.

• Ripple effect of making changes.

• Myopic view that maintenance is strictly a post-delivery activity.

D. Why Is Maintenance Expensive

• Programmers’ salaries consume the majority of the data processing budget

• Programmers spend most of their time maintaining programs

• Hardware is cheap

2. Model

• Background: requirement changes generated by users and the environment and the consequent need for adapting the software to the changes is unpredictable and cannot be accommodated without iteration.

Model appropriate for Maintenance

• The traditional view of software life cycle : maintenance is solely as a single step at the end of the cycle.

• Maintenance should be portrayed as 2nd, 3rd, …, nth round development.

3. Methods For Improving Maintenance

• Design approach

• Maintenance practices

• Management

• Tools

Design approach

• Design software with maintainability in mind

• Develop design criteria for achieving maintainability

• Simplicity should outweigh completeness

• Change management should be used to:

-determine ripple effect on other modules of make change to a module.

- determine ripple effect on a modules of make change to a local variable

• Evaluate the design for excessive complexity

Another design approach

• Another design approach to aid maintenance describes the design in terms of parts and the interconnections of those parts:– Part interconnections as the central of the

design and documentation, using list and graphical form, can more readily judge the possible ripple effect of change.

– The connections list shows the input/output relationships between functions and data.

Maintenance practices needed

• Change Management:– Make easiest changes first

– Change one module at a time

– Inspect proposed changes for each type of side effect

– Run regression tests after every change

• Produce guidelines for modifying and retesting software:– Provide information to support assessment of the

impact of a change in various parts of the software

Other practices needed

• Identify source statements which have been changed with a number which is associated with the change request

• Learn to read programs• Keep diaries of bugs and maintenance issues• Centralize variable declarations in a program

Other practices needed(Continue)

• Centralize symbolically defined and referenced database definitions in a computer processible data dictionary

• Each programmer in the process should give consideration to the next programmer in the life cycle.

• Form correct interpretations of delocalized plans.

Management policies needed

• Involve maintainers in design and testing.• Put the same emphasis on the use of standards in

maintenance as in design.• Rotate personnel between design and

maintenance.• Make design documentation available to

maintainers at design time.

Management policies needed(Continue)

• Carry over the use of design tools into maintenance.

• Use configuration management and change request procedures.

• Establish a liaison between users and maintenance.

• Integrate design and maintenance.

Tools needed

• The reason we need tools:– Looking for structure (procedure, control, data,

input/output)– Understand data aliases– Following data flow– Following control flow– Understand version of a program

Tool capabilities

• Structure chart: shows hierarchy and call/called relationships

• Data trace

• Control trace

• Version comparisons

• Stored test execution information

• Test cases

Structured retrofit

• One tool to restructure unstructured code.

• The character of the unstructured code:

The design concept was good but its implementation was poor.

It meet the user requirement but difficultly and costly to maintain.

Structured retrofit Procedure

• Scoring with the following criteria:– Degree of structure– Level of nesting– Degree of complexity– Breakout of verb utilization– Analysis of potential failure modes– Trace of control logicIf a problem scores low on the above criteria but still runswith little time required for maintenance, it will not

retrofitted.

Structured retrofit Procedure(Continue)

• Compilation: programs which are not be retrofitted are compiled.

• Restructuring: programs that are unstructured are put through this process to make them structured.

• Formatting: programs are made more readable through the formatting process. They are then recompiled to pick up possible syntax errors.

Structured retrofit Procedure(Continue)

• Validation: The same inputs are applied to the original and restructured programs and the outputs are compared on a bit-by-bit basis by a file-to-file compare utility.

• Optimization: the code is optimized to reduce overhead which may have been introduced by the restructuring process.

4. Metrics

• We want maintenance to improve software. But too often, maintenance makes software worse, due to unforseen ripple effect.

• Ripple effect is caused by interaction between models(a change to a module causes changes to other modules).

• In order to minimize ripple effect, software must be stable which achieved at design time, not maintenance phase.

The concept of Stability(1)

• Program stability: quality attribute indicating resistance to the potential ripple effect when a program would have when it is modified

• Module stability: a measure of the resistance to the potential ripple effect of a modification of the module on other modules in the program

• logical stability: a measure of the resistance to impact of a modification on other modules in terms of logical consideration

The concept of Stability(2)

• Intramodule change propagation involves flow of changes within the module as a consequence of a modification.

• Intermodule change propagation involves flow of changes across module as a consequence of a modification.

• The definition of stability only applies to modular software, but much of the existing software which must be maintained is not modular.

The measure of design stability

• The measure of design stability of a module is the reciprocal of the total number of assumptions made by other modules about the given module.

• The modules which cause large ripple effects, if modified, are among the modules with poor design stability

Capture needed information in a metric

• The effects of a change to a single variable or changes to a set of variables.

• The effects of a change on documentation

• The effects of a change on other aspects of a program

• Weight the assumptions above since they are not equally important

5. Maintenance information management

• Information about the characteristics of the code and specifications are essential to doing an effective job of maintenance.

• Information base are: – Control flow information– Data flow information– Declaration information

• Information base should be established as part of every design and maintenance activity.

6. Standards

• No standards exist for maintenance. In general, development standards are inappropriate for use in maintenance.

• National Bureau of Standards for conducting an effective maintenance are shown below:

1. Recognize improvement of maintainability

2. Develop a software maintenance plan

3. Elevate maintenance visibility in the organization

4. Reward maintenance personnel; provide a career path and training

5. Establish and enforce standards

7. Maintenance of existing code

• Much of the existing code are not modularly designed.

• Restructuring

The unstructured program is parsed into an abstract syntax tree, then transformed into a control flow graph. The graph represents a structured algorithm

• Recovering the design with abstract specifications(only on large programs)

8. Surveys(1)

• In a survey 487 data processing organizations:

55% perfective: enhance performance, improve maintainability, improve executing efficiency.

25% adaptive: adapt to changes in the data requirements or processing environments.

20% corrective: identify and correct software failures, performance failures, and implementation failures.

Survey(2)

• The fourth generation lauguages are beneficial for development .

• The languages make maintenance more difficult and expensive because interprogram and intersystem communication of data with it is often obscure, rendering the effect of a maintenance action unclear.

Surveys(3)

• The biggest problems in software maintenance work are:

1. Poor document

2. Inadequate staff

conclusion

• Lots of systems are not designed for maintenance.

• Software engineers should recognize the importance of maintenance.