Unit-III: Software Maintenance & Software Project Measurement

Need- Software maintenance is the ongoing process of modifying, updating, and

optimizing software post-delivery to correct bugs, adapt to new environments,
and enhance performance.

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.

Types of Maintenance

Maintenance can be divided into the following:

1. 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.

2. 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.

3. 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 demands.

4. Preventive maintenance: This type of maintenance includes modifications and

updations to prevent future problems of the software. It goals to attend
problems, which are not significant at this moment but may cause serious issues
in future.
Software Configuration Management (SCM) is a disciplined software engineering
process used to systematically handle, organize, and control changes to software
components throughout the development lifecycle. It ensures that a software system is
always in a known, stable state and that every modification is tracked, authorized, and
reproducible.

Core Processes of SCM

Standard SCM practices typically follow five primary functional stages to maintain
integrity and traceability:
 Configuration Identification: Defining and labeling all components (Configuration
Items or CIs) of a project, such as source code, documentation, requirements, and
test cases.
 Version Control: Tracking and managing multiple versions of software artifacts,
allowing teams to collaborate simultaneously and revert to previous states if errors
occur.
 Change Control: A formal process—often involving a Configuration Control Board
(CCB)—to evaluate, approve, and implement proposed changes while assessing
their impact.
 Configuration Status Accounting (CSA): Recording and reporting the status of
configuration items and change requests to provide visibility into the project's
evolution.
 Configuration Audits & Reviews: Verifying that the software product matches the
specified requirements and that all authorized changes have been correctly
implemented

A software change management

A software change management process is a structured approach to

identifying, assessing, approving, implementing, and documenting
modifications to software systems. It ensures changes are authorized and
tested, reducing risks and maintaining system stability. Key steps include
submitting a formal Request for Change (RFC), impact analysis, approval,
implementation, and review.

Key Stages in the Software Change Management Process

1. Change Identification & Request (RFC): A Request for Change (RFC) is
created, detailing what needs to change, why, and the anticipated impact.

2. Assessment and Evaluation: The change management team (or CAB -

Change Advisory Board) reviews the request for feasibility, technical merit, and
potential risks to the system.
 3. Planning and Scheduling: An approved change is scheduled. A detailed plan is
created, including resources, timelines, and fallback/rollback procedures to revert
if issues arise.

4. Implementation and Testing: The change is implemented and thoroughly

tested in a controlled, non-production environment (staging/development) to
verify functionality.

5. Deployment and Closing: The change is deployed to the live environment and
monitored. Finally, the request is closed and documented in a change log

Version control
In software engineering, version control (also known as source or revision control) is
the practice of tracking and managing changes to a project's source code and other files
over time. It acts as a safety net, allowing developers to experiment, collaborate, and
maintain a complete historical record of every modification.

Core Benefits
 Collaboration: Multiple developers can work on the same codebase
simultaneously without overwriting each other's work.

 Revision History: Teams can see who made changes, exactly what was
modified, and when.

 Reversibility: If a bug is introduced or a feature fails, the system can instantly

revert the codebase to a previous, stable version.

 Experimentation: Through "branching," developers can create a separate copy

of the code to test new ideas safely without affecting the main product.

Types of Version Control Systems

1. Local (LVCS): Stores all versions on a single computer. Primarily used by solo
developers but lacks collaboration features.

2. Centralized (CVCS): All file history is stored on a single central server.

Developers "check out" files to work on them and "commit" changes back to the
server (e.g., Subversion (SVN)).

3. Distributed (DVCS): Every developer has a full copy (clone) of the entire
repository and its history locally. Work is independent and only synchronized
when "pushed" or "pulled" to a shared server (e.g., Git)
Change control and Reporting
Change control and reporting in software engineering is a structured process
to manage, authorize, and document modifications to software baselines,
ensuring system integrity, minimized disruption, and efficient resource usage. It
involves identifying, analyzing, and approving changes, creating, and reviewing
change requests, and tracking changes through status accounting.
Key Aspects of Change Control and Reporting:
Change Control Process:

 Request & Recording: All changes are initiated via a formalized change request,
ensuring every modification is documented.

 Impact Analysis: The change is evaluated for technical merit, cost, time, and
potential side effects on the system.

 Approval & Authorization: A Configuration Control Board (CCB) or designated

authority reviews the impact assessment and approves or rejects the request.

 Implementation & Verification: Approved changes are implemented, tested for

quality, and verified for compliance.

 Baseline Management: Changes are controlled against a, allowing for version

tracking

Program Comprehension Techniques

Program comprehension involves reconstructing the logic, structure, and intent of
software. Engineers use a mix of cognitive models (top-down or bottom-up reading),
static/dynamic analysis tools, and program slicing to interpret existing codebases and
prepare for maintenance tasks.
Cognitive Comprehension Models
Human developers naturally gravitate toward specific mental strategies to parse code:
 Top-Down: Programmers with domain expertise first form hypotheses about the
software's broader purpose, then recursively look at specific code segments to verify
and refine their expectations.
 Bottom-Up: Developers with less domain knowledge read code line-by-line,
identifying micro-structures (e.g., loops and variables) and grouping them into
higher-level abstractions.
 Integrated: Combines both models; developers shift between forming global
hypotheses and studying localized code details based on what they encounter

Software 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.

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:
1. To describe a cost-effective option for system evolution.
2. To describe the activities involved in the software maintenance process.
3. To distinguish between software and data re-engineering and to explain
the problems of data re-engineering.
Overall, software re-engineering can be a cost-effective way to improve the
quality and functionality of existing software systems, while minimizing the
risks and costs associated with starting from scratch.

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.
Reverse Engineering
Software Reverse Engineering is the process of analyzing a software system
to understand its design, requirements, and functionality by examining its
code. It helps rebuild knowledge about how a program works by extracting
information from existing software.
 Breaks down existing code to understand system design and logic
 Helps recover missing documentation or specifications
 Builds a structured program database from analyzed code
 Useful for debugging, maintenance, and security analysis

Steps of Software Reverse Engineering

 Collection Information: This step focuses on collecting all possible
information (i.e., source design documents, etc.) about the software.
 Examining the Information: The information collected in step-1 is
studied so as to get familiar with the system.
 Extracting the Structure: This step concerns identifying program
structure in the form of a structure chart where each node corresponds
to some routine.
 Recording the Functionality: During this step processing details of
each module of the structure, charts are recorded using structured
language like decision table, etc.
 Recording Data Flow: From the information extracted in step-3 and
step-4, a set of data flow diagrams is derived to show the flow of data
among the processes.
 Recording Control Flow: The high-level control structure of the
software is recorded.
 Review Extracted Design: The design document extracted is reviewed
several times to ensure consistency and correctness. It also ensures
that the design represents the program.
 Generate Documentation: Finally, in this step, the complete
documentation including SRS, design document, history, overview, etc.
is recorded for future use.

How it Works
The reverse engineering process takes compiled binary code and translates it back into
readable formats.
  Disassembly: Translates machine-level binary code (the raw ones and zeros)
into a human-readable assembly language.

 Decompilation: Takes disassembled code and attempts to reconstruct it into

higher-level languages like C or C++.

 Static Analysis: Examines the code without running the program to study its
control flow, structure, and embedded data.

 Dynamic Analysis:

Reverse Engineering Tools

Reverse engineering tools analyze source code and generate design
representations such as structural, procedural, data, and behavioral models.
Since manual reverse engineering is time-consuming, automated tools are
used.
Common tools include:
 CIAO and CIA: A graphical navigator for software and web repositories,
along with a collection of reverse engineering tools.
 Rigi: A visual software understanding tool used to analyze and explore
software systems.
 Bunch: A tool used for software clustering and modularization.
 GEN++: An application generator that supports the development of
analysis tools for the C++ programming language.
 PBS (Programmer’s Bookshelf System): A set of tools used for
extracting and visualizing the architecture of software programs.

Project Management Concepts

Software project management (SPM) in software engineering involves planning,
monitoring, and controlling the development process to deliver high-quality software on
time and within budget. Key concepts include managing the "4 P's" (People, Product,
Process, Project), scope definition, risk management, scheduling, and aligning
stakeholders.
Core Project Management Concepts
 The 4 P's of Management: The foundational elements for success—People
(teamwork), Product (goals/scope), Process (methodologies), and Project
(execution).
 Software Development Life Cycle (SDLC): Management of structured phases:
Feasibility Study, Planning, Execution, and Termination.
 Scope Definition & Management: Identifying the purpose of the software, defining
requirements, and ensuring only authorized work is done.
 Estimation & Scheduling: Calculating time, cost, and resources needed, then
creating a roadmap (scheduling).
 Risk Management: Identifying, analyzing, and taking steps to avoid or mitigate
problems.

Feasibility Analysis
A feasibility study in software engineering is a preliminary analysis that determines if a
proposed software project is technically possible, economically viable, and practically
actionable. It acts as an initial risk-assessment tool, preventing organizations from
wasting time and budget on unrealistic or unprofitable applications.
Key Dimensions Evaluated
A comprehensive study is typically structured around the TELOS framework:
 T - Technical Feasibility: Assesses whether the development team has the
required technical skills, and if the necessary hardware, software, and current
technologies are available to successfully build the product.
 E - Economic Feasibility: Conducts a cost-benefit analysis. It evaluates the
financial viability of the project, estimating development costs, maintenance
expenses, and the projected return on investment (ROI).
 L - Legal Feasibility: Checks for compliance with regulatory requirements, data
privacy laws (such as GDPR or regional policies), licensing agreements, and
copyrights.
 - Operational Feasibility: Examines if the proposed software will be accepted
and effectively utilized by the end-users and the organization once deployed.
 S - Scheduling Feasibility: Determines whether the project can be realistically
completed within an acceptable or predetermined timeframe and analyzes
project milestones

Project and process planning

Project and process planning in software engineering are the foundational activities
that define a project's scope, timeline, budget, and methodology. They translate
business goals into actionable, risk-mitigated execution steps, ensuring the team
knows exactly what to build and how to build it efficiently.
The planning process is divided into two major tracks: Software Project Planning
(the "what" and "when") and Software Process Planning (the "how").

1. Software Project Planning

This phase deals with estimating the required effort, establishing the schedule, and
allocating resources.
 Estimation: Decomposes the problem and forecasts effort, size, and cost.
Techniques often involve breaking down code metrics or utilizing function points
to estimate timelines.
 Scheduling: Develops the project timeline using visual task networks,
establishing milestones, and assigning roles to team members.
 Risk Management: Identifies potential bottlenecks—such as timeline delays or
scope creep—and establishes proactive mitigation plans to safeguard project
quality and budget.
 Change Management: Puts procedures in place to track, evaluate, and approve
changes to the initial project plan.

2. Software Process Planning

This focuses on the framework and methodologies your team will use to turn
requirements into a working software product.
 Choosing an SDLC: Determines the overarching Systems Development Life
Cycle (SDLC). Teams choose between iterative models (like Agile/Scrum) for
continuous delivery, or linear models (like Waterfall) for highly predictable
requirements.
 Quality Management Planning: Defines quality goals, testing strategies, and
the standards to which the software product must adhere.
 Task Granularity: Establishes how much detail is required in planning. For
example, near-term work is highly granular (planned in days/weeks), while
future work might be planned at a high level

Core Principles for Success

To avoid project failures, delays, and budget overruns, effective planning rests on a
few golden principles:
1. Iterative Refinement: Planning is not a one-time event; it evolves as
requirements and constraints become clearer over time.
2. Clear Objectives: Every objective must be defined clearly, utilizing standardized
project management frameworks to measure progress.
3. Continuous Tracking: A plan is only as good as its execution. Routine progress
monitoring helps identify discrepancies early so the team can adjust and course-
correct.

Resource allocation
 Resource allocation in software engineering is the strategic process of assigning
and scheduling personnel, time, budget, and technological tools across development
phases. Its primary goal is to maximize productivity, prevent team burnout, and meet
project deadlines without exceeding budgetary limits.

Key Categories of Resources

In software projects, resources are broadly categorized into four groups:
 Human Resources: Developers, QA testers, UI/UX designers, DevOps
engineers, and project managers.
 Technological Resources: IDEs, cloud infrastructure (e.g., AWS, Azure), CI/CD
pipelines, and project management/tracking tools (e.g., Jira, Asana).
 Financial Resources: The budget required for salaries, software licenses, and
third-party APIs.
 Time: The structured timeline or sprint cycle (e.g., in Agile frameworks) available
to build and deploy the software.

Software effort estimation is a critical project management process used to predict

the person-hours, person-months, or financial budget required to build or maintain a
software system. Accurate forecasting helps prevent cost overruns, resource
exhaustion, and missed deadlines by establishing realistic schedules before
development begins.

Key Components of Software Effort

In software engineering, effort is primarily driven by the application size (how big
the software is) and the productivity of the team (how fast they can build it).
Size Metrics: Effort is initially linked to measuring the software's scale, typically
using lines of code or complex deliverables.
 Productivity Factors: An individual's output capability is influenced by their
experience, technological adaptability, and the team environment.
 Person-Months: The final required effort is usually translated into person-
months, which represents the total amount of work one average developer
can accomplish in one month.

Common Estimation Techniques

To accurately quantify effort, teams rely on a mix of empirical data, statistical
models, and historical baselines:
Algorithmic Models: Mathematical formulas, such as COCOMO, that calculate
effort based on size variables and project complexity multipliers.
  Expert Judgment: Leveraging the experience and intuition of senior
developers and architects to evaluate project requirements and predict
required person-hours.
 Estimation by Analogy: Comparing the new project requirements to
historical, previously completed projects with similar characteristics and
tracking the effort spent on them.

Important Laws and Rules in Effort Management

Understanding how to manage and distribute effort is critical. Software
engineering relies on two foundational principles regarding team size and project
effort:
Parkinson's Law: States that work expands to fill the time allotted. If estimates
are too generous or targets too easy, the project timeline will inflate without
adding actual value.
Brooks' Law: States that adding more programmers to a late software project
will make it even later. The added effort required for onboarding, communication,
and coordination often slows down overall progress.

Schedule and cost estimation

Schedule and cost estimation are foundational processes in software engineering
used to forecast the effort (person-months), calendar time, and financial budget
required to deliver a project. Accurate predictions prevent budget overruns, align
stakeholder expectations, and optimize resource allocation.

1. The Core Metrics

Before calculating schedules or budgets, engineering teams must measure the
anticipated work:
 Size Metrics: Lines of Code (LOC) or Function Points (FP) are used to
quantify the scale of the software.
 Effort Metrics: Measured in person-months or person-hours. It dictates how
many team members are needed over a specific time period.

2. Primary Estimation Techniques

Software projects use a combination of top-down (evaluating the whole project) and
bottom-up (breaking tasks down to granular units) approaches.
Algorithmic Models: Use mathematical formulas to calculate effort and schedule
based on historical data. The most famous is COCOMO (Constructive Cost Model),
which estimates effort (\(E\)) and schedule (\(S\)) using the formulas:
(Where constants a, b, c, and d depend on the project's complexity, such as organic,
semi-detached, or embedded).
 Expert Judgment: Relies on the experience of senior developers and
architects who break down the project and reach a consensus.
 Agile Estimation: Uses relative sizing instead of absolute time. Teams use
techniques like Planning Poker or T-shirt Sizing to assign story points
based on task complexity.

3. Schedule Estimation
The overall project timeline depends on the effort estimate and the number of
developers assigned to the project.
Stretching a schedule (longer time, fewer people) or compressing it (shorter time,
more people) is non-linear.
 The Square Root Check: A common rule of thumb dictates that the schedule
duration shouldn't be drastically altered without factoring in how many people
are executing the tasks.
 Tools like Gantt charts are typically used to map these task dependencies.

4. Cost Estimation
The total financial cost of the software goes far beyond just developer salaries. A
thorough budget factors in:
Direct Costs: Salaries, hardware/software tools, and cloud infrastructure.
 Indirect Costs: Office space, utilities, networking, and administrative
overhead.
 Contingency Reserves: Additional budget set aside to manage unexpected
technical risks or requirement changes

Project Scheduling and Tracking

Project scheduling and tracking are the foundational processes of

mapping out tasks, timelines, and resources in software engineering,
and continuously monitoring progress to ensure the project meets its
deadlines and budget.

1. Project Scheduling Process

Scheduling distributes the estimated engineering effort over the
project's planned duration.
 Work Breakdown Structure (WBS): Decomposes complex software
requirements into smaller, manageable tasks.
 Dependency Mapping & Critical Path: Identifies the relationships
between tasks (e.g., QA testing cannot start until coding is
complete) and maps out the critical path to determine the
shortest possible completion time.
 Milestone Tracking: Sets specific checkpoints to gauge progress,
such as completing UI wireframes, a database migration, or an API
release.
 Resource Allocation: Assigns exact personnel, budget, and
timeframes (e.g., person-hours) to ensure the team is not
overloaded.

2. Project Tracking Methods

Tracking involves comparing actual performance against the baseline
schedule to identify delays or scope creep early.

Agile Boards: Tools like Jira or Linear allow teams to track the daily flow
of tickets (User Stories) using Kanban or Scrum boards.
 Daily Stand-ups & Reviews: Quick, localized team meetings where
engineers report what they completed, what they will do next,
and any blockers they face.
 Earned Value Management (EVM): A quantitative technique that
evaluates schedule and budget variance by calculating how much
work was actually completed versus what was planned to be
spent by a given date.
 Burndown & Velocity Charts: Used in Agile environments to
visually track the amount of work remaining in a sprint and gauge
how much work the team can handle in future cycles

Risk Assessment and Mitigation

Software Risk is a problem that may or may not occur that shows the
uncertainty of risks but if occurs, unwanted losses threats, or
consequences will occur. It is generally caused due to a lack of incomplete
information, control, or time.

Risk Assessment and Risk Mitigation is a process in which identifying,

assessing, and mitigating risk takes place to the scope, schedule, cost, and
quality of the project.

What is Risk Assessment?

Risk assessment simply means to describe the overall process or method
to identify risk and problem factors that might cause harm. It is a systematic
examination of a task or project that you perform to simply identify
significant risks, problems, and hazards, and then to find out control
measures that you will take to reduce risk. The best approach is to prepare
a set of questions that can be answered by project managers to assess
overall project risks.

These questions are shown below:

 Will the project get proper support from the customer manager?
 Are end-users committed to software that has been produced?
 Is there a clear understanding of the requirements?
 Is there an active involvement of customers in the requirement
definition?
 Are the expectations set for the product are realistic?
 Is the project scope stable?
 Are there team members with the required skills?
 Are project requirements stable?
 Is the technology used for software known to developers?
 Is the size of the team sufficient to develop the required product?
 Do all customers know the importance of the product/requirements of
the system to be built?

Thus, the number of negative answers to these questions represents the

severity of the impact of risk on the overall project. It is not about creating
or making a large number of work papers, but rather simply identifying and
finding out measures to control risks in your workplace.

What is Risk Mitigation?

Risk mitigation simply means to reduce adverse effects and impact of risks
that are harmful to project and Business continuity. It includes introducing
measures and steps taken into a project plan to mitigate, reduce, eliminate,
or control risk. Risk mitigation means preventing risks from occurring (risk
avoidance).

The following are measures and steps to be taken to mitigate risks:

 Communicate with concerned staff to find probable risks.
 Identify and eliminate all those causes and issues that can create risk
before the beginning of project work.
 Develop a policy in an organization that will help to continue the
project even though some staff leave the organization.
 Everybody in the project team should be acquainted i.e. should be
aware of and familiar with current development activity.
 Maintain corresponding documents promptly. This documentation
should be strictly followed as per standards set by the organization.
 Conduct timely reviews to speed up work.
 For conducting every critical activity during software development,
additional staff is required.

Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is simply a way to assure quality in the
software. It is the set of activities that ensure processes, procedures as
well as standards are suitable for the project and implemented correctly. It
is a process that works parallel to Software Development. It focuses on
improving the process of development of software so that problems can
be prevented before they become major issues. Software Quality
Assurance is a kind of Umbrella activity that is applied throughout the
software process.

Quality
Quality in a product or service can be defined by several measurable
characteristics. Each of these characteristics plays a crucial role in
determining the overall quality.
Generally, the quality of the software is verified by third-party organizations
like international standard organizations .
 Quality in Software Engineering

Elements of Software Quality Assurance (SQA)

 Standards: The IEEE, ISO, and other standards organizations have
produced a broad array of software engineering standards and
related documents. The job of SQA is to ensure that standards that
have been adopted are followed and that all work products conform
to them.
 Reviews and audits: Technical reviews are a quality control activity
performed by software engineers for software engineers. Their intent
is to uncover errors. Audits are a type of review performed by SQA
personnel (people employed in an organization) with the intent of
ensuring that quality guidelines are being followed for software
engineering work.
 Testing: Software testing is a quality control function that has one
primary goal to find errors. The job of SQA is to ensure that testing is
properly planned and efficiently conducted for primary goal of
software.
 Error/defect collection and analysis : SQA collects and analyzes
error and defect data to better understand how errors are introduced
and what software engineering activities are best suited to eliminating
them.
 Change management: SQA ensures that adequate change
management practices have been instituted.
 Education: Every software organization wants to improve its
software engineering practices. A key contributor to improvement is
education of software engineers, their managers, and other
stakeholders. The SQA organization takes the lead in software
 process improvement which is key proponent and sponsor of
educational programs.
 Security management: SQA ensures that appropriate process and
technology are used to achieve software security.
 Safety: SQA may be responsible for assessing the impact of
software failure and for initiating those steps required to reduce risk.
 Risk management : The SQA organization ensures that risk
management activities are properly conducted and that risk-related
contingency plans have been established.