CH-1: Software Evolution and maintenance concepts

 Software maintenance involves the process of updating, fixing, and improving software systems after they have
been deployed.
 The concept of software evolution means a continual change from a lesser, simpler, or worse state to a higher or
better state.
 Software maintenance and software evolution are closely related concepts but they have distinct focuses.
 All support activities carried out after delivery of software are put under the category of
maintenance.
 Goals: primary aims to ensures the software continues to function correctly, meets current user needs, and operates
within new environment
 a border concept that encompasses the overall process of software development and change over time including
maintenance, upgrades, and reengineering.
 Goal: aims to adopt to changing requirement, technologies, and business environment, often involves significant
architectural changes or rethinking of software.
 …

Key differences
Scope: maintenance is a subset of evolution; evolution includes all aspects of software change, includes
maintenance.
Perspective: maintenance is often reactive (fixing issues) while evolution is more proactive( planning for future
needs and improvement)
Evolution: is about long-term growth and adaptability, while maintenance is about keeping the software
functional and efficient in the short term. Both are crucial for a software system's success over its lifecycle.
 Software Evolution

Fundamental work in the field of software evolution was done by Lehman and
his collaborators.
Based on empirical studies, Lehman and his collaborators formulated some observations
and they introduced them as laws of evolution.
The “laws” themselves have “evolved” from three in 1974 to eight by 1997.
Those laws are the results of studies of the evolution of large-scale proprietary
or closed source software (CSS) systems.
The laws concern a category of software systems called E-type systems.
E-type systems, or "evolving-type systems," refer to a category of software that is
particularly complex and subject to continual change over time.
The eight laws are briefly explained as follows:
 Software Evolution…

1. Continuing change: Software must continually change to remain useful and

relevant.
2. Increasing complexity: As software systems evolve, their complexity tends to
increase unless managed carefully.
3. Self-regulation: The evolution of software is often regulated by user
requirements and market demands.
4. Conservation of organizational stability: Organizations need to maintain a
balance between software changes and operational stability.
 Software Evolution…

4. Conservation of familiarity: emphasizing the importance of user familiarity with software

systems. Changes that significantly alter the user interface or functionality can lead to
confusion and reduce productivity. The Law of Conservation of Familiarity underscores
the importance of keeping user experience in mind during software evolution
6. Continuing growth: The size of a software system will continue to grow unless
actively controlled.
7. Declining quality: Unless the design of a system is diligently fine-tuned and
adapted to new operational environments, the system’s qualities will be
perceived as declining over the lifetime of the system.
8. Feedback system: The behavior of software is influenced by external feedback,
such as user interactions and system performance. Effective feedback mechanisms
can help guide future evolution.
 Software Maintenance

There are defects in delivered software applications, because defect removal

and quality control processes are not perfect.
Therefore, maintenance is needed to repair those defects in released software.
E. Burton Swanson initially defined three categories of software maintenance activities,
namely, corrective, adaptive, and perfective.
Those definitions were later incorporated into the standard software
engineering–software life cycle processes–Maintenance and introduced a fourth
category called preventive maintenance.
some researchers and developers view preventive maintenance as a subset of perfective
maintenance.
 Software Maintenance…

Types of Maintenance:
Corrective: Adaptive:
Definition: Involves fixing defects or bugs in the Definition: Involves modifying the software to
software. work in a new or changed environment.
Purpose: To ensure that the software performs as Purpose: To accommodate changes such as new
expected and to resolve issues reported by users hardware, operating systems, or compliance with
new regulations.
Perfective:  Preventive:
Definition: Focuses on improving the Definition: Involves making changes to the
performance or efficiency of the software. Change software to prevent future issues or failures.
in requirement Purpose: To anticipate potential problems and
Purpose: To enhance features, improve usability, mitigate risks before they affect the system.
or optimize the system based on user feedback and Example, dealing with legacy system
performance metrics.
 Software Maintenance…

Swanson’s classification of maintenance activities is intention based because

the maintenance activities reflect the intents of the developer to carry out
specific maintenance tasks on the system.
In the intention-based classification of maintenance activities, the intention of
an activity depends upon the motivations for the change.
Activities to make corrections: If there are difference between the expected behavior of a
system and the actual behavior, then some activities are performed to eliminate or reduce
the difference.
Activities to make enhancements: A number of activities are performed to implement a
change to the system, thereby changing the behavior or implementation of the system.
 Software Maintenance…

This category of activities is further refined into three subcategories:

 Enhancements that modify existing requirements;

 Enhancements that create new requirements; and

 Enhancements that modify the implementation without changing the requirements.

 Software Maintenance…

Component based software systems (CBS): New components are developed by combining
Commercial Off-the-Shelf (COTS) software refers to ready-made software products that are available for sale
to the general public, custom-built (in-house) components, and open source software components.
The major differences between component-based software systems (CBS) and custom-built
software systems:
 Skills of system maintenance teams: Maintenance of CBS requires specialized skills to monitor and integrate
COTS products.
 Infrastructure and organization: Running a support group for in-house products is necessary to manage a large
product.
 COTS maintenance cost: This cost includes the costs of purchasing components, licensing components,
upgrading components, and training maintenance personnel.
 Larger user community: COTS users are part of a broad community of users, and the community of users can be
considered as a resource, which is a positive factor.
 Software Maintenance…

 Modernization: the processes and strategies used to update, improve, or transform software applications to meet
current business needs, technological standards, and user expectations. CBS require high efforts to modernize
than custom-built (in-house) components.
 Split maintenance function: refers to the practice of separating the maintenance tasks into different functions or
responsibilities. Including modularity, separation of concern, and version control. In this case component based
software is more suitable for maintenance because it support modularity and separation of concern.
 SOFTWARE EVOLUTION MODELS AND PROCESSES

 Software maintenance should have its own software maintenance life cycle (SMLC) model.
 A number of SMLC models with some variations are available in literature. Three common features of the
SMLC models found in the literature are:
 Understanding the code;
 Modifying the code; and
 Revalidating the code.
 Other models view software development as iterative processes and based on the idea of change mini-cycle as
explained in the following:
 Iterative models: Systems are constructed in builds, each of which is a refinement of requirements of
the previous build. A build is refined by considering feedback from users.
 Change mini-cycle models: These models consist of five major phases: change request, analyze and
plan change, implement change, verify and validate, and documentation change.
 In this process model, several important activities were identified, such as program
comprehension, impact analysis, refactoring, and change propagation.
 SOFTWARE EVOLUTION MODELS …

A different kind of software evolution model, called staged model of maintenance and
evolution, has been proposed by Rajlich and Bennett.
The model is descriptive in nature, and its primary objective is to improve the
understanding of how long-lived software evolves.
The model considers four distinct, sequential stages of the lifetime of a system, as explained
below:
1. Initial development: When the initial version of the system is produced, detailed knowledge about the
system is fresh. Before delivery of the system, it undergoes many changes. Eventually, a system architecture
emerges and soon it stabilizes.
2. Evolution: Significant changes involve higher cost and higher risk. In the period immediately following
the initial delivery, knowledge about the system is still almost fresh in the minds of the developers.
 In general, for many systems, their lifespan are spent in this stage, because the systems continue to be of
importance to the organizations.
 SOFTWARE EVOLUTION MODELS …

3. Servicing: When the knowledge about the system has significantly decreased, the developers mainly focus
on maintenance tasks, such as fixing bugs, whereas architectural changes are rarely effected.
4. Phase out: When even minimal servicing of a system is not an option, the system enters its very final stage.
The organization decides to replace the system for various reasons:
(i) it is too expensive to maintain the system; or
(ii) there is a newer solution available.
 SOFTWARE EVOLUTION MODELS …

Software Maintenance Standards: A well-defined process for software maintenance can be

observed and measured, and thus improved.
IEEE and ISO have both addressed s/w maintenance processes.
IEEE/EIA 1219 and ISO/IEC 14764 as a part of ISO/IEC12207 (life cycle process).
IEEE/EIA 1219 organizes the maintenance process in seven phases:
Problem identification, Analysis, Design, Implementation, System test, Acceptance
test and Delivery.
 for each phase, the standard identifies the input and output deliverables, the supporting processes and
the related activities, and a set of evaluation metrics.
 SOFTWARE EVOLUTION MODELS …

Software Configuration Management: Configuration management (CM) is the discipline of managing,

tracking, and controlling changes in the evolution of software systems.
 The goal of CM is to manage and control the various extensions, adaptations, and corrections that are
applied to a system over its lifetime.
A SCM system has four different elements, each element addressing a distinct user need as follows:
 Identification of software configurations: This includes the definitions of the different artifacts, their
baselines or milestones, and the changes to the artifacts.
 Control of software configurations: controlling the ways artifacts or configurations are altered with the
necessary technical and administrative support.
 Auditing software configurations: Making the current status of the software system in its life cycle
visible to management and determining whether or not the baselines meet their requirements.
 Accounting software configuration status: providing an administrative history of how the software
system has been altered, by recording the activities.
 REENGINEERING

 Reengineering in the context of software refers to the process of redesigning and restructuring existing
software systems to improve their performance, maintainability, and adaptability. This practice is often
employed to update legacy systems, enhance functionality, or align software with changing business
requirements
 To a large extent, software evolution can be seen as repeated software reengineering.
 Reengineering includes some kind of reverse engineering activities to design an abstract view of a given
system.
 The new abstract view is restructured, and forward engineering activities are performed to implement the
system in its new form.
 The aforementioned process is captured by Jacobson and Lindst¨orm with the following expression:
 Reengineering = Reverse engineering+Δ+Forward engineering.
 REENGINEERING…

The first element “Reverse engineering” is the activity of defining a more abstract and easier
to understand representation of the system.
 For example, the input to the reverse engineering process is the source code of the system, and the output is
the system architecture.
 The core of reverse engineering is the process of examination of the system, and it is not a process of
change.
The third element “forward engineering” is the traditional process of moving from a high-
level abstraction and logical, implementation-independent design to the physical
implementation of the system.
The second element “Δ” captures alterations performed to the original system.
 LEGACY SYSTEMS

A legacy software system is an old program that continues to be used because it still meets
the users’ needs, in spite of the availability of newer technology or more efficient
methods of performing the task.
It is the phase out stage of the software evolution model of Rajlich and Bennet described
earlier.
There are a number of options available to manage legacy systems. Typical solution include:
 Freeze: The organization decides no further work on the legacy system should be performed.
 Outsource: engage with third-party vendors that specialize in legacy systems management to provide support.
Modernization or migration services.
 LEGACY SYSTEMS…

 Carry on maintenance: Despite all the problems of support, the organization decides to carry on maintenance for
another period.
 Discard and redevelop: Throw all the software away and redevelop the application once again from scratch.
 Wrap: It is a black-box modernization technique – surrounds the legacy system with a software layer that
hides the unwanted complexity of the existing data, individual programs, application systems, and
interfaces with the new interfaces.
 Migrate: Legacy system migration basically moves an existing, operational system to a new platform, retaining
the legacy system’s functionality and causing minimal disruption to the existing operational business
environment as possible.
 IMPACT ANALYSIS

Impact analysis is the task of estimating the parts of the software that can be affected if a
proposed change request is made.
Impact analysis techniques can be partitioned into two classes:
 Traceability analysis: In this approach the high-level artifacts such as requirements, design, code and test
cases related to the feature to be changed are identified.
 A model of inter-artifacts such that each artifact in one level links to other artifacts is constructed, which
helps to locate a pieces of design, code and test cases that need to be maintained.
 Dependency (or source-code) analysis is a critical practice in software development that involves
examining the relationships between different components, modules, or packages in a software system.
This analysis helps developers understand how changes in one part of the codebase can affect other parts,
facilitating better maintenance, refactoring, and overall system reliability.
The two dependency-based impact analysis techniques are: call graph based analysis and
dependency graph based analysis.
 REFACTORING

Refactoring: is the process of making a change to the internal structure of software to make it
easier to understand and cheaper to modify without changing its observable behavior.
It is the object-oriented equivalent of restructuring.
Refactoring, which aims to improve the internal structure of the code, achieve through the
removal of duplicate code, simplification, making code easier to understand, help to find
defects and adding flexibility to program faster.
There are two aspects of the above definition:
 It must preserve the “observable behavior” of the software system (through regression).
 To improve the internal structure of a software system (improve maintainability).
 SOFTWARE REUSE

Software reuse was introduced by Dough McIlroy in his 1968 seminal paper:
The development of an industry of reusable source-code software components and the
industrialization of the production of application software from off-the-shelf components.
Software reuse is using existing artifacts or software knowledge during the construction of a
new software system.
Reusable assets can be either reusable artifacts or software knowledge.
Capers Jones identified four types of reusable artifacts:
data reuse, involving a standardization of data formats,
architectural reuse, which consists of standardizing a set of design and programming
conventions dealing with the logical organization of software,
design reuse, for some common business applications, and
program reuse, which deals with reusing executable code.
 SOFTWARE REUSE…

Benefits of Reuse
Increased reliability
Reduced process risk
Increase productivity
Standards compliance
Accelerated development
Improve maintainability
Reduction in maintenance time and effort
 CH-2: Maintenance Support Processes
Maintenance Planning
Evolution and Maintenance
Testing
Configuration Management
Problem Management
Maintenance supporting tools
✓A process that is used, when required, by an operational process is said to be an operational
support process.
✓Operational processes are the systematic activities and procedures that the organization use
to manage their day-to- day operations efficiently and effectively.
✓Maintenance support processes are crucial for ensuring the ongoing functionality.
Performances, and other requirements.
✓In most IS/IT organizations, developers, maintainers, and operations share the responsibility
for these processes.
Maintenance Support Processes…

✓ Support processes typically include:

✓A documentation process

✓A software configuration and version management process and tools

✓A product quality assurance process

✓The verification and validation processes

✓The problem resolution process, which is often shared with operations

✓The reviews and audits processes

 Maintenance Planning

✓Software maintenance, being a large portion of IT costs, needs to be part of the

strategic IT plan.
✓Maintenance planning ensures the creation and updating of plans that describe
the current and planned software maintenance activities
✓Software maintenance planning is typically elaborated from three perspectives:
organizational, tactical, and operational.
 Maintenance Planning…

✓At organizational level focuses on aligning maintenance activities with the overall business strategy.
✓At the organizational level, planning goals are strategic, general, and corporate, and include
partners, the SLA(service level agreement), contracts, and licensing.
✓At the tactical level, developing specific strategies and plans for maintenance activies. the planning
goal is to identify and plan the activities of predelivery and transition for new software and also the
yearly plans associated with a specific customer account.
✓Finally, at the operational level, day-to-day execution of maintenance activities the goals are specific:
(a) To conduct impact analysis on a given maintenance request,
(b) To plan the recovery/failure tests,
(c) To plan software versions/releases (e.g., assign each request to a future version/release of the software), and
(d) To plan software upgrades (especially the COTS) for the many platforms.
Maintenance Planning…

Goals of Maintenance Planning KPA (Key Performance Area)

1. Ensure a proactive collection and documentation of customer/user, development, and
computer operation requests (in the short term, medium term …) to conduct detailed
planning.
2. Identify, communicate, and obtain consensus on priorities of requests currently in queue
and assigned.
3. Identify the required controls for each type of maintenance service and application software
under maintenance.
4. Plan the recovery/failure tests for all software in maintenance.
5. Identify version management plans ( also called release plans) for all software maintained.
Maintenance Planning…

6. Prepare software upgrade plans.

7. Establish a rationale for the allocation of new requests to maintenance engineers and for the
capacity of maintenance.
8. Inform the stakeholders of maintenance work performed, waiting in queue, and in progress
based on agreed priorities.
9. Inform stakeholders on the status of budgets and on the use of resources.
Maintenance Planning…

Expected Results from the KPA

After the successful implementation of the exemplary practices of this KPA, the following can be observed:
✓ A reliable and well-founded prediction is available on needed resources in software maintenance (strategic plan,
tactical plan, and operational plan).
✓ SLA, agreement, license, and contract renewals are planned.
✓ The failure/recovery tests are planned for each software in maintenance.
✓ Requests are allocated to future versions of the software.
✓ Software upgrades are planned.
✓ Pre-delivery and transition services are planned(tactical).
✓ There is an optimal allocation of maintenance resources to work items.
✓ Software maintenance has a plan, and this plan is communicated and approved.
✓ The stakeholders are informed about the plans.
 EVOLUTION AND MAINTENANCE TESTING

Maintenance Testing
✓Maintenance Testing is done on the already deployed software.
✓The deployed software needs to be enhanced, changed or migrated to other
hardware.
✓The Testing done during this enhancement, change and migration cycle is
known as maintenance testing.
Maintenance Testing…

Usually maintenance testing is consisting of two parts:

✓ First one is, testing the changes that has been made because of the correction in the system or if the system
is extended or because of some additional features added to it. It verify that specific defects or issues
identified in previous testing have been successfully fixed.
✓ Second one is regression tests to prove that the rest of the system has not been affected by the maintenance
work. It verify the existing functionalities remain unaffected after changes have been made.
 Configuration Management

✓Software Configuration Management encompasses the disciplines and techniques of

initiating, evaluating and controlling change to software products during and after the
software engineering process.
✓Configuration management consists of determining the configuration and description of
products and intermediate work products at a precise time.
✓Its objective is to ensure systematic control over configuration changes and to maintain
integrity and traceability throughout the life cycle of a request that will modify the existing
software.
Configuration Management…

✓Configuration management's first objective is to establish and maintain the integrity of the
project’s products throughout their lifecycle.
✓The maintainer is thus able to follow a change's progress from

Initial Request Requirements Impact Analysis Detailed Design

To Use by the Technical Programming

Testing
User Documentation
Configuration Management…

✓This first aspect of configuration is called traceability.

✓Another aspect of configuration management is the use of support software to reserve components
while the software is being worked on. (integrity)
✓This activity ensures that employees cannot change a component without being aware
of changes made by a colleague.
✓Developers and maintainers also make images of software at every critical step using the same tools.
✓For example
✓ They would make a copy of the complete configuration at each major step in the testing phase.
✓ This technique allows them to isolate an image of all software components at any given time.
✓ They can always revert to this state should the work being done become corrupted.
✓ It can be imagined that backup copies are, in fact, images of the software's configuration.
Configuration Management…

The fundamental differences between a backup copy and a configuration image are the
following:
✓ Backup Copy: A backup copy is primarily intended for data recovery. It usually includes user data,
application data, and system files to restore a system to a previous state in case of data loss or corruption.

✓ Typically includes user-generated files, databases, documents, and other personal or application data. It
may or may not include system files, depending on the backup strategy.

✓ Configuration Image: A configuration image, on the other hand, is focused on preserving the system's
configuration settings, system files, and installed applications. It’s used to quickly restore the system’s
operational state, including network settings, software configurations, and system preferences.

✓ Contains the operating system, installed applications, and their configurations, along with any custom
settings. It serves as a snapshot of the system's environment.
 Problem Management

✓A mechanized problem reporting process is used that ensures efficient

communications for quick resolution of failures and other support requests.
✓A specific user request, sometimes called a "ticket," will typically circulate
between the help desk, software maintenance, and operations in order to isolate a
problem.
✓The IT department provides a large number of IT services to its customers, which are
mainly departments from the sibling organization.
✓To manage the communication with customers regarding those services, the department
has implemented helpdesk management and problem management processes.
Problem Management…

✓The implementation of these processes has been based on the Information Technology
Infrastructure Library (ITIL). ITIL provides a framework for managing IT services
efficiently and effectively, emphasizing the importance of service quality and customer
satisfaction
✓The ITIL process Helpdesk Management is used to guarantee the continuity of services,
while the ITIL process Problem Management is used to improve the level of service in the
future.
✓Helpdesk Management deals with incidents, whereas Problem Management is concerned
with solving the problems that cause these incidents.
 Problem Management Process

The problem management process has many steps, and each is vitally important to the
success of the process and the quality of service delivered.
1. Detect the problem: A problem is raised either through
✓ Appreciation from the service desk
✓ Proactive evaluation of incident patterns and alerts from event management
✓ Continual service improvement processes.
2. Log the problem: Problems are logged in a problem record. A problem record is a compilation of every
problem in an organization. Pertinent problem data, such as the time and date of occurrence, the related
incident, the symptoms, previous troubleshooting steps…
3. Categorize the problem: Incident [and problem] categorization involves assigning a main and secondary category
to the issue. This step is beneficial in several ways.
✓ It allows the service desk to sort and model incidents that occur regularly.
✓ The modeling allows for automatic assignment of prioritization.
✓ The third and most important benefit is the ability to gather and report on service desk data.
Problem Management Process…

4. Prioritize the problem: is determined by its impact on users and on the business and its urgency. Urgency is
how quickly the organization requires a resolution to the problem.

5. Investigating and diagnosing the problem: involves analyzing the incidents that lead to the problem report
as well as further testing that may not be possible at the service desk level, such as advanced log analysis.

6. Identify a workaround for the problem: A workaround enables the service desk to restore services to users
while the problem is being resolved. A problem can take anywhere from an hour to months to resolve,
therefore a workaround is vital.
Problem Management Process…

7. Raise a known error record: It’s good practice to record a known error in both an incident knowledge base
and what ITIL calls a known error database (KEDB). Documenting the workaround allows the service desk to
resolve incidents quickly and avoid further problems being raised on the same issue.
8. Resolve the problem: Resolution resolves the underlying cause of a set of incidents and prevents those
incidents from recurring. Some resolutions may require the change management board, as they may affect
service levels.
9. Close the problem: This step should only occur after the problem has been raised, categorized, prioritized,
identified, diagnosed, and resolved.
10. Review the problem: During the review, the problem management team evaluates the problem
documentation and identifies what happened and why.
✓ Lessons learned, such as process bottlenecks, what went wrong, and what helped should be discussed.
 Maintenance Supporting Tools

✓ Software maintenance tools are programs used by software engineers

✓ To increase their productivity for gathering data
✓ To detecting bugs and
✓ To managing their software.

✓ Without these tools, it would be nearly impossible for these engineers to go through thousands of lines of code
to find errors or determine why a particular server went down.

✓ The software Maintenance supporting tools set provides software engineers can categorized
✓ Supporting maintenance quality enhancement
✓ E.g. Metrics Measurement tool, Programming rule Checker, Redundancy Checker

✓ Support for program repair work

✓ E.g. Structure Analyzer, Maintenance document generator, Impact Analyzer
Maintenance Supporting Tools…

Examples of Software maintenance tools regarding program comprehension include:

✓ Program slicers: which select only parts of a program affected by a change
✓ Version control system example git, Subversion,
✓ Issue tracking system - an incident is defined as an unplanned interruption or reduction in the quality of an IT service. Example jira,
Bugzilla.
✓ Continuous Integration/Continuous Deployment (CI/CD) Tools - Automate the integration and deployment processes, ensuring
that updates are tested and deployed quickly and reliably.Examples: Jenkins, GitLab CI, CircleCI
✓ Static analyzers: which allow general viewing and summaries of a program content example SonarQube, ESLint, PMD
✓ 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.
 Reference

• Alain April, Alain Abran (2008), Software Maintenance Management Evaluation and
Continuous Improvement
• FRANK NIESSINK and HANS VAN VLIET(2000), Software Maintenance from a Service
Perspective, Faculty of Sciences, division of Mathematics and Computer Science, Vrije
Universiteit, De Boelelaan Amsterdam, the Netherlands.
• Pierre Bourque, École de technologie supérieure(2014), Guide to the Software Engineering
Body of Knowledge (SWEBOK) Version 3.0, A Project of the IEEE Computer Society.
• www.techwalla.com/articles/list-of-software-maintenance-tools (Retrieved March 20 2018)
• www.softwaretestingmentor.com/maintenance-testing/(Retrived March 20 2018)
• http://www.bmc.com/guides/itil-problem-management.html(Updated )
 CH-3: Maintenance Measurements

Maintenance Metrics
Maintenance Cost Estimation

✓ To initialize a metrics process, management needs to identify technical factors that reflect
✓ Technical quality
✓ Management quality (i.e., effective use of schedule and resources) of the software being maintained.
✓ Once these factors are identified as indicators, then measures should be developed that correspond to the technical
factors and quantify those technical factors.
✓ It is suggested that the selection of the technical factors and their corresponding metrics /measures be optimized such
that only the factors that are most pertinent to the specific phase of the maintenance process are addressed during that
respective phase of the maintenance process.
 Maintenance Metrics

The objective of Maintenance Measurement and Analysis KPA is

✓To ensure that all of software maintenance's information needs are defined.
✓To specify what measures, analysis techniques, data collecting activities, repositories, and
reports will be used by software maintenance employees, customers, and managers.
Maintenance Metrics…

Goals of this KPA

1. Align data collection and analysis activities.

2. Establish analyses, their informational objectives, and the measures needed
to perform these analyses.
3. Develop data collection processes and processes for their storage in image
data repositories.
4. Communicate maintenance analysis results.
Maintenance Metrics…

Links with Other KPAs

✓Refer to the Maintenance Planning KPA
✓ to learn more about estimating effort for software maintenance activities.
✓Refer to the Requests/Software Monitoring and Control KPA
✓ to learn more about the data required to control and follow up maintenance work items.
✓Refer to the Configuration and Version Management KPA
✓ to learn more about managing maintenance products (including measures).
✓Refer to the Maintenance Process/Service Definition KPA
✓ to learn more about collecting data that lead to establishing maintenance measures.
✓Refer to the Maintenance Training KPA
✓ to learn more about training activities concerning collecting and using measures.
Maintenance Metrics…

Expected Results of this KPA

After the successful implementation of the exemplary practices of this KPA, the
following can be observed:

✓The measures being used meet specific objectives and stem from documented information
needs.
✓Measures and analyses are benchmarked using the industry's exemplary practices.
✓Data collection procedures and instructions are deployed and supported by tools.
✓Useful, specific, and updated reports and analyses are available.
Maintenance metrics…

✓Control complexity: Can be measured by examining the conditional statements in the

program
✓Data complexity: Complexity of data structures and component interfaces.
✓Length of identifier names: Longer names imply readability
✓Program comments: Perhaps more comments mean easier maintenance
✓Coupling: How much use is made of other components or data structures
✓Degree of user interaction: The more user I/O, the more likely the component is to require
change
✓Speed and space requirements: Require tricky programming, harder to maintain
Maintenance Process Metrics

➢Number of requests for corrective maintenance

➢Average time required for impact analysis

➢Average time taken to implement a change request

➢Number of outstanding change requests

➢If any or all of these is increasing, this may indicate a decline in maintainability
 Maintenance Cost Estimation

➢Software maintenance cost is derived from the changes made to software after it has been
delivered to the end user.
➢Software does not “wear out” but it will become less useful as it gets older, plus there
WILL always be issues within the software itself.
Maintenance Cost Estimation…

Maintenance Cost Factors

➢Module independence
✓It should be possible to change one module without affecting others
➢Programming language
✓High-level language programs are easier to maintain
➢Programming style
✓Well-structured programs are easier to maintain
➢Program validation and testing
✓Well-validated programs tend to require fewer changes due to corrective maintenance
➢Hardware stability
✓Programs designed for stable hardware will not require to change as the hardware
changes
Maintenance cost factors…

➢Documentation
✓Good documentation makes programs easier to understand
➢Configuration management
✓Good CM means that links between programs and their documentation are maintained
➢Application domain
✓Maintenance is easier in mature and well-understood application domains
➢Staff stability
✓Maintenance costs are reduced if the same staff are involved with them for some time
 Maintenance Cost Estimation

Figure. Goals, Estimates, and Plans

Table. Software maintenance goals, questions, and metrics.
 Maintenance Cost Estimation…

Estimation Techniques
✓ Estimations are used to analyze and forecast the resources or time necessary to implement requirements.
✓ See Effort, Schedule, and Cost Estimation in the Software Engineering Management KA and Maintenance Cost
Estimation in the Software Maintenance KA.

Five families of estimation techniques exist:

1. Expert judgment
2. Analogies to similar systems
3. Estimation by parts
4. Parametric methods
5. Statistical methods
Maintenance Cost Estimation…

Choice of methodology is dependent upon

➢Type of system
➢Software, hardware, etc
➢Phase of program
➢Development, Production, Support
➢Available data
➢Historical data points from earlier system versions or similar system
➢Technical parameters of system
Estimation Techniques…

1. Expert judgment
Useful in assessing differences between past projects and new ones for which no historical
precedent exists.
Example:
➢ Three software engineers are renown in the ERP software development.
➢ You hold interviews which each explaining the requirements, sizing level, and development
process for your new system.
➢ Each member of the group submits their opinion of the final cost and the estimate converges to
$50M.
Estimation Techniques…

2. Analogies to similar systems

➢Estimates costs by comparing proposed programs with similar, previously completed
programs for which historical data is available.
➢ Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to
derive new cost estimates
➢ Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed
approach
➢ Compares similarities and differences
Estimation Techniques…

Example:
Your company is developing a new IT payroll system serving 5,000 people and containing 100,000 lines of
C++ code.

Another company developed a similar 100,000 lines of code system for $20M for only 2,000 people. Your
software engineers tell you that the new system is 25% more complicated than the other system.

Estimated cost=$62.5M total cost

Cont…
Estimation Techniques…

3. Parametric methods
➢Utilizes statistical techniques called Cost Estimating Relationships (CER).
➢Relates a dependent variable (cost) to one or more independent variables
➢Based on specific factors that have a high correlation to total cost
✓ Number of software lines of code (SLOC) or function points,
✓ Square feet for office floor space,
✓ Number of floors in a high rise building for cabling estimates,
✓ Database size, etc.
Estimation Techniques…

You have a previously developed CER to estimate a new IT system based on

SLOC.
Cost = SLOC * 25 $/SLOC
The CER is based on systems ranging from 1,000,000 to 3,000,000 SLOC.
You have estimated 2,600,000 SLOC for new system
Cost = 2,600,000 * $25 = $65M
Maintenance Cost Estimation…

✓No single estimation technique is perfect, so using multiple estimation technique is useful.
✓Convergence among the estimates produced by different techniques indicates that the
estimates are probably accurate.
✓Spread among the estimates indicates that certain factors might have been overlooked.
✓Finding the factors that caused the spread and then reestimating again to produce results that
converge could lead to a better estimate.
Maintenance Cost Estimation…

Maintenance Project Costs =

Costs of Development of the new Version +

Costs of Correction of the last Version +
Costs of Maintenance Management

✓ Costs of new Version are computed based on the size

of the added function
✓ Costs of correction are based on the number of errors
to correct
 Maintenance Cost Estimation…

Estimation of Correction Costs

1. Counting of Error Reports so far

Version-1 = 16 Error Reports
Version-2 = 12 Error Reports
2. Calculating Efforts of Error Correction so far
Version-1 = 30 Person Days = 1.4 PD per Error
Version-2 = 20 Person Days = 1.6 PD per Error
3. Estimation of Error Reports for the next Version
Version_3 = Number of Errors
4. Estimation of Error Correction Efforts for the next version
Version-3 = ? Person Days = PD per Error x Number of Errors
Reference

✓Alain April, Alain Abran (2008), Software Maintenance Management Evaluation and
Continuous Improvement.
✓Pierre Bourque, École de technologie supérieure(2014), Guide to the Software Engineering
Body of Knowledge (SWEBOK) Version 3.0, A Project of the IEEE Computer Society.