U.S. Department

of Commerce

National Bureau

of Standards

Computer Science

and Technology

NBS

PUBLICATIONS

, ."'VINST OF STAND S TECH R.I.C.

NBS Special Publication 500-429

Software Maintenance

Management

James A. McCall, Mary A. Herndon, and

Wilma M. Osborne

nc—

100

U57

500-129

1985

c 2
TM he National Bureau of Standards' was established by an act of Congress on March 3, 1901. The

jM Bureau's overall goal is to strengthen and advance the nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides: (1) a

basis for the nation's physical measurement system, (2) scientific and technological services for industry and

government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety.

The Bureau's technical work is performed by the National Measurement Laboratory, the National

Engineering Laboratory, the Institute for Computer Sciences and Technology, and the Institute for Materials

Science and Engineering

.

The National Measurement Laboratory

Provides the national system of physical and chemical measurement;

coordinates the system with measurement systems of other nations and

furnishes essential services leading to accurate and uniform physical and

chemical measurement throughout the Nation's scientific community, in- dustry, and commerce; provides advisory and research services to other Government agencies; conducts physical and chemical research; develops,-

produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

• Basic Standards^

• Radiation Research

• Chemical Physics

• Analytical Chemistry

The National Engineering Laboratory

Provides technology and technical services to the public and private sectors to address national needs and to solve national problems; conducts research in engineering and applied science in support of these efforts; builds and maintains competence in the necessary disciplines required to carry out this research and technical service; develops engineering data and measurement

capabilities; provides engineering measurement traceability services; develops

test methods and proposes engineering standards and code changes; develops

and proposes new engineering practices; and develops and improves

mechanisms to transfer results of its research to the ultimate user. The

Laboratory consists of the following centers:

Applied Mathematics

Electronics and Electrical Engineering^

Manufacturing Engineering

Building Technology

Fire Research

Chemical Engineering^

The Institute for Computer Sciences and Technology

Conducts research and provides scientific and technical services to aid Federal agencies in the selection, acquisition, application, and use of computer technology to improve effectiveness and economy in Government

operations in accordance with Public Law 89-306 (40 U.S.C. 759), relevant Executive Orders, and other directives; carries out this mission by managing

the Federal Information Processing Standards Program, developing Federal ADP standards guidelines, and managing Federal participation in ADP

voluntary standardization activities; provides scientific and technological advisory services and assistance to Federal agencies; and provides the technical foundation for computer-related policies of the Federal Government. The Institute consists of the following centers:

• Programming Science and

Technology

• Computer Systems

Engineering

The Institute for Materials Science and Engineering

Conducts research and provides measurements, data, standards, reference

materials, quantitative understanding and other technical information fundamental to the processing, structure, properties and performance of materials; addresses the scientific basis for new advanced materials technologies; plans

research around cross-country scientific themes such as nondestructive

evaluation and phase diagram development; oversees Bureau-wide technical programs in nuclear reactor radiation research and nondestructive evaluation; and broadly disseminates generic technical information resulting from

its programs. The Institute consists of the following Divisions:

Inorganic Materials Fracture and Deformation^

Polymers

Metallurgy Reactor Radiation

'Headquarters and Laboratories at Gaithersburg, MD, unless otherwise noted; mailing address

Gaithersburg, MD 20899. 'Some divisions within the center are located at Boulder, CO 80303. ^Located at Boulder, CO, with some elements at Gaithersburg, MD.
PAnOCAl BUR£M

Of ST DAW'S

UBKAJII Computer Science

and Technology

NBS Special Publication 500-129

Software Maintenance

Management

James A. McCall and Mary A. Herndon

Science Applications International Corporation

La Jolla, CA 92038

Wilma M. Osborne

Center for Progrannnning Science and Technology

Institute for Connputer Sciences and Technology

National Bureau of Standards

Gaithersburg, MD 20899

Issued October 1985

U.S. DEPARTMENT OF COMMERCE

Malcolm Baldrige, Secretary

National Bureau of Standards

Ernest Ambler, Director
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the

NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness

of computer utilization in the Federal sector, and to perform appropriate research

and development efforts as foundation for such activities and programs. This

publication series will report these NBS efforts to the Federal computer community as

well as to interested specialists in the academic and private sectors. Those wishing

to receive notices of publications in this series should complete and return the form

at the end of this publication.

Library of Congress Catalog Card Number: 85-600596

National Bureau of Standards Special Publication 500-129

Natl. Bur. Stand. (U.S.), Spec. Publ. 500-129, 65 pages (Oct. 1985)

CODEN: XNBSAV

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1985

For sale by the Superintendent of Documents. U.S. Government Printing Oflice, Washington. DC 20402
ABSTRACT

This report focuses on the management and maintenance of

software and provides guidance to Federal government personnel

to assist them in performing and controlling software

maintenance. It presents an overview of the various aspects of

software maintenance including the problems and issues

identified during the ICST sponsored survey of Government and

private industry maintenance organizations. Techniques,

practices, tools, and procedures which aid in reducing these

problems and which help to insure that quality software is

developed for and by the Federal ADP community are identified.

A definition of software maintenance is provided which

recognizes that maintenance includes enhancing a system to meet

users needs, modifying a system to adapt to a changing

environment, as well as correcting errors in the system. An

integrated approach to software maintenance is described with

suggestions for improving the software maintenance process.

These suggestions provide a basis for improving both the

software quality and the productivity of the organization.

Keywords: cost control measures, decision aids, management,

software configuration management, software maintenance

management, software maintenance tools, software quality

assurance, test plans.

iii
TABLE OF CONTENTS

Section Page

1.0 EXECUTIVE SUMMARY .... 1

2.0 BACKGROUND 3

2 . 1 Purpose 3

2.2 Introduction 4

2.3 Organization of Report 6

3.0 SOFTWARE MAINTENANCE DEFINITION 3 ^ 3.1 ' Software Maintenance as a Phase

of The Lifecycle 9

3.2 Software Maintenance Characteristics .... 11

3.3 Software Maintenance Problems 12

4.0 MANAGING THE MAINTAINER 16

4.1 The Difficulty of Software

Maintenance Activities 16

4.2 The Maintenance Career Path 17

4.3 Attributes of Maintenance Personnel .... 17

4.4 Personnel Scheduling 19

4.5 Deadline Assignments 19

4.6 Performance Criteria and

Personnel Effectiveness 20

5.0 THE MAINTENANCE ORGANIZATION

AND USER INTERFACE 21

5.1 Establishing the User Interface 21

5.2 User Interface and Task

Prioritizing/Scheduling 22

6.0 ECONOMIC CONSIDERATIONS OF SOFTWARE

MAINTENANCE 24

6.1 Cost Control Measures 24

6.2 Cost Estimation Models 24

6.3 Work Breakdown Structures 25

6.4 Specifying Resource Requirements: A Software

Maintenance Management Plan 25

7.0 SOFTWARE MAINTENANCE TECHNIQUES 30

7.1 Problem Reporting Procedures 30

7.1.1 Forms 33

7.1.2 Data analysis 33

7.2 Software Quality Assurance Procedures ... 33

iv
TABLE OF CONTENTS (cont)

7.3 Configuration Management 34

7.4 Test Plans and Procedures 37

8.0 MAINTENANCE SUPPORT TOOLS AND TECHNIQUES ... 39

8.1 Types of Tools 39

8.1.1 Support librarians 39

8.1.2 Code analysis 39

8.1.3 Requirements database

and requirements tracing 39

8.1.4 Test data management 40

8.1.5 Test and error analysis 40

8.1.6 Code instrumentors/execution

analyzers 40

8.1.7 Text editors 41

8.1.8 Structure/restructuring 41

8.1.9 Application generation 41

8.1.10 Simulation/emulation 41

8.1.11 Management tools 42

8.2 An Integrated Maintenance Environment ... 44

8 . 3 Build or Buy Decision 44

9.0 MAINTENANCE MANAGEMENT DECISION AIDS 46

9.1 Redesign Guidance 46

9.2 Structured Versus Unstructured

Coding Techniques 47

9.3 Regression Test Coverage 47

9.4 Requirements Impact Analysis 48

9.5 Major Versus Minor

Modification Assessments 48

10.0 SOFTWARE MAINTENANCE PROBLEMS TO AVOID .... 49

10.1 Common Mistakes and Pitfalls

to Avoid 49

10.2 A Strategy for Implementing Survival

Tecliniques 51

11.0 PERFORMANCE GOALS OF SOFTWARE

MAINTENANCE MANAGEMENT 52

11.1 System Availability and Reliability .... 52

11.2 User Satisfaction 52

11.3 Change Request /Problem Report

Response Time 53

11.4 Productivity 53

V
TABLE OF CONTENTS (cont)

12.0 SUMMARY AND CONCLUSIONS . 54

13. REFERENCES 59

LIST OF TABLES

Section Page

2.3-1 TOPIC INDEX 7

3.1-1 SOFTWARE MAINTENANCE DEFINITION HIERARCHY .... 8

3.1-2 MAINTENANCE ACTIVITIES IN EACH CATEGORY 10

3.2- 1 SURVEY RESULTS 15

4.3- 1 ATTRIBUTES OF MAINTENANCE PERSONNEL 18

5.1-1 KEY INFORMATION ON SOFTWARE

CHANGE REQUEST 23

6.4- 1 OUTLINE OF A SOFTWARE MAINTENANCE

MANAGEMENT PLAN 28

6.4-2 IMPLEMENTING A SOFTWARE MAINTENANCE

MANAGEMENT PLAN 29

8.1- 1 TOOL TYPES 43

8.2- 1 TOOL PRIORITIES 44

9.2-1 REDESIGN TRADEOFFS 46

10.1-1 COMMON MISTAKES AND PITFALLS 50

12.1-1 IMPROVING THE MAINTAINABILITY

OF SOFTWARE 56

12.1-2 MAINTENANCE CONSIDERATION DURING DEVELOPMENT . . 57

12.1-3 ATTRIBUTES OF MAINTAINABLE SOFTWARE 58

List of Figures

6.2-1 Example of Workflow 26

7.1- 1 Problem Reporting Process

for Maintenance 31

7.1.1-1 Sample Problem Report Form 32

7.2- 1 SQA Code Walkthrough Checklist 35

7.3- 1 Flow of System Problem Reports and Change

Request Through Configuration Management ... 36

vi
1 EXECUTIVE SUMMARY

Software maintenance is a critical function witliin most

large organizations. Tlie reliability of software systems upon

which these organizations depend is the software maintainer's

mission. This mission includes not only correcting errors, but

modifying the system to make it more effective for the user. In

spite of its importance to the organization, software

maintenance often has been ignored as a significant management

concern.

This report focuses on the management of software

maintenance. Specific problems, identified during a survey of

Government and private industry software maintenance

organizations are described. These problems fall into the

following categories:

0 The level of resources required for software maintenance;

o The lack of management discipline and visibility into the

maintenance process;

o The lack of formal techniques and decision aids for

performing software maintenance;

o The lack of support tools for the maintainer;

o Personnel issues such as turnover, career paths, and

assignment and training techniques; and

o The legacy of development - the poor quality of the software

and documentation that must be maintained.

These problems make it difficult for organizations to:

meet user's changing needs; effectively manage a large inventory

of application software; control the increasing costs of

maintenance; and keep up with the demand for new application

software development

.

A definition of software maintenance is provided which

recognizes that maintenance includes enhancing a system to meet

users needs, modifying a system to adapt to a changing

environment, as well as correcting errors in the system. An

integrated approach to software maintenance is described with

suggestions for improving the software maintenance process.

- 1 -
Our recommendations are that software maintenance can be

improved hy taking the following steps:

0 DEVELOP A SOFTWARE MAINTENANCE PLAN

0 RECOGNIZE IMPROVEMENT OF MAINTAINABILITY

QUALITY ASSURANCE)

O ELEVATE MAINTENANCE VISIBILITY IN THE

ORGANIZATION

O REWARD MAINTENANCE PERSONNEL, PROVIDE

A CAREER PATH AND TRAINING

0 FORMALIZE QUALITY ASSURANCE AND TEST

PROCEDURES

0 ESTABLISH AND ENFORCE STANDARDS

o RECORD ALL SYSTEM CHANGES (KEEP DATA)

o INTRODUCE SOFTWARE TOOLS

0 USE MODERN PROGRAMMING TECHNIQUES

O CONTROL DATA (INCLUDING TEST DATA)

o USE SCHEDULED MAINTENANCE CYCLES

Additional improvements can be realized by introducing

software maintenance considerations during the early phases of a

software system's life cycle. In order to develop maintainable

software products, the goal of maintainability must be

established during the requirements, design, and development

stages and built into the software using standards, and proven

design and development techniques. It is essential, however, to

involve the managers, maintainers, and users during each of

these stages.

- 2 -
2 BACKGROUND

This report was produced in support of the National Bureau

of Standards Institute for Computer Sciences and Technology

(ICST) acting in response to its Brooks Act charter to promote

the cost effective selection, acquisition, and utilization of

automatic data processing resources within Federal agencies.

ICST efforts include research in computer science and

technology, direct technical assistance, and the development of

Federal standards for data processing equipment, practices, and

software

.

As part of this responsibility and the need to improve

software maintenance methods and management , the ICST is

developing software maintenance guidance designed to assist

Federal agencies in the ongoing support of existing computer

systems. While software systems vary in function, type, and

size, many of the functions performed under software maintenance

are universal in scope and the activities required to keep these

systems operational are generally the same.

This report, which is part of a comprehensive family of

software maintenance guidance, addresses management and

technical practices and discusses the need for a maintenance

policy with enforceable controls for use throughout the software

lifecycle

.

2.1 Purpose

The purpose of this report is to provide guidance to

Federal government personnel to assist them in performing and

controlling the software maintenance process. It presents an

overview of the various aspects of software maintenance,

including the current, most pressing problems. It identifies

techniques, practices, tools, and procedures which aid in

reducing these problems and which help to insure that quality

software is developed for and by the Federal ADP community.

The objectives of this report are:

o to provide a set of definitions relating to software

maintenance for use by Federal agencies. Define the various

aspects of software maintenance;

o to describe a methodology which provides the information and

guidance necessary for the preparation and implementation of

disciplined software maintenance procedures;

- 3 -
0 to provide specific and detailed guidance for managing

software maintenance;

0 to provide specific and detailed guidance on the various

techniques and methods which produce more effective software

maintenance management practices;

o to provide guidance on techniques and tools that can be used

during original development to reduce the cost and

difficulty of software maintenance;

0 to provide an analysis of the problems associated with

software maintenance; and

o to help Federal agencies to produce higher quality software

and reduce software costs.

While this report is prepared specifically for use within the

Federal government, it should be applicable and useful to

software maintenance managers and practitioners in industry as

well

.

2.2 Introduction

It is currently estimated that software maintenance

accounts for sixty to seventy percent of each software dollar

allocated [NBS106] , [MART83, GAOSlb, LIEN76] . Software, as it

is used here, refers to computer programs, data, and

documentation. In some environments, it is reported that

programmers spend up to eighty percent of their time on

maintenance functions. It is important to note that over the

lifecycle, software maintenance consumes a far greater amount of

resources than software development and inevitably costs more.

Software maintenance is also a highly visible, labor intensive

activity subject to both application area and computing

environment changes. If software maintenance is to be improved,

aid is needed to improve not only the quality of the software,

but the environmental factors as well. This will require the

adoption of improved maintenance techniques, tools, procedures,

and a management philosophy which incorporates planned and

anticipated or preventive software maintenance.

A number of Federal Agencies have initiated measures to

help achieve more effective software maintenance. The U.S.

General Accounting Office (GAO) produced several reports

addressing the cost and problems associated with software

maintenance and the need for guidance in this area. The first

report, [GA080] , suggested that unless Federal agencies make

more use of modern software tools and techniques for development

and maintenance. Federal computer software will continue to cost

- 4 -
millions more than is necessary. The second report, [GA081a]

,

concluded that Federal data processing systems often are not

cost effective, do not meet user needs, have cost overruns and

simply do not work. This was attributed in part to inadequate

management control during system development and inadequate

control over software changes. In a third report [GA081b] , it

was estimated that two-thirds of the programmers on fifteen

sites visited by the GAO, spent their time on maintenance. The

National Bureau of Standards (NBS) SP 500-106 entitled "Guidance

on Software Maintenance" identifies software maintenance

problems and provides recommendations for reducing both its

difficulty and cost

.

One of the comments frequently encountered in the

literature is that maintenance costs are difficult to control

because of the disparity in how maintenance is defined. There

is also a difference of opinion on whether all of the costs

attributed to maintenance are justified. Many contend that the

majority of what is termed software maintenance is in fact,

on-going development . For what is considered development in one

environment is considered maintenance in another . Thus , a

comprehensive set of definitions which encompasses all of the

functions commonly identified as maintenance is needed. This

would facilitate better software management and a more even

assignment of maintenance costs.

Lientz and Swanson [LIEN80] defined software maintenance to

include all modifications made to an existing applications

system, including enhancements and extensions. They divided

software maintenance into three major categories: corrective,

adaptive, and perfective. The GAO document AFMD-81-25 [GAOSlb]

defineds maintenance to include: the removal of defects, tuning

the software for efficiency and economy, modifying the software

for end-user satisfaction, and adapting the software to new

operating conditions. Most of the managers surveyed agree that

maintenance generally refers to those activities required to

keep the software system operational from the time it is

accepted until the software is replaced. Regardless of how

maintenance is defined, many of the same activities need to be

performed. If maintenance is to be performed effectively, then

a methodology which employs the best available techniques and

tools must be used.

- 5

-
2.3 Organization Of Report

This section provides an overview of the structure of the

Guide and includes an alphabetized table indexed by topic.

Section 1 provides an executive summary, highlighting the

general observations and guidance offered in the report.

Section 2 provides the background, introduction, purpose, and

organization of the report.

Section 3 provides a standard definition for software

maintenance and summarizes the current problems faced by most

maintenance organizations.

Section 4 discusses the types of qualifications and experience

needed in a maintenance environment

.

Section 5 discusses user interface responsibilities in a

software maintenance environment

.

Section 6 examines current software maintenance costs, describes

estimating techniques and the concept of a software maintenance

management plan.

Section 7 describes specific maintenance techniques ranging from

problem reporting, quality assurance, configuration management,

testing, and standards and conventions which should be employed

as standard practices.

Section 8 provides an overview of software support tools which

can be beneficial in a software maintenance organization.

Section 9 describes decision

managers or supervisors

organizations

.

aids that can be helpful to

within software maintenance

Section 10 identifies common mistakes and pitfalls and discusses

how to avoid them.

Section 11 recommends performance goals that will assist in

monitoring and evaluating the organization's maintenance

activities, and provides details on how to develop maintainable

software

.

Section 12 provides the summary and conclusions.

- 6 -
TABLE 2.3-1 TOPIC INDEX

TOPIC SECTION NUMBER

Common Mistakes/Pitfalls 10

Configuration Management 7

Costs 6

Decision Aids 9

Definitions 3

Estimating 6

Executive Summary 1

Introduction 2

Maintenance Measures 11

Management Plan 6

Organization 5

Performance Evaluation 4, 11

Performance Goals 11

Personnel Issues 4

Problems 3

Problem Reporting/Cliange Requests 7

Quality Assurance 7

Redesign Criteria 9

Scheduling 4

Software Maintainability 11

Software Support Tools 8

Standards and Conventions 7

Task Assignments 5

Testing 7

Test Coverage 9

Workbreakdown Structure 6

- 7

-
3 SOFTWARE MAINTENANCE DEFINITIONS

This section provides a constituent set of software

maintenance definitions and establishes a common basis for

discussion in this report. This set of definitions is in the

form of a hierarchy. At the highest level, software maintenance

is defined as a phase of the lifecycle of a software product.

At the next level, the different types of maintenance typically

performed are identified. This is the level at which managers

are likely to relate to from a functional standpoint. At the

lowest level, the activities or generic tasks typically

performed during software maintenance are defined. The concept

of this hierarchy of definitions is shown in Table 3.1-1.

In the first two levels of the definition hierarchy, the

works of Swanson [SWAN76] and Martin and Osborne [MART82] have

been used extensively.

TABLE 3.1-1 SOFTWARE MAINTENANCE DEFINITION HIERARCHY

Software Maintenance: Performance i of those activities required to I keep a software system operational I and responsive to its users I after it is accepted i and placed into production. iLEVEL 1

Definition as a

phase of lifecycle

Perfective i LEVEL 2

Adaptive I Corrective I Categories of

maintenance

Requirements Analysis I Design Analysis I User Interface 1 Design Review I Configuration Control 1 Code Audits 1LEVEL 3

Maintenance

activities

- 8

-
3. 1 Software Maintenance As A Phase Of The Lifecyle

The lifecycle of a computer software system is defined as

the period from its initial conception until it is no longer

used. Traditionally, the lifecycle phases have been defined as

requirements, design, implementation, testing, and operation and

maintenance. These phases are generally associated with the

development of a software system. Software maintenance,

however, is usually associated with those activities performed

after development. Thus, the definition of software maintenance

as a lifecycle phase is:

the pgrf^rmanse Q,f th^se aQtiYities required tQ keep a. s^jftware system operational and resp^^ssiye ts its users

after it is accepted and placed into production

.

There is a set of products associated with each lifecycle

phase. These products encompass requirements and design

documentation, code, the data base, users manuals, test plans,

procedures and results, operators manuals, etc. Software

maintenance, then, is a set of activities which results in

changes in the baseline product.

CATEGORIES QF SQFTSARE MAINTENANCE

Maintenance activities are frequently divided into three

categories which were originally proposed by Swanson [SWAN76].

These are: perfective, adaptive, and corrective. In this

Guide, these categories are defined as follows:

0 Perfective Maintenance

All changes, insertions and deletions,

modifications, extensions, and enhancements made to a

system to meet the evolving and/or expanding needs of the

user are considered to be perfective maintenance.

Activities designed to make the code easier to understand

and use, such as restructuring or documentation updates

(often referred to as "preventive" maintenance) are

considered to be perfective as well as optimization to

make the code run faster or use storage more efficiently.

Estimates indicate that more than 60% of all maintenance

effort falls into this category.

- 9

-
0 Adaptive Maintenance

Adaptive maintenance consists of all effort initiated as

a result of changes in the environment in which a

software system must operate. These environmental

changes are normally beyond the control of the software

maintainer and consist primarily of changes to the

computer hardware, operating system, operating system

tools (compilers, utilities, etc.) and terminal devices.

Note that changes in requirement specifications by the

user are considered to be perfective, not adaptive.

Estimates indicate that approximately 20% of all

maintenance effort falls into this category.

0 Corrective Maintenance

Changes necessitated by actual errors (induced and

residual "bugs") in a system are considered to be

corrective maintenance. This category consists of

activities normally considered to be "fire-fighting" or

"quick fixes" to allow a system to continue to be

operational. Corrective maintenance is usually a

reactive type process where an error must be fixed

immediately. Estimates indicate that only 20% of all

maintenance effort falls into this category. Table 3.1-2

provides some example activities of each of these

categories.

TABLE 3.1-2 MAINTENANCE ACTIVITIES IN EACH CATEGORY

CATEGORY I ACTIVITY

PERFECTIVE

ADAPTIVE

CORRECTIVE

Making Code Easier to Understand

Improving Documentation

Optimizing the Code

Adding a New Capability

Modifying application for new version of

operating system, compiler, peripherals, or DB

Quick fixes and fire-fighting

- 10 -
3.2 Software Maintenance Characteristics

Software maintenance involves many of the same activities

associated with software development . One way of describing the

activities of software maintenance is to identify them as

successive iterations of the first four phases of the software

lifecycle, i.e. requirements, design, implementation, and

testing. Software maintenance is this successive iteration with

unique characteristics of its own. The unique characteristics

include the time-frame in which maintenance is performed, the

personnel performing maintenance, the environment of the

software product, and the testing process. Software maintenance

is typically performed within a much shorter time-frame than a

software development effort which often spans one or more years.

With respect to personnel, software development projects

are usually staffed with a specific mix of skills to meet the

requirements of the application and development efforts. People

with different skills are assigned at the various phases of the

development to take full advantage of their expertise. In

contrast, all maintenance activities for a particular software

product may be performed by one person, acting as requirements

analyst, designer, coder, and tester. Although this is not

always the case, the separation and assembling of a certain mix

of skills is more typical during development than during

maintenance

.

Another characteristic of maintenance is that the

maintainers usually are not the same persons who developed the

system. Thus, the maintainers must analyze and understand the

existing product before they can modify or correct the software,

usually without any inherent knowledge of the implementation

strategies employed by the developer. While this is a subtle

difference, it is significant. It is also the basic reason

people traditionally have stated that maintenance is not a

creative process, motivating many 'good' programmers to seek

development projects. Since maintenance activities are

performed within the context of an existing framework or system,

it is generally thought that an individual ' s flexibility is

somewhat constrained. This, more than any other factor,

presents the most challenging problem for maintenance personnel.

Moreover, the older the system, the more difficult the system is

to maintain.

Software maintenance can be viewed as successive iterations

of the development phases, but its uniqueness should be

recognized to insure effective management, staffing and planning

considerations. The following is a list of functions typically

performed while maintaining software

:

- 11 -
Change Requirements

Impact Analysis

User Interface

Problem Report Recording and Control

Change Request Recording and Control

Configuration Control

Data Base Modification

Code Modification/Recompilation

Code Debugging

Module/ Subsystem/ System Testing

Documentation Modification

Code Inspections/Walkthroughs

Test Data Generation

Management Planning and Control

Field Delivery

Administrative Support

User Assistance/Training

Depending on the environment , a certain subset of the these

activities may be associated with corrective maintenance while

another subset may be associated with perfective maintenance.

The processes are influenced by such factors as the size of the

change, response time or other time constraints, whether the

maintenance is performed on-site or at a centralized maintenance

facility, etc.

3.3 Software Maintenance Problems

Recognition of the cost of software maintenance to the

Government was the catalyst for the focus of attention on

maintenance. Two surveys, one by the General Accounting Office

(GAO) and one by Lientz, Swanson, and Tomkins , contributed

significantly to this recognition. Each survey identified the

major problems in software maintenance. Table 3.2-1 summarizes

the findings of these two surveys along with the findings of the

survey conducted by the National Bureau of Standards (NBS). The

problems identified in each of these surveys are grouped

according to six major problem areas.

- 12 -
The first problem area identified is that of cost. GAO

estimated that two-thirds of the programming staff in the

Federal government are involved in maintenance. Statistics from

Department of Defense studies report up to 75% of the lifecycle

budget for software systems is related to software maintenance

[RADC82] . A recent book on software maintenance [MART83]

estimates $30 billion are spent annually on software maintenance

world wide. These types of statistics have only recently been

recognized due to the lack of a standard definition of what

constitutes maintenance and to the difficulties in obtaining

cost accounting and management data.

Management problems are considered to be the second most

significant area of concern. The problems in this group involve

managing/recognizing maintenance as a separate function; user

and upper level management's perception of maintenance; a lack

of goals, standards, and criteria to judge performance; and

managing the user interface. These problems can be attributed

to the fact that unique aspects of software maintenance were not

recognized in the past

.

The third problem area specifically addresses technical

approaches (techniques) and procedures for performing software

maintenance. While there are many standards, methodologies,

techniques, and procedures advocated for software development,

there are few associated with maintenance. Emphasis on software

development problems is a familiar theme within the software

research and software engineering communities. However, until

recently software maintenance has received little attention. A

typical response to the reason for this neglect is that if

software is developed well in the first place it will be easy to

maintain. This response ignores the fact that sixty to seventy

percent of maintenance consists of modifying software to perform

new functions or to comply with new requirements. It also

ignores the sizeable software inventory currently being

maintained that was developed without the use of modern

programming practices. Without disciplined approaches to

maintenance, these systems are characterized by an exponential

growth in size and complexity during their post delivery life.

The result is generally premature system demise or instability

and progressively more costly maintenance.

The fourth problem area identified in the survey is

software tools. There are few tools available which directly

apply and support the unique aspects of software maintenance.

The lack of specific tools for software maintenance is

compounded by the fact that tools common to development

organizations that would also benefit software maintenance are

rarely transferred to the maintenance organization.

- 13 -
Tlie fifth problem area involved personnel issues such as

availability, lack of training, turnover, motivation,

ezperience, scheduling, etc.

The last problem area identified by maintenance personnel

is the legacy of development. This legacy is that software

turned over to the maintainers is often poorly designed, poorly

implemented, and poorly documented. Thus, the maintainer has a

poorly structured product to maintain without the proper

information to understand it. These attributes all contribute

to making the software more difficult to fix or modify.

The existence of these problems in a data processing

organization can result in:

o an inability to meet the user's changing needs;

0 an inability to manage effectively a significant investment

in a large inventory of software programs and data;

0 an application backlog, where most resources are devoted to

maintaining existing systems, preventing development of new

applications. (The costs of not developing a new system are

typically not accounted for but can be significant.); and

0 a decline in the quality of systems because of poor software

maintenance, resulting in more expensive future maintenance.

- 14 -
Table 3.2-1 Survey Results

1 IH

1 *> <M

1 a>

1 «04J 1 B

1 O

1

1 A a 1 4J

1 o 1 B.

1 r-t 1 o;

1 0) (0 1 0

1 c a t>o 1

\ o o o 1 0)

1 O »H 1 Ck.

1 U V

n 1 h u a 1 ID

1 4J

1 ll <M 1 B < 1 4J 1 0) 0)

1 Cl. u 1 E O

1 Q u a 1 Q, a X 1 h « 1 tie d

1 Vi 1 c c

1 o >^ u 1 c &

>> 1 o 1 s) e 1 1^ D O 1 B a

> 1 O 'IJ •-I it 1 CC (D -<-> 1 k. d a 1

' 1 a> B

to 1 1^ « u 1 c~

1 O 3 O 1 &.<M

CO 1 iO B C 1 D O

GOK 1 O O 1 o

ji

*i0

a fi. 0)

fi kt o €9 <D o a 1

1 .A 1 ID k.

1 O «j 1

1 «H 0> o

ID a 1 SI o

01 o 1 > a 0)

It « o 1 a

9 O 1 ID Q 1 o

T) *> 1 rH •3 1 -H

a> 1 O 4J 1 *i O ID 1 O Q 0 1 •) o a> 1 0) w^ 4-> 1 ^

b «o 1 o D a 1 a

A. a 1 u a fi H IS C E 1 •3 1 F-t u u fi ^ 0) 1

1 £ a •m fi 1 3 0) »i 4J 1 o o 1 ) 0) O 1 O (D ID 1

1 It 4J 1 O O 0) >> 1

1 a >. o 1 O T5 ID 1 c o 1 D >4 *J o 1 c « «-) a 1 V. >». Vi ^ 1 o >> 1 « fi iH o 1 O O O 01 1 o >H U > 4-> 1 •x a 1 V4 *i 1 1 o a> 1 O b « > a. 1 *i +3 4J 3 1 s 1 O r-l O a> 1 -H 1 M V 1 M fi. •H a o 1 t-1 FI « 1 o a 1 O fi. C k. « I u e e u J

1 19 S > 3 ki •J b. 1 >3 m < H cu O O 1 o o o o 1 O O O O 1

1 *3

1 a

oni

1 01

1 fH «

CD

fi

1 a> 1 fi.O O

ID 1 E a k> 1 o a kl t- 1 a> «0 1 1 01 « B «0 to

1 c T3 1 B 1 1 fi. a .H O O O

1 c C c 1 B ^ 1 1 a> 0) ^ kl a

1 « ID ) 0) F^ 1 « E 1 1 k. *i o a 'Wfi.fi.

1-4 1 £ *i 4J fi. o> 1 4J B 1 1 o a o B 0 ID .3 •w 1 a C ID H a 1 a> a ) 1 1 ^ a o

IS 0 1 a c ki 0) a 1 kl <b kl 1 I •) « ID c e a

B E 0) o 1 U E «D 1 1 ID E B k. a> B «o e 0) ID 1 ki •a ki ID 1 » c O 1

1 n a S B -H 0 1 o 4^ a ID ki 1 "O o kl 1 1 B fi. 3 X>0 IS ID X> B. 1 w. 9 ID Q> 1 k. h fi. >, 1 1 d O a O -H 0) a O Q e 3 fi. 1 0 ^ 4^ 1 1 E -4 V. O kl

k> 1 IC E k4 (0 1 X > O -H 1 1 Q) ^ o •o O

1 -D o a> O t>04^ 1 o 4J kl 1 1 T) e tM u O 1 (3 u ID •4 c a 1 O 0 «0 1 1 »H c w O

>> 1 « 3 *3 ^ OJ 1 4J (B ID DP 1 1 «Ofh fH fH o O O

•o k. 1 E a> ID ^ E 1 O O D « 1 1 6 -4 a> kl o 0. « >, a 0) O 1 S 1-1 >H ID S 1 ID a kl B 1 1 -H £l B C 4^ >. 0 « ^ ID 1 ^ 3 o •H D kl 1 QJ d t! « ^ 1 1 ^ d C > m c e 4J 4J 0

O O e O -H 1 u » h T3 1 1 a, f4 o O f4 o > Ft -H 3 N T>0 k> 1 ki (D M 0) V 3 1 B 0) B « 1 1 fi.'F4 ID E fH f4 fh cr

*i ^ » 1 Q> ja C kl kc cr 1 gj .a 0) 1 1 E e k. k. U 4J d d (D a 3 > 1 ID O « BOO 1 £ O •O ^ •] 1 1 o > 0) 3 M t c 3 3 TJ a to O i B LQ .3 D b. kl 1 U ID < ID Q 1 1 o < fi.i-> CO fi.X oo<

o o 1 O O O o o 1 o O O 1 1 o o o o o o o o

e 1 rs

t-i 1 a> a

£l e kl 1 1 B d 44

4J O 1 1 «-! .a .H u fh a « 1 d 4J

1 ID 1 *i e d ID 1 i fH 1 B

«o > m 41 fi. "O 1 1 o fH fi, 1 a

a « k< s g> o M 1 J o 1 d fi. o 1 o

«4 S (C 10 4J d o 1 1 *> 1 s O f4 1 «-! e 4J « E E fi. •O O 1 a e 1 4> a 4> E B CD O a «o 1 1 <M 1 a fi. > 1 d o 3 e d kl c o d 1 1 o 1 a o 1 49 < O V kl 0) o H k4 1 1 *i *> ^ 1 a O > ID O IP 1 1 « 1 <M a 1 CD O o o o a V. O 1 1 ID 1 o (D 49 1 E « a kl u ^ >> o a 1 1 3 k< « 1 3

>> 0) fi. d B f4 ID d d 1 1 o> 1 O

*> B <-l B O (D 4J FH -4 B 1 1 -a 1 kl <M 49 : O

CD s d d —t ^ d kl kl 1 1 a> 1 d , -a

kl O «S O kl E 4J> .H a O D O 1 J 4J 1 » •H a

3 O d O O > •'4 VS'k) Vi 1 1 -H 1 4J V ID 1 k< (0 a to T) 4J C W •H b> 1 1 B 1 IM o 1 o

o d ^ o 0 3 0 0) o kl a> J 1 -H 1 O 1 o o

<

SS E N h. ae <M z V s U fi. 1 1 .3 1 CO A 4> 1 En O O o o O 1 1 o 1 o 1 O

Bn 1 49 o 1 0

9 1 fH 1 <M 9 H 1 9 1 O E

1 a 1 fi. f4 1 a 1 >>o

d f IB 1 o 1 CH

E 1 fH 1 IS

kl 1 o 1 kl 1 «o>

O 1 o 1 w 1 e e

b. 1 H 1 a. 1 J Q

- 15 -
4 MANAGING THE MAINTAINER

Tlie software development process has evolved to a set of

procedures that are performed in a prescribed order. Although

performance of the procedures often requires several passes

before the desired quality is obtained, the course of action is

generally better defined than the maintenance process. Although

the maintenance process can be viewed as iterations of the

development process, there are unique aspects of maintenance

which seemingly have no procedural counterpart to development.

There are numerous training courses on software development

techniques , but only a few corresponding types of courses that

address software maintenance. While numerous studies have

investigated the inherent difficulty of constructing a complex

system, only a few studies have addressed the difficulty of

maintaining a complex system. Furthermore, the results of these

studies have contributed to the development of tools and

techniques to aid in the tasks of software requirements

definition, design, coding, and testing. Maintenance tasks are,

in general, less organized than development tasks. The

situation is further complicated by the fact that documentation

and other information necessary to complete maintenance tasks

are often unavailable.

4.1 The Difficulty Of Software Maintenance Activities

One research study [CIRA71] related maintenance to trying

to find "a needle in the haystack". For example, when a

software error occurs, how does the analyst proceed to isolate,

analyze, and repair the problem? There are no tried and true

techniques that can immediately isolate the routine at fault.

Rather, the analyst must perform some "detective work" based

upon analytical skills and perseverance, and must be able to

reconstruct the processing scenario at the time the problem

occurred. The process of reconstructing the scenario can be

extremely difficult, involving complex processing. The analyst

must decide, on the basis of clues, which parts of the system

contain the faults. This process, sometimes referred to as

"over confirmation of clues" [CIRA71]), is inefficient in terms

of the number of logic paths the analyst must trace before

identifying the faulty one.

Examination of the psychological processes necessary for

incorporating a major enhancement, reveals further sources of

difficulties. For example, upon beginning a task, the analyst

may have a reasonable idea of what routine will be affected.

However, before that intuition can be verified, the impact on

the design must be assessed. This assessment necessitates a

- 16 -
jump upward in the level of abstraction. If the affected module

is tightly coupled with other modules, additional jumps upward

are necessary. After identifying all of the modules implicated,

the analyst must move quickly to a lower level of abstration,

(i.e. the code) to begin modifications. Studies have shown

[CIRA 71] that the process of hopping from one level of

abstraction to another is error-prone and inefficient.

Since maintenance managers and technical personnel are

judged by their success in meeting deadlines, there is often an

attempt to hurry to complete the tasks. Pressure mounts and

mistakes occur. Thus, the physical environment may not be

conducive to maintaining the concentration level essential for

the task.

4.2 The Maintenance Career Path

Throughout the industry, the role of the maintenance staff

has not always been viewed favorably. Often, a person is

assigned to a maintenance activity after performing development

tasks poorly or simply as an "entry-level" assignment. Careers

are sometimes short-lived because of the lack of management

support and a good organizational attitude about software

maintenance. The very nature of maintenance responsibilities

can result in a demanding 24 hour on-call environment . In some

cases, the personnel must agree to be available on weekends in

the event of a system emergency. Fortunately, the traditional

viewpoint and other unfavorable conditions are disappearing in

the DP community.

Organizations should identify a specific career path for

maintenance personnel. This path may be identified in the same

terms as development personnel, i.e. progression from an

entry-level programmer to a senior programmer to an analyst to a

supervisor to a unit manager. However, the key is to

demonstrate that there is a career path.

4.3 Attributes Of Maintenance Personnel

Software maintenance is a critical function in most

organizations; thus, it is important that the staff be highly

skilled. The key attributes of successful maintenance personnel

are highlighted in Table 4.3-1. Attempts should be made to hire

persons with these attributes; they should also be encouraged in

the existing staff through training courses and by managers who

reinforce them during meetings and counseling.

- 17 -
TABLE 4.3-1 ATTRIBUTES OF MAINTENANCE PERSONNEL

ATTRIBUTES TECHNICAL BACKGROUND

EXPERIENCED Application

Coding /Debugging

Testing

TECHNICAL

PROGRAMMING SKILLS

Understand existing software

Ability to make software more

maintainable

ABLE TO RELATE

TO USERS NEEDS

ABLE TO RELATE TO

OPERATIONAL

ENVIRONMENT

VERSATILE Knowledge of various hardware,

operating systems, languages.

ANALYTICAL Able to find, error.

Able to analyze impact of change.

ADAPTABLE Able to work under sometimes poor

conditions, using poor documentation.

RESOURCEFUL/

IMAGINATIVE

Must be creative, (i.e. must be able

to diagnose problem, create work around

or invent a method for enhancing a

system within existing constraints).

OBJECTIVE Must recognize deadline and technical

constraints of task.

THOROUGH

:

Fixes and changes must be thoroughly

debugged and tested.

- 18 -
4.4 Personnel Sclieduling

A frequently practiced management strategy in software

maintenance is to assign a "resident ezpert" to every system

that is maintained. While the simplicity of this management

strategy is attractive, the overall effectiveness of the

maintenance team may be reduced. Depending upon the size and

urgency of the request load, bottlenecks may develop, especially

if the resident expert is unavailable. Another result of this

approach is an eventual deterioration of the documentation

because the resident expert fails to maintain it. In fact,

undocumented changes enhance the maintenance expert's image and

job security. If this resident expert leaves the organization,

however, the system is left in an unmaintainable state. One way

to avoid this type of disaster, is to make multiple system

assignments so that no single individual becomes the weak link

in the chain.

Another approach is to rotate assignments so that the lack

of one person will be less of a bottleneck in the completion of

tasks. An added advantage of rotational assignments is the

increase in the responsibility level of personnel. The concept

of rotational assignment is also applicable between development

and maintenance assignments.

4.5 Deadline Assignments

Maintenance activities typically are more susceptible to

deadlines than development activities. Problems that result in

a system crash demand an immediate response, e.g. banks must

post transactions on a daily basis or incur both a loss of funds

and the wrath of customers. Similarly, payroll offices are

beset with complaints if weekly payroll checks are not on time.

Inevitably, the maintenance tasks of "keeping the system up and

running" generate the pressing deadline requirements for the

technical staff. While the ability to meet deadlines is often

an important evaluation criteria for the technical staff, missed

deadlines reflect negatively on management as well.

Effective techniques for forecasting resource requirements

are often not available. Thus, task completion estimation

techniques for software consist of heuristic recipes rather than

replicable analytical techniques. If the technical staff is

unduly rushed in performing maintenance tasks, there is a high

probability that the quality of work will be lower. In the

process , maintenance standards and procedures are often ignored

in an effort to "get it out the door". The end result is

degraded system and software quality and more deadline

assignments

.

- 19 -
The tendency to "rusli to fix" tasks can be reduced by:

o rotating "on-call" assignments among the staff so no

one person is relegated to continuous on-call

assignment. This may be more difficult to accomplish

in small organizations than in large ones;

o offering incentives to lessen the psychological

burdens

;

o estimating the resources required for enhancements and

other major modifications before assignment;

o taking the complexity of the change and the system into

consideration when estimating the time required for

change implementation; and

0 considering the presence or absence of adequate

documentation

.

4.6 Performance Criteria And Personnel Effectiveness

Accurate and objective personnel evaluation techniques for

programmers and analysts are not well established in the

industry. Programmer productivity, whether in a maintenance or

a development setting, has proven to be difficult to measure.

While many types of measures have been proposed, (lines of code

produced per day, success in meeting deadlines, cost per line of

code, etc.) no one set of measures has been unanimously accepted

as a standard. Furthermore, programmer productivity takes on a

separate meaning when considering maintenance rather than

development

.

Maintenance productivity metrics should evaluate the

criteria that reflect the measure of satisfaction to the user

and organization as a whole. Some examples of appropriate

metrics include the ability to meet a deadline (if realistically

set); the degree of quality of the maintenance activities

(post-maintenance problem report frequency) ; the ability to

improve future maintenance by preparation of adequate

documentation; and the observation of standards and procedures.

- 20 -
5 THE MAINTENANCE ORGANIZATION AND USER INTERFACE

The historical perspective is that maintenance is a

necessary evil, required because the software was not developed

well in the first place. This attitude is changing rapidly in

today's environment where computers and software are present in

all facets of our life. Almost every major organization is

dependent to some extent on the effective performance of

software maintenance. Thus, an understanding of the

difficulties, challenges, and requirements of software

maintenance by manager and users is essential.

There are a number of factors which contribute to efficient

and cost effective software maintenance. Most of these factors

are discussed in detail in sections six through eleven of this

Guide. The two factors that are perhaps the best indicators of

how well a software maintenance organization is performing,

however, are effective user interface and user satisfaction.

5 . 1 Establishing The User Interface

Effective user interface helps insure that all persons

involved or affected by the change request are aware of each

others' requirements, as well as the functional capabilities of

the system. It is one of the most important responsibilities

within a maintenance organization. Most maintenance

(approximately 60%) is performed specifically at the users

request (to modify the system). The user interface group would

have responsibility to:

o Forecast User's Needs /System Changes;

o Complete System Change Request

;

o Estimate time and resources requirements;

o Review Estimates;

o Keep informed of status;

o Participate in tests;

o Review User ' s Manual

;

o Understand User's situation, people, needs; and

o Educate user to the environment,

organizational capabilities, feasible

responses

.

User interface should be established with a degree of

formality and conducted on as friendly a basis as possible. The

degree of formality can be introduced by the use of a system

change request form. This form not only introduces some

formality, it provides an historical record of system changes

and provides a basis for managing the change process. Table

5.1-1 identifies the key information the change request form

should contain. A more detailed example of a problem reporting

- 21 -
form which could also be used for change requests may be found

in section seven of this report. The requestor should always

provide as much information as possible about the cause of the

problem or the nature of the change. This will not only assist

the maintainer in changing the software, and but will help

management better assess the cost of making the change.

5.2 User Interface And Task Prioritizing/Scheduling

When possible, fixed maintenance cycles should be

established. The user should be involved in the assignment

process. An effective technique is to have periodic user group

meetings where new and current system change requests,

availability of resources, and priorities can be reviewed. It

is important that the user recognize that the maintenance

organization is a limited resource and that change requests must

be prioritized to effectively utilize that resource.

Organizations that employ scheduled maintenance cycles are able

to manage their resources more effectively than those that react

to daily ad hoc demands.

- 22 -
TABLE 5.1-1 KEY INFORMATION ON SOFTWARE CHANGE REQUEST FORM

o Identification of Requestor

o Date of Request

o Change Desired (description and why)

o Date Change Needed/ Priority

0 Analysis (description of approach to change)

o Identification of Resources Required

0 Responsible People

o Schedule/Milestones

o Date Change Made (with maintainer and user

sign off)

- 23 -
6 ECONOMIC CONSIDERATIONS OF SOFTWARE MAINTENANCE

The effort required to maintain systems developed within

the last five years is typically less than that required for

older systems. The reason is that these systems typically have

been developed using structured high level languages, structured

design and implementation methodologies, well documented system

utilities and data base management systems. As a result, these

systems tend to be easier to understand and modify.

6.1 Cost Control Measures

Maintenance organizations are beginning to recognize the

need to improve systems as they are modified. Evidence suggests

that a 20% to 50% reduction in future maintenance costs can be

achieved by the consistent use of software quality standards,

tools, and techniques (See [MCCA83] and [MART83].).

Another cost control measure that has proven effective,

though not always compatible with an organization's accounting

procedure, is the use of a charge back system. In a charge back

system, the users pay for maintenance on the applications that

support them. The advantage of this system is that requests for

modifications are evaluated in detail , and in terms of their

cost /benefits by persons responsible for the cost. A related

benefit is that the user gains insight into the maintenance

process. While it is difficult to determine the cost savings

provided by a charge back system, the use of this technique has

the effect of encouraging more efficiencies in the system by

users and maintenance staff.

6.2 Cost Estimation Models

Most cost estimation models are parametric models for which

the user provides input parameters describing the system in

terms of size, application, language, complexity, etc. Some of

these models provide an estimate of lifecycle costs for the

system

.

The output of the models is the estimated level of

effort /cost to develop and maintain the system. This output can

be used to estimate the cost of making a major change to an

existing system. The change may be described to the model in

terms of the amount of new code to be developed and the

percentage of the existing code to be modified. Further

information can be found in [THIB81] and [COOK80]

.

- 24 -
6.3 Work Breakdown Structures

A work breakdown structure is a tectinique used for planning

and controlling projects by decomposing each project into

manageable work units. This technique is used often when

Government organizations contract for development or services.

Essentially, this technique requires a planner to describe the

workflow within the maintenance organization. For a particular

maintenance task, this work flow can be used to plan/estimate

resources required and milestones. An advantage of using a

consistent work breakdown structure across many tasks is that

planning and estimating become easier and more accurate because

of the empirical data upon which those plans are based. Figure

6.3-1 provides an example of a work flow plan. Each boz

represents a work unit that could be associated with a work

breakdown structure accounting code.

6.4 Specifying Resource Requirements: A Software

Maintenance Management Plan

The mode of many software maintenance organizations

responding to problem reports and change requests is both ad hoc

and reactive. It is difficult to project resource requirements

on a long term basis using this mode of management . We

recommend that a plan be developed to assist management in

specifying project resource requirements. This plan should

provide a brief description of the application system including

the hardware/ software environment on which the production system

runs. Any variations or multiple configurations should be

defined. Organizations which use the system or have

responsibility for its development and maintenance should be

identified. Their responsibilities and interfaces should be

outlined

.

- 25 -
I •+ — — 4-

I I «

I O I

I ^ c t>0 I

I E « a I

I 0) 4^ 'H I

I 4-> dfti I

I (fi OJ CO I

I >> O ffi I

I CO o H I * < I

I

+ >

1 + + —

1

1 + 1

1 1 a

1 1

1 + — +

1 1 "0 1 1

1 1 h 4> 1 B 1

1 1 OS 'H 1 O «0 1

1 1 13 1 <p a 1 + —

+ 1 1 n p 1 Cfi ^ 1

1 1 «< 1 >»-p 1

1 1 -p 1 u m 1 a> a 1 1 CO 1 £ a> 1

1 1 1 9 H 1

1 + + •f CO 1 ts a 1 ss

1 1

1 1

1 1

1 —

-f

1 — 1 4- +

1

1

1 — > 1

1

1 + 1 + —

1 > + a

a a

E IS

a> >>

•H u

a p

&•<

I

I

4- — -f — —

ao

"O *> o d

(0 U 4>

o> e x s) n E U 0) -H 9

4> o (DUO a -H Q

MM «

a

I T)

I 43 0)

I E 01 U> >

I 0) w) a> ^

I 4> n 9 0)

I B) d cru

I >>A 0) 0)

I CO u a: ce

I 4. _

+ 4- 4-

««a» p-l B

T) 4i 0 O IS •O X 0) O H U

•a -H o > U 01

4- 4- 1 1 e 1 1 1

1 1 0 a 1 1 0 1 1 0

1 1 1 -H 0 1 1 0 1 1 0

1 r 1 43 ^ 1 1 ^ 1 1 ^fI

1 1 1 IS 4> 1 1 43 1 1 f 4- 4- 1 1 4> « 1 1 « 1 1 d

1 1 CI 0 1 1 e 0 1 1 d 0

1 1 0) ^ 1 1 TJ W 1 1 *> -H WO <D 1 1 E vi 1 1 0 <H 1 1 d<M

<D 9 W 9 10^1 1 O-H 0 4:1 43 0> 1 1 o-o 1 1 1 1 Tl « OS iH 1 1 0 0 1 1 0 1 1 0

9 E (4 t> 1 1 Q X 1

1 1 1

1 X 1 1 X o-H a> a 1 1 a *> a K 1 4- — — 4- 4- 4- 4- 0? (0 <p o: H u 1 1 1 1 a t 1 1 1 « 1 1

1

1

1 + 4- 1 4- — 4-

1 1 — +

4-4- — + 4-+ — 4-4-— 4-4-

4- 4- — 4-

I I

I I

I a » I

I QOO) I

I -H 'H I > 4- 10 > I

> 4. 4.

+ — — — 4-

a a I (4 d -H I <ti 4^ a \ U ID I D -H d I 10 u I 10 H I < I

I 4- — 4-

+ 4-

a I iH I T3 iH I ^ O I E O (1 I Q> O *> I H 01 a I XIU o \ O O I (4 43 I Cl. ti « I O fl I e.d I 0) I a I

I 4. +

4- 4- O I h ^ I 0> 4> I > o o I •ri 4:1 9 I r4 -a I SO I ^ I

I

I

I

I 4- — 4-

I 10 I 0> I 49 I 4 > 4 X d I

1 OV I

I &< I

I D I

I

M •I hi

I o « ^

ID <MO

01

»4 01 S H

t>0 Cl<

•rt E

lb d

MH

I I 4 4-

- 26 -
The plan should outline the procedures to be followed in

maintaining the systems. The procedures should address how

system changes are requested by the user and how priorities and

schedules are to be assigned. Other procedures to be covered

include problem reporting by the user, provisions for customer

assistance, and response times for problem resolution,

provisions for review, approval, and implementation of

configuration and version changes, and any planned maintenance

cycles. Any quality assurance activities and testing activities

(regression testing) including user involvement in acceptance

testing should also be addressed.

The plan should identify such resource requirements as

hardware, software, personnel, facilities, and supplies. Care

should be taken to include the anticipated time requirements for

maintenance of the system. The plan should also identify

support software tools and methods to be used in maintaining the

system

.

The plan may change as the situation changes or as lessons

are learned and feedback obtained. The fact that it ezists,

however, provides continuity, formality, and a rationale for the

procedures in place. The result of these influences on the

maintenance organization is an introduction of a more

disciplined approach to maintenance providing a more effective

resource to the overall organization. Table 6.4.1 describes key

attributes of a software maintenance management plan; while

Table 6.4-2 descibes specific steps that should be taken when

implementing a software maintenance management plan.

- 27 -
TABLE 6.4-1 OUTLINE OF A SOFTWARE MAINTENANCE MANAGEMENT PLAN

1.0 Introduction

Purpose

Scope

Applicable Documents

2.0 System Description

Hardware (Application system Production Environment)

Software

Definitions /Glossary

3 . 0 Management

Identification of User, Developer, Maintainer

Responsibilities

Interfaces

4.0 Procedures

System Change Requests /Problem Reports

Customer Assistance

Configuration Control

Quality Assurance

Testing /Acceptance Testing

Maintenance Cycles

5.0 Resources

Hardware ( Maintenance Environment

)

Support Software

Personnel (Assigned Responsibilities)

Facilities

Supplies

- 28 -
TABLE 6.4-2 IMPLEMENTING A SOFTWARE MAINTENANCE MANAGEMENT PLAN

o Inventory all application software and documentation.

0 Establish maintenance management plans for each, application.

0 Establish a common workflow.

o Assign personnel to key functions such as configuration

management, quality assurance, user interface, and testing.

0 Establish standards and conventions.

0 Initiate the use of system change request and problem report

forms and maintenance logs.

0 Document a plan to purchase or build support tools incrementally.

Present this plan to upper management for approval.

o Establish procedures for fixed maintenance cycles to handle

user change requests and problem reports (critical problems

in a high priority mode)

.

0 Establish a training program including in-house training,

on-the-job training, and commercial seminar /course attendance.

0 Brief upper level management periodically on the progress of the

improvement plan citing statistics collected from problem

reports, change request forms and maintenance logs.

o Schedule periodic meetings with staff to solicit ideas on

effective techniques or tools.

0 Communicate with developers and provide them with feedback on

maintenance problems, including problem type and frequency.

The goal of this exercise is to improve software development

standards and quality.

- 29 -
7 SOFTWARE MAINTENANCE TECHNIQUES

Effective control of a software maintenance organization

usually results in a higher quality product. Controlling the

activities performed by the maintenance personnel is best

accomplished when there is a definitive set of procedures to

follow. The techniques and procedures discussed in this section

include: problem reporting (forms usage, data analysis),

software quality assurance, code walkthroughs, software

configuration management, and test plans and procedures.

7.1 Problem Reporting Procedures

A critical aspect of user satisfaction is a responsive

problem reporting procedure. Problems can be residual

(delivered with the system) or introduced as a part of

modification activities. Regardless of which type of problem

exists, maintenance organizations must be prepared to catalogue

problems efficiently for either future or immediate analysis and

correction. An example of a useful reporting system is a data

base management system that maintains the current problem

reports and their status, catalogues the problem reports, and

provides various error analysis as depicted in figure 7.1-1.

Key aspects of a problem reporting procedure include:

o a form for the user to fill out;

0 discussion of the problem report with the user and

estimate of the time and resources required to correct

the problem;

o documentation of the analysis of the problem;

0 categorization the problem for future use;

o involvement of the configuration control function in

assigning the priority and insuring the update is made

properly; and

o documentation the completion of the fix.

- 30 -
Analysis

Figure 7.1-1 Problem Reporting Process for Hainten&nce

- 31 -
TITLh

DATt „

P*<00fUM ID: AKiALYSTfS):

Coaputltlanal

11(1 US MMtlM

•ivltiwi Itr t»««

Mel9iious itatanMt

•rrwicout ealeuUtlon

i^NwcMMry wicylttiw

1a*«

l»i»ufflel»«

violation of eodlitv ttandtrd

subscript •rrpn

cr9iMnt list inemtlttcftclM

tfFiinitlallXffd ««n«b)t

eats ltr«tftur» trrori

sesllitfl/prBClllon trrof^

lts1<«« taft

»i ruwous wnmt ««()u»nct

Tastar

Low. Hediw, .Bl9h,

^rfrcl^*^) -Performance Sufastandird Performance Unacceptab'k - Systew Stops

METHOD OF DFTECTION:

DESCRIPTION OF PROBLEM:

EFFECTS OF PROBLEM:

RECOMMENDED SOLUTION:

f ^fSr^^ REQUIREMENTS LIN>:S NUMBERS: CLOSED

S • CLOSED DATt - Circle one: c . CORRECTED. CLOSED

U « UNSUPPORT^). CLOSED

Figure T. 1.1.1 Staple Problem Report Form

- 32 -
7.1.1 Forms -

Problems can originate from the field, from users, or from

in-house analysts and programmers. Often, the need to retrieve

information quickly is very important in maintaining high

user-satisfaction. A form that records certain useful

descriptive information can aid in this task. Figure 7.1.1-1

contains an ezample of a Problem Report Form. Problem reports

vary in form but the information content is generally as shown.

More advanced problem reporting systems, based on data base

management systems can assist in analysis and provide statistics

on the types and frequency of problems being reported.

7.1.2 Data Analysis -

The data gathered by the problem reporting system can be

used to describe the changing quality of the system. For

example, the project manager may wish to examine each module in

a system for a frequency distribution of the number of problems

by module. Experience has indicated that sources of errors are

rarely uniformly distributed across all modules. Rather, a

subset of modules will exhibit high error rates. Once the

problem areas are pinpointed, management is better able to

determine whether it would be more cost effective to redesign

rather than continue maintaining these modules.

7.2 Software Quality Assurance Procedures

The software quality assurance (SQA) procedures should

identify the documents that will be reviewed, the personnel

involved, and the schedule. These procedures and

responsibilities should be documented in a software quality

assurance plan. The SQA procedures should, as a minimum,

involve design and code walkthroughs. They may also include a

documentation audit, test monitoring, and an SQA sign off prior

to release.

The most common of these procedures is the code walkthrough

which is performed typically by a group of four people. The

author of the code explains the program statement by statement.

During this time, a checklist is used by the moderator to

eliminate common coding errors. The checklist identifies such

items as: data item initializations, subscripts in array

references, pointer updates, computation errors and comparison

errors. An example checklist is shown in Figure 7.2-1. As the

walkthrough progresses, group interaction results in a trouble

shooting analysis of the software. One benefit of the group

- 33 -
interaction is that design errors are often discovered by other

team members.

7.3 Configuration Management

The primary objective of software configuration management

(SCM), generally referred to as the management of software

changes, is the release of operationally correct, reliable, and

cost effective software. SCM consists of four functions:

identification, configuration control, status accounting, and

auditing. It helps to ensure that software changes satisfy

specified requirements and test criteria. It is also the

responsibility of SCM to: provide for records retention,

disaster recovery, library activities, a software repository,

and to ensure that the necessary coordination and approvals are

obtained prior to changing the baseline. SCM helps to track all

actions associated with a problem report or change request.

Figure 7.3-1 identifies the flow of control for problem reports

and change requests using SCM.

- 34 -
I Code «BLU:tlirougb Cbeoklist i Inepector:

I

I Systen N&ne : i Date

:

Progr&D M&ine: I

STRUCTURE

1. Does the progr&n exceed establlslied size etandards?

2. Does the program have only one entrance and one exit?

3. Does the prooesslng flow fron top to hottom?

4. Does the number of decisions exceed established complexity

standards?

5. Does the number of paragraphs exceed established standards?

DOCUMEKTATION / COMMEKTS

1. Are there prologue comments that identify function, inputs and

outputs, variables, author, modifications made, limitations, etc?

2. Are decisions commented?

3. Are variables described by comments?

4. Are branches commented?

5 . Is all machine language code commented?

6. Do comments do more than repeat operation?

7. Is consistent indentation and spacing used?

DATA

1 . Are all variables names unique?

2. Does each variable have only one unique name?

3. Are variables used in only one way?

4. Are global variables used consistently with respect to \inits

and type?

5. Are all elements of an array /table functionally related?

6. Are all variables initialized before use?

7. Are all default values described?

6. Are arrays/tables/ strings initialized before use?

INTERFACES

1. Are all calls to other programs commented?

2. Are all arguments within calls parametrics?

3. Does the calling program maintain control?

ERROR HANDLING

1 . Are inputs range tested?

2. Are possible conflicts or Illegal combinations of inputs checked?

3. Is there a check to determine if all necessary data is available

prior to processing?

4. Are loop and branch index parameters range tested?

5. Are sTibscripts range tested?

6. Vhen an error condition occurs, is it passed to a calling module?

7. Are the results of a computation checked before outputting or processing continues?

6. Are there any mix made expressions?

9. Are all unusual termination conditions described?

10. Are error messages descriptive and necessary actions explained?

CONSISTENCY/COMPLETENESS

1. Dofis the code represent the design?

2. AiHi all global variables defined?

3. ^re all called programs defined?

4. Is all code reachable?

5 . Are all labels necessary?

6. Are nonstandard language features avoided?

7. Is sfcJ-f -modifying code avoided?

Figure 7.2-1 SQA Code Walkthrough Checklist

- 35 -
Figure 7.3-1 Flow of Systea Proijlem Reports eiad Change RequeBxs

Tlirougii Configuration Management

- 36 -
7.4 Test Plans And Procedures

Effective test plans and procedures can help to ensure

software quality during maintenance. The test plan should be

established with milestones and estimates for each step that

indicate when a system fix or modification is to be designed,

coded, tested, and placed into production. A reasonable amount

of time should be allocated for testing prior to release.

Management should also require that status reports, which

provide visibility into the testing schedule, be received

promptly from the person or team responsible for making

modifications and testing. Otherwise, intermediate milestones

may slip without any adjustment being made to the final

milestone or release date. This often results in a compressed

testing schedule which makes thorough testing impossible. There

should be a standard approach for testing and using automated

aids for test case generation and storage. The standard

approach should include the following steps

:

0 plan for enough time to thoroughly test a modification to a

system;

0 require the development and use of test cases which

thoroughly test the software;

0 archive the test data for future regression testing;

0 prepare tests that are based on user scenarios and on the

functional requirements of the system; and

0 establish a set of criteria for test coverage that provides

confidence that the testing has been thorough. This set of

criteria may include such procedures as

:

a percentage of all lines of code must be executed;

a percentage of all decision paths within the software

must be executed; and

execution of all error handling processes in the code.

o Use a parallel test system.

0 Involve user in acceptance of system.

There should be a commitment to establish and maintain a

standard set of test cases (data) for each application. This

set of test data can be used for regression testing whenever

software modifications are required.

- 37 -
While there are many software tools that support the test

process, many maintenance programmers develop their own tools to

assist in debugging and testing code. It is recommended that a

standard set of tools be used in the test process. Tools to be

considered range from test data generators, to test database

management systems, to code instrumentors/execution analyzers.

The following NBS publications provide additional information in

the areas addressed in this section: [FIPS106] , NBS106]

,

[FIPSlOl], [NBS98], and [NBS93]

.

- 38 -
8 MAINTENANCE SUPPORT TOOLS AND TECHNIQUES

During the survey of maintenance organizations, most

managers expressed a desire for more software support tools.

Many were not aware of tlie existence of tools for maintenance

activities, Others stated that their budget was not sufficient

to purchase additional tools. The following section identifies

the types and function categories of the tools that are

available. A more detailed description of these tools may be

found in Table 8.1-1 and in the NBS Special Publications 500-88

[HOUG 82]

.

8 . 1 Types Of Tools

8.1.1 Support Librarians -

There is a wide variety of tools which control changes to

the configuration or version of source code. They range from

specific configuration control systems to programmer utilities

which facilitate standard program construction and modification

processes. Most maintenance organizations practice

configuration control but only about half use an automated tool

to support that activity. This is an area in which automated

support librarian tools are especially useful.

8.1.2 Code Analysis -

One of the first steps a maintenance programmer performs,

when debugging a reported error is to examine the source code.

Considerable time is spent looking at the source code since the

documentation is often out of date. Code analysis tools can be

used to process the source code for: standards enforcement,

data flow analysis, complexity analysis, generation of cross

reference listings, or production of flow charts.

8.1.3 Requirements Database And Tracing -

When a user requests a change to a function or capability

of the system, the change is not identified with a particular

routine. In a large system, tracing a change (requirement)

through the design of the system to where it is implemented can

be time consuming. Tools exist that provide this type of

traceability . In some cases these tools require the

specifications to be written in a formal language ([ALF077].

[TEIC77]) and in other cases they do not [HERN81] . In all

cases, these tools can be very advantageous to the maintainer

- 39 -
attempting to analyze how to modify a system and wliat impact a

change will have.

8.1.4 Test Data Management -

Test data may be prepared manually, generated from actual

production data sets, or prepared as a result of analysis of the

code. Once prepared, the test data should be maintained for

regression testing. Tools such as test data generators and data

base management systems support these activities and provide

considerable cost savings by preventing the maintainers from

generating and storing test data manually.

8.1.5 Test And Error Analysis -

Problem reports from the users are valuable sources of

information to a maintenance organization. They not only

identify corrections that must be made but help to keep track of

the frequency, number, and type of problems being reported,

enabling an organization to improve its performance over time.

This improvement can be realized by completely redesigning and

rewriting programs which exhibit high error rates, by assigning

senior personnel to those problem programs, and by instituting

standards which will alleviate occurrence of certain types of

errors during modifications or correction activities.

8.1.6 Code Instrumentors/execution Analyzers -

Tools exist which instrument source code with counters,

sensors, and assertions, and then provide reports after test

cases have been run against the code. These tools report code

and path coverage and assertions during the test /execution run

providing some assessment of the thoroughness of testing. Other

tools in this category assist in optimization by identifying

frequency of execution of individual statements and segments of

the code. Such tools support the debugging process by allowing

a programmer to step through the execution of a program during

execution. These types of tools provide automated support in

analyzing the dynamic behavior of the code, and are particularly

helpful when tuning a system or during testing (regression

testing) changes to the system.

- 40 -
8.1.7 Text Editors -

Text editors are used extensively in software environments

to produce documents and to enter and modify code. A

significant benefit can be realized in maintenance if the

documentation produced during development is delivered to the

maintenance organization in machine readable form. Modification

(updates and revisions) of the documentation then becomes a

process similar to that of code modification and is more easily

enforced upon the programmers. Keeping the documentation up to

date can provide significant savings in debugging and designing

modifications

.

8.1.8 Structuring/restructuring -

Several tools

few years which

unstructured code,

product can be

most cases, the

considerable to

Other tools in

preprocessors to

conversion package

have emerged in the market place in the last

are designed to generate structured code from

The benefits of working with a structured

significant to a maintenance organization. In

inventory of unstructured code must be

warrant the expense of a restructuring tool,

this category include structured language

facilitate structured coding and language

s which support conversion of code.

8.1.9 Application Generation -

Application generators are high level languages oriented

toward a specific type of application which allow use of

functional statements to build a system. In the past, these

types of tools have not facilitated maintenance because of the

difficulty in debugging, tuning, and testing in the high level

language, the lack of support tools, and the scarcity of

personnel experienced in application generators. However,

recent advances in these types of tools make them more

accommodating to the maintainer. Their use is dictated to the

maintainer if the development was performed using one.

8.1.10 Simulation/emulation -

Simulations and emulations are typically developed for a

specific application. They are used to assess performance of

the system. In maintenance, they can be used to assess whether

performance goals are met after modification. They also are

useful if an application is being maintained on a computer

system which is not the same as the production system. In this

- 41 -
case, a simulator or emulator allows testing to be done on the

maintenance facility prior to fielding the new version.

8.1.11 Management Tools -

There are a number of tools which can assist in managing a

maintenance organization. Tools such as schedulers can be used

to keep track of different tasks, personnel assignments,

milestones, etc. Tools that utilize data from various sources

can provide management data which describe the amount of change

being made to a system, the growth in complexity of that system

as a result of the changes, the performance of the maintenance

organization in terms of user problem reports, and response time

for completion of change requests. Although these tools may not

increase the maintenance staff's productivity, they do assist

the manager in making better decisions about resource

allocation.

- 42 -
TABLE 8.1-1 TOOL TYPES

TOOL TYPES 1 FUNCTION CATEGORIES IN NBS SPECIAL PUBLICATION 500-88 [ HOTJG 82]

Support Librarians 1 formatting, configuration management

Code AnalyslB 1 cross-reference, data flow analysis, structure checking, comparison

1 Interface analysis, type analysis

RequlrenentE Data Base

and Tracing

completeness checking, consistency checking, tracabillty

Test Data Management test data generation, regression testing

Test and Error AnalyslB problem report data base.

Code Instrumentation/

Ezeoutlon Analysis

coverage analysis, tracing, tuning, symbolic execution, assertion cheokin

debugging support

Text Editors editing

Structure /Restructure translation, restructuring

Application Generators synthesis

Optlnlzers optimization

Simulations /Emulations simulation

Management Tools schedulers, PERT/CPM, status reports, cost estimation models

- 43 -
8.2 An Integrated Maintenance Environment

A recommended approach to realizing long term benefits from

software tools is to accumulate an inventory of tools that will

support the various activities performed by the maintainer. The

goal should be to establish an integrated set of tools which

support a logical sequence of activities (a methodology), share

data, and provide a common user interface. Table 8.2-1 provides

a list of tools grouped by the order in which they should be

accummulated to maximize phasing in the tools under budgetary

constraints. This concept can have tremendous benefit to an

organization if all personnel are using the same set of tools.

TABLE 8.2-1 TOOL PRIORITIES

First Phase Compiler (structured

languages)

Text Editor

Configuration Manager/

Support Library

On-line Debugger

Second Phase Code Analyzer

Test and Error Analysis

Optimizers

Code Instrumentation/

Execution Analysis

Simulation /Emulation

Management Tools

Third Phase Restructurer

Requirements Data Base

Application Generator

8 . 3 Build Or Buy Decision

Software support tools have always suffered from the "not

invented here" syndrome. Programmers often prefer to develop

their own utilities and tools rather than use existing ones.

Traditionally, tools have been poorly documented, very

specialized, and difficult to move from one environment to

another. There has been significant improvement in commercial

tool development, and many of the software tools now offered are

reliable, and well documented. Therefore, a build or buy

decision process should be conducted prior to building a tool

- 44 -
in-house . If a tool that sufficiently meets the requirements of

the maintenance organization can be purchased commercially, it

is usually cost beneficial to do so rather than building one

in-house

.

- 45 -
9 MAINTENANCE MANAGEMENT DECISION AIDS

Managing a maintenance organization is a challenging task.

Decision aids assist management by helping them decide when to

redesign rather than to continue making patches; when structured

coding techniques should be used on unstructured code; and what

the impact of a change will be on the system and on resource

requirements

.

9 . 1 Redesign Guidance

One of the more difficult questions that arises during

change analysis, is when to redesign. The basic question is

whether a change to a system should be simply a modification to

the code (a patch) or if a particular segment (module or

modules) of the system should be redesigned and rewritten.

Table 9.2-1 provides the basic tradeoffs involved in making this

decision.

TABLE 9.2-1 REDESIGN TRADEOFFS

Why Patch Why Redesign

0 Expediency 0 Feasibility of change

0 Schedule 0 Efficiency of Performance

0 Effort 0 Restructure Code

0 Continued 0 Use modern design/code

operation techniques

0 Facilitate future changes

Generally, redesign is dictated when the change is not

feasible within the current structure of the system or in order

to meet performance (efficiency) goals. Other compelling, but

often overlooked reasons to redesign are the restructure of the

code: to comply with standards; to incorporate more modern

design and programming practices; and to facilitate future

changes. A basic set of criteria for redesign may be:

- 46 -
o time and effort are available;

0 feasibility of change requires it;

o performance requirement necessitates it;

0 if more that 20% of the lines of code of a module are

affected; and

o if a patch will cause the complexity of the system to

exceed established standards.

9.2 Structured Versus Unstructured Coding Techniques

A significant percentage of the inventory of software being

maintained in most organizations today was developed over eight

years ago. This software may have been developed using

unstructured languages and without the discipline of modern

programming practices. In some situations, attempting to change

this type of code using modern structured approaches is

difficult. If the change is small and expediency takes

priority, then no attempt to "structure" the code is necessary.

If the change is significant , then redesign using more modern

techniques are recommended. In this way, the overall structure

of a software system can be gradually improved.

9.3 Regression Test Coverage

A key decision that must be made in all maintenance

organizations is when a new version of a system should be placed

into production. The question that must be answered is: has

the system been tested, sufficiently to provide the manager with

confidence that the system will perform satisfactorily?

Resource and time limitations typically prevent an organization

from testing as much as they would like. The following

guidelines are recommended: o If modifications to a system are

localized, then regression testing should be performed against

the subset of software effected. This subset can be determined

by analyzing interfaces and determining that subset of software

whose interfaces with the rest of the system are not affected by

the change

.

o If the modification permeates the system, regression testing

should be performed. This is especially true where the change

affects global data. The key to successful testing, however, is

the proper selection of test data. See [MCCA77] . o During

regression testing, criteria of complete testing are:

- 47 -
execution without failure;

100% coverage of all decision paths; and

100% coverage of all interfaces.

9.4 Requirements Impact Analysis

Most change requests involve adding a new capability or

modifying an existing capability. The user generally identifies

more uses for the system or identifies more effective ways to

use the system. The impact of a change should be assessed by

the maintenance organization prior to making the change.

The manager should encourage the user to take a long range

view of the system and plan changes to the system in a

systematic way. One technique that has proven effective

involves establishing and maintaining an itemized requirements

data base which identifies each function and traces that

function to the modules which implement it. This data base can

then be used by managers to determine the feasibility and cost

effectiveness of each change. The ability to estimate the

probable resources required for each change has implications

both in the resources and priority assigned to the requests.

Use of the data base to analyze priority, impact, and long term

goals with the user enables the manager to better plan for

resource requirements.

9.5 Major Versus Minor Modification Assessments

The difference between a major modification and a minor one

can vary significantly from one applications area to another.

The set of criteria used to make the distinction of major and

minor is installation dependent. What one manager may consider

to be a large resource commitment, another may perceive as

typical and acceptable.

Using a definite set of criteria will help the manager, as

well as the user to understand the magnitude of each change.

The manager must prepare information for each user request that

will support any scheduling decisions. This information can

often be prepared from historical data referencing past changes

that were similar to the specific request.

- 48 -
10 SOFTWARE MAINTENANCE PROBLEMS TO AVOID

There are two key ingredients to successful ADP maintenance

management. The first is to recognize problems that are unique

to the ADP maintenance environment, and the second is to plan

strategies and policies that incorporate maintenance technology,

good management practices, and service goals of the

organization

.

10.1 Common Mistakes And Pitfalls To Avoid

From a management viewpoint , establishing set procedures

(policies) and insuring that supervisors and personnel enforce

those procedures is the best way to avoid problems and pitfalls.

Many of these mistakes are a result of actions taken for the

sake of expediency or from a lack of established procedures

.

Table 10.1-1 identifies common mistakes made in maintenance

organizations, and describes the associated indicators or

symptoms

.

- 49 -
TABLE 10.1-1 COMMON MISTAKES AND PITFALLS

MISTAKES /PITFALLS SYMPTOMS / INDICATORS

0 CM done manually

by programmer

0 No records kept (no ctiange

request form, problem report,

or maintenance log)

Loss of configuration

control

No resource tracking by task

Inability to estimate

task requirements

Loss of configuration

control

0 Respond to problem reports

and change requests only,

0 No separation of

maintenance function

- Reactive maintenance

Transparent costs

Lack of control/visibility

o Lack of organizational

respect for maintenance,

personnel management , use

of junior/entry level programmers

- High turnover

0 No quality assurance

0 No documentation updates

o No redesign/all patch

methodology

0 No formal regression testing

- Cost of maintaining system

gets higher each cycle

- Error rates after maintenance cycle are high

- Cost of maintaining system

gets higher each cycle

- Loss of configuration cntl.

- Fixes become all patches

to avoid ripple effect

- System performance degrades

- Cost of maintaining system

gets higher each cycle

- High turnover

- Higher error rates after

fielding

- customer dissatisfaction

- 50 -
10.2 A Strategy For Implementing Survival Techniques

Implementation of survival tecliniques in an ADP maintenance

environment requires the cooperation of the other ADP functional

areas as well as the maintenance group. All parties involved

must be convinced that the improvements are in their best

interest and the overall goal is the improvement of the

organizations ' s performance. Unless the implementation plan

convinces all parties, provincial attitudes are likely to hinder

any real improvements. Once some order is established, the

maintenance manager can proceed to implement a plan to improve

the overall performance of the maintenance organization.

Consideration should be given to the following recommendations:

0 If your maintenance organization is completely saturated and

over-committed, has borrowed as many resources as possible

from developing organizations, and management is considering

a new application development which will dilute resources

even further, look at off-the-shelf software. Many packages

are available with maintenance support

.

0 If an application system has degraded in performance,

maintenance is extremely difficult because of the complexity

of the code, and documentation is outdated, consider forming

an audit team. This audit team, consisting of at least one

senior analyst, a programmer, perhaps a technical writer,

and a user representative, could review all documentation,

code, and records, and provide a documented recommendation

of how to salvage the application system.

o If the workload is impossible to perform within required

schedules, the manager should attempt to form a review group

of users. The manager should chair this group and, at

meetings, outline user requests, and schedule commitments,

and available resources. Where conflicts exist, it will be

the responsibility of this group to assign priorities and

slip schedules.

o Develop a plan which provides a phased approach to the

software maintenance process. This plan should introduce

formal procedures for assigning responsibilities, and

purchasing or developing tools. It should not only give

direction to the staff, but help to improve the software

products

.

- 51 -
11 PERFORMANCE GOALS OF SOFTWARE MAINTENANCE MANAGEMENT

The overall goals of a maintenance group can be summarized

as "keeping the system up and running" and "pleasing the users".

This section describes some key measures of the performance of a

maintenance organization which are listed as follows:

0 System availability and reliability

o User satisfaction

0 Timely responses to change requests and problem reports

0 Productivity improvement

It is recommended that, as a minimum, these elements be measured

when evaluating software maintenance performance goals.

11.1 System Availability And Reliability

Problem report frequency is a good measure of how well a

maintenance organization is doing. This involves counting the

problem reports that represent failure of the system to perform

as specified. It does not include change requests which

represent the user's desires for new capabilities or

enhancements. The amount of downtime that results from a

failure is an indicator of the severity of the problem. If the

frequency of problem reports is steadily decreasing, then the

maintenance organization is performing maintenance more

effectively.

11.2 User Satisfaction

Although difficult to evaluate objectively, user

satisfaction is the most important performance measure of a

maintenance organization. The user's satisfaction with the

maintenance organization is influenced, to a large extent, by an

effective user interface. In some cases, the users lack

in-depth knowledge of data processing. In other cases, the user

may want to get involved in the technical issues of maintenance.

A technique that is effective in assessing user

satisfaction is the use of periodic user surveys soliciting a

critique of the maintenance organization's performance. Review

of the results of this survey with the user and development of

corrective action plans can be effective in improving user

satisfaction.

- 52 -
11 . 3 Change Request /Problem Report Response Time

The time it takes to make a change to the system

significantly influences the attitude about the maintenance

organization. The attitude of upper level managers, as well as

users, is influenced by the timeliness of completing each change

request. Users want a response to their requests as soon as

possible, and the upper level managers will focus on the cost

factors involved in each alteration.

The change request and problem report forms can be used to

capture statistics about response time. These statistics can be

used to justify additional tools to increase productivity and to

identify bottlenecks in procedures.

11.4 Productivity

Very few maintenance organizations use productivity

measures, primarily because no standards or commonly accepted

measures exist. However, using some measure of productivity is

recommended because it aids in pinpointing areas where

productivity gains can be realized. Some measures that are

commonly used and that are relatively easy to compile include:

o number of problem reports corrected per time period;

o number of change requests completed per time period;

0 number of lines of code (entire inventory of applications)

maintained per maintenance personnel ; and

o number of lines of code modified or added per maintenance

personnel

.

These productivity measures can be evaluated on an

organization-wide basis or by application. Applications for

which very low productivity figures are recorded may be

candidates for redesign, documentation support, or support

tools

.

- 53 -
12 SUMMARY AND CONCLUSIONS

Software maintenance effort is impacted by tlie fact that a

large percentage of the current inventory of applications being

maintained was not designed to accommodate change. A

significant number of systems are poorly implemented and poorly

documented due to the lack of discipline, the lack of uniformity

in development approaches, and schedule and budget pressures.

Thus, the use of state-of-the-art development methodologies will

not guarantee a software system in which all future changes are

anticipated.

Our findings indicate that there is a need to:

0 adopt a software engineering approach for software

maintenance which takes into consideration software

problems, personnel involved, and user and management

constraints, (i.e. schedules, cost, and system capability);

0 develop management policies and procedures which incorporate

maintenance requirements. This implies establishing a

maintenance philosophy during the early stages of software

development , as well as a maintenance technology which

defines software maintenance requirements, activities,

techniques, and tools. The overriding objective of this

technology should be understandable, maintainable software

which is easy to revise and validate over the software life

cycle; and

0 adopt enforceable controls. Any clarification or

redefinition of maintenance may provide scant savings if not

accompanied by controls which can be made to work within the

organization. Such controls will enable improved error

tracking and also help to insure that software change

requests

:

-are within the scope of maintenance;

-do not adversly affect software performance;

-are incorporated using a modular approach;

-are adequately tested; and

-are properly documented.

It must be recognized that the problems faced in most

software maintenance environments are twofold: improving

maintainability and convincing management that the greatest gain

will be realized only when maintainability is engineered into

the software products. The goal of maintainability must be

established during the requirements, design, and development

stages and built into the software using standards, and proven

design and development techniques. It is also essential to

involve the managers, maintainers, and users during each of

these stages. The early introduction of maintenance concepts,

- 54 -
coupled with the use of more effective techniques for

maintenance, will lead to an integrated approach to software

maintenance over the lifecycle. The overall effect will be

increased maintainability and increased cost effectiveness of

the ADP organization in general. Therefore, maintainability

must be a goal of development

.

The following three tables provide general guidance on

practices that, when followed, will result in more maintainable

software. Table 12.1-1 provides a list of general practices

found to be effective for improving software maintainability.

Table 12.1-2 identifies factors and describes the activities

necessary to ensure that maintainability is engineered into the

software products, while Table 12.1-3 provides a checklist of

attributes that can be used as guidance to help programmers

improve the quality and maintainability of the software. This

guidance ranges from conceptual (anticipating the need to change

in design and implementation) , to incorporating state-of-the-art

technology (using modern programming practices), to managerial

(transition development tools to maintenance environment), to

practical (have maintainer be involved in development). If

these concepts are consistently enforced, the resultant software

product will be easier to understand, correct, modify, and

maintain

.

- 55 -
TABLE 12.1-1 IMPROVING THE MAINTAINABILITY OF SOFTWARE

0 Design and Implement for Maintainability/

Enhancement (Top down)

0 Use High. Order languages (4th Generation

languages if possible)

0 Use Report Generators, Data Base Management

Systems, System Utilities, Support Software

Use Modern Programming Practices/Techniques

n nnonTTiPTil". \J \^ KJLJAl^^ XX \J npsi ^-J O _i_ tfn tl XJ. anrt Uj XX\^ Ttrinl _L XL L yj _X PTtiPntati \^ XI I XX \J \Jij \J nnXX

0 Trace Requirements to Implementation

;

' 0 Save Test Data

0 Use Error Checking Techniques

0 Design for Human Engineering

0 Move Development Tools to Maintenance

Environment

- 56 -
Table 12.1-2 MAINTENANCE CONSIDERATIONS DURING DEVELOPMENT

Phases

Requirements

Specification

Activity

o Identify maintainability as a

primary goal of development

.

o Identify maintenance Facility/

Resource requirements,

o Document requirements.

Design Phase Establish design standards and

conventions (maintainability

supporting standards.

Audit design for compliance with

standards

.

Document design.

Document data base design.

Trace requirements to design.

Coding Phase 0 Establish coding standards and

conventions (maintainability

supporting standards).

0 Audit code for compliance with

standards)

.

0 Trace design to code.

o Document code

.

0 Comment code

.

o Document a maintenance manual

.

0 Transition code and debug tools

to maintenance.

Test Phase I o

I 0

I

I 0

Document all errors

.

Assess maintainability during

error correction.

Maintain code and documentation

during test/error correction

activities

.

Establish test data base

Transfer test tools to

maintenance environment

- 57 -
TABLE 12.1-3 ATTRIBUTES OF MAINTAINABLE SOFTWARE [MCCA77]

Maintainability - the effort required to locate and fix an error

in operational program or the effort required

to modify an operational program (Flexibility)

Consistency - those attributes of software that provide

uniform design and implementation techniques

and notation.

Simplicity

Conciseness

those attributes of the software that provide

implementation of functions in the most understandable manner (usually avoidance of practices which increase complexity)

.

those attributes of the software that provide

for implementation of a function with a minimum

amount of code

.

Modularity - those attributes of the software that provide a

structure of highly independent modules.

Self-Descriptiveness - those attributes of the software that

provide explanation of the implementation of a

function.

Generality - those attributes of the software that provide

breadth to the functions performed.

Expandability - those attributes of the software that provide

for expansion of data storage requirements or

computational functions.

- 58 -
13 REFERENCES

[AFTE80] AFTEC/TEBC, "Software OTS'E Guidelines, Vol.

Ill: Software Maintainability Evaluator's Handbook."

NTIS ADA 104328, Apr. 1980.

[AFL077] Alford, M. , "A Requirements Engineering

Methodology for Real-Time Processing Requirements,"

IEEE Transactions Software Engineering, Vol 3,

1977.

[B0EH76] Boehm, B., "Software Engineering," IEEE

Transact icns CB Computers, Vol. C-25 , No

1976.

[CIRA71]

[COOK80]

[DER079]

[ DONAS0]

[GA080]

[GA081a]

[GAOeib]

(IRAD), "A Study of Fundamental Factors

Underlying Software Maintenance Problems

Report" ESD-TR-72-121 , Dec. 1971.

12, Dec

Final

Cook, J. , "An Appraisal of Selected Cost/

Resource Estimation Models for Software Systems,"

NASA Z-582-81-1, Dec. 1980.

DeRoze, B. , Nyman, T. , "The Software Lifecycle - A Management and Technological Challenge in the

Department of Defense," IEEE TraBsaCticss CB Scftvzare

EngineeriBg, Vol 4, 1979.

Donahoo, J. et al, "A Review of Software

Maintenance Technology," RADC-TR-80-13 , Feb, 1980

GAG, "Wider Use of Better Computer Software

Technology Can Improve Control and Reduce Costs,"

FGMSD-80-38, Apr. 1980.

GAG, "Government -Wide Guidelines and Management

Assistance Center Needed to Improve ADP Systems

Development," AFMD-81-20, Feb. 1981.

GAG, "Federal Agencies' Maintenance of Computer

Programs: Expensive and Undermanaged, " Report to

Congress AFMD-81-25, Feb. 1981.

- 59 -
[GELP79]

[GILB79]

[HALS77]

[ HERNS 1]

[H0UG82]

[LIEN76]

[MART82]

[MARTS 3]

[MCCA76]

[MCCA77]

[MCCA83]

[MYER75]

[MYER77]

[PARIS2]

[PARI83]

Gelperin, D. , "Testing Maintainability," AQM

SIGSQFT Software Engineering SQtes, Vol. 4 /No,

Apr. 1979.

2,

Gilb, T. , "A Comment on 'The Definitions of

Maintainability'," ACM SIGSQFT S^ftsare Engineering

NQtes, Vol. 4, /No. 3, Jul. 1979.

Halstead, M. , Software Seience. Exoelier Press,

1977.

Herndon, M. , "Development of tlie Requirements

Management Methodology, " SAI Report LJF-S 1-0071 /OFS

OSS, Jan. 19S0.

Houghton, R. , "Software Development Tools," NBS

Special Pub 500-S8, Mar. 19S2.

Leintz, B. and Swanson, E.B., "Characteristics of

Application Software Maintenance," NTIS ADA 024085,

Dec. 1976.

Martin, R. , Osborne W. , "Guidance on Software

Maintenance," NBS Special Publications 500-106,

December 1983.

Martin, J., McClure , C. , SQfts/are Maintgnancej.

The Problem and Its Si^luti^^n, Prentice-Hall, Inc. , New

Jersey, 1983.

McCabe, T. , "Complexity Measure," Ttqq 2nd

International CsnferesQe fin Software Engineering,

1976.

McCall, J., et al, "Factors in Software Quality,"

RADC-TR-77-369, Nov. 1977.

McCall, J., Herndon, M. , "Software Maintenance

Survey," NBS Contract NBS2SBCA1650 , June 1983.

Myers, G. , Reliable Soft^^are Through Composite

Design, Petrocelli/Charter , 1975.

Myers, G. , Sfift^aze Eeliabilityj. Principles

and Practises, John Wiley & Sons, 1977.

Parikh, G. , Teehnigues Qi. Program and Systeffl

Maintenance, Winthrop Publisher, Inc., 1982.

Parkh, G. , Zvegintzov, N. , "Tutorial on Software

Maintenance," IEEE Computer Society, Catalog

EH0201-4, 1983.

No

- 60 -
[RADC82] RADC DACS Newsletter, June 1982.

[STAN77] Stanfield, JR., "Software Acquisition

Management Guidebook: Software Maintenance:" AD

A052040, Oct. 1977.

[SWAN76] Swanson, E.B., "The Dimensions of Maintenance,"

P£QQ SeQ^jnd Conference QS Sfift^-zare Engineering, 1976.

[TEIK77] Teichroew, D. , Hershey, E., "PSL/PSA: A

Computer-aided Teclinique for Structured Documentation

and Analysis of Information Processing Systems," IEEE

TranaQtiQns Qu ^Qft'^SiTQ. Engineering, vol 3, 1977.

[THIB81] Thibodeau, "An Evaluation of Software Cost

Estimation Models," RADC TR, Feb. 1981.

[WHIT77] Whitmore, D.C., "Computer Program Maintenance

One of the Software Acquisition Engineering Guidebook

Series," NTIS ADA083209, Dec. 1977.

- 61 -
NBS-n4A (REV. 2-8C

)

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

PUBLICATION OR

REPORT NO.

NBS/SP-500/129

2. Performing Organ. Report No^ 3. Publication Date October 1985

4. TITLE AND SUBTITLE

Computer Science and Technology:

Software Maintenance Management

5. AUTHOR(S)

James A. McCall, Mary A. Herndon, Wilma M. Osborne

6. PERFORMING ORGANIZATION (If joint or other tttan NBS. see /n struct/on s; NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

«(A:SmNfiY8M^fiKlXX80(^X

Gaithersburg, MD 20899

7. Contract/Grant No.

8. Type of Report & Period Covered

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City, State. ZiP)

Same as item 6.

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 85-600596

Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a si gnificant

bi bliography or literature survey, mention it here)

Software maintenance is a critical support function within most large organizations

today. In spite of its importance to the organization, software maintenance has been

ignored as a significant management concern and as a fertile area for technical

This report presents an overview of the various aspects of software mainprovides an indepth analysis of the associated problems, giving particular

the most pressing ones. It identifies tools, techniques, and procedures

reducing these problems. This report also provides detailed guidance for

managing software maintenance as a separate organizational entity. It also provides

assistance needed to develop and employ improved maintenance practices and procedures,

that result in reduced software costs and which help to insure that quality software

is developed for and by the Federal ADP community.

improvement,

tenance, and

attention to

which aid in

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons)

cost control measures; decision aids, lifecycle management plan; performance criteria

regression testing; software maintenance; software quality; software techniques; soft- ware tools; test plans; software quality

13. AVAILABILITY

[~Xl Unlimited

I I For Official Distribution. Do Not Release to NTIS

[x] Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

65

15. Price

USCOMM-DC 6043-P80
ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued m the

series: National Bureau of Standards Special Publication 500-

Namc

Company

Addresa

City State Zip Code

(Notification k»y N-S03)



Technical Publications

Periodical

Journal of Research—The Journal of Research of the National Bureau of Standards reports NBS research and development in those disciplines of the physical and engineering sciences in which the Bureau is active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a broad

range of subjects, with major emphasis on measurement methodology and the basic technology underlying

standardization. Also included from time to time are survey articles on topics closely related to the Bureau's

technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs—Major contributions to the technical literature on various subjects related to the Bureau's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) developed in cooperation with interested industries, professional organizations, and regulatory bodies.

Special Publications—Include proceedings of conferences sponsored by NBS, NBS annual reports, and other

special publications appropriate to this grouping such as wall charts, pocket cards, and bibliographies.

Applied Mathematics Series—Mathematical tables, manuals, and studies of special interest to physicists,

engineers, chemists, biologists, mathematicians, computer programmers, and others engaged in scientific and

technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical properties

of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide pro- gram coordinated by NBS under the authority of the National Standard Data Act (Public Law 90-396).

NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) is published quarterly for NBS by

the American Chemical Society (ACS) and the American Institute of Physics (AIP). Subscriptions, reprints,

and supplements are available from ACS, 1155 Sixteenth St., NW, Washington, DC 20056.

Building Science Series—Disseminates technical information developed at the Bureau on building materials,

components, systems, and whole structures. The series presents research results, test methods, and perfor- mance criteria related to the structural and environmental functions and the durability and safety

characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of a

subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject

area. Often serve as a vehicle for final reports of work f)erformed at NBS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally recognized re- quirements for products, and provide all concerned interests with a basis for common understanding of the

characteristics of the products. NBS administers this program as a supplement to the activities of the private

sector standardizing organizations.

Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest to the consumer. Easily understandable language and illustrations provide useful background

knowledge for shopping in today's technological marketplace.

Order the above NBS publications from: Superintendent of Documents, Government Printing Office,

Washington, DC 20402. Order the following NBS publications—FIPS and NBSIR 's—from the National Technical Information Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FTPS PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register. The Register serves as the official source of

information in the Federal Government regarding standards issued by NBS pursuant to the Federal Property

and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented

by Executive Order 11717 (38 FR 12315, dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal

Regulations).

NBS Interagency Reports (NBSIR)—A special series of interim or final reports on work performed by NBS

for outside sponsors (both government and non-government). In general, initial distribution is handled by the sponsor; public distribution is by the National Technical Information Service, Springfield, VA 22161, in paper copy or microfiche form.
U.S. Department of Commerce

National Bureau of Standards

Gaithersburg, MD 20899

Official Business

Penalty for Private Use $300