CHAPTER 6

SOFTWARE MAINTENANCE
Acronyms Software maintenance is an integral part of a
CASE Computer -Aided Software software life cycle. However, it has not,
Engineering historically, received the same degree of
CM Configuration Management attention that the other phases have. Historically,
CMMi Capability Maturity Model development has had a much higher profile than
Integration maintenance in most organizations. This is now
CR Correction Request changing, as organizations strive to squeeze the
ICSM International Conference on most out of their development investment by
Software Maintenance keeping software operating as long as possible.
ISO International Organization for Concerns about the Year 2000 (Y2K) rollover
Standardization focused significant attention on the software
MR Modification Request maintenance phase, and the Open Source
PSM Practical Software and Systems paradigm has brought further attention to the
Measurement issue of maintaining code developed by others.
SCM Software Configuration Management In the Guide, software maintenance is defined as
SW-CMMi Capability Maturity Model the totality of activities required to provide cost-
Integration for Software effective support to a software system. Activities
SQA Software Quality Assurance are performed during the pre-delivery stage, as
V&V Verification and Validation well as during the post-delivery stage. Pre-
Y2K Year 2000 delivery activities include planning for post-
WCRE Working Conference on Reverse delivery operations, for maintainability, and for
Engineering logistics determination for transition activities.
Post-delivery activities include software
INTRODUCTION modification, training, and operating or
interfacing to a help desk.
Software development efforts result in the
The Software Maintenance Knowledge Area
delivery of a software product which satisfies
(KA) is related to all other aspects of software
user requirements. Accordingly, the software
engineering. Therefore, this KA description
product must change or evolve. Once in
refers specifically to all other chapters of the
operation, defects are uncovered, operating
Guide.
environments change, and new user requirements
The breakdown covers the areas typically
surface. The maintenance phase of the life cycle
discussed in texts and standards, although there
begins after a warranty period or post-
is less discussion on the pre-maintenance
implementation support delivery, but
activities, planning for example. Other topics,
maintenance activities occur much earlier.
such as measures, are often not addressed,
Software maintenance sustains the software
although they are receiving more attention now.
product throughout its operational life cycle.
The extent to which industry implements the
Modification requests are logged and tracked,
software maintenance concepts in the literature
the impact of proposed changes is determined,
and in standards varies by company and project.
code is modified, testing is conducted, and a new
version of the software product is released. Also,
training and daily support are provided to users.

© IEEE – Trial Version 1.00 – Décembre 2003 6-1

BREAKDOWN OF TOPICS FOR A maintainer is defined by ISO/IEC 12207 as an
SOFTWARE MAINTENANCE organization which performs maintenance
activities [ISO12207-95].
1. Fundamentals ISO/IEC 12207 identifies the primary activities
This first section introduces the concepts and of software maintenance as: process
terminology that form an underlying basis to implementation; problem and modification
understanding the role and scope of Software analysis; modification implementation;
Maintenance. The topics provide definitions and maintenance review/acceptance; migration; and
to emphasize why there is a need for retirement. These activities are discussed in a
maintenance. Categories are critical to later section. They are further defined in
understanding the underlying meaning of ISO/IEC 12207.
software maintenance. 1.2. The Nature of Maintenance
1.1. Definitions and Terminology [IEEE1219- [Pfl01:c11s11.2]
98:s3.1.12; ISO12207-95:s3.1,s5.5; Pfleeger [Pfl01] states that ‘maintenance has a
ISO14764-00:s6.1] broader scope, with more to track and control’,
Software maintenance is defined in the IEEE than development.
Standard for Software Maintenance, IEEE 1219 Maintainers, however, can learn from the
[IEEE 1219], as the modification of a software software engineer’s knowledge of the system.
product after delivery to correct faults, to Contact with the software engineers and early
improve performance or other attributes, or to involvement by the maintainer helps reduce the
adapt the product to a modified environment. maintenance effort. In some instances, the
The standard also addresses maintenance software engineer cannot be reached or has
activities prior to delivery of the software moved on to other tasks, which creates an
product, but only in an information appendix of additional challenge for the maintainers.
the standard. Maintenance must take the products of the
The ISO/IEC 12207 standard for life cycle development, for example, code or
processes essentially depicts maintenance as one documentation for example, and support them
of the primary life cycle processes, and describes immediately and evolve/maintain them
maintenance as the process of a software progressively over the life cycle.
product undergoing “modification to code and 1.3. Need for Maintenance [Pfl01:c11.s11.2;
associated documentation due to a problem or Pig97: c2s2.3; Tak97:c1]
the need for improvement. The objective is to Maintenance is needed to ensure that the system
modify the existing software product while continues to satisfy user requirements.
preserving its integrity.” [ISO/IEC 12207] Maintenance is applicable to software developed
ISO/IEC 12207 also describes “Process using any software life-cycle model (for example,
Implementation.” That activity establishes the spiral). The system changes due to corrective
maintenance plan and procedures that are used and non-corrective software actions.
later, during the maintenance process. Maintenance must be performed in order to:
ISO/IEC 14764 [ISO14764-00], the - Correct faults;
international standard for software maintenance, - Correct requirements and design flaws;
defines software maintenance in the same terms - Improve the design;
as ISO/IEC 12207 and emphasizes the pre- - Implement enhancements;
delivery aspects of maintenance, for example - Interface with other systems;
planning for example. - Adapt programs so that different
hardware, software, system features, and
telecommunications facilities can be used;
- Migrate legacy systems;
 - Retire systems. - Application type;
There are four key characteristics of the - System Novelty;
maintainer’s activities, according to Pfleeger - Maintenance staff availability;
[Pfl01]: - System life span;
1.- Maintaining control over the system’s - Hardware characteristics;
- Quality of design, construction,
day-to-day functions;
documentation and testing.
1.- Maintaining control over system
modification. 1.5. Evolution of Software
1.- Perfecting existing functions; [Art88:c1s1.0,s1.1,s1.2,c11,s1.1,s1.2;
1.- Preventing system performance from Leh97:108-124], (Bel72)
degrading to unacceptable levels. Lehman first addressed software maintenance
and evolution of systems in 1969. Over a period
1.4. Majority of Maintenance Costs
of twenty years, his research led to the
[Abr93:63-90; Pfl01:c11s11.3; Pig97:c3;
formulation of eight Laws of Evolution [Leh97].
Pre01:c30s2.1,c30s2.2]
Key findings include the fact that maintenance is
Maintenance consumes a major share of life
really evolutionary developments and that
cycle financial resources. A common perception
maintenance decisions are aided by
of maintenance is that it merely fixes faults.
understanding what happens to systems (and
However, studies and surveys over the years
software) over time. Others state that
have indicated that the majority, over 80%, of
maintenance is really continued development,
the maintenance effort is used for non-corrective
except that there is an extra input (or constraint)
actions [Abr93, Pig97, Pre01]. Jones (Jon91)
– the existing software system, and those large
describes the way in which maintenance
systems are never complete and continue to
managers often group enhancements and
evolve. As they evolve, they grow more complex
corrections together in their management
unless some action is taken to reduce this
reports. This inclusion of enhancement requests
complexity.
with problem reports contributes to some of the
Since systems demonstrate regular behavior and
misconceptions regarding the high cost of
trends, they can be measured. The first attempt
corrections. Understanding the categories of
to develop predictive models to estimate
maintenance helps us to understand why
maintenance effort has been made, and, as a
maintenance is so costly. Also, understanding the
result, useful management tools have been
factors that influence the maintainability of a
developed [Art88], (Bel72).
system can help to contain costs. Pfleeger
[Pfl01] presents some of the technical and non-
technical factors affecting maintenance costs, as
follows:

© IEEE – Trial Version 1.00 – Décembre 2003 6-3

 Software Maintenance

Key Issues in
Maintenance Techniques for
Fundamentals Software
Process Maintenance
Maintenance

Definitions and Maintenance Process

Technical Program Comprehension
Terminology Models

Nature of
Management Maintenance Activities Re-engineering
Maintenance

Maintenance Cost and

Need for Maintenance Maintenance Cost Reverse Engineering
Estimation

Majority of Software Maintenance Impact Analysis

Maintenance Costs Measurement

Evolution of Soffware

Categories of
Maintenance

Figure 1 Breakdown of topics for the Software Maintenance KA.

1.6. Categories of Maintenance [Art88:c1s1.2; - Adaptive maintenance: Modification of a

Lie78; Dor02:v1c9s1.5; IEEE1219- software product performed after delivery to
98:s3.1.1,s3.1.2,s3.1.7,A.1.7; ISO14764- keep a software product usable in a changed
00:s4.1,s4.3,s4.10, s4.11,s6.2; or changing environment.
Pig97:c2s2.3] - Perfective maintenance: Modification of a
Lientz & Swanson initially identified three software product after delivery to improve
categories of maintenance: corrective, adaptive, performance or maintainability.
and perfective. [Lie78]. These have been updated, - Preventive maintenance: Modification of a
and the International Organization for software product after delivery to detect and
Standardization (ISO) has defined a new category correct latent faults in the software product
in the Standard for Software Engineering- before they become effective faults.
Software Maintenance, ISO/IEC 14764 ISO 14764 classifies Adaptive and Perfective
[ISO14764-00][IEEE 1219-98]. The categories maintenance as enhancements. It also groups
of maintenance defined by ISO/IEC are as together the corrective and preventive
follows: maintenance categories into a Correction
- Corrective maintenance: Reactive category, as shown in Figure 2. Preventive
modification of a software product performed maintenance, the newest category, is most often
after delivery to correct discovered problems. performed on software products where safety is
critical.
 and when the developers are not available to
Correction Enhancement explain the source code, which is often the case.
Preventive Perfective Thus, maintainers may initially have a limited
Corrective Adaptive understanding of the software, and much has to be
done to increase their own understanding of the
Figure 2: ISO14764-00 software maintenance software.
categories
2.1.2. Testing [Art88:c9; Pfl01:c11s11.3]
2. Key Issues in Software Maintenance The cost of repeating full testing on a major piece
A number of key issues must be dealt with to of software can be significant in terms of time and
ensure the effective maintenance of software money. Regression testing, the selective retesting
systems. It is important to understand that of a system or component to verify that the
software maintenance provides unique technical modifications have not caused unintended effects,
and management challenges for software is important to maintenance. Finding time to test
engineers. Trying to find a fault in a system is often difficult. There is also the challenge of
containing 500K lines of code that the maintainer coordinating tests when different members of the
did not develop is a good example. Similarly, maintenance team are working on different
competing with software developers for resources problems at the same time [Plf01]. When a system
is a constant battle. Planning for a future release, performs critical functions, it may be impossible
while coding the next release and sending out to bring it offline to test. The Software Testing
emergency patches for the current release, also KA provides details of testing.
creates a challenge. The following section 2.1.3. Impact analysis [Art88:c3;
presents some of the technical and management Dor02:v1c9s1.10; Pfl01: c11s11.5]
issues related to software maintenance. They
have been grouped according to the following Impact analysis describes how to conduct, cost
topics: effectively, a complete analysis of the impact of a
- Technical issues change in existing software. Maintainers must
- Management issues possess an intimate knowledge of the software’s
- Cost estimation and structure and content [Pfl01]. They use that
- Measures. knowledge to perform impact analysis, which
identifies all systems and system products affected
2.1. Technical Issues by a software change request and develops an
2.1.1. Limited understanding estimate of the resources needed to accomplish
[Dor02:v1c9s1.11.4; Pfl01:c11s11.3; the change [Art88]. Additionally, the risk of
Tak97:c3] making the change is determined. The change
“Limited understanding” refers to how quickly request, sometimes called a modification request
one can understand where to make a change or a (MR) and often called a problem report (PR),
correction in software that this individual did not must first be analyzed and translated into software
develop. Research indicates that some 40% to terms [Dor02]. It is performed after a change
60% of the maintenance effort is devoted to request enters the configuration management
understanding the software to be modified. Thus, process. Arthur [Art88] states that the objectives
the topic of software comprehension is one of of impact analysis are:
interest to maintainers. Comprehension is more - Determination of the scope of a change in
difficult for text-oriented representation, for order to plan and implement work;
example, source code. It is often difficult to trace - Development of accurate estimates of
the evolution of software through its resources needed to perform the work;
releases/versions if changes are not documented,

© IEEE – Trial Version 1.00 – Décembre 2003 6-5

 - Analysis of the cost/benefits of the 2.2. Management Issues
requested change; 2.2.1. Alignment with organizational
- Communication to others of the complexity objectives [Ben00:c6sa; Dor02:v1c9s1.6]
of a given change.
The severity of a problem is often used to decide Organizational objectives describe how to
demonstrate the return on investment of
how and when a problem will be fixed. The
maintenance activities. Bennett [Ben00] states
maintainer then identifies the affected
components. Several potential solutions are that “initial software development is usually proj-
provided and then a recommendation is made as ect-based, with a defined time scale and budget.
The main emphasis is to deliver on time and
to the best course of action.
Software designed with maintainability in mind within budget to meet user needs. In contrast,
greatly facilitates the impact of the analysis software maintenance often has the objective of
extending the life of a software system for as long
process.
as possible. In addition, it may be driven by the
2.1.4. Maintainability [ISO14764- need to meet user demand for software updates
00:s6.8s6.8.1; Pfl01: c9s9.4; Pig97:c16] and enhancements. In both cases, return on
How does one promote and follow up on investment is much less clear, so that the view at
maintainability issues during development? The senior management level is often of a major
IEEE (IEEE610.12-90) defines maintainability as activity consuming large resources with no clear
the ease with which software can be maintained, quantifiable benefit for the organization.”
enhanced, adapted, or corrected to satisfy 2.2.2. Staffing [Dek92:10-17;
specified requirements. ISO/IEC defines Dor02:v1c9s1.6; Par86: c4s8-c4s11]
maintainability as one of the quality characteristics (Lie81);
(ISO9126-01).
Staffing refers to how to attract and keep
Maintainability sub-characteristics must be
specified, reviewed, and controlled during the maintenance staff. Maintenance is often not
software development activities in order to reduce viewed as glamorous work. Deklava provides a
list of staffing-related problems based on survey
maintenance costs. If this is done successfully, the
data [Dek92]. Maintenance personnel are often
maintainability of the software will improve. This
viewed as second-class citizens (Lie81) and
is difficult to attain because the maintainability
morale therefore suffers [Dor02].
sub-characteristics are not an important focus
during the software development process. The 2.2.3. Process [Ben00:c6sb;
developers are preoccupied with many other Dor02:v1c9s1.3]
things and often disregard the maintainer’s Process refers to how to highlight and
requirements. This in turn can, and often does, communicate the uniqueness of some maintenance
result in a lack of system documentation, which is processes and/or activities. At the process level,
a leading cause of difficulties in program there are many activities in common with software
comprehension and impact analysis. To attain a development (for example, software configuration
maintainable system, the maintainer must management is a crucial activity in both) [Ben00].
constantly strive to educate software engineers on Maintenance also requires several activities which
the importance of quality requirements, design, are not found in software development (see
and construction. It has also been observed that section 3.2 on unique activities for details). These
the presence of standard and mature processes, activities present challenges to management
techniques, and tools helps to enhance the [Dor02].
maintainability of a system.
 2.2.4. Organizational Aspects of Another challenge identified is the transition of
Maintenance [Pfl01:c12s12.1-c12s12.3; the software to the outsourced company [Pig97].
Par86:c4s7; Pig97:c2s2.5; Tak97:c8] 2.3. Cost Estimation
Organizational aspects describe how to identify Software engineers must understand the different
which organization and/or function will be categories of maintenance, discussed above, in
responsible for the maintenance of software. The order to address the question of estimating the
team that develops the software is not always cost of maintenance. For planning purposes,
assigned to maintain the system once it is estimating costs is an important aspect of
operational. A maintainer must be selected, and software maintenance.
there are two main options for doing this, as 2.3.1. Cost estimation [Art88:c3; Boe81:c30;
presented below. Jon98:c27; Pfl01:c11s11.3; Pig97:c8]
In deciding where the maintenance function will Earlier, we asserted that impact analysis identifies
be located, software engineering organizations all systems and system products affected by a
may, for example, stay with the original developer software change request and develops an estimate
or go to a separate team (or maintainer). Often, of the resources needed to accomplish that change
the maintainer option is chosen to ensure that the [Art88]. It is performed after a change request
system runs properly and evolves to satisfy enters the software configuration management
changing user needs. Since there are many pros process, and it is used in concert with cost
and cons to each of these options [Par86, Pig97], estimation techniques discussed below.
the decision should be made on a case-by-case Maintenance cost estimates are affected by many
basis. What is important is the delegation or technical and non-technical factors.
assignment of maintenance responsibility to a ISO/IEC14764 states that “the two most popular
group or person[Pig97], regardless of the approaches to estimating resources for software
organization’s structure. maintenance are the use of parametric models and
2.2.5. Outsourcing [Dor02:v1c9s1.7; the use of experience” [ISO14764-00:s7.4.1].
Pig97:c9s9.1,s9.2], (Car94; McC02) Most often, a combination of these is used.
Outsourcing of maintenance is becoming a major 2.3.2. Parametric models [Ben00:s7; Boe81:c30;
industry. Large corporations are outsourcing Jon98:c27; Pfl01:c11s11.3]
entire portfolios of software systems, including Some work has been undertaken in applying
software maintenance. More often, the parametric cost modeling to software maintenance
outsourcing option is selected for less mission- [Boe81, Ben00]. Of significance is that data from
critical software, as companies are unwilling to past projects are needed in order to use the
lose control of the software used in their core models. Jones [Jon98] discusses all aspects of
business. Carey (Car94) reports that some will estimating costs, including function points
outsource only if they can find ways of (IEEE14143.1), and provides a detailed chapter
maintaining strategic control. However, control on maintenance estimation.
measures are hard to find. One of the major
2.3.3. Experience [ISO14764-
challenges for the outsourcers is to determine the
00:s7,s7.2,s7.2.1,s7.2.4; Pig97:c8; Sta94]
scope of the maintenance services required and
the contractual details.. McCracken (McC02) Experience, in the form of expert judgment (using
states that 50% of outsourcers provide services the Delphi technique for example), analogies, and
without any clear service-level agreement. a work breakdown structure, are several
Outsourcing companies typically spend a number approaches which should be used to augment data
of months assessing the software before they will from parametric models. Clearly the best
enter into a contractual relationship [Dor02]. approach to maintenance estimation is to combine
empirical data and experience. These data should

© IEEE – Trial Version 1.00 – Décembre 2003 6-7

be provided as a result of a measurement Testability: Measures of the maintainer’s and
program. users’ effort in trying to test the modified
2.4. Measure [IEEE1061-98:A.2; software. Measurement of the maintainability of
Pig97:c14s14.6; Tak97: c6s6.1-c6s6.3] software can be performed using available
The Software Maintenance Measurement topic is commercial tools (Lag96; Apr00).
one that is not addressed very well in the
3. The Maintenance Process
literature. Most books on maintenance barely
touch on it. Measurement information is most The Maintenance Process sub-area provides
often found in generalized measurement books. current references and standards used to
This topic was chosen to highlight the need for implement the maintenance process. The
unique maintenance measures and to provide Maintenance Activities topic differentiates
specific maintenance measurement references. maintenance from development and shows its
There are software measures that are common to relationship to other software engineering
all endeavors, and the Software Engineering activities.
Institute (SEI) has identified the following: size; The need for software process is well
effort; schedule; and quality [Pig97]. These documented. CMMi models apply to
measures constitute a good starting point for the maintenance processes, which are similar to the
maintainer. Discussion of measurement is developers’ processes. Software Maintenance
presented in the Software Engineering Process Capability Maturity models which address the
KA. unique processes of the maintainers are described
2.4.1. Specific Measures [Car90:s2-s3; Gra87; in [SEI01] (Nie02, Kaj01, Apr03)
IEEE1219-98:Table3; Sta94:239-249] 3.1. Maintenance Process Models [IEEE1219-
98:s4; ISO14764-00:s8; ISO12207-95:s5.5;
Abran [Abr93] presents internal benchmarking Par86:c7s1; Pig97:c5; Tak97:c2]
techniques to compare different internal Process models provide needed activities and
maintenance organizations. The maintainer must detailed inputs/outputs to those activities.
determine which measures are appropriate for the Maintenance Process models are provided in
organization in question. [IEEE1219-98; software maintenance standards IEEE 1219
ISO9126-01; Sta94] provide suggested measures [IEEE1219-98] and ISO/IEC 14764 [ISO14764-
which are more specific to software maintenance 00].
measurement programs. That list includes a The maintenance process model described in the
number of standard measures for each of the four Standard for Software Maintenance (IEEE 1219
sub-characteristics of maintainability: [IEEE1219-98]), starts with the software
Analyzability: Measures of the maintainer’s effort maintenance effort during the post-delivery stage
or resources expended in trying to diagnose and discusses items such as planning for
deficiencies or causes of failure, or in identifying maintenance. That process model, also called
parts to be modified. Software Change Request, with the IEEE
Changeability: Measures of the maintainer’s maintenance phases, is depicted in Figure 3.
effort associated with implementing a specified
modification.
Stability: Measures of the unexpected behavior of
software, including that encountered during
testing.
 Figure 3 The IEEE1219-98 Maintenance Process Activities
Figure 4 ISO/IEC 14764-00 Software
ISO/IEC 14764 [ISO14764-00] is an elaboration Maintenance Process
of the ISO/IEC 12207 [ISO12207-95]
maintenance process. The activities of the Each of the ISO/IEC 14764 primary software
ISO/IEC maintenance process are similar to those maintenance activities is further broken down into
of the IEEE, except that they are aggregated a tasks, as follows.
little differently. The maintenance process Process Implementation tasks are intended to:
activities developed by ISO/IEC are shown in - Develop maintenance plans and
Figure 4. procedures.
- Establish procedures for Modification
Requests.
Process - Implement the software configuration
Implementation
management process.
Problem and Modification Analysis tasks are
intended to:
- Perform initial analysis.
- Verify the problem.
Problem and Maintenance - Develop options for implementing the
Modification Review/ modification.
Analysis Acceptance - Document the results.
- Obtain approval for a modification option.
Modification Implementation tasks are intended
Modification to:
Implementation - Perform detailed analysis.
- Develop, code, and test the modification.
Maintenance Review/Acceptance tasks are
intended to:
Migration - Conduct reviews.
Retirement - Obtain approval for a modification.
Migration tasks are intended to:

© IEEE – Trial Version 1.00 – Décembre 2003 6-9

- Develop a migration plan. transferred progressively from the developer
- Notify users of migration plans. to the maintainer [Dek92, Pig97];
- Conduct parallel operations. - Service Level Agreements (SLAs) and
- Notify the user that migration has started. specialized (domain-specific) maintenance
- Conduct a post-operation review. contracts (Apr01) negotiated by maintainers;
- Ensure that old data are accessible. - Modification Request and Problem Report
Software Retirement tasks are intended to: Help Desk: a problem-handling process used
- Develop a retirement plan. by maintainers to prioritize, documents and
- Notify the user of retirement plans. route the requests they receive [Ben00];
- Conduct parallel operations. - Modification Request acceptance/rejection:
- Notify the user that retirement has started. modification request work over a certain
- Ensure that old data are accessible. size/effort/complexity may be rejected by
Takang and Grubb [Tak97] provide a history of maintainers and rerouted to a developer.
maintenance process models leading up to the [Dor02], (Apr01).
development of the IEEE and ISO/IEC process 3.2.2. Supporting Activities [IEEE1219-
models. Parikh [Par86] also give a good overview 98:A.7,A.11; ISO12207-95:c6,c7; ITI01;
of a generic maintenance process. Recently, there Pig97:c10s10.2,c18] ;(Kaj01)
have been emerging agile methodologies which
Maintainers may also perform supporting
promote light processes. This requirement
emerges from the ever-increasing demand for fast activities, such as maintenance planning, software
turn-around of maintenance services. Some configuration management (SCM), verification
experiments with Xtreme maintenance are and validation, quality assurance, reviews, audits,
and user training
presented in (Poo01)
3.2. Maintenance Activities Another supporting activity, maintainer training, is
As we have said earlier, many maintenance also needed [Pig97;ISO12207-95] (Kaj01)
!" Maintenance Planning Activity [IEEE1219-
activities are similar to those of software
98:A.3; ISO14764-00:s7; ITI01;
development. Maintainers perform analysis,
Pig97:c7,c8]
design, coding, testing, and documentation.
An important activity for software maintenance is
Maintainers must track requirements in their
planning., and maintainers must address the issues
activities just as is done in development. They
associated with a number of planning
must update documentation as baselines change.
perspectives:
ISO/IEC14764 recommends that, when a
1)- Business planning (organizational level);
maintainer refers to a similar development
1)- Maintenance planning (transition level);
process, he must adapt it to meet his specific
1)- Release/version planning (software level);
needs [ISO14764-00 s8.3.2.1, 2]. However, for
and
software maintenance, some activities involve
1)- Individual CR and MR planning (request
processes unique to maintenance.
level).
3.2.1. Unique Activities [Art88:c3; At the individual request level, the planning is
Dor02:v1c9s1.9.1; IEEE1219-98:s4.1,s4.2; carried out during the impact analysis (refer to
ISO14764-00:s8.2.2.1,s8.3.2.1; section 1.3 for details). The release/version
Pfl01:c11s11.2] planning activity requires that the maintainer
There are a number of processes, activities and [ITI01]:
practices that are unique to maintainers, for - Collect the dates of availability of
example: individual requests;
- Transition: a controlled and coordinated - Agree with users on the content of next
sequence of activities during which a system is releases/versions;
- Identify potential conflicts and develop ISO12207-95:s6.2; Pfl01:c11s11.5;
alternatives; Tak97:c7]
- Assess the risk of a given release and The IEEE Standard for Software Maintenance,
develop a back-out plan in case problems IEEE 1219 [IEEE1219-98], describes software
should arise; configuration management as a critical element of
- Inform all the stakeholders. the maintenance process. Software configuration
Although a new version/release might contain management procedures should provide for the
elements other than software changes, the focus verification, validation, and audit of each step
and responsibility of the software maintainer is required to identify, authorize, implement, and
restricted to software. release the software product.
Whereas developments can typically last from It is not sufficient to simply track Modification
some months to a few of years, the maintenance Requests or Problem Reports. The software
phase usually lasts for many years. Making product and any changes made to it must be
estimates of resources is a key element of controlled. This control is established by
maintenance planning. Those resources should be implementing and enforcing an approved software
included in the developers’ project planning configuration management (SCM) process. The
budgets. Maintenance planning should begin with Software Configuration Management KA
the decision to develop a new system and should provides details of SCM and discusses the process
consider quality objectives (IEEE1061-98). A by which software change requests are submitted,
concept document should be developed, followed evaluated, and approved. SCM for maintenance is
by a maintenance plan. different from SCM for development in the
The concept document for maintenance number of small changes that must be controlled
[ISO14764-00:s7.2] should address: on an operational system. The SCM process is
- The scope of the maintenance; implemented by developing and following a
- The adaptation of the maintenance process; configuration management plan and operating
- The identification of the maintenance procedures. Maintainers participate in
organization; Configuration Control Boards to determine the
- An estimate of maintenance costs. content of the next release/version.
The next step is to develop a corresponding !" Software quality [Art98:c7s4; ISO12207-
maintenance plan. The maintenance plan should 95:s6.3; IEEE1219-98:A.7; ISO14764-
be prepared during software development, and 00:s5.5.3.2]
should specify how users will request software It is also not sufficient to simply hope that
modifications or report problems. Maintenance increased quality will result from the maintenance
planning [Pig97] is addressed in IEEE 1219 of software. It must be planned and processes
[IEEE1219-98] and ISO/IEC 14764. [ISO14764- implemented to support the maintenance process.
00] ISO/IEC14764 provides guidelines for a The activities and techniques for Software Quality
maintenance plan. Assurance (SQA), V&V, reviews and audits must
Finally, at the highest level, the maintenance be selected in concert with all the other processes
organization will have to conduct business to achieve the desired level of quality. It is also
planning activities (budgetary, financial, and recommended that the maintainer adapt the
human resources) just like all the other divisions development processes and techniques, for
of the company. For this purpose, the knowledge instance testing documentation, and test results
required can be found in the discipline of [ISO14764-00].
management. More details can be found in the Software Quality
!" Software configuration management KA.
[Art88:c2,c10; IEEE1219-98:A.11;

© IEEE – Trial Version 1.00 – Décembre 2003 6-11

4. Techniques for Maintenance improve maintainability, but to replace aging
The Techniques topic is provided to introduce legacy systems. Arnold [Arn92] provides a
some of the generally accepted techniques used in comprehensive compendium of topics, for
software maintenance. example: concepts, tools and techniques, case
Effective software maintenance is performed studies, and risks and benefits associated with
using techniques specific to maintenance. The reengineering.
following provides some of the best-practice 4.3. Reverse engineering [Arn92:c12;
techniques used by maintainers. Dor02:v1c9s1.11.3; IEEE1219-98:B.3;
4.1. Program Comprehension [Arn92:c14; Tak97:c4]
Dor02:v1c9s1.11.4; Tak97:c3] Reverse engineering is the process of analyzing a
Programmers spend considerable time in reading system to identify the system’s components and
and understanding programs in order to their inter-relationships and to create
implement changes. Code browsers are a key tool representations of the system in another form or
in program comprehension. Clear and concise at higher levels of abstraction. Reverse
documentation can aid in program engineering is passive; it does not change the
comprehension. system, or result in a new one. Reverse
4.2. Re-engineering [Arn92:c1,c3-c6; engineering efforts produce call graphs and
Dor02:v1c9s1.11.4; IEEE1219-98: B.2], control flow graphs from source code. One type
(Fow99) of reverse engineering is redocumentation.
Re-engineering is defined as the examination and Another type is design recovery [Dor02]. For its
alteration of the software to reconstitute it in a part, Data Reverse Engineering has gained in
new form, and includes the subsequent importance over the last few years. Refactoring,
implementation of the new form. Dorfman and (Fow99) a program transformation which
Thayer [Dor02] state that reengineering is the reorganizes a program without changing its
most radical (and expensive) form of alteration. behavior, is a form of reverse engineering that
Others believe that reengineering can be used for seeks to improve the structure of programs.
minor changes. It is often not undertaken to
MATRIX OF TOPICS VS. REFERENCE MATERIAL

© IEEE – Trial Version 1.00 – Décembre 2003 6-13

 98]
Topics

[Pfl01]

[Art88]
[Pig97]
[Pre01]
[Sta94]

[Par86]

[Ben00]
[Boe81]
[Car90]
[Dor97]
[Jon98]
[Leh97]

[Abr93]
[Arn92]
[Dek92]
[Tak97]

[ISO12207-95]
[ISO14764-00]

[IEEE1219-98]

[IEEE610.12-90]
[ANSI/IEEE1061-
1. Fundamentals

Definitions and Terminology s3.1.12 s3.1, s5.5 s6.1

Nature of Maintenance c11s11.2
Need for Maintenance c11s11.2 c2s2.3 c1
Majority of Maintenance Costs 63- c11s11.3 c3 c30s2.1-
90 c30s2.2
Evolution of Software c1s1.0-
c1s1.2, 108-
c11s1.1, 124
c11s1.2
Categories of Maintenance c1s1.2 v1c9s1.5 s3.1.1, s3.1.2, s4.1, s4.3s4.10, c2s2.3
s3.1.7, A.1.7 s4.11, s6.2
2. Key Issues in Software
Maintenance
Technical issues
Limited Understanding v1c9s1.11.4 c11s11.3 c3
Testing c9 c11s11.3
Impact Analysis c3 v1c9s1.10.1 c11s11.5
-
v1c9s1.10.3
Maintainability s3 s6.8, s6.8.1 c9s9.4 c16
Management issues
Alignment with c6sa v1c9s1.6
organizational issues
Staffing 10- v1c9s1.6 c4s8-
17 c4s11
Process c6sb v1c9s1.3
Organizational aspects of c4s7 c12s12.1- c2s2.5 c8
c12s12.3
Maintenance
Outsourcing v1c9s1.7 c9s9.1-
c9s9.2
Cost Estimation
Cost estimation c3 c30 c27 c11s11.3 c8
Parametric models s7 c30 c27 c11s11.3
Experience s7,s7.2, s7.2.1, c8
s7.2.4
Measures A.2 c14s14.6 c6s6.1-
c6s6.3
Specific Measures s2- Table 3 239-
s3 249

3. Maintenance Process
Maintenance Process Models s4 s5.5 s8 c7s1 c5 c2
Maintenance Activities
Unique Activities c3 v1c9s1.9.1 s4.1-s4.2 s8.2.2.1, c11s11.2
s8.3.2.1
Supporting Activities A.7,A.11 c6,c7 c10s10.2,
c18
Maintenance Planning A.3 s7 c7,c8
Activity
Configuration Management c2,c10 A.11 s6.2 c11s11.5 c7
Quality c7s4 A.7 s6.3 s5.5.3.2
4. Techniques for Maintenance
Program Comprehension c14 v1c9s1.11.4 c3
Re-engineering c1,c3- v1c9s1.11.4 B.2
c6
Reverse Engineering c12 v1c9s1.11.3 B.3 c4
 [IEEE1219-98] IEEE STD 1219: Standard for
1.RECOMMENDED REFERENCES FOR Software Maintenance, 1998.
SOFTWARE MAINTENANCE [ISO9126-01] ISO/IEC 9126:200: Information
The following set of references provides a strong Technology – Software Product Evaluation –
foundation on which to acquire knowledge on Quality characteristics and guidelines for their
specific topics identified in the breakdown. They use, 2nd ed.,, 2001.
were chosen to provide coverage of all aspects of [ISO12207-95] ISO/IEC 12207: Information
software maintenance. Priority was given to Technology-Software Life Cycle Processes, 1995.
standards and to maintenance-specific [ISO14764-00] ISO/IEC 14764: Software
publications, and then to general software Engineering-Software Maintenance, 2000.
engineering publications. [ITI01] IT Infrastructure Library, Service
[Abr93] A. Abran and H. Nguyenkim, Delivery and Service Support, Published by the
“Measurement of the Maintenance Process from Stationary Office, Office of Government of
a Demand-Based Perspective,” Journal of Commerce, UK, 2001.
Software Maintenance: Research and Practice, [Jon98] T. C. Jones. Estimating Software Costs.
Vol 5, no 2, 1993 McGraw-Hill, 1998.
[Arn92] R.S. Arnold. Software Reengineering. [Leh97] M.M. Lehman, Laws of Software
IEEE Computer Society, 1993. Evolution Revisited, EWSPT96, October 1996,
[Art88] L.J. Arthur. Software Evolution: The LNCS 1149, Springer Verlag, 1997.
Software Maintenance Challenge. John Wiley & [Lie78] B.Lientz, E.B. Swanson and G.E.
Sons, 1988. [Ben00] K.H. Bennett, Software Tompkins, Characteristics of Applications
Maintenance: A Tutorial, Software Engineering Software Maintenance Comm. ACM, Vol. 21,
edited by Dorfman and Thayer, IEEE Computer 1978.
Society Press, 2000. [Par86] G. Parikh. Handbook of Software
[Boe81] B.W. Boehm. Software Engineering Maintenance. John Wiley & Sons, 1986.
Economics. Prentice-Hall, 1981. [Pfl01] S.L. Pfleeger. Software Engineering—
[Car90] D.N. Card and R. L. Glass, Measuring Theory and Practice. Prentice Hall, 2nd ed.,
Software Design Quality, Prentice Hall, 1990. 2001.
[Dek92] S. Dekleva. Delphi Study of Software [Pig97] T.M. Pigoski. Practical Software
Maintenance Problems. Proceedings of the Maintenance: Best Practices for Managing your
International Conference on Software Software Investment. Wiley, 1997.
Maintenance, 1992. [Pre01] R.S. Pressman. Software Engineering: A
[Dor02] M. Dorfman and R. H. Thayer. Software Practitioner’s Approach. McGraw-Hill, 5th ed.,
Engineering (Vol. 1 & Vol. 2). IEEE Computer 2001.
Society Press, 2002. [SEI01] Software Engineering institute,
[Gra87] R.B. Grady and D. L. Caswell. Software Capability Maturity Model Integration, v1.1,
Metrics: Establishing a Company-wide Program. CMU/SEI-2002-TR-002, ESC-TR-2002-002,
Prentice-Hall, 1987. December 2001.
[IEEE610.12-90] IEEE STD 610.12: IEEE [Sta94] G.E. Stark, L. C. Kern, and C. V.
Standard Glossary of Software Engineering Vowell. A Software Metric Set for Program
Terminology, 1990. Maintenance Management. Journal of Systems
[IEEE1061-98] IEEE STD 1061. IEEE Standard and Software, Vol. 24, no. 3, March 1994.
for a Software Quality Metrics Methodology. [Tak97] A. Takang and P. Grubb. Software
IEEE Computer Society Press, 1998. Maintenance Concepts and Practice.
International Thomson Computer Press, 1996.

© IEEE – Trial Version 1.00 – Décembre 2003 6-15

 cover the maintenance KA: 1) Service Delivery;
APPENDIX B – LIST OF FURTHER and 2) Service Support.
READINGS The Journal of Software Maintenance and
Beside the recommended references listed in this Evolution, published by John Wiley & Sons, also
chapter, there are other resources available for is an excellent resource for maintenance.
learning more about software maintenance. The A list of additional readings is also provided to
IEEE Computer Society sponsors the annual identify additional reference material for the
International Conference on Software Software Maintenance KA. These references also
Maintenance (ICSM). This conference, started in contain generally accepted knowledge.
1983, provides a Proceedings, which incorporates References
numerous research and practical industry papers [Abr93] A.Abran, Maintenance Productivity &
concerning evolution and maintenance topics. Quality Studies: Industry Feedback on
Other venues, which address these topics, include: Benchmarking. Proceedings of the Software
a) The Workshop on Software Change and Maintenance Conference, ICSM93, Montréal
Evolution (SCE). September 27-30, 1993, pp. 370.
[HTTP://www.dur.ac.uk/~dcs0elb/ [Bas85] V.R. Basili, “Quantitative Evaluation of
csm/sce99/] Software Methodology,” Proceedings First Pan-
b) Manny Lehman’s work on the FEAST Pacific Computer Conference, September 1985.
project at Imperial College in England [Ben00] K. H. Bennett and V. T. Rajlich.
continues to provide valuable research into “Software Maintenance and Evolution: A
software evolution. [HTTP://www- Roadmap”, in A. Finklestein (ed.), The Future of
dse.doc.ic.uk/~mml/] Software Engineering, ACM Press, 2000
c) The International Workshop on Empirical [Bol95] C. Boldyreff, E. Burd, R. Hather, R.
Studies of Software Maintenance (WESS). Mortimer, M. Munro, and E. Younger, “The
[HTTP://computer.org/conferences/calendar/ AMES Approach to Application Understanding:
htm] A Case Study,” Proceedings of the International
d) The Research Institute for Software Conference on Software Maintenance-1995,
Evolution (RISE) at the University Of IEEE Computer Society Press, Los Alamitos, CA,
Durham, England, concentrates its research 1995.
on software maintenance and evolution. [Boo94] G.Booch, D. Bryan, Software
[HTTP://www.dur.ac.uk/csm] Engineering with Ada, (3rd. ed.),
e) The Reengineering Forum. Benjamin/Cummings Publishing Company,
[http://reengineer.org] Redwood City, California, 1994
f) The Practical Software and Systems [Cap94] M.A. Capretz and M. Munro, “Software
Measurement (PSM) project describes an Configuration Management Issues in the
issue-driven measurement process Maintenance of Existing Systems,” Journal of
[http://www.psmsc.com] that is used by many Software Maintenance, Vol. 6, no.2, 1994.
organizations and is quite practical. [Car92] J. Cardow, “You Can’t Teach Software
g) The website http://www.seg.iit.nrc.ca/projects Maintenance!,” Proceedings of the Sixth Annual
/easse provides a number of papers on Meeting and Conference of the Software
comprehension and tools for assisting with Management Association, 1992.
comprehension processes [Dor97] M. Dorfman and R. H. Thayer. Software
Engineering. IEEE Computer Society Press,
The IT Infrastructure Library [ITI01], published 1997.
by the UK Office of Government of Commerce [Fow99] M. Fowler et al., Refactoring:
(2001), presents two best-practice guides which Improving the Design of Existing Code, Addison-
Wesley, 1999.
[Gra87] R.B. Grady and D. L. Caswell. Software Engineering Test Lab, Technical Report, 91-08
Metrics: Establishing a Company-wide Program. TR, November 1991.
Prentice-Hall, 1987. [Oma92] P. Oman and J. Hagemeister, “Metrics
[Gra92] R.B. Grady, Practical Software Metrics for Assessing Software System Maintainability,”
for Project Management and Process Proceedings of the International Conference on
Improvement, Prentice-Hall, Inc., Englewood Software Maintenance-1992, IEEE Computer
Cliffs, NJ, 1992. Society Press, Los Alamitos, CA, 1992.
[IEEE1061-98] IEEE STD 1061. IEEE Standard [Pig93] T.M. Pigoski, “Maintainable Software:
for a Software Quality Metrics Methodology. Why You Want It and How to Get It,”
IEEE Computer Society Press, 1998. Proceedings of the Third Software Engineering
[ISO15271-98] ISO/IEC TR 15271, Information Research Forum-November 1993, University of
Technology – Guide for ISO/IEC 12207, West Florida Press, Pensacola, FL, 1993.
(Software Life Cycle Process), 1998 [Pig94] T.M. Pigoski. “Software Maintenance,”
[Kaj01] M. Kajko-Mattsson, S. Forssander, U. Encyclopedia of Software Engineering, John
Olsson, Corrective Maintenance Maturity Model: Wiley & Sons, New York, NY, 1994.
Maintainer’s Education and Training, in [Pol03] M. Polo, M. Piattini and F. Ruiz (editors).
Proceedings, International Conference on Advances in Software Maintenance Management:
Software Engineering, IEEE Computer, 2001. Technologies and Solutions. Idea Group
[Kho95] T.M. Khoshgoftaar, R.M. Szabo, and Publishing, Hershey, PA, 2003.
J.M. Voas, “Detecting Program Module with [Put97] L.H. Putman and W. Myers. Industrial
Low Testability,” Proceedings of the Strength Software – Effective Management Using
International Conference on Software Measurement, IEEE Computer Society Press, Los
Maintenance-1995, IEEE Computer Society Alamitos, CA, 1997.
Press, Los Alamitos, CA, 1995. [Sch87] N.F. Schneidewind. The State of
[Lag96] B.Laguë, A.April Mapping of the ISO Software Maintenance. Proceedings of the IEEE,
9126 Maintainability Internal Metrics to an 1987.
industrial research tool, SESS, Montréal, [Sch97] S.L. Schneberger, Client/Server Software
October 21-25, 1996. Maintenance, McGraw-Hill, 1997.
[Leh85] M.M. Lehman and L.A. Belady, [Sch99] S.R. Schach, Classical and Object-
Program Evolution – Processes of Software Oriented Software Engineering With UML and
Change, Academic Press Inc. (London) Ltd., C++, McGraw-Hill, 1999
1985. [Som01] I. Sommerville. Software Engineering.
[Leh97] M.M. Lehman, Laws of Software Addison-Wesley, 6th ed., 2001.
Evolution Revisited, EWSPT96, October 1996, [Val94] J.D. Vallett, S.E. Condon, L. Briand,
LNCS 1149, Springer Verlag, 1997. Y.M. Kim, and V.R. Basili, “Building on
[Oma91] P.W. Oman, J. Hagemeister, and D. Experience Factory for Maintenance,”
Ash, A Definition and Taxonomy for Software Proceedings of the Software Engineering
Maintainability, University of Idaho, Software Workshop, Software Engineering Laboratory,
1994.

© IEEE – Trial Version 1.00 – Décembre 2003 6-17

 Performance Evaluation. New York:Academic
APPENDIX C – REFERENCES USED TO Press, 1972.
WRITE AND JUSTIFY THE SOFTWARE [Ben00] K.H.Bennett, Software Maintenance: A
MAINTENANCE DESCRIPTION Tutorial, Software Engineering edited by
[Abr93] A.Abran, Maintenance Productivity & Dorfman and Thayer, IEEE Computer Society
Quality Studies: Industry Feedback on Press, 2000.
Benchmarking. Proceedings of the Software [Boe81] B.W. Boehm. Software Engineering
Maintenance Conference, ICSM93, Montréal Economics. Prentice-Hall, 1981.
September 27-30, 1993, pp. 370. [Bol95] C. Boldyreff, E. Burd, R. Hather, R.
[Abr93a] A. Abran and H. Hguyenkim, Mortimer, M. Munro, and E. Younger, “The
“Measurement of the Maintenance Process from a AMES Approach to Application Understanding:
Demand-Based Perspective,” Journal of Software A Case Study,” Proceedings of the International
Maintenance: Research and Practice, Vol. 5, no Conference on Software Maintenance-1995,
2, 1993. IEEE Computer Society Press, Los Alamitos, CA,
[IEEE1061-98] ANSI/IEEE STD 1061. IEEE 1995.
Standard for a Software Quality Metrics [Boo94] G.Booch, D. Bryan, Software
Methodology. IEEE Computer Society Press, Engineering with Ada, 3rd ed.,
1998. Benjamin/Cummings Publishing Company,
[Apr00] A. April and D. Al-Shurougi, Software Redwood City, California, 1994
Product Measurement for Supplier Evaluation, [Cap94] M.A. Capretz and M. Munro, “Software
FESMA 2000, Madrid, October 18-20, 2000. Configuration Management Issues in the
[Apr01] A.April, J.Bouman, A.Abran, and D.Al- Maintenance of Existing Systems,” Journal of
Shurougi, Software Maintenance in a Service Software Maintenance, Vol. 6, no.2, 1994.
Level Agreement: Controlling the Customer’s [Car90] D.N. Card and R.L. Glass, Measuring
Expectations, European Software Measurement Software Design Quality, Prentice Hall, 1990.
Conference, Heidelberg, Germany, May 8-11, [Car92] J. Cardow, “You Can’t Teach Software
2001. Maintenance!,” Proceedings of the Sixth Annual
[Apr03] A. April , A. Abran, and R. Dumke, Meeting and Conference of the Software
"Software Maintenance Capability Maturity Management Association, 1992.
Model (SM-CMM): Process Performance [Car94] D.Carey, Executive round-table on
Measurement,” 13th International Workshop on business issues in outsourcing- Making the
Software Measurement _ IWSM 2003, Montréal decision, CIO Canada June/July 1994.
(Canada), Springer-Verlag, Sept. 23-25, 2003, [Dek92] S. M. Dekleva. Delphi Study of
pp. 311-326. Software Maintenance Problems. Proceedings of
[Arn92] R.S. Arnold. Software Reengineering. the International Conference on Software
IEEE Computer Society, 1992. Maintenance, 1992.
[Art88] L.J. Arthur. Software Evolution: The [Dor02] M. Dorfman and R. H. Thayer. Software
Software Maintenance Challenge. John Wiley & Engineering (Vol. I & Vol. 2). IEEE Computer
Sons, 1988. Society Press, 2002.
[Bas85] V. R. Basili, “Quantitative Evaluation of [Fow99] M. Fowler et al., Refactoring:
Software Methodology,” Proceedings First Pan- Improving the Design of Existing Code, Addison-
Pacific Computer Conference, September 1985. Wesley, 1999.
[Bel72] L.Belady, and M.M.Lehman, “An [Gra87] R. B. Grady and D. L. Caswell. Software
introduction to growth dynamics,” in Metrics: Establishing a Company-wide Program.
W.Freiberger (ed), StatisticalComputer Prentice-Hall, 1987.
[Gra87a] R.B. Grady. Measuring and Managing [Lag96] B. Laguë and A.April. Mapping of the
Software Maintenance. IEEE Software Vol. 4, no ISO 9126 Maintainability Internal Metrics to an
9, 1987. industrial research tool, SESS, Montréal, 1996.
[Gra92] R.B. Grady, Practical Software Metrics [Leh85] M.M. Lehman and L.A. Belady,
for Project Management and Process Program Evolution – Processes of Software
Improvement, Prentice-Hall, Inc., Englewood Change, Academic Press Inc. (London) Ltd.,
Cliffs, NJ, 1992. 1985.
[IEEE610.12-90] IEEE STD 610.2: IEEE [Leh97] M.M. Lehman, Laws of Software
Standard Glossary of Software Engineering Evolution Revisited, EWSPT96, October 1996,
Terminology, 1990. LNCS 1149, Springer Verlag, 1997.
[IEEE1219-98 IEEE STD 1219: Standard for [Lie78] B.Lientz, E,B. Swanson, and G.E.
Software Maintenance, 1998. Tompkins, Characteristics of Applications
[ISO9126-01] ISO/IEC 9126:200: Information Software Maintenance Comm. ACM, Vol. 21,
Technology – Software Product Evaluation – 1978. [pp. 466—471]
Quality characteristics and guidelines for their [Lie81] B.P.Lientz and E.B.Swanson. Problems?
use, 2nd ed.,, 2001. in application software maintenance.
[ISO12207-95] ISO/IEC 12207: Information Communications of the ACM, 24(11) 1981. [pp.
Technology-Software Life Cycle Processes, 1995. 763-769]
[ISO14764-00] ISO/IEC 14764: Software [McC02] B.McCracken, Taking Control of IT
Engineering-Software Maintenance, 2000. Performance, InfoServer LLC, Dallas, Texas,
[ISO15271-98] ISO/IEC TR 15271, Information October 2002.
Technology - Guide for ISO/IEC 12207, [Nie02] F.Niessink, V. Clerk, H,.van Vliet, The IT
(Software Life Cycle Process), 1998 Service Capability Maturity Model, release L2+3-
[ITI01] IT Infrastructure Library, Service 0.3 draft, 2002 [Online] at
Delivery and Service Support, Published by the http://www.itservicecmm.org/doc/itscmm-l23-0.3.pdf
Stationary Office, Office of Government of (accessed on September 15, 2003).
Commerce, UK, 2001. [Oma91] P.W. Oman, J. Hagemeister, and D.
[Jon91] C.Jones, Applied Software Measurement. Ash, A Definition and Taxonomy for Software
McGraw-Hill, 1991. Maintainability, University of Idaho, Software
[Jon98] T.C. Jones. Estimating Software Costs. Engineering Test Lab, Technical Report, 91-08
McGraw-Hill, 1998. TR, November 1991.
[Kaj01] M.Kajko-Mattsson, Motivating the [Oma92] P. Oman and J. Hagemeister, “Metrics
Corrective Maintenance Maturity Model (Cm3), for Assessing Software System Maintainability,”
7th International Conference on Engineering of Proceedings of the International Conference on
Complex Systems, 2001, pp. 112-117. Software Maintenance-1992, IEEE Computer
[Kaj01a] M. Kajko-Mattsson, S. Forssander, and Society Press, Los Alamitos, CA, 1992.
U. Westblom, Corrective-Maintenance Maturity [Par86] G. Parikh. Handbook of Software
Model (Cm3) : Maintainer's Education and Maintenance. John Wiley & Sons, 1986.
Training, ICSE, 2001, pp. 610-619. [Pfl01] S.L. Pfleeger. Software Engineering—
[Kho95] T.M. Khoshgoftaar, R.M. Szabo, and Theory and Practice. Prentice Hall, 2nd ed.,
J.M. Voas, “Detecting Program Module with 2001.
Low Testability,” Proceedings of the [Pig93] T.M. Pigoski, “Maintainable Software:
International Conference on Software Why You Want It and How to Get It,”
Maintenance-1995, IEEE Computer Society Proceedings of the Third Software Engineering
Press, Los Alamitos, CA, 1995. Research Forum-November 1993, University of
West Florida Press, Pensacola, FL, 1993.

© IEEE – Trial Version 1.00 – Décembre 2003 6-19

[Pig94] T.M. Pigoski. “Software Maintenance,” [Sch97] S.L. Schneberger, Client/Server Software
Encyclopedia of Software Engineering, John Maintenance, McGraw-Hill, 1997.
Wiley & Sons, New York, NY, 1994. [Sch99] S.R. Schach, Classical and Object-
[Pig97] T.M. Pigoski. Practical Software Oriented Software Engineering With UML and
Maintenance: Best Practices for Managing your C++, McGraw-Hill, 1999
Software Investment. Wiley, 1997. [SEI01] Software Engineering Institute,
[Pol03] M. Polo, M. Piattini, and F. Ruiz (eds.). Capability Maturity Model Integration, v1.1,
Advances in Software Maintenance Management: CMU/SEI-2002-TR-002, ESC-TR-2002-002,
Technologies and Solutions. Idea Group December 2001.
Publishing, Hershey, PA, 2003. [Som01] I. Sommerville. Software Engineering.
[Poo01] C. Poole, and W. Huisman. Using Addison-Wesley, 6th ed., 2001.
Extreme Programming in a Maintenance [Sta94] G.E. Stark, L.C. Kern, and C.V. Vowell.
Environment, IEEE Software A Software Metrics Set for Program Maintenance
November/December 2001, pp.42-50. Management. Journal of Systems and Software,
[Pre01] R.S. Pressman. Software Engineering: A 1994.
Practitioner’s Approach. McGraw-Hill, 5th ed., [Tak97] A. Takang and P. Grubb. Software
2001. Maintenance Concepts and Practice.
[Put97] L.H. Putman and W. Myers. Industrial International Thomson Computer Press, 1997.
Strength Software – Effective Management Using [Val94] J.D. Vallett, S.E. Condon, L. Briand,
Measurement, IEEE Computer Society Press, Los Y.M. Kim, and V.R. Basili, “Building on
Alamitos, CA, 1997. Experience Factory for Maintenance,”
[Sch87] N.F. Schneidewind. The State of Proceedings of the Software Engineering
Software Maintenance. Proceedings of the IEEE, Workshop, Software Engineering Laboratory,
1987. 1994.