ISO/IEC 14764:1999

INTERNATIONAL ISO/IEC
STANDARD 14764
First edition
1999-11-15
Information technology — Software
maintenance
Technologies de l'information — Maintenance du logiciel
Reference number
©
ISO/IEC 1999
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading
this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in
this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the
unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved

© ISO/IEC
Contents
Foreword. vi
Introduction . vii
1 Scope . 1
1.1 Purpose. 1
1.2 Field of application . 1
1.3 Limitations. 2
2 Conformance. 2
3 Normative references . 2
4 Terms and definitions. 3
4.1 Adaptive maintenance. 3
4.2 Baseline . 3
4.3 Corrective maintenance . 3
4.4 Maintainability Plan . 3
4.5 Maintenance enhancement . 3
4.6 Maintenance Plan. 3
4.7 Maintenance Process . 4
4.8 Maintenance programme . 4
4.9 Modification Request (MR). 4
4.10 Perfective maintenance . 4
4.11 Preventive maintenance . 4
4.12 Problem Report (PR) . 5
4.13 Software Engineering Environment (SEE). 5
4.14 Software Test Environment (STE). 5
4.15 Software transition . 5
5 Application of this International Standard. 5
5.1 Maintenance process . 5
iii
© ISO/IEC
5.2 Organization of this International Standard.5
6 Implementation considerations.6
6.1 Introduction.6
6.2 Types of maintenance.6
6.3 Arrangements for maintenance .7
6.4 Tools for maintenance .7
6.5 Software measurement.8
6.6 Documentation of process .8
6.7 Early involvement in development .8
6.8 Maintainability.8
6.8.1 Maintainability and the development process.9
6.8.2 Maintainability and specific activities in the development process.10
6.9 Software transition .11
6.10 Documentation.11
7 Software maintenance strategy .11
7.1 Introduction.11
7.2 The maintenance concept.12
7.2.1 Scope.12
7.2.2 Tailoring of the process.12
7.2.3 Designation of who will provide maintenance.12
7.2.4 Estimate of maintenance costs.13
7.3 Maintenance planning .13
7.3.1 Introduction.13
7.3.2 The maintenance plan.13
7.3.3 Guidelines for a maintenance plan.14
7.4 Resource analysis .16
7.4.1 Personnel resources.16
7.4.2 Environment resources .16
7.4.3 Financial resources.16
8 Maintenance processes .17
iv
© ISO/IEC
8.1 Process implementation . 18
8.1.1 Inputs. 18
8.1.2 Tasks . 19
8.1.3 Controls. 20
8.1.4 Support. 20
8.1.5 Outputs. 20
8.2 Problem and modification analysis. 21
8.2.1 Inputs. 21
8.2.2 Tasks. 21
8.2.3 Controls. 23
8.2.4 Support. 23
8.2.5 Outputs. 24
8.3 Modification implementation . 24
8.3.1 Inputs. 24
8.3.2 Tasks. 25
8.3.3 Controls. 25
8.3.4 Support. 25
8.3.5 Outputs. 26
8.4 Maintenance review/acceptance . 26
8.4.1 Inputs. 26
8.4.2 Tasks. 26
8.4.3 Controls. 27
8.4.4 Support. 27
8.4.5 Outputs. 27
8.5 Migration. 28
8.5.1 Inputs. 28
8.5.2 Tasks. 28
8.5.3 Controls. 31
8.5.4 Support. 31
v
© ISO/IEC
8.5.5 Outputs.31
8.6 Software retirement.32
8.6.1 Inputs .32
8.6.2 Tasks .32
8.6.3 Controls .34
8.6.4 Support .34
8.6.5 Outputs .34
Annex A (informative) Cross-reference between ISO/IEC FDIS 14764 and ISO/IEC 12207 .36
Bibliography.38
Figures
Figure 1 Modification Request.4
Figure 2 Maintenance Process .18
vi
©
ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 14764 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information
technology, Subcommittee SC 7, Software engineering.
Annex A of this International Standard is for information only.
vii
© ISO/IEC
Introduction
This International Standard clarifies requirements for the Software Maintenance Process. Software Maintenance is a
primary process in the life cycle of a software product, as described in ISO/IEC 12207, “Information Technology -
Software - Part 1: Software life cycle processes.” The Maintenance Process contains the activities and tasks of the
maintainer. This International Standard is part of the ISO/IEC 12207 family of documents and provides guidance.
This International Standard elaborates the Maintenance Process contained in ISO/IEC 12207. The only mandatory
clauses in this International Standard come from ISO/IEC 12207. The mandatory clauses contain shalls and each
shall from ISO/IEC 12207 that is duplicated in this International Standard is boxed. The related ISO/IEC 12207 clause
number is listed after the boxed ISO/IEC 12207 shalls.
In many projects, especially those having a long life, software maintenance will almost certainly be an important
project consideration.
Due to product cost and time-frame constraints, as well as not following the best practices of ISO/IEC 12207,
software is often delivered in an imperfect state. It is then necessary to be able to correct faults that are found during
operation. It is frequently necessary to make improvements to the software to meet changed user requirements.
Software maintenance may be a significant portion of life cycle costs.
This International Standard addresses readers who are familiar with Software Maintenance. It is recommended that
readers who are unfamiliar with Software Maintenance study textbooks or obtain training before applying this
International Standard.
Software Maintenance may be performed by a combination of software tools, methods and techniques. This
International Standard does not specify how to implement or perform the activities and tasks in the Software
Maintenance Process since this is agreement and organizationally dependent. The Software Maintenance
requirements remain the same irrespective of the tools by which Software Maintenance is implemented.
Clause 1 provides the scope. Clause 2 provides conformance information. Clause 3 provides normative references.
Clause 4 provides terms and definintions. Clause 5 provides the application of this International Standard. Clause 6
provides implementation considerations for the maintenance process. Clause 7 provides the software maintenance
stragegy. Clause 8 provides the details of the maintenance process. Annex A provides a cross reference between
clauses in this International Standard and ISO/IEC 12207.
A major contributor to this International Standard was IEC/TC 56.
viii
© ISO/IEC
the modification of a software product after delivery to detect and correct latent faults in the software product before
they become effective faults
4.12
Problem Report (PR)
a term used to identify and describe problems detected in a software product
4.13
Software Engineering Environment (SEE)
the set of automated tools, firmware devices, and hardware necessary to perform the software engineering effort
NOTE The automated tools may include but are not limited to compilers, assemblers, linkers, loaders operating systems,
debuggers, simulators, emulators, test tools, documentation tools, and database management systems.
4.14
Software Test Environment (STE)
the facilities, hardware, software, firmware, procedures, and documentation needed to perform qualification, and
possibly other, testing of software
NOTE Elements may include but are not limited to simulators, code analyzers, test case generators, and path analyzers, and
may also include elements used in the software engineering environment. [MIL-HDBK-347]
4.15
software transition
a controlled and coordinated sequence of actions wherein software development passes from the organization
performing initial software development to the organization performing software maintenance.
5 Application of this International Standard
This clause presents the Maintenance Process that is required to maintain software products.
5.1 Maintenance process
Software Maintenance is one of the five primary life cycle processes that may be performed during the life cycle of
software (ISO/IEC 12207). The Acquisition and Supply primary life cycle processes of ISO/IEC 12207 may initiate the
Process Implementation activity of the Software Maintenance primary life cycle process through an agreement or
contract. The Operation primary life cycle process of ISO/IEC 12207 may initiate the Software Maintenance life cycle
process through submission of a Modification Request or Problem Report. The Software Maintenance primary life
cycle process invokes the Development primary life cycle process of ISO/IEC 12207. The supporting processes of
Documentation, Configuration Management, Quality Assurance, Verification, Validation, Joint Review, Audit, and
Problem Resolution of ISO/IEC 12207 are used by the Software Maintenance life cycle process.
The organizational life cycle processes of ISO/IEC 12207 consist of four processes. The Management,
Infrastructure, and Training organizational life cycle processes of ISO/IEC 12207 are employed by the maintainer
when initiating each maintenance project. The Improvement Process of ISO/IEC 12207 is invoked to effect software
maintenance process improvement.
Tailoring of this International Standard is addressed in ISO/IEC 12207. Tailoring is appropriate for non-routine events
such as emergency maintenance.
© ISO/IEC
5.2 Organization of this International Standard
These clauses that follow are presented in the order that Maintainers should address them.
Clause 6 provides implementation considerations, and issues to be considered when planning for maintenance.
Clause 7 then provides comprehensive planning information. Clause 8 provides the details of the Maintenance
Process including tasks and task-steps needed to implement the Maintenance Process.
6 Implementation considerations
6.1 Introduction
The software maintenance life cycle process begins with process implementation where planning for maintenance is
performed and ends with the retirement of the software product. It includes modification of code and documentation
due to a problem or need for improvement. The objective of the Maintenance Process is to modify an existing
software product while preserving its integrity. The following provides implementation considerations.
The Maintenance Process is needed because software products undergo change over the life cycle. If the software
product is developed using Computer-Aided Software Engineering (CASE) tools, maintenance is still needed. CASE
tools facilitate maintenance but do not eliminate the requirement for maintenance. If no application code is
developed, i.e., the software product consists solely of off-the-shelf products, maintenance may still be required.
Maintenance of off-the-shelf software products by the acquirer or supplier will usually involve modification of the
interfaces, both data and operational, to the product.
Consideration should be given to implicit requirements and constraints imposed on the original developer.
Circumstances may have changed and some of the original requirements may no longer be applicable.
During execution of the Development, Operations, and Maintenance processes of ISO/IEC 12207, any problems
detected are recorded and monitored by the Problem Resolution process of ISO/IEC 12207. Modification Requests
(MRs) or Problem Reports (PRs) are submitted. Often, these are referred to as change requests. The Problem
Resolution process of ISO/IEC 12207 analyzes and resolves problems. It also determines if an MR/PR is a problem
or an enhancement. The Configuration Management (CM) process of ISO/IEC 12207 records and reports the status
of Modification Requests (MRs)/Problem Reports (PRs). The Configuration Control activity of the CM process then
decides whether to approve the request. Approved MRs/PRs are then implemented by calling the Maintenance
Process.
Maintenance may also be required regardless of the development life cycle model (e.g., incremental, waterfall,
evolutionary) or the approach used in development (e.g., Rapid Application, prototype, mock-up). For example, upon
release of a new build increment, development continues but maintenance may be required for the installed
increment.
The Maintenance Process may consume a significant portion of life cycle costs. Analysis of the types of maintenance
performed helps to provide an understanding of the costs.
6.2 Types of maintenance
Corrective maintenance refers to changes necessitated by actual errors in a software product. If the software product
does not meet its requirements, corrective maintenance is performed
Preventive Maintenance refers to the changes necessitated by detecting potential errors in a software product.
Preventive Maintenance is commonly performed on software products which have safety or prevention of loss of life
as a concern.
Adaptive and Perfective changes are enhancements to a software product. These changes are those that were not in
the design specifications or the released software. Adaptive changes are those changes necessary to accommodate
a changing environment. Adaptive changes include changes to implement new system interface requirements, new
system requirements, or new hardware requirements. Perfective changes improve the software product's
© ISO/IEC
performance or maintainability. A perfective change might entail providing new functionality improvements for users
or reverse engineering to create maintenance documentation that did not exist previously or to change existing
documentation.
Software maintenance requires change to an existing structure or system, i.e., software modifications are introduced
into an existing architecture and must allow for constraints imposed by the design structure. Thus, enhancements in
the form of adaptive and perfective maintenance, are often very costly and time consuming. Enhancements may
consume a significant portion of maintenance costs.
6.3 Arrangements for maintenance
The acquirer may enter an agreement with the original developer to perform maintenance or a separate third party
may be the maintainer. Maintenance can also be provided by internal two party agreements.
ISO/IEC 12207 provides detailed tasks for the derivation of an agreement between the acquirer and supplier. This
should be used to aid the derivation of a maintenance agreement whether acquirer or supplier are from the same or
different organizations. Specific maintenance issues are discussed later.
If the acquirer requires software maintenance from the developer after delivery, or at the end of a warranty period, this
should be stipulated in the agreement. Updated documentation should be stipulated in the agreement as a
deliverable. Training should also be stipulated. The supplier should then prepare procedures for the maintenance
task, keep these procedures up to date and check that the activities comply with the agreement requirements and
prepared procedures. Empirical data suggests that use of procedures is cost effective. The items to be maintained,
the maintenance procedures, and the time for which they are to be maintained, should be specified in the
maintenance plan.
The supplier (the maintainer) and the acquirer should first agree on a maintenance agreement and stipulate
procedures to incorporate modifications into the maintained software products. Similar procedures should be used by
the original developer and third party maintainers.
These procedures should include:
basic rules used to determine when the software can be locally corrected or when a new baseline, using the
Development Process of ISO/IEC 12207 for installation and release, is required;
descriptions of types of releases depending on their frequency or their effects on software operation (e.g.,
emergency releases, periodic releases);
ways in which the acquirer will be informed on the status of current or future changes;
methods to confirm that the changes will not introduce other problems into the software;
classification of type of change, urgency, and relationship with other pending proposed changes.
6.4 Tools for maintenance
A potential means of containing software maintenance costs is to use CASE tools. These tools aid software
maintenance activities. The vision for CASE is an interrelated set of tools supporting all aspects of software
development and maintenance [ISO/IEC DTR 14471]. This interrelated collection of CASE tools should be brought
together in the form of a Software Engineering Environment (SEE) to support the methods, policies, guidelines, and
standards that support software maintenance activities. A Software Test Environment (STE) should also be provided
for the maintainer so that the modified software product can be tested in a non-operational environment. The SEE
provides the tools to initially develop and modify the software products. The STE provides the test environment. The
STE should be used to test the modified software products in a non-operational environment.
To date the adoption of CASE tools has met with limited success. Maintainers should plan these efforts carefully
[ISO/IEC DTR 14471].
© ISO/IEC
6.5 Software measurement
Software quality is an important consideration in the maintenance of a software product. Maintainers should have a
software quality program that includes the six characteristics of software quality described in ISO/IEC 9126. A
process should be implemented to identify, define, select, apply, validate, and improve software measurement for
software maintenance.
As part of software measurement, the maintainer should determine the effort (in terms of resources expended) for
corrective, preventive, adaptive, and perfective maintenance. Data should be collected, analyzed, and interpreted in
order to facilitate Maintenance Process improvement and to obtain a better understanding of where maintenance
costs are being expended. Empirical metric data should be collected in order to assist life cycle cost estimating.
6.6 Documentation of process
The detailed software Maintenance Process (clause 8 of this International Standard) should be documented so that
all maintenance personnel follow the same process. The metrics should support the process and related software
process improvement efforts.
6.7 Early involvement in development
Data suggests that the cost of software maintenance and the maintainer's ability to conduct software maintenance is
greatly influenced by what occurs or does not occur during the software development process. In many cases, the
maintainer can not be involved due to contractual or other reasons. Specifically, when maintenance is outsourced to
a third party, there is often no opportunity for involvement. When the maintainer can be involved during development,
the maintainer should be involved.
Functions performed by the maintainer should include:
plan for the logistics of supporting the software product;
ensure the supportability of the software product;
support the planning for the transition of software products from development to maintenance.
Planning is discussed in detail in clause 7 of this International Standard. Supportability of the software product
includes tasks such as testing, and ensuring maintainability. ISO/IEC 9126 addresses maintainability and other
characteristics that are important considerations during developments. Supportability can be improved by maintainer
participation in the quality assurance, verification, and validation supporting life cycle processes of ISO/IEC 12207.
The maintainer should:
participate in reviews;
perform code analysis;
trace requirements;
perform Verification and Validation.
6.8 Maintainability
Software maintainability and maintenance are important aspects of dependability. Maintainability is an important
feature of software for the acquirer, supplier, and user. Maintainability requirements should be included in the
Initiation Activity of the Acquisition Process of ISO/IEC 12207 and should be evaluated throughout the Development
Process of ISO/IEC 12207. Variations in design should be monitored throughout development for impact to
maintainability. Various measures should be used to define and assess the quality of software. Both qualitative and
quantitative evaluation is important. Maintainability is a software quality characteristic that affects the speed and
ease of changing software after it is released for use (ISO/IEC 9126).
© ISO/IEC
6.8.1 Maintainability and the development process
Maintainability should be addressed prior to software development. Agreements should be developed between the
acquirer and supplier as part of the Initiation Activity of ISO/IEC 12207. The developer should prepare a
Maintainability Plan which provides specific maintainability practices, resources and sequence of activity relevant to
software. An effort to support the monitoring and evaluation of the maintainability aspects of the Development
Process of ISO/IEC 12207 should be established.
The capability to monitor and evaluate maintainability aspects should be developed during software development.
The capability describes qualitative and quantitative software maintainability requirements specified by the customer.
It defines the criteria and the ways of checking them. Qualitative requirements are used to define the techniques
employed to facilitate maintenance costing and resources. Quantitative requirements are used to define
maintainability magnitudes or quality criteria and the metrics used to determine values or indicators throughout the
various software life cycle phases.
The effectiveness of such an effort during development becomes evident once maintenance activities begin.
Developers should implement requirements for maintainability and maintainers should monitor implementation. The
effort should be part of the software maintenance strategy.
One of the key factors in applying ISO/IEC 12207 is the development of a software maintenance strategy (Guide for
ISO/IEC TR 15271). Accordingly, a maintenance strategy should be developed and maintenance should be planned
(clause 7 of this International Standard).
A software maintenance strategy should also be established prior to design. This early maintainer involvement in the
development has the potential to save money. There are many actions, including software maintenance planning, to
be performed during the development process. These actions should be documented in the software maintenance
plan (sub-clause 7.3.2 of this International Standard).
The following aspects, all of which affect maintainability, should be taken into account in choosing the programming
language:
language portability;
language legibility;
language stability;
self-documentation;
tolerance of programming "tricks" which reduce program clarity;
program structuring possibilities;
the ease with which new releases can be produced;
data structuring possibilities;
availability of a compiler and other such tools;
stability of a compiler and other such tools;
test possibilities during compiling and runs;
the availability of software engineering and software test environments to assist in production, debugging,
configuration management and the satisfaction of reliability and quality requirements;
the life of the various development tools.
© ISO/IEC
6.8.2 Maintainability and specific activities in the development process
6.8.2.1 Software requirements analysis
The software specifications should exhaustively and unambiguously describe the maintainability requirements of the
software. These should be included in the quality characteristics specifications required by ISO/IEC 12207. The
following aspects affect maintainability and should be considered :
the identification and definition of functions, particularly optional functions;
the accuracy and logical organization of data;
interfaces (machine and users), particularly future interfaces;
the performance requirements, including the effects of any corrections and additions;
requirements imposed by the planned environment;
the granularity of requirements as it impacts the ease or difficulty of traceability,
the Software Quality Assurance Plan which should emphasize documentation and its compliance.
6.8.2.2 Software architectural design
This activity transforms the requirements for the software item into an architecture that describes its top-level
structure and identifies its software components (ISO/IEC 12207). The main features of this Development Process
Activity of ISO/IEC 12207 which effect maintainability are the choice of the program structure, the breakdown into
entities and the flow of data through them. As in other activities, it is important to use the data processing knowledge
of the programming teams since this can, in particular, reveal possibilities of using parts of existing programs or
libraries which have already proved their dependability.
Modular design, combined with top-down analysis, and adequate documentation, which allow for easy additions
when necessary, are the two main features which will continue to achieving maintainability requirements.
6.8.2.3 Software detailed design
This Development Process Activity of ISO/IEC 12207 provides a detailed design for each software component, for
interfaces, and databases. The activity produces accurate, detailed description of each function to complete the
proposed programming solution. Software maintainability will be improved by inclusion of quality characteristics
found in ISO/IEC 9126.
6.8.2.4 Software coding and testing
This Development Process Activity of ISO/IEC 12207 develops, documents, and tests software units, and databases.
Software maintainability will be improved by upgrading the quality of documentation. Quality documentation should
provide information which can help in performing the Maintenance Process. Suggestions for improving
maintainability with quality documentation include:
ensuring legibility;
avoiding non-structured code;
eliminating classic traps by considering the language weaknesses;
detecting errors in the detailed design;
using techniques to facilitate error-tracing.
© ISO/IEC
6.8.2.5 Software qualification testing
This activity ensures that the implementation of each software requirement is tested for compliance (ISO/IEC 12207).
The software requirements which relate to quality are tested during this activity. The test cases used during software
development should be kept for regression testing after modification. In addition, the development history of a
program should be available for maintenance in order to avoid repeating the same errors during development.
6.9 Software transition
Software transition is a controlled and coordinated sequence of actions wherein software development passes from
the organization performing initial software development to the organization performing software maintenance. If
maintenance responsibility will transfer from one organization to another, a Transition Plan should be developed. The
plan should address:
the transfer of hardware, software, data, and experience from the developer to the maintainer;
the tasks needed for the maintainer to implement the software maintenance strategy (e.g., staffing, training,
installation, replicating maintenance problems).
6.10 Documentation
Maintainers are often faced with providing maintenance for a software product for which little or no documentation
exists. If no documentation exists, the maintainer should create the needed documentation. Documentation creation
is a part of perfective maintenance. This presents difficulty in performing the maintenance function. When faced with
this situation, maintainers should perform the following in order to prepare for maintenance.
a) Understand the problem domain (the type of application). Read any documentation (if available), discuss the
software product with developers (if available), and operate the software product.
b) Learn the structure and organization of the software product. Inventory the software product, place the software
product under CM, rebuild the software product from the CM libraries, produce call trees, and analyze the
structure of the software product.
c) Determine what the software product is doing. Review specifications (if available), review overall structure,
analyze call trees, read the code, provide oral presentations to other maintainers, and add comments to code.
d) Fix low priority MRs or PRs.
Maintainers should document the software product as the guidance listed above is executed. Documents such as
specifications, programmers’ maintenance manua
...