Software Maintenance – Software Engineering

Software Maintenance refers to the process of modifying and updating a

software system after it has been delivered to the customer. This involves
fixing bugs, adding new features, and adapting to new hardware or
software environments. Effective maintenance is crucial for extending the
software’s lifespan and aligning it with evolving user needs. It is an
essential part of the software development life cycle (SDLC), involving
planned and unplanned activities to keep the system reliable and up-to-
date.

What is Software Maintenance?

Software maintenance is a continuous process that occurs throughout the
entire life cycle of the software system.
• The goal of software maintenance is to keep the software system
working correctly, efficiently, and securely, and to ensure that it
continues to meet the needs of the users.
• This can include fixing bugs, adding new features, improving
performance, or updating the software to work with new hardware or
software systems.
• It is also important to consider the cost and effort required for software
maintenance when planning and developing a software system.
• It is important to have a well-defined maintenance process in place,
which includes testing and validation, version control, and
communication with stakeholders.
• It’s important to note that software maintenance can be costly and
complex, especially for large and complex systems. Therefore, the cost
and effort of maintenance should be taken into account during the
planning and development phases of a software project.
• It’s also important to have a clear and well-defined maintenance plan
that includes regular maintenance activities, such as testing, backup,
and bug fixing.
Several Key Aspects of Software Maintenance
1. Bug Fixing: The process of finding and fixing errors and problems in
the software.
2. Enhancements: The process of adding new features or improving
existing features to meet the evolving needs of the users.
3. Performance Optimization: The process of improving the speed,
efficiency, and reliability of the software.
4. Porting and Migration: The process of adapting the software to run
on new hardware or software platforms.
5. Re-Engineering: The process of improving the design and architecture
of the software to make it more maintainable and scalable.
6. Documentation: The process of creating, updating, and maintaining
the documentation for the software, including user manuals, technical
specifications, and design documents.
Several Types of Software Maintenance
1. Corrective Maintenance: This involves fixing errors and bugs in the
software system.
2. Patching: It is an emergency fix implemented mainly due to pressure
from management. Patching is done for corrective maintenance but it
gives rise to unforeseen future errors due to lack of proper impact
analysis.
3. Adaptive Maintenance: This involves modifying the software system
to adapt it to changes in the environment, such as changes in
hardware or software, government policies, and business rules.
4. Perfective Maintenance: This involves improving functionality,
performance, and reliability, and restructuring the software system to
improve changeability.
5. Preventive Maintenance: This involves taking measures to prevent
future problems, such as optimization, updating documentation,
reviewing and testing the system, and implementing preventive
measures such as backups.
Maintenance can be categorized into proactive and reactive types.
Proactive maintenance involves taking preventive measures to avoid
problems from occurring, while reactive maintenance involves addressing
problems that have already occurred.

Maintenance can be performed by different stakeholders, including the

original development team, an in-house maintenance team, or a third-
party maintenance provider. Maintenance activities can be planned or
unplanned. Planned activities include regular maintenance tasks that are
scheduled in advance, such as updates and backups. Unplanned
activities are reactive and are triggered by unexpected events, such as
system crashes or security breaches. Software maintenance can involve
modifying the software code, as well as its documentation, user manuals,
and training materials. This ensures that the software is up-to-date and
continues to meet the needs of its users.
Software maintenance can also involve upgrading the software to a new
version or platform. This can be necessary to keep up with changes in
technology and to ensure that the software remains compatible with other
systems. The success of software maintenance depends on effective
communication with stakeholders, including users, developers, and
management. Regular updates and reports can help to keep stakeholders
informed and involved in the maintenance process.
Software maintenance is also an important part of the Software
Development Life Cycle (SDLC). To update the software application and
do all modifications in software application so as to improve performance
is the main focus of software maintenance. Software is a model that runs
on the basis of the real world. so, whenever any change requires in the
software that means the need for real-world changes wherever possible.
Need for Maintenance
Software Maintenance must be performed in order to:
• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Accommodate programs so that different hardware, software, system
features, and telecommunications facilities can be used.
• Migrate legacy software.
• Retire software.
• Requirement of user changes.
• Run the code fast
Challenges in Software Maintenance
The various challenges in software maintenance are given below:
• The popular age of any software program is taken into consideration up
to ten to fifteen years. As software program renovation is open-ended
and might maintain for decades making it very expensive.
• Older software programs, which had been intended to paint on sluggish
machines with much less reminiscence and garage ability can not
maintain themselves tough in opposition to newly coming more
advantageous software programs on contemporary-day hardware.
• Changes are frequently left undocumented which can also additionally
reason greater conflicts in the future.
• As the era advances, it turns into high prices to preserve vintage
software programs.
• Often adjustments made can without problems harm the authentic
shape of the software program, making it difficult for any next
adjustments.
• There is a lack of Code Comments.
• Lack of documentation: Poorly documented systems can make it
difficult to understand how the system works, making it difficult to
identify and fix problems.
• Legacy code: Maintaining older systems with outdated technologies
can be difficult, as it may require specialized knowledge and skills.
• Complexity: Large and complex systems can be difficult to understand
and modify, making it difficult to identify and fix problems.
• Changing requirements: As user requirements change over time, the
software system may need to be modified to meet these new
requirements, which can be difficult and time-consuming.
• Interoperability issues: Systems that need to work with other systems
or software can be difficult to maintain, as changes to one system can
affect the other systems.
• Lack of test coverage: Systems that have not been thoroughly tested
can be difficult to maintain as it can be hard to identify and fix problems
without knowing how the system behaves in different scenarios.
• Lack of personnel: A lack of personnel with the necessary skills and
knowledge to maintain the system can make it difficult to keep the
system up-to-date and running smoothly.
• High-Cost: The cost of maintenance can be high, especially for large
and complex systems, which can be difficult to budget for and manage.
To overcome these challenges, it is important to have a well-defined
maintenance process in place, which includes testing and validation,
version control, and communication with stakeholders. It is also important
to have a clear and well-defined maintenance plan that includes regular
maintenance activities, such as testing, backup, and bug fixing.
Additionally, it is important to have personnel with the necessary skills and
knowledge to maintain the system.
Categories of Software Maintenance
Maintenance can be divided into the following categories.
• Corrective maintenance: Corrective maintenance of a software
product may be essential either to rectify some bugs observed while
the system is in use, or to enhance the performance of the system.
• Adaptive maintenance: This includes modifications and updations
when the customers need the product to run on new platforms, on new
operating systems, or when they need the product to interface with new
hardware and software.
• Perfective maintenance: A software product needs maintenance to
support the new features that the users want or to change different
types of functionalities of the system according to the customer’s
demands.
• Preventive maintenance: This type of maintenance includes
modifications and updations to prevent future problems with the
software. It goals to attend to problems, which are not significant at this
moment but may cause serious issues in the future.
Reverse Engineering
Reverse Engineering is the process of extracting knowledge or design
information from anything man-made and reproducing it based on the
extracted information. It is also called back engineering. The main
objective of reverse engineering is to check out how the system works.
There are many reasons to perform reverse engineering. Reverse
engineering is used to know how the thing works. Also, reverse
engineering is to recreate the object by adding some enhancements.
Software Reverse Engineering
Software Reverse Engineering is the process of recovering the design
and the requirements specification of a product from an analysis of its
code. Reverse Engineering is becoming important, since several existing
software products, lack proper documentation, are highly unstructured, or
their structure has degraded through a series of maintenance efforts.
Why Reverse Engineering?
• Providing proper system documentation.
• Recovery of lost information.
• Assisting with maintenance.
• The facility of software reuse.
• Discovering unexpected flaws or faults.
• Implements innovative processes for specific use.
• Easy to document the things how efficiency and power can be
improved.
Uses of Software Reverse Engineering
• Software Reverse Engineering is used in software design, reverse
engineering enables the developer or programmer to add new features
to the existing software with or without knowing the source code.
• Reverse engineering is also useful in software testing, it helps the
testers to study or detect the virus and other malware code.
• Software reverse engineering is the process of analyzing and
understanding the internal structure and design of a software system. It
is often used to improve the understanding of a software system, to
recover lost or inaccessible source code, and to analyze the behavior
of a system for security or compliance purposes.
• Malware analysis: Reverse engineering is used to understand how
malware works and to identify the vulnerabilities it exploits, in order to
develop countermeasures.
• Legacy systems: Reverse engineering can be used to understand
and maintain legacy systems that are no longer supported by the
original developer.
• Intellectual property protection: Reverse engineering can be used to
detect and prevent intellectual property theft by identifying and
preventing the unauthorized use of code or other assets.
• Security: Reverse engineering is used to identify security
vulnerabilities in a system, such as backdoors, weak encryption, and
other weaknesses.
• Compliance: Reverse engineering is used to ensure that a system
meets compliance standards, such as those for accessibility, security,
and privacy.
• Reverse-engineering of proprietary software: To understand how a
software works, to improve the software, or to create new software with
similar features.
• Reverse-engineering of software to create a competing product:
To create a product that functions similarly or to identify the features
that are missing in a product and create a new product that
incorporates those features.
• It’s important to note that reverse engineering can be a complex and
time-consuming process, and it is important to have the necessary
skills, tools, and knowledge to perform it effectively. Additionally, it is
important to consider the legal and ethical implications of reverse
engineering, as it may be illegal or restricted in some jurisdictions.
Advantages of Software Maintenance
• Improved Software Quality: Regular software maintenance helps to
ensure that the software is functioning correctly and efficiently and that
it continues to meet the needs of the users.
• Enhanced Security: Maintenance can include security updates and
patches, helping to ensure that the software is protected against
potential threats and attacks.
• Increased User Satisfaction: Regular software maintenance helps to
keep the software up-to-date and relevant, leading to increased user
satisfaction and adoption.
• Extended Software Life: Proper software maintenance can extend the
life of the software, allowing it to be used for longer periods of time and
reducing the need for costly replacements.
• Cost Savings: Regular software maintenance can help to prevent
larger, more expensive problems from occurring, reducing the overall
cost of software ownership.
• Better Alignment with business goals: Regular software
maintenance can help to ensure that the software remains aligned with
the changing needs of the business. This can help to improve overall
business efficiency and productivity.
• Competitive Advantage: Regular software maintenance can help to
keep the software ahead of the competition by improving functionality,
performance, and user experience.
• Compliance with Regulations: Software maintenance can help to
ensure that the software complies with relevant regulations and
standards. This is particularly important in industries such as
healthcare, finance, and government, where compliance is critical.
• Improved Collaboration: Regular software maintenance can help to
improve collaboration between different teams, such as developers,
testers, and users. This can lead to better communication and more
effective problem-solving.
• Reduced Downtime: Software maintenance can help to reduce
downtime caused by system failures or errors. This can have a positive
impact on business operations and reduce the risk of lost revenue or
customers.
• Improved Scalability: Regular software maintenance can help to
ensure that the software is scalable and can handle increased user
demand. This can be particularly important for growing businesses or
for software that is used by a large number of users.
Disadvantages of Software Maintenance
• Cost: Software maintenance can be time-consuming and expensive,
and may require significant resources and expertise.
• Schedule disruptions: Maintenance can cause disruptions to the
normal schedule and operations of the software, leading to potential
downtime and inconvenience.
• Complexity: Maintaining and updating complex software systems can
be challenging, requiring specialized knowledge and expertise.
• Risk of introducing new bugs: The process of fixing bugs or adding new
features can introduce new bugs or problems, making it important to
thoroughly test the software after maintenance.
• User resistance: Users may resist changes or updates to the
software, leading to decreased satisfaction and adoption.
• Compatibility issues: Maintenance can sometimes cause
compatibility issues with other software or hardware, leading to
potential integration problems.
• Lack of documentation: Poor documentation or lack of
documentation can make software maintenance more difficult and
time-consuming, leading to potential errors or delays.
• Technical debt: Over time, software maintenance can lead to
technical debt, where the cost of maintaining and updating the software
becomes increasingly higher than the cost of developing a new system.
• Skill gaps: Maintaining software systems may require specialized
skills or expertise that may not be available within the organization,
leading to potential outsourcing or increased costs.
• Inadequate testing: Inadequate testing or incomplete testing after
maintenance can lead to errors, bugs, and potential security
vulnerabilities.
• End-of-life: Eventually, software systems may reach their end-of-life,
making maintenance and updates no longer feasible or cost-effective.
This can lead to the need for a complete system replacement, which
can be costly and time-consuming.
System configuration management
Whenever software is built, there is always scope for improvement and those
improvements bring picture changes. Changes may be required to modify or
update any existing solution or to create a new solution for a problem.
Requirements keep on changing daily so we need to keep on upgrading our
systems based on the current requirements and needs to meet desired outputs.
Changes should be analyzed before they are made to the existing system, recorded
before they are implemented, reported to have details of before and after, and
controlled in a manner that will improve quality and reduce error. This is where the
need for System Configuration Management comes. System Configuration
Management (SCM) is an arrangement of exercises that controls change by
recognizing the items for change, setting up connections between those things,
making/characterizing instruments for overseeing diverse variants, controlling the
changes being executed in the current framework, inspecting and
revealing/reporting on the changes made. It is essential to control the changes
because if the changes are not checked legitimately then they may wind up
undermining a well-run programming. In this way, SCM is a fundamental piece of
all project management activities.
It uses the tools which keep that the necessary change has been implemented adequately to
the appropriate component. The SCM process defines a number of tasks:
o Identification of objects in the software configuration
o Version Control
o Change Control
o Configuration Audit
o Status Reporting
Processes involved in SCM – Configuration management provides a disciplined
environment for smooth control of work products. It involves the following
activities:
1. Identification and Establishment – Identifying the configuration items from
products that compose baselines at given points in time (a baseline is a set of
mutually consistent Configuration Items, which has been formally reviewed
and agreed upon, and serves as the basis of further development). Establishing
relationships among items, creating a mechanism to manage multiple levels of
control and procedure for the change management system.
2. Version control – Creating versions/specifications of the existing product to
build new products with the help of the SCM system. A description of the
version is given below:Suppose after some changes, the version of the
configuration object changes from 1.0 to 1.1. Minor corrections and changes
result in versions 1.1.1 and 1.1.2, which is followed by a major update that is
object 1.2. The development of object 1.0 continues through 1.3 and 1.4, but
finally, a noteworthy change to the object results in a new evolutionary path,
version 2.0. Both versions are currently supported.

3. Change control – Controlling

 changes to Configuration items (CI). The change control process is explained in
Figure below:

4. A change request (CR) is submitted and evaluated to assess technical merit,

potential side effects, the overall impact on other configuration objects and
system functions, and the projected cost of the change. The results of the
evaluation are presented as a change report, which is used by a change control
board (CCB) —a person or group who makes a final decision on the status and
priority of the change. An engineering change Request (ECR) is generated for
each approved change. Also, CCB notifies the developer in case the change is
rejected with proper reason. The ECR describes the change to be made, the
constraints that must be respected, and the criteria for review and audit. The
object to be changed is “checked out” of the project database, the change is
made, and then the object is tested again. The object is then “checked in” to the
database and appropriate version control mechanisms are used to create the next
version of the software.
4. Configuration auditing – A software configuration audit complements the
formal technical review of the process and product. It focuses on the technical
correctness of the configuration object that has been modified. The audit
confirms the completeness, correctness, and consistency of items in the SCM
system and tracks action items from the audit to closure.
5. Reporting – Providing accurate status and current configuration data to
developers, testers, end users, customers, and stakeholders through admin
 guides, user guides, FAQs, Release notes, Memos, Installation Guide,
Configuration guides, etc.
System Configuration Management (SCM) is a software engineering practice that
focuses on managing the configuration of software systems and ensuring that
software components are properly controlled, tracked, and stored. It is a critical
aspect of software development, as it helps to ensure that changes made to a
software system are properly coordinated and that the system is always in a known
and stable state.
SCM involves a set of processes and tools that help to manage the different
components of a software system, including source code, documentation, and other
assets. It enables teams to track changes made to the software system, identify
when and why changes were made, and manage the integration of these changes
into the final product.
Importance of Software Configuration Management
1. Effective Bug Tracking: Linking code modifications to issues that have
been reported, makes bug tracking more effective.
2. Continuous Deployment and Integration: SCM combines with
continuous processes to automate deployment and testing, resulting in
more dependable and timely software delivery.
3. Risk management: SCM lowers the chance of introducing critical flaws
by assisting in the early detection and correction of problems.
4. Support for Big Projects: Source Code Control (SCM) offers an orderly
method to handle code modifications for big projects, fostering a well-
organized development process.
5. Reproducibility: By recording precise versions of code, libraries, and
dependencies, source code versioning (SCM) makes builds
repeatable.
6. Parallel Development: SCM facilitates parallel development by
enabling several developers to collaborate on various branches at
once.
Why need for System configuration management?
1. Replicability: Software version control (SCM) makes ensures that a
software system can be replicated at any stage of its development.
This is necessary for testing, debugging, and upholding consistent
environments in production, testing, and development.
2. Identification of Configuration: Source code, documentation, and
executable files are examples of configuration elements that SCM
helps in locating and labeling. The management of a system’s
constituent parts and their interactions depend on this identification.
3. Effective Process of Development: By automating monotonous
processes like managing dependencies, merging changes, and
resolving disputes, SCM simplifies the development process. Error risk
is decreased and efficiency is increased because of this automation.
Key objectives of SCM
1. Control the evolution of software systems: SCM helps to ensure
that changes to a software system are properly planned, tested, and
integrated into the final product.
2. Enable collaboration and coordination: SCM helps teams to
collaborate and coordinate their work, ensuring that changes are
properly integrated and that everyone is working from the same version
of the software system.
3. Provide version control: SCM provides version control for software
systems, enabling teams to manage and track different versions of the
system and to revert to earlier versions if necessary.
4. Facilitate replication and distribution: SCM helps to ensure that
software systems can be easily replicated and distributed to other
environments, such as test, production, and customer sites.
5. SCM is a critical component of software development, and effective
SCM practices can help to improve the quality and reliability of
software systems, as well as increase efficiency and reduce the risk of
errors.
The main advantages of SCM
1. Improved productivity and efficiency by reducing the time and effort
required to manage software changes.
2. Reduced risk of errors and defects by ensuring that all changes were
properly tested and validated.
3. Increased collaboration and communication among team members by
providing a central repository for software artifacts.
4. Improved quality and stability of software systems by ensuring that all
changes are properly controlled and managed.
The main disadvantages of SCM
1. Increased complexity and overhead, particularly in large software
systems.
2. Difficulty in managing dependencies and ensuring that all changes are
properly integrated.
3. Potential for conflicts and delays, particularly in large development
teams with multiple contributors.

Program Comprehension Techniques

Program Comprehension is the process of gaining new or regaining lost
knowledge about a computer program. Due to the generic nature of program
understanding and the fact that some level of program understanding is a
prerequisite for virtually every software-development activity, we will further
refine it into more specific activities. Program comprehension starts at the level
of code (Program-Code Understanding) and then attempts to raise the level of
abstraction to design (Design Recovery) and application domain (Domain
Analysis). Program-Code Understanding subsumes tasks such as Program-
Concept Assignment or Feature Location.
Program-Concept Assignment: If a developer needs to understand the behavior
and purpose of a given piece of code, he or she needs to determine the
underlying programming concept the given code implements, for instance, what
kind of sorting algorithm the code implements. Program-Concept Assignment at
the level of code is exactly this process: mapping a piece of code onto a
programming concept. Knowing clones can help in assigning program concepts:
if a developer already understood a piece of code, she or he can detect other
similar pieces of that code that perform similar functions [56] (Clone
Conceptualization). For example, when we have a code fragment containing a
search algorithm, we can infer that all files that contain a copy of this code also
perform some kind of search. Knowing the syntactic differences among the
found clone instances as well as the differences in the contexts in which they are
contained (Clone Differencing) allows one to determine the differences among
similar programming-concepts implementations.
Feature Location: While Program-Concept Assignment starts at a given piece
of code and tries to figure out the feature it implements, Feature Location is the
reverse process. Here a developer searches for pieces of code that implement a
given feature of interest, for instance, to fix a bug of that feature. If a developer
searches for a feature 𝑓 and already knows that a piece of code 𝑐 implements a
feature 𝑓′ similar to 𝑓, she or he can search for code similar to 𝑐 (Clone Class
Detection within Program Unit) and inspect the differences of the cloned
content as well as the differences in the respective contexts the two pieces of
code are embedded (Clone Differencing). Although Program-Concept
Assignment and Feature Location are inverse to each other, the potential
contribution of clone detection to these and, hence, the information needs
specific to cloning are the same.
Design Recovery: Research shows that bigger program structures that have
been cloned often mark the presence of higher-level design concepts in a
program [54]. Finding such repetitions (All-Clone Detection within Unit) along
with their differences in representation and context (Clone Differencing) to form
higher-level clones can aid in Design Recovery, which is the process of
examining program code to find significant design information or abstractions
(Clone Conceptualization). Such higher-level clones may be formed by
relations among clone classes (N32 in Clone Linkage). Knowing clones may
also help in architecture recovery in software-product lines based on the
reflexion method [57] where existing reverse engineered mappings of cloned
code onto architecture components may be re-used across variants [58].
Domain Analysis often involves analyzing commonalities and variabilities in
software systems in a given domain. Clones found across systems signify
commonalities in the domain [59]. The relevant information needs for this user
goal are to locate all clone classes across systems in a given domain (N3) and
identifying how these systems and their clones differ from each other (Clone
Differencing). Typically, a Design Recovery process is required in advance to
find domain concepts at a higher level of abstraction (Clone Conceptualization),
such that all information needs for Design Recovery are relevant for Domain
Analysis, too.

Re-engineering
Software Re-engineering is a process of software development that is
done to improve the maintainability of a software system. Re-engineering
is the examination and alteration of a system to reconstitute it in a new
form. This process encompasses a combination of sub-processes like
reverse engineering, forward engineering, reconstructing, etc.

What is Re-engineering?
Re-engineering, also known as software re-engineering, is the process of
analyzing, designing, and modifying existing software systems to improve
their quality, performance, and maintainability.
1. This can include updating the software to work with new hardware or
software platforms, adding new features, or improving the software’s
overall design and architecture.
2. Software re-engineering, also known as software restructuring or
software renovation, refers to the process of improving or upgrading
existing software systems to improve their quality, maintainability, or
functionality.
3. It involves reusing the existing software artifacts, such as code, design,
and documentation, and transforming them to meet new or updated
requirements.
Objective of Re-engineering
The primary goal of software re-engineering is to improve the quality and
maintainability of the software system while minimizing the risks and costs
associated with the redevelopment of the system from scratch. Software
re-engineering can be initiated for various reasons, such as:
Process of Software Re-engineering
The process of software re-engineering involves the following steps:

Process of Software Re-engineering

1. Planning: The first step is to plan the re-engineering process, which

involves identifying the reasons for re-engineering, defining the scope,
and establishing the goals and objectives of the process.
2. Analysis: The next step is to analyze the existing system, including
the code, documentation, and other artifacts. This involves identifying
the system’s strengths and weaknesses, as well as any issues that
need to be addressed.
3. Design: Based on the analysis, the next step is to design the new or
updated software system. This involves identifying the changes that
need to be made and developing a plan to implement them.
4. Implementation: The next step is to implement the changes by
modifying the existing code, adding new features, and updating the
documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software
system needs to be tested to ensure that it meets the new
requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered software
system and make it available to end-users.
Why Perform Re-engineering?
Re-engineering can be done for a variety of reasons, such as:
1. To improve the software’s performance and scalability: By
analyzing the existing code and identifying bottlenecks, re-engineering
can be used to improve the software’s performance and scalability.
2. To add new features: Re-engineering can be used to add new
features or functionality to existing software.
3. To support new platforms: Re-engineering can be used to update
existing software to work with new hardware or software platforms.
4. To improve maintainability: Re-engineering can be used to improve
the software’s overall design and architecture, making it easier to
maintain and update over time.
5. To meet new regulations and compliance: Re-engineering can be
done to ensure that the software is compliant with new regulations and
standards.
6. Improving software quality: Re-engineering can help improve the
quality of software by eliminating defects, improving performance, and
enhancing reliability and maintainability.
7. Updating technology: Re-engineering can help modernize the
software system by updating the technology used to develop, test, and
deploy the system.
8. Enhancing functionality: Re-engineering can help enhance the
functionality of the software system by adding new features or
improving existing ones.
9. Resolving issues: Re-engineering can help resolve issues related to
scalability, security, or compatibility with other systems.
Steps involved in Re-engineering
1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering
 Steps of Re-Engineering

Re-engineering Cost Factors

1. The quality of the software to be re-engineered.
2. The tool support available for re-engineering.
3. The extent of the required data conversion.
4. The availability of expert staff for re-engineering.
Factors Affecting Cost of Re-engineering
Re-engineering can be a costly process, and there are several
factors that can affect the cost of re-engineering a software system:
1. Size and complexity of the software: The larger and more complex
the software system, the more time and resources will be required to
analyze, design, and modify it.
2. Number of features to be added or modified: The more features that
need to be added or modified, the more time and resources will be
required.
3. Tools and technologies used: The cost of re-engineering can be
affected by the tools and technologies used, such as the cost
of software development tools and the cost of hardware and
infrastructure.
4. Availability of documentation: If the documentation of the existing
system is not available or is not accurate, then it will take more time
and resources to understand the system.
5. Team size and skill level: The size and skill level of the development
team can also affect the cost of re-engineering. A larger and more
 experienced team may be able to complete the project faster and with
fewer resources.
6. Location and rate of the team: The location and rate of the
development team can also affect the cost of re-engineering. Hiring a
team in a lower-cost location or with lower rates can help to reduce the
cost of re-engineering.
7. Testing and quality assurance: Testing and quality assurance are
important aspects of re-engineering, and they can add significant costs
to the project.
8. Post-deployment maintenance: The cost of post-deployment
maintenance such as bug fixing, security updates, and feature
additions can also play a role in the cost of re-engineering.
In summary, the cost of re-engineering a software system can vary
depending on a variety of factors, including the size and complexity of the
software, the number of features to be added or modified, the tools and
technologies used, and the availability of documentation and the skill level
of the development team. It’s important to carefully consider these factors
when estimating the cost of re-engineering a software system.
Advantages of Re-engineering
1. Reduced Risk: As the software is already existing, the risk is less as
compared to new software development. Development problems,
staffing problems and specification problems are the lots of problems
that may arise in new software development.
2. Reduced Cost: The cost of re-engineering is less than the costs of
developing new software.
3. Revelation of Business Rules: As a system is re-engineered ,
business rules that are embedded in the system are rediscovered.
4. Better use of Existing Staff: Existing staff expertise can be
maintained and extended accommodate new skills during re-
engineering.
5. Improved efficiency: By analyzing and redesigning processes, re-
engineering can lead to significant improvements in productivity,
speed, and cost-effectiveness.
6. Increased flexibility: Re-engineering can make systems more
adaptable to changing business needs and market conditions.
7. Better customer service: By redesigning processes to focus on
customer needs, re-engineering can lead to improved customer
satisfaction and loyalty.
8. Increased competitiveness: Re-engineering can help organizations
become more competitive by improving efficiency, flexibility, and
customer service.
9. Improved quality: Re-engineering can lead to better quality products
and services by identifying and eliminating defects and inefficiencies in
processes.
10. Increased innovation: Re-engineering can lead to new and
innovative ways of doing things, helping organizations to stay ahead of
their competitors.
11. Improved compliance: Re-engineering can help organizations to
comply with industry standards and regulations by identifying and
addressing areas of non-compliance.
Disadvantages of Re-engineering
Major architectural changes or radical reorganizing of the systems data
management has to be done manually. Re-engineered system is not likely
to be as maintainable as a new system developed using modern software
Re-engineering methods.
1. High costs: Re-engineering can be a costly process, requiring
significant investments in time, resources, and technology.
2. Disruption to business operations: Re-engineering can disrupt
normal business operations and cause inconvenience to customers,
employees and other stakeholders.
3. Resistance to change: Re-engineering can encounter resistance from
employees who may be resistant to change and uncomfortable with
new processes and technologies.
4. Risk of failure: Re-engineering projects can fail if they are not planned
and executed properly, resulting in wasted resources and lost
opportunities.
5. Lack of employee involvement: Re-engineering projects that are not
properly communicated and involve employees, may lead to lack of
employee engagement and ownership resulting in failure of the project.
6. Difficulty in measuring success: Re-engineering can be difficult to
measure in terms of success, making it difficult to justify the cost and
effort involved.
7. Difficulty in maintaining continuity: Re-engineering can lead to
significant changes in processes and systems, making it difficult to
maintain continuity and consistency in the organization.

difference between Reverse and Re-Engineering in very simple

terms. But before diving deep into these terms, let’s understand a
very basic definition of Software Engineering

What is Software Engineering?

It is a branch of Computer Science which deals with the design,
development, testing, deployment and maintenance of a software
application. Software engineering enables to build real world
software solutions for the end users or customers.

After having a brief understanding of Software Engineering, let’s

understand Re-Engineering first.

Re — Engineering

1. It is a process to re design a product or a particular component

2. It is also called as software refactoring

3. It is like a modification of the existing product to improve its

performance, maintainability and adaptability

4. It is a cost effective method as a part of the software is altered

instead of the entire product

5. Less coding knowledge is required for re-engineering

6. This practice is generally followed for safety issues or to update a

new feature into the product’s existing functionality

7. Re-engineering takes less time in comparison to Reverse

Engineering

Why is Re-Engineering required

1. To adapt to changing business needs: As business
requirements changes, it is important to re-structure the
software to support new technology

2. To improve quality of software: Re engineering can help

identify and rectify errors and defects, thus making the software
robust and reliable

3. To modernize the software: As technology is dynamic and is

constantly changing, it is important to keep the software updated
which can be achieved via the process of re-engineering

Reverse Engineering

1. It is a process of deconstructing a product to see how it actually

works

2. It is also known as backward engineering

3. In this, the product is broken down to see its functionality and is

then recreated to bring something new out of it

4. It is an expensive method as the entire product is rebuilt

5. It requires prior coding knowledge regarding the software

followed by knowledge of system components and their
relationship

6. This practice is generally followed by companies to evaluate their

competitor’s latest inventions and get something better out of it
7. This process comparatively takes more time as the product is
created from scratch

Why is Reverse Engineering required

1. To find how a system works: Reverse engineering helps in

an in-depth analysis of the entire product and can be used to
learn how things work

2. As a learning tool: It is a way to make new and compatible

products that might be cheaper than what’s currently in the
market

3. To uncover features: Reverse engineering helps to unveil

some undocumented features of commercial products that might
be incorporated while building the entire product from start

Cost and Schedule Estimating Process

Cost estimation simply means a technique that is used to find out the
cost estimates. The cost estimate is the financial spend that is done on
the efforts to develop and test software in Software Engineering. Cost
estimation models are some mathematical algorithms or parametric
equations that are used to estimate the cost of a product or a project.
Various techniques or models are available for cost estimation, also
known as Cost Estimation Models.
Cost Estimation Models as shown below :
 Cost
Estimation Models

1. Empirical Estimation Technique – Empirical estimation is a

technique or model in which empirically derived formulas are used for
predicting the data that are a required and essential part of the
software project planning step. These techniques are usually based on
the data that is collected previously from a project and also based on
some guesses, prior experience with the development of similar types
of projects, and assumptions. It uses the size of the software to
estimate the effort. In this technique, an educated guess of project
parameters is made. Hence, these models are based on common
sense. However, as there are many activities involved in empirical
estimation techniques, this technique is formalized. For example Delphi
technique and Expert Judgement technique.

2. Heuristic Technique – Heuristic word is derived from a Greek word

that means “to discover”. The heuristic technique is a technique or
model that is used for solving problems, learning, or discovery in the
practical methods which are used for achieving immediate goals.
These techniques are flexible and simple for taking quick decisions
through shortcuts and good enough calculations, most probably when
working with complex data. But the decisions that are made using this
technique are necessary to be optimal. In this technique, the
relationship among different project parameters is expressed using
mathematical equations. The popular heuristic technique is given
by Constructive Cost Model (COCOMO). This technique is also used
to increase or speed up the analysis and investment decisions.

3. Analytical Estimation Technique – Analytical estimation is a type of

technique that is used to measure work. In this technique, firstly the
task is divided or broken down into its basic component operations or
elements for analyzing. Second, if the standard time is available from
some other source, then these sources are applied to each element or
 component of work. Third, if there is no such time available, then the
work is estimated based on the experience of the work. In this
technique, results are derived by making certain basic assumptions
about the project. Hence, the analytical estimation technique has some
scientific basis. Halstead’s software science is based on an analytical
estimation model.
Other Cost Estimation Models
1. Function Point Analysis (FPA): This technique counts the number
and complexity of functions that a piece of software can perform to
determine how functional and sophisticated it is. The effort needed for
development, testing and maintenance can be estimated using this
model.
2. Putnam Model: This model is a parametric estimation model that
estimates effort, time and faults by taking into account the size of the
the programme, the expertise of the development team and other
project-specific characteristics.
3. Price-to-Win Estimation: Often utilized in competitive bidding, this
model is concerned with projecting the expenses associated with
developing a particular software project in order to secure a contract. It
involves looking at market dynamics and competitors.
4. Models Based on Machine Learning: Custom cost estimating models
can be built using machine learning techniques including neural
networks, regression analysis and decision trees. These models are
based on past project data. These models are flexible enough to adjust
to changing data and project-specific features.
5. Function Points Model (IFPUG): A standardized technique for
gauging the functionality of software using function points is offered by
the International Function Point Users Group (IFPUG). It is employed
to calculate the effort required for software development and
maintenance.
COCOMO Model – Software Engineering
The Constructive Cost Model (COCOMO) is a software cost estimation
model that helps predict the effort, cost, and schedule required for a
software development project. Developed by Barry Boehm in 1981,
COCOMO uses a mathematical formula based on the size of the software
project, typically measured in lines of code (LOC).

What is the COCOMO Model?

The COCOMO Model is a procedural cost estimate model for software
projects and is often used as a process of reliably predicting the various
parameters associated with making a project such as size, effort, cost,
time, and quality. It was proposed by Barry Boehm in 1981 and is based
on the study of 63 projects, which makes it one of the best-documented
models.
The key parameters that define the quality of any software product, which
are also an outcome of COCOMO, are primarily effort and schedule:
1. Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
2. Schedule: This simply means the amount of time required for the
completion of the job, which is, of course, proportional to the effort put
in. It is measured in the units of time such as weeks, and months.
Types of Projects in the COCOMO Model
In the COCOMO model, software projects are categorized into three types
based on their complexity, size, and the development environment. These
types are:
1. Organic: A software project is said to be an organic type if the team
size required is adequately small, the problem is well understood and
has been solved in the past and also the team members have a
nominal experience regarding the problem.
2. Semi-detached: A software project is said to be a Semi-detached type
if the vital characteristics such as team size, experience, and
knowledge of the various programming environments lie in between
organic and embedded. The projects classified as Semi-Detached are
comparatively less familiar and difficult to develop compared to the
organic ones and require more experience better guidance and
creativity. Eg: Compilers or different Embedded Systems can be
considered Semi-Detached types.
3. Embedded: A software project requiring the highest level of
complexity, creativity, and experience requirement falls under this
category. Such software requires a larger team size than the other two
models and also the developers need to be sufficiently experienced
and creative to develop such complex models.
Comparison of these three types of Projects in COCOMO Model
Aspects Organic Semidetached Embedded

300 and above

2 to 50 KLOC 50-300 KLOC
Project Size KLOC

Complexity Low Medium High

Some experienced as Mixed

Team Highly
well as inexperienced experience,
experienced
Experience staff includes experts
 Aspects Organic Semidetached Embedded

Highly rigorous,
Flexible, fewer Somewhat flexible,
strict
constraints moderate constraints
Environment requirements

Effort E=
E = 3.0(400)1.12 E = 3.6(400)1.20
Equation 2.4(400)1.05

Simple payroll New system interfacing Flight control

Example system with existing systems software

Detailed Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate
version with an assessment of the cost driver’s impact on each step of the
software engineering process. The detailed model uses different effort
multipliers for each cost driver attribute. In detailed COCOMO, the whole
software is divided into different modules and then we apply COCOMO in
different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
 Phases of COCOMO Model

Different models of COCOMO have been proposed to predict the cost

estimation at different levels, based on the amount of accuracy and
correctness required. All of these models can be applied to a variety of
projects, whose characteristics determine the value of the constant to be
used in subsequent calculations. These characteristics of different system
types are mentioned below. Boehm’s definition of organic, semidetached,
and embedded systems:
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project
budgeting, COCOMO offers a methodical approach to software
development cost estimation.
2. Resource Management: By taking team experience, project size, and
complexity into account, the model helps with efficient resource
allocation.
3. Project Planning: COCOMO assists in developing practical project
plans that include attainable objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO
assists in identifying and mitigating potential hazards by including risk
elements.
5. Support for Decisions: During project planning, the model provides a
quantitative foundation for choices about scope, priorities, and
resource allocation.
6. Benchmarking: To compare and assess various software
development projects to industry standards, COCOMO offers a
benchmark.
7. Resource Optimization: The model helps to maximize the use of
resources, which raises productivity and lowers costs.
Types of COCOMO Model
There are three types of COCOMO Model:
• Basic COCOMO Model
• Intermediate COCOMO Model
• Detailed COCOMO Model
1. Basic COCOMO Model
The Basic COCOMO model is a straightforward way to estimate the effort
needed for a software development project. It uses a simple mathematical
formula to predict how many person-months of work are required based
on the size of the project, measured in thousands of lines of code (KLOC).
It estimates effort and time required for development using the following
expression:
E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate in Kilo Lines
of Code
Tdev is the development time in months
a, b, c are constants determined by the category of software project given
in below table.
The above formula is used for the cost estimation of the basic COCOMO
model and also is used in the subsequent models. The constant values a,
b, c, and d for the Basic Model for the different categories of the software
projects are:
Software
Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-
3.0 1.12 2.5 0.35
Detached

Embedded 3.6 1.20 2.5 0.32

1. The effort is measured in Person-Months and as evident from the

formula is dependent on Kilo-Lines of code. The development time is
measured in months.
2. These formulas are used as such in the Basic Model calculations, as
not much consideration of different factors such as reliability, and
expertise is taken into account, henceforth the estimate is rough.
Example of Basic COCOMO Model
Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of
code). Calculate effort and time for each of the three modes of
development. All the constants value provided in the following table:
Solution
From the above table we take the value of constant a,b,c and d.
1. For organic mode,
• effort = 2.4 × (400)1.05 ≈ 1295 person-month.
• dev. time = 2.5 × (1295)0.38 ≈ 38 months.
2. For semi-detach mode,
• effort = 3 × (400)1.12 ≈ 2462 person-month.
• dev. time = 2.5 × (2462)0.35 ≈ 38 months.
3. For Embedded mode,
• effort = 3.6 × (400)1.20 ≈ 4772 person-month.
• dev. time = 2.5 × (4772)0.32 ≈ 38 months.
Below are the programs for Basic COCOMO Model:
// C++ program to implement basic COCOMO
#include <bits/stdc++.h>

using namespace std;

// Function For rounding off float to int
int fround(float x)
{
int a;
x = x + 0.5;
a = x;
return (a);
}

// Function to calculate parameters

// of Basic COCOMO
void calculate(float table[][4], int n,
char mode[][15], int size)
{
float effort, time, staff;

int model;

// Check the mode according to size

// organic
if (size >= 2 && size <= 50)
model = 0;

// semi-detached
else if (size > 50 && size <= 300)
model = 1;

// embedded
else if (size > 300)
model = 2;
 cout << "The mode is " << mode[model];

// Calculate Effort
effort = table[model][0] * pow(size,
table[model][1]);

// Calculate Time
time = table[model][2] * pow(effort,
table[model][3]);

// Calculate Persons Required

staff = effort / time;

// Output the values calculated

cout << "\nEffort = " << effort <<
" Person-Month";

cout << "\nDevelopment Time = " << time <<

" Months";

cout << "\nAverage Staff Required = " <<

fround(staff) << " Persons";
}

// Driver code
int main()
{
float table[3][4] = {2.4, 1.05, 2.5, 0.38, 3.0, 1.12,
2.5, 0.35, 3.6, 1.20, 2.5, 0.32};
 char mode[][15]
= {"Organic", "Semi-Detached", "Embedded"};

int size = 4;

calculate(table, 3, mode, size);

return 0;
}
Output
The mode is Organic
Effort = 10.289 Person-Month
Development Time = 6.06237 Months
Average Staff Required = 2 Persons
2. Intermediate COCOMO Model
The basic COCOMO model assumes that the effort is only a function of
the number of lines of code and some constants evaluated according to
the different software systems. However, in reality, no system’s effort and
schedule can be solely calculated based on Lines of Code. For that,
various other factors such as reliability, experience, and Capability. These
factors are known as Cost Drivers (multipliers) and the Intermediate
Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their Attributes:
The cost drivers are divided into four categories
Product attributes:
• Required software reliability extent
• Size of the application database
• The complexity of the product
Hardware attributes
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
Personal attributes
• Analyst capability
• Software engineering capability
• Application experience
• Virtual machine experience
• Programming language experience
Project attributes
• Use of software tools
• Application of software engineering methods
• Required development schedule
Each of the 15 such attributes can be rated on a six-point scale ranging
from “very low” to “extra high” in their relative order of importance. Each
attribute has an effort multiplier fixed as per the rating. Table give below
represents Cost Drivers and their respective rating:
The Effort Adjustment Factor (EAF) is determined by multiplying the
effort multipliers associated with each of the 15 attributes.
The Effort Adjustment Factor (EAF) is employed to enhance the estimates
generated by the basic COCOMO model in the following expression:
Intermediate COCOMO Model equation:
E = a*(KLOC)b * EAF PM
Tdev = c*(E)d
Where,
• E is effort applied in Person-Months
• KLOC is the estimated size of the software product indicate in Kilo
Lines of Code
• EAF is the Effort Adjustment Factor (EAF) is a multiplier used to refine
the effort estimate obtained from the basic COCOMO model.
• Tdev is the development time in months
• a, b, c are constants determined by the category of software project
given in below table.
The constant values a, b, c, and d for the Basic Model for the different
categories of the software projects are:
Software
Projects a b c d

Organic 3.2 1.05 2.5 0.38

Semi-
3.0 1.12 2.5 0.35
Detached

Embedded 2.8 1.20 2.5 0.32

3. Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by
diving deeper into project-specific factors. It considers a wider range of
parameters, like team experience, development practices, and software
complexity. By analyzing these factors in more detail, Detailed COCOMO
provides a highly accurate estimation of effort, time, and cost for software
projects. It’s like zooming in on a project’s unique characteristics to get a
clearer picture of what it will take to complete it successfully.
CASE Studies and Examples
1. NASA Space Shuttle Software Development: NASA estimated the
time and money needed to build the software for the Space Shuttle
program using the COCOMO model. NASA was able to make well-
informed decisions on resource allocation and project scheduling by
taking into account variables including project size, complexity, and
team experience.
2. Big Business Software Development: The COCOMO model has
been widely used by big businesses to project the time and money
needed to construct intricate business software systems. These
organizations were able to better plan and allocate resources for their
software projects by using COCOMO’s estimation methodology.
3. Commercial Software goods: The COCOMO methodology has
proven advantageous for software firms that create commercial goods
as well. These businesses were able to decide on pricing, time-to-
market, and resource allocation by precisely calculating the time and
expense of building new software products or features.
4. Academic Research Initiatives: To estimate the time and expense
required to create software prototypes or carry out experimental
studies, academic research initiatives have employed COCOMO.
Researchers were able to better plan their projects and allocate
resources by using COCOMO’s estimate approaches.
Advantages of the COCOMO Model
1. Systematic cost estimation: Provides a systematic way to estimate
the cost and effort of a software project.
2. Helps to estimate cost and effort: This can be used to estimate the
cost and effort of a software project at different stages of the
development process.
3. Helps in high-impact factors: Helps in identifying the factors that
have the greatest impact on the cost and effort of a software project.
4. Helps to evaluate the feasibility of a project: This can be used to
evaluate the feasibility of a software project by estimating the cost and
effort required to complete it.
Disadvantages of the COCOMO Model
1. Assumes project size as the main factor: Assumes that the size of
the software is the main factor that determines the cost and effort of a
software project, which may not always be the case.
2. Does not count development team-specific characteristics: Does
not take into account the specific characteristics of the development
 team, which can have a significant impact on the cost and effort of a
software project.
3. Not enough precise cost and effort estimate: This does not provide
a precise estimate of the cost and effort of a software project, as it is
based on assumptions and averages.
Best Practices for Using COCOMO
1. Recognize the Assumptions Underpinning the Model: Become
acquainted with the COCOMO model’s underlying assumptions, which
include its emphasis on team experience, size, and complexity.
Understand that although COCOMO offers useful approximations,
project results cannot be predicted with accuracy.
2. Customize the Model: Adapt COCOMO’s inputs and parameters to
your project’s unique requirements, including organizational capacity,
development processes, and industry standards. By doing this, you can
be confident that the estimations produced by COCOMO are more
precise and appropriate for your situation.
3. Utilize Historical Data: To verify COCOMO inputs and improve
estimating parameters, collect and examine historical data from
previous projects. Because real-world data takes project-specific
aspects and lessons learned into account, COCOMO projections
become more accurate and reliable.
4. Verify and validate: Compare COCOMO estimates with actual project
results, and make necessary adjustments to estimation procedures in
light of feedback and lessons discovered. Review completed projects
to find errors and enhance future project estimation accuracy.
5. Combine with Other Techniques: To reduce biases or inaccuracies
in any one method and to triangulate results, add COCOMO estimates
to other estimation techniques including expert judgment, similar
estimation, and bottom-up estimation.
Important Questions on COCOMO Model
1. A company needs to develop digital signal processing software
for one of its newest inventions. The software is expected to have
20000 lines of code. The company needs to determine the effort in
person-months needed to develop this software using the basic
COCOMO model. The multiplicative factor for this model is given
as 2.2 for the software development on embedded systems, while
the exponentiation factor is given as 1.50. What is the estimated
effort in person-months? [ ISRO CS 2016 ]
(A) 196.77
(B) 206.56
(C) 199.56
(D) 210.68
Solution: The correct Answer is (A).
2. Estimation of software development effort for organic software
in basic COCOMO is [ ISRO CS 2017 – May ]
(A) E = 2.0(KLOC)1.05PM
(B) E = 3.4(KLOC)1.06PM
(C) E = 2.4(KLOC)1.05PM
(D) E = 2.4(KLOC)1.07PM
Solution: The correct Answer is (C).
Conclusion
The COCOMO model provides a structured way to estimate the time,
effort, and cost needed for software development based on project size
and various influencing factors. It helps project managers and developers
plan resources effectively and set realistic timelines and budgets,
improving overall project management and success.
Frequently Asked Questions on COCOMO Model -
FAQs
1. How many COCOMO models are there?
There are three types of COCOMO model:
• Basic COCOMO Model
• Intermediate COCOMO Model
• Detailed COCOMO Model

2. What does COCOMO Model stands for?

COCOMO Model stands for Constructive Cost Model.
3. Why is COCOMO II used?
COCOMO II is useful for software development that is non-sequential,
quick, and reusable. It gives estimations of work and schedule. It delivers
estimates within one standard deviation of the most likely estimate.