commit - 003ba9ccc2c4f0d5679e4b08e040bbd9c648c4b6
commit + 701b64df7b83e0a2f4636ef1b3f54a181dd89dfa
blob - 763bf0bf2dc30609d376784804e6498a2fadfe57
blob + 88ceac8cee7a706bdaec2ea5057246e2ec685f4a
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
-**CHAPTER 5**
+## Chapter 5: Software Maintenance
-**SOFTWARE MAINTENANCE**
+**Acronyms**
-##### ACRONYMS
-
MR Modification Request
PR Problem Report
SCM Software Configuration Management
SQA Software Quality Assurance
V&V Verification and Validation
-##### INTRODUCTION
+**Introduction**
-Software development efforts result in the deliv-
-ery of a software product that satisfies user
-requirements. Accordingly, the software product
-must change or evolve. Once in operation, defects
-are uncovered, operating environments change,
-and new user requirements surface. The mainte-
-nance phase of the life cycle begins following a
-warranty period or postimplementation support
-delivery, but maintenance activities occur much
-earlier.
-Software maintenance is an integral part of a
-software life cycle. However, it has not received
-the same degree of attention that the other phases
-have. Historically, software development has had
-a much higher profile than software maintenance
-in most organizations. This is now changing, as
-organizations strive to squeeze the most out of
-their software development investment by keep-
-ing software operating as long as possible. The
-open source paradigm has brought further atten-
-tion to the issue of maintaining software artifacts
+Software development efforts result in the delivery of a software product that
+satisfies user requirements. Accordingly, the software product must change or
+evolve. Once in operation, defects are uncovered, operating environments
+change, and new user requirements surface. The maintenance phase of the life
+cycle begins following a warranty period or postimplementation support
+delivery, but maintenance activities occur much earlier.
+
+Software maintenance is an integral part of a software life cycle. However, it
+has not received the same degree of attention that the other phases have.
+Historically, software development has had a much higher profile than software
+maintenance in most organizations. This is now changing, as organizations
+strive to squeeze the most out of their software development investment by
+keeping software operating as long as possible. The open source paradigm has
+brought further attention to the issue of maintaining software artifacts
developed by others.
-In this _Guide_ , software maintenance is defined
-as the totality of activities required to provide
-cost-effective support to software. Activities are
-performed during the predelivery stage as well as
+In this _Guide_ , software maintenance is defined as the totality of activities
+required to provide cost-effective support to software. Activities are
+performed during the predelivery stage as well as during the postdelivery
+stage. Predelivery activities include planning for postdelivery operations,
+maintainability, and logistics determination for transition activities [1*,
+c6s9]. Postdelivery activities include software modification, training, and
+operating or interfacing to a help desk. The Software Maintenance knowledge
+area (KA) is related to all other aspects of software engineering. Therefore,
+this KA description is linked to all other software engineering KAs of the
+Guide.
-during the postdelivery stage. Predelivery activi-
-ties include planning for postdelivery operations,
-maintainability, and logistics determination for
-transition activities [1*, c6s9]. Postdelivery
-activities include software modification, training,
-and operating or interfacing to a help desk.
-The Software Maintenance knowledge area
-(KA) is related to all other aspects of software
-engineering. Therefore, this KA description is
-linked to all other software engineering KAs of
-the Guide.
+BREAKDOWN OF TOPICS FOR SOFTWARE MAINTENANCE
+The breakdown of topics for the Software Maintenance KA is shown in Figure
+5.1.
-BREAKDOWN OF TOPICS FOR
-SOFTWARE MAINTENANCE
+### 1. Software Maintenance Fundamentals
+This first section introduces the concepts and terminology that form an
+underlying basis to understanding the role and scope of software maintenance.
+The topics provide definitions and emphasize why there is a need for
+maintenance. Categories of software maintenance are critical to understanding
+its underlying meaning.
-The breakdown of topics for the Software Main-
-tenance KA is shown in Figure 5.1.
+#### 1.1. Definitions and Terminology
-**1. Software Maintenance Fundamentals**
+<!-- [1*, c3] [2*, c1s2, c2s2] -->
+The purpose of software maintenance is defined in the international standard
+for software maintenance: ISO/IEC/IEEE 14764 [1].^1 In the context of software
+engineering, software maintenance is essentially one of the many technical
+processes.
-This first section introduces the concepts and
-terminology that form an underlying basis to
-understanding the role and scope of software
-maintenance. The topics provide definitions and
-emphasize why there is a need for maintenance.
-Categories of software maintenance are critical to
-understanding its underlying meaning.
+1 For the purpose of conciseness and ease of read- ing, this standard is
+referred to simply as IEEE 14764 in the subsequent text of this KA.
+The objective of software maintenance is to modify existing software while
+preserving its integrity. The international standard also states the importance
+of having some maintenance activities prior to the final delivery of software
+(predelivery activities). Notably, IEEE 14764 emphasizes the importance of the
+predelivery aspects of maintenance - planning, for example.
-1.1. Definitions and Terminology
-[1*, c3] [2*, c1s2, c2s2]
+#### 1.2. Nature of Maintenance
+<!-- [2*, c1s3] -->
-The purpose of software maintenance is defined
-in the international standard for software mainte-
-nance: ISO/IEC/IEEE 14764 [1].^1 In the context
-of software engineering, software maintenance is
-essentially one of the many technical processes.
+Software maintenance sustains the software product throughout its life cycle
+(from development to operations). Modification requests are logged and tracked,
+the impact of proposed changes is determined, code and other software artifacts
+are modified, testing is conducted, and a new version of the software product
+is released. Also, training and daily support are provided to users. The term
+maintainer is defined as an organization that performs maintenance activities.
+In this KA, the term will sometimes refer to individuals who perform those
+activities, contrasting them with the developers.
+IEEE 14764 identifies the primary activities of software maintenance as process
+implementation, problem and modification analysis, modification implementation,
+maintenance review/acceptance, migration, and retirement. These activities are
+discussed in section 3.2, Maintenance Activities. Maintainers can learn from
+the developers’ knowledge of the software. Contact with the developers and
+early involvement by the maintainer helps reduce the overall maintenance
+effort. In some instances, the initial developer cannot be reached or has moved
+on to other tasks, which creates an additional challenge for maintainers.
+Maintenance must take software artifacts from development (for example, code or
+documentation) and support them immediately, then progressively
+evolve/maintain them over a software life cycle.
-1 For the purpose of conciseness and ease of read-
-ing, this standard is referred to simply as IEEE 14764
-in the subsequent text of this KA.
+
-
-The objective of software maintenance is to
-modify existing software while preserving its
-integrity. The international standard also states
-the importance of having some maintenance
-activities prior to the final delivery of software
-(predelivery activities). Notably, IEEE 14764
-emphasizes the importance of the predelivery
-aspects of maintenance—planning, for example.
-
-_1.2. Nature of Maintenance_
-[2*, c1s3]
-
-Software maintenance sustains the software prod-
-uct throughout its life cycle (from development
-to operations). Modification requests are logged
-and tracked, the impact of proposed changes is
-determined, code and other software artifacts are
-
-
-modified, testing is conducted, and a new version
-of the software product is released. Also, train-
-ing and daily support are provided to users. The
-term maintainer is defined as an organization that
-performs maintenance activities. In this KA, the
-term will sometimes refer to individuals who per-
-form those activities, contrasting them with the
-developers.
-IEEE 14764 identifies the primary activities of
-software maintenance as process implementation,
-problem and modification analysis, modification
-implementation, maintenance review/acceptance,
-migration, and retirement. These activities are
-discussed in section 3.2, Maintenance Activities.
-Maintainers can learn from the develop-
-ers’ knowledge of the software. Contact with
-the developers and early involvement by the
-
-
-Figure 5.1. Breakdown of Topics for the Software Maintenance KA
-
-
-
Software Maintenance 5-3
-maintainer helps reduce the overall maintenance
-effort. In some instances, the initial developer
-cannot be reached or has moved on to other tasks,
-which creates an additional challenge for main-
-tainers. Maintenance must take software artifacts
-from development (for example, code or docu-
-mentation) and support them immediately, then
-progressively evolve/maintain them over a soft-
-ware life cycle.
+#### 1.3. Need for Maintenance
-_1.3. Need for Maintenance_
-[2*, c1s5]
+<!-- [2*, c1s5] -->
-Maintenance is needed to ensure that the software
-continues to satisfy user requirements. Mainte-
-nance is applicable to software that is developed
-using any software life cycle model (for example,
-spiral or linear). Software products change due
-to corrective and noncorrective software actions.
-Maintenance must be performed in order to
+Maintenance is needed to ensure that the software continues to satisfy user
+requirements. Maintenance is applicable to software that is developed using any
+software life cycle model (for example, spiral or linear). Software products
+change due to corrective and noncorrective software actions. Maintenance must
+be performed in order to
- correct faults;
- improve the design;
- implement enhancements;
- interface with other software;
-- adapt programs so that different hardware,
- software, system features, and telecommuni-
- cations facilities can be used;
+- adapt programs so that different hardware, software, system features, and
+ telecommunications facilities can be used;
- migrate legacy software; and
- retire software.
-Five key characteristics comprise the maintain-
-er’s activities:
+Five key characteristics comprise the maintainer’s activities:
-- maintaining control over the software’s day-
- to-day functions;
-- maintaining control over software
- modification;
+- maintaining control over the software’s day-to-day functions;
+- maintaining control over software modification;
- perfecting existing functions;
-- identifying security threats and fixing secu-
- rity vulnerabilities; and
-- preventing software performance from
- degrading to unacceptable levels.
+- identifying security threats and fixing security vulnerabilities; and
+- preventing software performance from degrading to unacceptable levels.
-_1.4. Majority of Maintenance Costs_
-[2*, c4s3, c5s5.2]
+#### 1.4. Majority of Maintenance Costs
-Maintenance consumes a major share of the finan-
-cial resources in a software life cycle. A common
+<!-- [2*, c4s3, c5s5.2] -->
-
-perception of software maintenance is that it
-merely fixes faults. However, studies and sur-
-veys over the years have indicated that the major-
-ity, over 80 percent, of software maintenance is
-used for noncorrective actions [2*, figure 4.1].
-Grouping enhancements and corrections together
-in management reports contributes to some mis-
-conceptions regarding the high cost of correc-
-tions. Understanding the categories of software
-maintenance helps to understand the structure of
-software maintenance costs. Also, understanding
-the factors that influence the maintainability of
-software can help to contain costs. Some environ-
-mental factors and their relationship to software
-maintenance costs include the following:
-
-- Operating environment refers to hardware
- and software.
-- Organizational environment refers to poli-
- cies, competition, process, product, and
- personnel.
-
-
-1.5. Evolution of Software
-[2*, c3s5]
+Maintenance consumes a major share of the financial resources in a software
+life cycle. A common perception of software maintenance is that it merely fixes
+faults. However, studies and surveys over the years have indicated that the
+majority, over 80 percent, of software maintenance is used for noncorrective
+actions [2*, figure 4.1]. Grouping enhancements and corrections together in
+management reports contributes to some misconceptions regarding the high cost
+of corrections. Understanding the categories of software maintenance helps to
+understand the structure of software maintenance costs. Also, understanding the
+factors that influence the maintainability of software can help to contain
+costs. Some environmental factors and their relationship to software
+maintenance costs include the following:
+- Operating environment refers to hardware and software.
+- Organizational environment refers to policies, competition, process, product,
+ and personnel.
-Software maintenance in terms of evolution was
-first addressed in the late 1960s. Over a period of
-twenty years, research led to the formulation of
-eight “Laws of Evolution.” Key findings include a
-proposal that maintenance is evolutionary devel-
-opment and that maintenance decisions are aided
-by understanding what happens to software over
-time. Some state that maintenance is continued
-development, except that there is an extra input
-(or constraint)–in other words, existing large soft-
-ware is never complete and continues to evolve;
-as it evolves, it grows more complex unless some
-action is taken to reduce this complexity.
+#### 1.5. Evolution of Software
+<!-- [2*, c3s5] -->
-1.6. Categories of Maintenance
-[1*, c3, c6s2] [2*, c3s3.1]
+Software maintenance in terms of evolution was first addressed in the late
+1960s. Over a period of twenty years, research led to the formulation of eight
+“Laws of Evolution.” Key findings include a proposal that maintenance is
+evolutionary development and that maintenance decisions are aided by
+understanding what happens to software over time. Some state that maintenance
+is continued development, except that there is an extra input (or constraint) –
+in other words, existing large software is never complete and continues to
+evolve; as it evolves, it grows more complex unless some action is taken to
+reduce this complexity.
+#### 1.6. Categories of Maintenance
-Three categories (types) of maintenance have
-been defined: corrective, adaptive, and perfec-
-tive [2*, c4s3]. IEEE 14764 includes a fourth
+<!-- [1*, c3, c6s2] [2*, c3s3.1] -->
+
+Three categories (types) of maintenance have been defined: corrective,
+adaptive, and perfective [2*, c4s3]. IEEE 14764 includes a fourth
category–preventative.
-- Corrective maintenance: reactive modifi-
- cation (or repairs) of a software product
+- Corrective maintenance: reactive modifi- cation (or repairs) of a software
+ product performed after delivery to correct discovered problems. Included in
+ this category is emergency maintenance, which is an unscheduled modification
+ performed to temporarily keep a software product operational pending
+ corrective maintenance.
+- Adaptive maintenance: modification of a software product performed after
+ delivery to keep a software product usable in a changed or changing
+ environment. For example, the operating system might be upgraded and some
+ changes to the software may be necessary.
+- Perfective maintenance: modification of a software product after delivery to
+ provide enhancements for users, improvement of program documentation, and
+ recoding to improve software performance, maintainability, or other software
+ attributes.
+- Preventive maintenance: modification of a software product after delivery to
+ detect and correct latent faults in the software product before they become
+ operational faults.
+IEEE 14764 classifies adaptive and perfective maintenance as maintenance
+enhancements. It also groups together the corrective and preventive maintenance
+categories into a correction category, as shown in Table 5.1.
-performed after delivery to correct discov-
-ered problems. Included in this category
-is emergency maintenance, which is an
-unscheduled modification performed to tem-
-porarily keep a software product operational
-pending corrective maintenance.
-
-- Adaptive maintenance: modification of a
- software product performed after delivery to
- keep a software product usable in a changed
- or changing environment. For example,
- the operating system might be upgraded
- and some changes to the software may be
- necessary.
-- Perfective maintenance: modification of a
- software product after delivery to provide
- enhancements for users, improvement of
- program documentation, and recoding to
- improve software performance, maintain-
- ability, or other software attributes.
-- Preventive maintenance: modification of a
- software product after delivery to detect and
- correct latent faults in the software product
- before they become operational faults.
-
-IEEE 14764 classifies adaptive and perfective
-maintenance as maintenance enhancements. It
-also groups together the corrective and preven-
-tive maintenance categories into a correction cat-
-egory, as shown in Table 5.1.
-
-
Table 5.1. Software Maintenance Categories
-
Correction Enhancement
+Proactive Preventive Perfective Reactive Corrective Adaptive
-Proactive Preventive Perfective
-Reactive Corrective Adaptive
+### 2. Key Issues in Software Maintenance
-**2. Key Issues in Software Maintenance**
+A number of key issues must be dealt with to ensure the effective maintenance
+of software. Software maintenance provides unique technical and management
+challenges for software engineers—for example, trying to find a fault in
+software containing a large number of lines of code that another software
+engineer developed. Similarly, competing with software developers for resources
+is a constant battle. Planning for a future release, which often includes
+coding the next release while sending out emergency patches for the current
+release, also creates a challenge. The following section presents some of the
+technical and management issues related to software maintenance. They have been
+grouped under the following topic headings:
-A number of key issues must be dealt with to
-ensure the effective maintenance of software.
-Software maintenance provides unique techni-
-cal and management challenges for software
-engineers—for example, trying to find a fault in
-software containing a large number of lines of
-code that another software engineer developed.
-Similarly, competing with software developers
-for resources is a constant battle. Planning for a
-future release, which often includes coding the
-
-
-next release while sending out emergency patches
-for the current release, also creates a challenge.
-The following section presents some of the tech-
-nical and management issues related to software
-maintenance. They have been grouped under the
-following topic headings:
-
- technical issues,
- management issues,
- cost estimation, and
- measurement.
+#### 2.1. Technical Issues
-2.1. Technical Issues
+##### 2.1.1. Limited Understanding
+<!-- [2*, c6] -->
-2.1.1. Limited Understanding
-[2*, c6]
-
-
-Limited understanding refers to how quickly a
-software engineer can understand where to make
-a change or correction in software that he or she
-did not develop. Research indicates that about half
-of the total maintenance effort is devoted to under-
-standing the software to be modified. Thus, the
-topic of software comprehension is of great inter-
-est to software engineers. Comprehension is more
-difficult in text-oriented representation—in source
-code, for example—where it is often difficult to
-trace the evolution of software through its releases/
-versions if changes are not documented and if the
-developers are not available to explain it, which is
-often the case. Thus, software engineers may ini-
-tially have a limited understanding of the software;
+Limited understanding refers to how quickly a software engineer can understand
+where to make a change or correction in software that he or she did not
+develop. Research indicates that about half of the total maintenance effort is
+devoted to understanding the software to be modified. Thus, the topic of
+software comprehension is of great interest to software engineers.
+Comprehension is more difficult in text-oriented representation - in source
+code, for example - where it is often difficult to trace the evolution of
+software through its releases/ versions if changes are not documented and if
+the developers are not available to explain it, which is often the case. Thus,
+software engineers may initially have a limited understanding of the software;
much has to be done to remedy this.
+##### 2.1.2. Testing
-2.1.2. Testing
-[1*, c6s2.2.2] [2*, c9]
+<!-- [1*, c6s2.2.2] [2*, c9] -->
+The cost of repeating full testing on a major piece of software is significant
+in terms of time and money. In order to ensure that the requested problem
+reports are valid, the maintainer should replicate or verify problems by
+running the appropriate tests. Regression testing (the selective retesting of
+software or a component to verify that the modifications have not caused
+unintended effects) is an important testing concept in maintenance.
+Additionally, finding time to test is often difficult. Coordinating tests when
+different members of the maintenance team are working on different problems at
+the same time remains a challenge. When software performs critical functions,
+it may be difficult to bring it offline to test. Tests cannot be executed in
+the most meaningful place - the production system. The Software Testing KA
+provides additional information and references on this matter in its subtopic
+on regression testing.
-The cost of repeating full testing on a major
-piece of software is significant in terms of time
-and money. In order to ensure that the requested
-problem reports are valid, the maintainer should
-replicate or verify problems by running the
-appropriate tests. Regression testing (the selec-
-tive retesting of software or a component to ver-
-ify that the modifications have not caused unin-
-tended effects) is an important testing concept in
-maintenance. Additionally, finding time to test is
-often difficult. Coordinating tests when different
-members of the maintenance team are working
-
-
-
Software Maintenance 5-5
-on different problems at the same time remains a
-challenge. When software performs critical func-
-tions, it may be difficult to bring it offline to test.
-Tests cannot be executed in the most meaning-
-ful place–the production system. The Software
-Testing KA provides additional information and
-references on this matter in its subtopic on regres-
-sion testing.
+##### 2.1.3. Impact Analysis
+<!-- [1*, c5s2.5] [2*, c13s3] -->
-2.1.3. Impact Analysis
-[1*, c5s2.5] [2*, c13s3]
-
-Impact analysis describes how to conduct, cost-
-effectively, a complete analysis of the impact of
-a change in existing software. Maintainers must
-possess an intimate knowledge of the software’s
-structure and content. They use that knowledge
-to perform impact analysis, which identifies all
-systems and software products affected by a soft-
-ware change request and develops an estimate of
-the resources needed to accomplish the change.
-Additionally, the risk of making the change is
-determined. The change request, sometimes called
-a modification request (MR) and often called a
-problem report (PR), must first be analyzed and
-translated into software terms. Impact analysis is
-performed after a change request enters the soft-
-ware configuration management process. IEEE
-14764 states the impact analysis tasks:
+Impact analysis describes how to conduct, costeffectively, a complete analysis
+of the impact of a change in existing software. Maintainers must possess an
+intimate knowledge of the software’s structure and content. They use that
+knowledge to perform impact analysis, which identifies all systems and software
+products affected by a software change request and develops an estimate of the
+resources needed to accomplish the change. Additionally, the risk of making the
+change is determined. The change request, sometimes called a modification
+request (MR) and often called a problem report (PR), must first be analyzed and
+translated into software terms. Impact analysis is performed after a change
+request enters the software configuration management process. IEEE 14764 states
+the impact analysis tasks:
- analyze MRs/PRs;
- replicate or verify the problem;
-- develop options for implementing the
- modification;
-- document the MR/PR, the results, and the
- execution options;
-- obtain approval for the selected modification
- option.
+- develop options for implementing the modification;
+- document the MR/PR, the results, and the execution options;
+- obtain approval for the selected modification option.
-The severity of a problem is often used to
-decide how and when it will be fixed. The soft-
-ware engineer then identifies the affected com-
-ponents. Several potential solutions are provided,
-followed by a recommendation as to the best
+The severity of a problem is often used to decide how and when it will be
+fixed. The software engineer then identifies the affected components. Several
+potential solutions are provided, followed by a recommendation as to the best
course of action.
-Software designed with maintainability in mind
-greatly facilitates impact analysis. More informa-
-tion can be found in the Software Configuration
+
+Software designed with maintainability in mind greatly facilitates impact
+analysis. More information can be found in the Software Configuration
Management KA.
+##### 2.1.4. Maintainability
-2.1.4. Maintainability
-[1*, c6s8] [2*, c12s5.5]
+<!-- [1*, c6s8] [2*, c12s5.5] -->
+IEEE 14764 [1*, c3s4] defines maintainability as the capability of the software
+product to be modified. Modifications may include corrections, improvements, or
+adaptation of the software to changes in environment as well as changes in
+requirements and functional specifications. As a primary software quality
+characteristic, maintainability should be specified, reviewed, and controlled
+during software development activities in order to reduce maintenance costs.
+When done successfully, the software’s maintainability will improve.
+Maintainability is often difficult to achieve because the subcharacteristics
+are often not an important focus during the process of software development.
+The developers are, typically, more preoccupied with many other activities and
+frequently prone to disregard the maintainer’s requirements. This in turn can,
+and often does, result in a lack of software documentation and test
+environments, which is a leading cause of difficulties in program comprehension
+and subsequent impact analysis. The presence of systematic and mature
+processes, techniques, and tools helps to enhance the maintainability of
+software.
-IEEE 14764 [1*, c3s4] defines maintainability
-as the capability of the software product to be
-modified. Modifications may include corrections,
-improvements, or adaptation of the software to
-changes in environment as well as changes in
-requirements and functional specifications.
-As a primary software quality characteristic,
-maintainability should be specified, reviewed, and
-controlled during software development activi-
-ties in order to reduce maintenance costs. When
-done successfully, the software’s maintainability
-will improve. Maintainability is often difficult to
-achieve because the subcharacteristics are often
-not an important focus during the process of soft-
-ware development. The developers are, typically,
-more preoccupied with many other activities and
-frequently prone to disregard the maintainer’s
-requirements. This in turn can, and often does,
-result in a lack of software documentation and test
-environments, which is a leading cause of difficul-
-ties in program comprehension and subsequent
-impact analysis. The presence of systematic and
-mature processes, techniques, and tools helps to
-enhance the maintainability of software.
+#### 2.2. Management Issues
+##### 2.2.1. Alignment with Organizational Objectives
-2.2. Management Issues
+<!-- [2*, c4] -->
+Organizational objectives describe how to demonstrate the return on investment
+of software maintenance activities. Initial software development is usually
+project-based, with a defined time scale and budget. The main emphasis is to
+deliver a product that meets user needs on time and within budget. In contrast,
+software maintenance often has the objective of extending the life of software
+for as long as possible. In addition, it may be driven by the need to meet user
+demand for software updates and enhancements. In both cases, the return on
+investment is much less clear, so that the view at the senior management
+level is often that of a major activity consuming significant resources
+with no clear quantifiable benefit for the organization.
-2.2.1. Alignment with Organizational
-Objectives
-[2*, c4]
+##### 2.2.2. Staffing
+<!-- [2*, c4s5, c10s4] -->
-Organizational objectives describe how to demon-
-strate the return on investment of software main-
-tenance activities. Initial software development is
-usually project-based, with a defined time scale and
-budget. The main emphasis is to deliver a product
-that meets user needs on time and within budget.
-In contrast, software maintenance often has the
-objective of extending the life of software for as
-long as possible. In addition, it may be driven by
-the need to meet user demand for software updates
-and enhancements. In both cases, the return on
-investment is much less clear, so that the view at
-the senior management level is often that of a major
-activity consuming significant resources with no
-clear quantifiable benefit for the organization.
+Staffing refers to how to attract and keep software maintenance staff.
+Maintenance is not often viewed as glamorous work. As a result, software
+maintenance personnel are frequently viewed as “second-class citizens,” and
+morale therefore suffers.
+##### 2.2.3. Process
-2.2.2. Staffing
-[2*, c4s5, c10s4]
+<!-- [1*, c5] [2*, c5] -->
-Staffing refers to how to attract and keep soft-
-ware maintenance staff. Maintenance is not often
-viewed as glamorous work. As a result, software
-maintenance personnel are frequently viewed
-as “second-class citizens,” and morale therefore
-suffers.
+The software life cycle process is a set of activities, methods, practices, and
+transformations that people use to develop and maintain software and its
+associated products. At the process level, software maintenance activities
+share much in common with software development (for example, software
+configuration management is a crucial activity in both). Maintenance also
+requires several activities that are not found in software development (see
+section 3.2 on unique activities for details). These activities present
+challenges to management.
+##### 2.2.4. Organizational Aspects of Maintenance
-2.2.3. Process
-[1*, c5] [2*, c5]
+<!-- [1*, c7s2.3] [2*, c10] -->
-The software life cycle process is a set of activities,
-methods, practices, and transformations that peo-
-ple use to develop and maintain software and its
-associated products. At the process level, software
-maintenance activities share much in common
-with software development (for example, software
-configuration management is a crucial activity in
-both). Maintenance also requires several activities
-that are not found in software development (see
-section 3.2 on unique activities for details). These
-activities present challenges to management.
+Organizational aspects describe how to identify which organization and/or
+function will be responsible for the maintenance of software. The team that
+develops the software is not necessarily assigned to maintain the software once
+it is operational.
+In deciding where the software maintenance function will be located, software
+engineering organizations may, for example, stay with the original developer or
+go to a permanent maintenance-specific team (or maintainer). Having a permanent
+maintenance team has many benefits:
-2.2.4. Organizational Aspects of Maintenance
-[1*, c7s2.3] [2*, c10]
-
-Organizational aspects describe how to iden-
-tify which organization and/or function will be
-responsible for the maintenance of software. The
-team that develops the software is not necessar-
-ily assigned to maintain the software once it is
-operational.
-In deciding where the software maintenance
-function will be located, software engineering
-organizations may, for example, stay with the
-original developer or go to a permanent main-
-tenance-specific team (or maintainer). Having a
-permanent maintenance team has many benefits:
-
- allows for specialization;
- creates communication channels;
- promotes an egoless, collegiate atmosphere;
- reduces dependency on individuals;
- allows for periodic audit checks.
-Since there are many pros and cons to each
-option, the decision should be made on a case-by-
-case basis. What is important is the delegation or
+Since there are many pros and cons to each option, the decision should be made
+on a case-by-case basis. What is important is the delegation or assignment of
+the maintenance responsibility to a single group or person, regardless of the
+organization’s structure.
+##### 2.2.5. Outsourcing
-assignment of the maintenance responsibility to a
-single group or person, regardless of the organi-
-zation’s structure.
+<!-- [3] -->
+Outsourcing and offshoring software maintenance has become a major industry.
+Organizations are outsourcing entire portfolios of software, including software
+maintenance. More often, the outsourcing option is selected for less
+mission-critical software, as organizations are unwilling to lose control of
+the software used in their core business. One of the major challenges for
+outsourcers is to determine the scope of the maintenance services required, the
+terms of a service-level agreement, and the contractual details. Outsourcers
+will need to invest in a maintenance infrastructure, and the help desk at the
+remote site should be staffed with native-language speakers. Outsourcing
+requires a significant initial investment and the setup of a maintenance
+process that will require automation.
-2.2.5. Outsourcing
-[3]
+#### 2.3. Maintenance Cost Estimation
+Software engineers must understand the different categories of software
+maintenance, discussed above, in order to address the question of estimating
+the cost of software maintenance. For planning purposes, cost estimation is an
+important aspect of planning for software maintenance.
-Outsourcing and offshoring software mainte-
-nance has become a major industry. Organiza-
-tions are outsourcing entire portfolios of soft-
-ware, including software maintenance. More
-often, the outsourcing option is selected for less
-mission-critical software, as organizations are
-unwilling to lose control of the software used in
-their core business. One of the major challenges
-for outsourcers is to determine the scope of the
-maintenance services required, the terms of a ser-
-vice-level agreement, and the contractual details.
-Outsourcers will need to invest in a maintenance
-infrastructure, and the help desk at the remote site
-should be staffed with native-language speakers.
-Outsourcing requires a significant initial invest-
-ment and the setup of a maintenance process that
-will require automation.
+##### 2.3.1. Cost Estimation
+<!-- [2*, c7s2.4] -->
-2.3. Maintenance Cost Estimation
+Section 2.1.3 describes how impact analysis identifies all systems and software
+products affected by a software change request and develops an estimate of the
+resources needed to accomplish that change.
+Maintenance cost estimates are affected by many technical and nontechnical
+factors. IEEE 14764 states that “the two most popular approaches to estimating
+resources for software maintenance are the use of parametric models and the use
+of experience” [1*, c7s4.1]. A combination of these two can also be used.
-Software engineers must understand the different
-categories of software maintenance, discussed
-above, in order to address the question of estimat-
-ing the cost of software maintenance. For plan-
-ning purposes, cost estimation is an important
-aspect of planning for software maintenance.
-
-
-2.3.1. Cost Estimation
-[2*, c7s2.4]
-
-
-Section 2.1.3 describes how impact analysis iden-
-tifies all systems and software products affected
-by a software change request and develops an
-estimate of the resources needed to accomplish
-that change.
-Maintenance cost estimates are affected
-by many technical and nontechnical factors.
-IEEE 14764 states that “the two most popular
-approaches to estimating resources for software
-maintenance are the use of parametric models
-and the use of experience” [1*, c7s4.1]. A combi-
-nation of these two can also be used.
-
-
-
Software Maintenance 5-7
+##### 2.3.2. Parametric Models
-2.3.2. Parametric Models
-[2*, c12s5.6]
+<!-- [2*, c12s5.6] -->
-Parametric cost modeling (mathematical models)
-has been applied to software maintenance. Of sig-
-nificance is that historical data from past main-
-tenance are needed in order to use and calibrate
-the mathematical models. Cost driver attributes
-affect the estimates.
+Parametric cost modeling (mathematical models) has been applied to software
+maintenance. Of significance is that historical data from past maintenance are
+needed in order to use and calibrate the mathematical models. Cost driver
+attributes affect the estimates.
+##### 2.3.3. Experience
-2.3.3. Experience
-[2*, c12s5.5]
+<!-- [2*, c12s5.5] -->
-Experience, in the form of expert judgment,
-is often used to estimate maintenance effort.
-Clearly, the best approach to maintenance esti-
-mation is to combine historical data and experi-
-ence. The cost to conduct a modification (in terms
-of number of people and amount of time) is then
-derived. Maintenance estimation historical data
-should be provided as a result of a measurement
+Experience, in the form of expert judgment, is often used to estimate
+maintenance effort. Clearly, the best approach to maintenance estimation is to
+combine historical data and experience. The cost to conduct a modification (in
+terms of number of people and amount of time) is then derived. Maintenance
+estimation historical data should be provided as a result of a measurement
program.
-_2.4. Software Maintenance Measurement_
-[1*, c6s5] [2*, c12]
+#### 2.4. Software Maintenance Measurement
-Entities related to software maintenance, whose
-attributes can be subjected to measurement,
-include process, resource, and product [2*,
-c12s3.1].
-There are several software measures that can
-be derived from the attributes of the software,
-the maintenance process, and personnel, includ-
-ing size, complexity, quality, understandability,
-maintainability, and effort. Complexity measures
-of software can also be obtained using available
-commercial tools. These measures constitute a
-good starting point for the maintainer’s measure-
-ment program. Discussion of software process
-and product measurement is also presented in the
-Software Engineering Process KA. The topic of
-a software measurement program is described in
-the Software Engineering Management KA.
+<!-- [1*, c6s5] [2*, c12] -->
+Entities related to software maintenance, whose attributes can be subjected to
+measurement, include process, resource, and product [2*, c12s3.1].
-2.4.1. Specific Measures
-[2*, c12]
+There are several software measures that can be derived from the attributes of
+the software, the maintenance process, and personnel, including size,
+complexity, quality, understandability, maintainability, and effort. Complexity
+measures of software can also be obtained using available commercial tools.
+These measures constitute a good starting point for the maintainer’s
+measurement program. Discussion of software process and product measurement is
+also presented in the Software Engineering Process KA. The topic of a software
+measurement program is described in the Software Engineering Management KA.
-The maintainer must determine which measures
-are appropriate for a specific organization based
-on that organization’s own context. The software
+##### 2.4.1. Specific Measures
+<!-- [2*, c12] -->
-quality model suggests measures that are specific
-for software maintenance. Measures for subchar-
-acteristics of maintainability include the follow-
-ing [4*, p. 60]:
+The maintainer must determine which measures are appropriate for a specific
+organization based on that organization’s own context. The software quality
+model suggests measures that are specific for software maintenance. Measures
+for subcharacteristics of maintainability include the following [4*, p. 60]:
-- Analyzability: measures of the maintainer’s
- effort or resources expended in trying either
- to diagnose deficiencies or causes of failure
- or to identify parts to be modified.
-- Changeability: measures of the maintainer’s
- effort associated with implementing a speci-
- fied modification.
-- Stability: measures of the unexpected behav-
- ior of software, including that encountered
- during testing.
-- Testability: measures of the maintainer’s and
- users’ effort in trying to test the modified
- software.
+- Analyzability: measures of the maintainer’s effort or resources expended in
+ trying either to diagnose deficiencies or causes of failure or to identify
+ parts to be modified.
+- Changeability: measures of the maintainer’s effort associated with
+ implementing a specified modification.
+- Stability: measures of the unexpected behav- ior of software, including that
+ encountered during testing.
+- Testability: measures of the maintainer’s and users’ effort in trying to test
+ the modified software.
- Other measures that maintainers use include
- size of the software,
- complexity of the software ,
- understandability, and
- maintainability.
+Providing software maintenance effort, by categories, for different
+applications provides business information to users and their organizations. It
+can also enable the comparison of software maintenance profiles internally
+within an organization.
-Providing software maintenance effort, by
-categories, for different applications provides
-business information to users and their organiza-
-tions. It can also enable the comparison of soft-
-ware maintenance profiles internally within an
-organization.
+### 3. Maintenance Process
-**3. Maintenance Process**
+In addition to standard software engineering processes and activities described
+in IEEE 14764, there are a number of activities that are unique to maintainers.
+#### 3.1. Maintenance Processes
-In addition to standard software engineering pro-
-cesses and activities described in IEEE 14764,
-there are a number of activities that are unique to
-maintainers.
+<!-- [1*, c5] [2*, c5] [5, s5.5] -->
+Maintenance processes provide needed activities and detailed inputs/outputs to
+those activities as described in IEEE 14764. The maintenance process activities
+of IEEE 14764 are shown in Figure 5.2. Software maintenance activities include
-3.1. Maintenance Processes
-[1*, c5] [2*, c5] [5, s5.5]
-
-
-Maintenance processes provide needed activities
-and detailed inputs/outputs to those activities as
-described in IEEE 14764. The maintenance pro-
-cess activities of IEEE 14764 are shown in Figure
-5.2. Software maintenance activities include
-
- process implementation,
- problem and modification analysis,
- modification implementation,
- migration, and
- software retirement.
+
-Figure 5.2. Software Maintenance Process
-
-
Other maintenance process models include:
- quick fix,
- iterative enhancement, and
- reuse-oriented.
-Recently, agile methodologies, which promote
-light processes, have been also adapted to main-
-tenance. This requirement emerges from the ever-
-increasing demand for fast turnaround of main-
-tenance services. Improvement to the software
-maintenance process is supported by specialized
-software maintenance capability maturity models
-(see [6] and [7], which are briefly annotated in the
-Further Readings section).
+Recently, agile methodologies, which promote light processes, have been also
+adapted to maintenance. This requirement emerges from the everincreasing
+demand for fast turnaround of maintenance services. Improvement to the software
+maintenance process is supported by specialized software maintenance capability
+maturity models (see [6] and [7], which are briefly annotated in the Further
+Readings section).
-_3.2. Maintenance Activities_
-[1*, c5, c6s8.2, c7s3.3]
+#### 3.2. Maintenance Activities
-The maintenance process contains the activities
-and tasks necessary to modify an existing soft-
-ware product while preserving its integrity. These
+<!-- [1*, c5, c6s8.2, c7s3.3] -->
+The maintenance process contains the activities and tasks necessary to modify
+an existing software product while preserving its integrity. These activities
+and tasks are the responsibility of the maintainer. As already noted, many
+maintenance activities are similar to those of software development.
+Maintainers perform analysis, design, cod- ing, testing, and documentation.
+They must track requirements in their activities - just as is done in
+development - and update documentation as baselines change. IEEE 14764
+recommends that when a maintainer uses a development process, it must be
+tailored to meet specific needs [1*, c5s3.2.2]. However, for software
+maintenance, some activities involve processes unique to software maintenance.
-activities and tasks are the responsibility of the
-maintainer. As already noted, many maintenance
-activities are similar to those of software develop-
-ment. Maintainers perform analysis, design, cod-
-ing, testing, and documentation. They must track
-requirements in their activities—just as is done
-in development—and update documentation as
-baselines change. IEEE 14764 recommends that
-when a maintainer uses a development process,
-it must be tailored to meet specific needs [1*,
-c5s3.2.2]. However, for software maintenance,
-some activities involve processes unique to soft-
-ware maintenance.
+##### 3.2.1. Unique Activities
+<!-- [1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7] -->
-3.2.1. Unique Activities
-[1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7]
+There are a number of processes, activities, and practices that are unique to
+software maintenance:
+- Program understanding: activities needed to obtain a general knowledge of
+ what a software product does and how the parts work together.
+- Transition: a controlled and coordinated sequence of activities during which
+ software is transferred progressively from the developer to the maintainer.
+- Modification request acceptance/rejection: modifications requesting work
+ beyond a certain size/effort/complexity may be rejected by maintainers and
+ rerouted to a developer.
+- Maintenance help desk: an end-user and maintenance coordinated support
+ function that triggers the assessment, prioritization, and costing of
+ modification requests.
+- Impact analysis: a technique to identify areas impacted by a potential
+ change;
+- Maintenance Service-Level Agreements (SLAs) and maintenance licenses and
+ contracts: contractual agreements that describe the services and quality
+ objectives.
-There are a number of processes, activities, and
-practices that are unique to software maintenance:
+##### 3.2.2. Supporting Activities
-- Program understanding: activities needed to
- obtain a general knowledge of what a software
- product does and how the parts work together.
-- Transition: a controlled and coordinated
- sequence of activities during which software
- is transferred progressively from the devel-
- oper to the maintainer.
-- Modification request acceptance/rejection:
- modifications requesting work beyond a cer-
- tain size/effort/complexity may be rejected
- by maintainers and rerouted to a developer.
-- Maintenance help desk: an end-user and
- maintenance coordinated support function
- that triggers the assessment, prioritization,
- and costing of modification requests.
-- Impact analysis: a technique to identify areas
- impacted by a potential change;
-- Maintenance Service-Level Agreements
- (SLAs) and maintenance licenses and con-
- tracts: contractual agreements that describe
- the services and quality objectives.
+<!-- [1*, c4s1, c5, c6s7] [2*, c9] -->
+Maintainers may also perform support activities, such as documentation,
+software configuration management, verification and validation, problem
+resolution, software quality assurance, reviews, and audits. Another important
+support activity consists of training the maintainers and users.
-3.2.2. Supporting Activities
-[1*, c4s1, c5, c6s7] [2*, c9]
-
-
-Maintainers may also perform support activities,
-such as documentation, software configuration
-management, verification and validation, problem
-resolution, software quality assurance, reviews,
-
-
-
Software Maintenance 5-9
-and audits. Another important support activity
-consists of training the maintainers and users.
+##### 3.2.3. Maintenance Planning Activities
+<!-- [1*, c7s3] -->
-3.2.3. Maintenance Planning Activities
-[1*, c7s3]
+An important activity for software maintenance is planning, and maintainers
+must address the issues associated with a number of planning perspectives,
+including
-An important activity for software maintenance is
-planning, and maintainers must address the issues
-associated with a number of planning perspec-
-tives, including
-
- business planning (organizational level),
- maintenance planning (transition level),
- release/version planning (software level), and
-- individual software change request planning
- (request level).
+- individual software change request planning (request level).
-At the individual request level, planning is
-carried out during the impact analysis (see sec-
-tion 2.1.3, Impact Analysis). The release/version
-planning activity requires that the maintainer:
+At the individual request level, planning is carried out during the impact
+analysis (see section 2.1.3, Impact Analysis). The release/version planning
+activity requires that the maintainer:
-- collect the dates of availability of individual
- requests,
-- agree with users on the content of subsequent
- releases/versions,
-- identify potential conflicts and develop
- alternatives,
-- assess the risk of a given release and develop
- a back-out plan in case problems should
- arise, and
+- collect the dates of availability of individual requests,
+- agree with users on the content of subsequent releases/versions,
+- identify potential conflicts and develop alternatives,
+- assess the risk of a given release and develop a back-out plan in case
+ problems should arise, and
- inform all the stakeholders.
-Whereas software development projects can
-typically last from some months to a few years,
-the maintenance phase usually lasts for many
-years. Making estimates of resources is a key ele-
-ment of maintenance planning. Software main-
-tenance planning should begin with the decision
-to develop a new software product and should
-consider quality objectives. A concept document
-should be developed, followed by a maintenance
-plan. The maintenance concept for each software
-product needs to be documented in the plan [1*,
-c7s2] and should address the
+Whereas software development projects can typically last from some months to a
+few years, the maintenance phase usually lasts for many years. Making estimates
+of resources is a key element of maintenance planning. Software maintenance
+planning should begin with the decision to develop a new software product and
+should consider quality objectives. A concept document should be developed,
+followed by a maintenance plan. The maintenance concept for each software
+product needs to be documented in the plan [1*, c7s2] and should address the
- scope of the software maintenance,
-- adaptation of the software maintenance
- process,
- - identification of the software maintenance
- organization, and
- - estimate of software maintenance costs.
+- adaptation of the software maintenance process,
+- identification of the software maintenance organization, and
+- estimate of software maintenance costs.
+The next step is to develop a corresponding software maintenance plan. This
+plan should be prepared during software development and should specify how
+users will request software modifications or report problems. Software
+maintenance planning is addressed in IEEE 14764. It provides guidelines for a
+maintenance plan. Finally, at the highest level, the maintenance organization
+will have to conduct business planning activities (budgetary, financial, and
+human resources) just like all the other divisions of the organization.
+Management is discussed in the chapter Related Disciplines of Software
+Engineering.
-The next step is to develop a corresponding
-software maintenance plan. This plan should be
-prepared during software development and should
-specify how users will request software modifica-
-tions or report problems. Software maintenance
-planning is addressed in IEEE 14764. It provides
-guidelines for a maintenance plan. Finally, at
-the highest level, the maintenance organization
-will have to conduct business planning activities
-(budgetary, financial, and human resources) just
-like all the other divisions of the organization.
-Management is discussed in the chapter Related
-Disciplines of Software Engineering.
+##### 3.2.4. Software Configuration Management
+<!-- [1*, c5s1.2.3] [2*, c11] -->
-3.2.4. Software Configuration Management
-[1*, c5s1.2.3] [2*, c11]
+IEEE 14764 describes software configuration management as a critical element of
+the maintenance process. Software configuration management procedures should
+provide for the verification, validation, and audit of each step required to
+identify, authorize, implement, and release the software product.
+It is not sufficient to simply track modification requests or problem reports.
+The software product and any changes made to it must be controlled. This
+control is established by implementing and enforcing an approved software
+configuration management (SCM) process. The Software Configuration Management
+KA provides details of SCM and discusses the process by which software change
+requests are submitted, evaluated, and approved. SCM for software maintenance
+is different from SCM for software development in the number of small changes
+that must be controlled on operational software. The SCM process is implemented
+by developing and following a software configuration management plan and
+operating procedures. Maintainers participate in Configuration Control Boards
+to determine the content of the next release/version.
-IEEE 14764 describes software configuration
-management as a critical element of the mainte-
-nance process. Software configuration manage-
-ment procedures should provide for the verifica-
-tion, validation, and audit of each step required
-to identify, authorize, implement, and release the
-software product.
-It is not sufficient to simply track modifica-
-tion requests or problem reports. The software
-product and any changes made to it must be con-
-trolled. This control is established by implement-
-ing and enforcing an approved software configu-
-ration management (SCM) process. The Software
-Configuration Management KA provides details
-of SCM and discusses the process by which soft-
-ware change requests are submitted, evaluated,
-and approved. SCM for software maintenance is
-different from SCM for software development in
-the number of small changes that must be con-
-trolled on operational software. The SCM pro-
-cess is implemented by developing and following
-a software configuration management plan and
-operating procedures. Maintainers participate in
-Configuration Control Boards to determine the
-content of the next release/version.
+##### 3.2.5. Software Quality
+<!-- [1*, c6s5, c6s7, c6s8] [2*, c12s5.3] -->
-3.2.5. Software Quality
-[1*, c6s5, c6s7, c6s8] [2*, c12s5.3]
+It is not sufficient to simply hope that increased quality will result from the
+maintenance of software. Maintainers should have a software quality program. It
+must be planned and processes must be implemented to support the maintenance
+process. The activities and techniques for Software Quality Assurance (SQA),
+V&V, reviews, and audits must be selected in concert with all the other
+processes to achieve the desired level of quality. It is also recommended that
+the maintainer adapt the software development processes, techniques and
+deliverables (for instance, testing documentation), and test results. More
+details can be found in the Software Quality KA.
-It is not sufficient to simply hope that increased
-quality will result from the maintenance of soft-
-ware. Maintainers should have a software qual-
-ity program. It must be planned and processes
-must be implemented to support the maintenance
-process. The activities and techniques for Soft-
-ware Quality Assurance (SQA), V&V, reviews,
-and audits must be selected in concert with all
-the other processes to achieve the desired level
-of quality. It is also recommended that the main-
-tainer adapt the software development processes,
-techniques and deliverables (for instance, testing
-documentation), and test results. More details can
-be found in the Software Quality KA.
+### 4. Techniques for Maintenance
-**4. Techniques for Maintenance**
+This topic introduces some of the generally accepted techniques used in
+software maintenance.
-This topic introduces some of the generally
-accepted techniques used in software maintenance.
+#### 4.1. Program Comprehension
-_4.1. Program Comprehension_
-[2*, c6, c14s5]
+<!-- [2*, c6, c14s5] -->
-Programmers spend considerable time reading and
-understanding programs in order to implement
-changes. Code browsers are key tools for program
-comprehension and are used to organize and pres-
-ent source code. Clear and concise documentation
+Programmers spend considerable time reading and understanding programs in order
+to implement changes. Code browsers are key tools for program comprehension and
+are used to organize and present source code. Clear and concise documentation
can also aid in program comprehension.
-_4.2. Reengineering_
-[2*, c7]
+#### 4.2. Reengineering
-Reengineering is defined as the examination and
-alteration of software to reconstitute it in a new
-form, and includes the subsequent implementa-
-tion of the new form. It is often not undertaken to
-improve maintainability but to replace aging leg-
-acy software. Refactoring is a reengineering tech-
-nique that aims at reorganizing a program without
-changing its behavior. It seeks to improve a pro-
-gram structure and its maintainability. Refactor-
-ing techniques can be used during minor changes.
+<!-- [2*, c7] -->
+Reengineering is defined as the examination and alteration of software to
+reconstitute it in a new form, and includes the subsequent implementation of
+the new form. It is often not undertaken to improve maintainability but to
+replace aging legacy software. Refactoring is a reengineering technique that
+aims at reorganizing a program without changing its behavior. It seeks to
+improve a program structure and its maintainability. Refactoring techniques can
+be used during minor changes.
-4.3. Reverse Engineering
-[1*, c6s2] [2*, c7, c14s5]
+#### 4.3. Reverse Engineering
+<!-- [1*, c6s2] [2*, c7, c14s5] -->
-Reverse engineering is the process of analyzing
-software to identify the software’s components
-and their inter-relationships and to create repre-
-sentations of the software in another form or at
-higher levels of abstraction. Reverse engineer-
-ing is passive; it does not change the software
-or result in new software. Reverse engineer-
-ing efforts produce call graphs and control flow
-graphs from source code. One type of reverse
-engineering is redocumentation. Another type is
-design recovery. Finally, data reverse engineer-
-ing, where logical schemas are recovered from
-physical databases, has grown in importance over
-the last few years. Tools are key for reverse engi-
-neering and related tasks such as redocumenta-
-tion and design recovery.
+Reverse engineering is the process of analyzing software to identify the
+software’s components and their inter-relationships and to create
+representations of the software in another form or at higher levels of
+abstraction. Reverse engineering is passive; it does not change the software or
+result in new software. Reverse engineering efforts produce call graphs and
+control flow graphs from source code. One type of reverse engineering is
+redocumentation. Another type is design recovery. Finally, data reverse
+engineering, where logical schemas are recovered from physical databases, has
+grown in importance over the last few years. Tools are key for reverse
+engineering and related tasks such as redocumentation and design recovery.
+#### 4.4. Migration
-4.4. Migration
-[1*, c5s5]
+<!-- [1*, c5s5] -->
-
-During software’s life, it may have to be modi-
-fied to run in different environments. In order to
-migrate it to a new environment, the maintainer
-needs to determine the actions needed to accom-
-plish the migration, and then develop and docu-
-ment the steps required to effect the migration in
-a migration plan that covers migration require-
-ments, migration tools, conversion of product
-and data, execution, verification, and support.
-Migrating software can also entail a number of
-additional activities such as
+During software’s life, it may have to be modified to run in different
+environments. In order to migrate it to a new environment, the maintainer needs
+to determine the actions needed to accomplish the migration, and then develop
+and document the steps required to effect the migration in a migration plan
+that covers migration requirements, migration tools, conversion of product and
+data, execution, verification, and support. Migrating software can also entail
+a number of additional activities such as
- notification of intent: a statement of why
the old environment is no longer to be sup-
uled migration is completed, a notification is
sent to all concerned;
-
-
Software Maintenance 5-11
-- postoperation review: an assessment of par-
- allel operation and the impact of changing to
- the new environment;
+- postoperation review: an assessment of parallel operation and the impact of
+ changing to the new environment;
- data archival: storing the old software data.
-_4.5. Retirement_
-[1*, c5s6]
+#### 4.5. Retirement
-Once software has reached the end of its use-
-ful life, it must be retired. An analysis should
-be performed to assist in making the retirement
-decision. This analysis should be included in the
-retirement plan, which covers retirement require-
-ments, impact, replacement, schedule, and effort.
-Accessibility of archive copies of data may also
-be included. Retiring software entails a number
+<!-- [1*, c5s6] -->
+
+Once software has reached the end of its useful life, it must be retired. An
+analysis should be performed to assist in making the retirement decision. This
+analysis should be included in the retirement plan, which covers retirement
+requirements, impact, replacement, schedule, and effort. Accessibility of
+archive copies of data may also be included. Retiring software entails a number
of activities similar to migration.
-**5. Software Maintenance Tools**
- [1*, c6s4] [2*, c14]
+### 5. Software Maintenance Tools
-This topic encompasses tools that are particularly
-important in software maintenance where exist-
-ing software is being modified. Examples regard-
-ing program comprehension include
+<!-- [1*, c6s4] [2*, c14] -->
-- program slicers, which select only parts of a
- program affected by a change;
-- static analyzers, which allow general view-
- ing and summaries of a program content;
-- dynamic analyzers, which allow the main-
- tainer to trace the execution path of a
- program;
-- data flow analyzers, which allow the main-
- tainer to track all possible data flows of a
- program;
-- cross-referencers, which generate indices of
- program components; and
-- dependency analyzers, which help maintain-
- ers analyze and understand the interrelation-
- ships between components of a program.
+This topic encompasses tools that are particularly important in software
+maintenance where existing software is being modified. Examples regarding
+program comprehension include
+- program slicers, which select only parts of a program affected by a change;
+- static analyzers, which allow general viewing and summaries of a program content;
+- dynamic analyzers, which allow the maintainer to trace the execution path of
+ a program;
+- data flow analyzers, which allow the maintainer to track all possible data
+ flows of a program;
+- cross-referencers, which generate indices of program components; and
+- dependency analyzers, which help maintainers analyze and understand the
+ interrelationships between components of a program.
-Reverse engineering tools assist the process by
-working backwards from an existing product to
-create artifacts such as specification and design
-descriptions, which can then be transformed to
-generate a new product from an old one. Main-
-tainers also use software test, software configura-
-tion management, software documentation, and
-software measurement tools.
+Reverse engineering tools assist the process by working backwards from an
+existing product to create artifacts such as specification and design
+descriptions, which can then be transformed to generate a new product from an
+old one. Maintainers also use software test, software configuration management,
+software documentation, and software measurement tools.
+### Matrix Of Topics vs. Reference Material
-##### MATRIX OF TOPICS VS. REFERENCE MATERIAL
+IEEE/ISO/IEC 14764 2006
-##### IEEE/ISO/IEC 14764 2006
+[1]
-##### [1]
-
-
Grubb and Takang 2003
-##### [2]
+[2]
-
Sneed 2008
-##### [3]
+[3]
-**1. Software Maintenance
-Fundamentals**
+**1. Software Maintenance Fundamentals**
1.1. Definitions and Terminology c3 c1s2, c2s2
-
-
-1.2. Nature of Maintenance c1s3
-
-
-1.3. Need for Maintenance c1s5
-
-
-1.4. Majority of Maintenance Costs c4s3, c5s5.2
-
-
-1.5. Evolution of Software c3s5
-
-
-1.6. Categories of Maintenance c3, c6s2 c3s3.1, c4s3
-
-**2. Key Issues in Software
-Maintenance**
+ 1.2. Nature of Maintenance c1s3
+ 1.3. Need for Maintenance c1s5
+ 1.4. Majority of Maintenance Costs c4s3, c5s5.2
+ 1.5. Evolution of Software c3s5
+ 1.6. Categories of Maintenance c3, c6s2 c3s3.1, c4s3
+**2. Key Issues in Software Maintenance**
2.1. Technical Issues
+ 2.1.1. Limited Understanding c6
+ 2.1.2. Testing c6s2.2.2 c9
+ 2.1.3. Impact Analysis c5s2.5 c13s3
+ 2.1.4. Maintainability c6s8, c3s4 c12s5.5
+ 2.2. Management Issues
+ 2.2.1. Alignment with Organizational objectives c4
+ 2.2.2. Staffing c4s5, c10s4
+ 2.2.3. Process c5 c5
+ 2.2.4. Organizational Aspects of Maintenance c7s.2.3 c10
+ 2.2.5. Outsourcing/Offshoring all
+ 2.3. Maintenance Cost Estimation
+ 2.3.1. Cost Estimation c7s4.1 c7s2.4
-
-2.1.1. Limited Understanding c6
-2.1.2. Te s t i n g c6s2.2.2 c9
-
-
-2.1.3. Impact Analysis c5s2.5 c13s3
-
-
-2.1.4. Maintainability c6s8, c3s4 c12s5.5
-
-
-2.2. Management Issues
-2.2.1. Alignment with
-Organizational objectives
-c4
-
-
-2.2.2. Staffing c4s5, c10s4
-
-
-2.2.3. Process c5 c5
-2.2.4. Organizational Aspects of
-Maintenance
-c7s.2.3 c10
-
-
-2.2.5. Outsourcing/Offshoring all
-
-
-2.3. Maintenance Cost Estimation
-2.3.1. Cost Estimation c7s4.1 c7s2.4
-
-
-
Software Maintenance 5-13
-##### IEEE/ISO/IEC 14764 2006
+IEEE/ISO/IEC 14764 2006
-##### [1]
+[1]
-
Grubb and Takang 2003
-##### [2]
+[2]
-
Sneed 2008
-##### [3]
-
-
-2.3.2. Parametric Models c12s5.6
-
-
-2.3.3. Experience c12s5.5
-2.4. Software Maintenance
-Measurement
-c6s5 c12, c12s3.1
-
-
-2.4.1. Specific Measures c12
-
+[3]
+ 2.3.2. Parametric Models c12s5.6
+ 2.3.3. Experience c12s5.5
+ 2.4. Software Maintenance Measurement c6s5 c12, c12s3.1
+ 2.4.1. Specific Measures c12
**3. Maintenance Process**
-
-
-3.1. Maintenance Processes c5 c5
-
-
-3.2. Maintenance Activities
-c5, c5s3.2.2,
-c6s8.2, c7s3.3
-
-
-3.2.1. Unique Activities
-c3s10, c6s9, c7s2,
-c7s3
-c6,c7
-
-
-3.2.2. Supporting Activities c4s1, c5, c6s7 c9
-3.2.3. Maintenance Planning
-Activities
-c7s2, c7s.3
-
-
-3.2.4. Software Configuration
-Management
-c5s1.2.3 c11
-
-
-3.2.5. Software Quality c6s5, c6s7, c6s8 c12s5.3
-
+ 3.1. Maintenance Processes c5 c5
+ 3.2. Maintenance Activities c5, c5s3.2.2, c6s8.2, c7s3.3
+ 3.2.1. Unique Activities c3s10, c6s9, c7s2, c7s3 c6,c7
+ 3.2.2. Supporting Activities c4s1, c5, c6s7 c9
+ 3.2.3. Maintenance Planning Activities c7s2, c7s.3
+ 3.2.4. Software Configuration Management c5s1.2.3 c11
+ 3.2.5. Software Quality c6s5, c6s7, c6s8 c12s5.3
**4. Techniques for Maintenance**
-
-
-4.1. Program Comprehension c6,c14s5
-
-
-4.2. Reengineering c7
-
-
-4.3. Reverse Engineering c6s2 c7, c14s5
-
-
-4.4. Migration c5s5
-
-
-4.5. Retirement c5s6
-
+ 4.1. Program Comprehension c6,c14s5
+ 4.2. Reengineering c7
+ 4.3. Reverse Engineering c6s2 c7, c14s5
+ 4.4. Migration c5s5
+ 4.5. Retirement c5s6
**5. Software Maintenance Tools** c6s4 c14
-##### FURTHER READINGS
+**Further Readings
-A. April and A. Abran, _Software Maintenance
-Management: Evaluation and Continuous
-Improvement_ [6].
+A. April and A. Abran, _Software Maintenance Management: Evaluation and
+Continuous Improvement_ [6].
-This book explores the domain of small software
-maintenance processes (S3M). It provides road-
-maps for improving software maintenance pro-
-cesses in organizations. It describes a software
-maintenance specific maturity model organized
-by levels which allow for benchmarking and con-
-tinuous improvement. Goals for each key prac-
-tice area are provided, and the process model pre-
-sented is fully aligned with the architecture and
-framework of international standards ISO12207,
-ISO14764 and ISO15504 and popular maturity
-models like ITIL, CoBIT, CMMI and CM3.
+This book explores the domain of small software maintenance processes (S3M). It
+provides roadmaps for improving software maintenance processes in
+organizations. It describes a software maintenance specific maturity model
+organized by levels which allow for benchmarking and continuous improvement.
+Goals for each key practice area are provided, and the process model presented
+is fully aligned with the architecture and framework of international standards
+ISO12207, ISO14764 and ISO15504 and popular maturity models like ITIL, CoBIT,
+CMMI and CM3.
-M. Kajko-Mattsson, “Towards a Business
-Maintenance Model,” IEEE Int’l Conf.
+M. Kajko-Mattsson, “Towards a Business Maintenance Model,” IEEE Int’l Conf.
Software Maintenance [7].
-This paper presents an overview of the Correc-
-tive Maintenance Maturity Model (CM3). In
-contrast to other process models, CM3 is a spe-
-cialized model, entirely dedicated to corrective
-maintenance of software. It views maintenance in
-terms of the activities to be performed and their
-order, in terms of the information used by these
-activities, goals, rules and motivations for their
-execution, and organizational levels and roles
-involved at various stages of a typical corrective
-maintenance process.
+This paper presents an overview of the Corrective Maintenance Maturity Model
+(CM3). In contrast to other process models, CM3 is a specialized model,
+entirely dedicated to corrective maintenance of software. It views maintenance
+in terms of the activities to be performed and their order, in terms of the
+information used by these activities, goals, rules and motivations for their
+execution, and organizational levels and roles involved at various stages of a
+typical corrective maintenance process.
-##### REFERENCES
+**References**
[1] IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for Software
Engineering—Software Life Cycle Processes—Maintenance , IEEE, 2006.
