ISO/IEC/IEEE 14764:2022 ソフトウェアエンジニアリング—ソフトウェアライフサイクルプロセス—メンテナンス | ページ 6

3.1.1

adaptive maintenance

modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment

Note 1 to entry: Adaptive maintenance provides enhancements (3.1.7) necessary to accommodate changes in the environment in which a software product operates. These changes help keep pace with the changing environment, e.g. an upgrade to the operating system results in changes in the applications.

3.1.2

additive maintenance

modification of a software product performed after delivery to add functionality or features to enhance the usage of the product

Note 1 to entry: Additive maintenance may be excluded from the definition of maintenance in the context of dependability that addresses recovery of a system to previous operational, functional and performance level, e.g. definition, monitor or measurement of availability, recoverability, or MTBF (mean time between failure).

Note 3 to entry: Additions or enhancements (3.1.7) can be handled through the maintenance process, while larger changes can involve a new development effort.

3.1.3

correction

<software> change that addresses and implements problem resolutions to recover gaps and to make software operational enough to meet defined operational requirements

Note 1 to entry: In this document, the term “correction” is mainly used as a maintenance type and to classify modification requests (MR) (3.1.8) .

3.1.4

corrective maintenance

modification of a software product performed after delivery to correct discovered problems

Note 1 to entry: The modification repairs the software product to satisfy defined system requirements.

3.1.5

emergency maintenance

unscheduled modification performed to temporarily keep a system operational, pending corrective maintenance (3.1.4)

Note 1 to entry: Emergency maintenance may be performed to make a software system partially operational. It may include various modifications to the software or its parameters in order to limit operations, functionalities, inputs, outputs, interfaces, usability, etc.

Note 2 to entry: Emergency maintenance can be regarded as a corrective maintenance type.

3.1.6

maintainability

degree of effectiveness and efficiency with which a product or system can be modified

Note 1 to entry: Modifications can include corrections (3.1.3) , improvements or adaptation of the software to changes in environment, and in requirements and functional specifications. Modifications include those carried out by specialized support staff, and those carried out by business or operational staff, or end users.

Note 2 to entry: Maintainability includes installation of updates and upgrades.

Note 3 to entry: Maintainability can be interpreted as either an inherent capability of the product or system to facilitate maintenance activities, or the quality in use experienced by the maintainers for the goal of maintaining the product or system.

[SOURCE:ISO/IEC 25010:2011, 4.2.7, modified —"by the intended maintainers" at the end of the definition has been removed.]

3.1.7

enhancement

software change that addresses and implements a new requirement

Note 1 to entry: There are three types of software enhancements: adaptive, perfective and additive. An enhancement is not a software correction (3.1.3) .

Note 2 to entry: In this document, the term “enhancements” is mainly used as a maintenance type and to classify modification requests (MR) (3.1.8) .

3.1.8

modification request

mr

information item that identifies and describes proposed changes(s) to a product or service

Note 1 to entry: The MR may later be classified as a correction (3.1.3) or enhancement (3.1.7) and identified as corrective maintenance (3.1.4) , preventive maintenance (3.1.10) , adaptive maintenance (3.1.1) , additive maintenance (3.1.2) or perfective maintenance (3.1.9) . MRs are also referred to as change requests. See Figure 1.

Note 2 to entry: When formulating an MR, incidents, events and complaints should be reviewed as well as failure occurrence problem reports (3.1.11) and stakeholder’s maintenance requests.

Note 4 to entry: In some organizations, adaptive maintenance is not considered to be an enhancement.

Note 5 to entry: Adaptive maintenance can be requested from MRs classified as enhancement, when the software is to be adapted to its evolving and changing environment or different environments on which the software is not initially intended to operate. Additionally, adaptive maintenance can be requested from MRs classified as correction, when the software is to be adapted to its environment that has already changed.

Note 6 to entry: Additive is an enhancement type that some organizations use and different from perfective in that some changes to existing software or systems is made.

Note 7 to entry: Some organizations sub-divide each type into “scheduled”, “unscheduled” and “emergency” types.

Note 8 to entry: Another way to classify MR’s is by “reactive” or “proactive” maintenance as used in SWEBOK. Reactive includes corrective and adaptive types; and proactive includes preventive, perfective and additive types.

3.1.9

perfective maintenance

modification of a software product to provide enhancements (3.1.7) for users, improvements of information for users, and recording to improve software performance, maintainability (3.1.6) or other software attributes

3.1.10

preventive maintenance

modification of a software product after delivery to correct latent faults in the software product before they occur in the live system

3.1.11

problem report

PR

document used to identify and describe problems detected in a software product

Note 1 to entry: PRs are either submitted directly to denote faults or established after impact analysis is performed on modification requests (3.1.8) and faults are found.

3.1.12

software maintenance

totality of activities required to provide support to a software system

Note 1 to entry: Activities are performed during the pre-delivery stage as well as the post-delivery stage.

Note 2 to entry: Pre-delivery activities include, for example, planning for post-delivery operations, supportability, and logistics determination. Post-delivery activities include, for example, software modification, training, and operating a help desk.

Note 3 to entry: In the context of dependability, maintenance is a combination of all technical and management actions intended to retain an item in, or restore it to, a state in which it can perform as required.

3.1.13

software sustainment

activities to support, maintain and operate a software system to ensure that the software system or service remains operational

Note 1 to entry: Software sustainment includes processes, procedures, people, material and information required to support, maintain and operate the software aspects of a system.

Note 2 to entry: Sustainment is defined in ISO/IEC/IEEE 24765 as activities performed to ensure that a product or service remains operational. In this document, software sustainment is defined to emphasize that activities for supporting, maintaining and operating are performed more concurrently and iteratively to sustain operational software systems.

3.1.14

transition

activities involved in moving a new or changed service, system, or component to or from an environment