Software Maintenance and Software Project

Management:

Chapter 1: Software as an Evolutionary Entity

Introduction
Software is not a fixed or unchangeable product. Unlike physical hardware, which may
degrade over time, software becomes obsolete due to changing requirements,
technological advances, and evolving business environments. This continuous change and
adaptation is known as software evolution.

Nature of Software Evolution

Software systems are designed to serve specific business needs. However, these needs
continuously evolve, and so must the software. This leads to constant software
modification, enhancement, optimization, and correction.
Key Points:

• Software does not degrade physically but becomes less relevant or incompatible.
• Continuous maintenance is essential to keep software aligned with business goals.
• Even perfectly working software may require updates for new hardware, new
regulations, or new customer needs.

Reasons for Continuous Change

• Changing User Requirements: User needs evolve, requiring software updates.
• Technological Advancements: New hardware, operating systems, or programming
languages demand software modifications.
• Market Competitiveness: Organizations update software to stay ahead in the
market.
• Legal and Regulatory Compliance: Software must comply with changing legal
standards.
• Operational Issues and Errors: Bugs or inefficiencies discovered in production
environments must be addressed.

Legacy Systems and Their Challenges

A legacy system is an outdated software system still in use because it remains critical to
operations.
Challenges:
 • Lack of documentation
• Use of obsolete programming languages and platforms
• Complex integration with newer systems
• Difficulty in hiring developers with relevant legacy skills
Example: A bank using a 1980s COBOL-based system for transaction processing.

Diagram: Software Evolution Life Cycle

[Development] → [Operation] → [Maintenance] → [Enhancement] → [Retirement]

Chapter 2: Software Maintenance

Definition and Importance
Software maintenance is the process of modifying a software product after its delivery to
correct faults, improve performance, or adapt it to a changed environment.
Why is it Important?

• Software remains useful for longer.

• It reduces operational risks.
• It accounts for a major portion of the software budget (about 60-70%).

Types of Maintenance
1. Corrective Maintenance:

o What: Fixing defects after software deployment.

o Why: To address errors affecting system operation.
o Example: Fixing a login failure bug.
2. Adaptive Maintenance:

o What: Modifying software to operate in a new or changed environment.

o Why: Ensure compatibility with new hardware, OS, or legal standards.
o Example: Updating software to work with a new database system.
3. Perfective Maintenance:

o What: Improving software performance or maintainability.

o Why: Enhance user experience and system efficiency.
o Example: Adding a search filter to a reporting module.
4. Preventive Maintenance:

o What: Making changes to prevent future faults.

o Why: Improve software reliability and avoid breakdowns.
 o Example: Refactoring code to simplify complex logic.

Maintenance Process Models

• Direct Change Model:

o Changes made directly to operational software.

o Risky as it may introduce new defects.
• Reverse and Forward Engineering Model:

o Reverse Engineering: Analyzing and understanding existing code.

o Forward Engineering: Making changes or rewriting the software for
improvement.

Software Reverse Engineering

Definition: The process of analyzing a system to identify its components and
interrelationships, often to recreate lost documentation.
Why:

• Recover lost design information.

• Detect and fix security vulnerabilities.
Techniques:

• Code decompilation
• Static and dynamic analysis

Software Re-Engineering
Definition: Process of examining and altering existing software to reconstitute it in a new
form.
Why:

• Improve maintainability and performance.

• Migrate legacy systems to modern platforms.
Process:

• Source code translation

• Data restructuring
• User interface updates
• Documentation improvement

Cost of Maintenance
Factors Influencing Cost:
 • Complexity of software
• Quality of documentation
• Skill level of maintenance team
• Age of software
• Size and modularity
Strategies to Reduce Maintenance Cost:

• Modular and structured software design

• Good documentation practices
• Comprehensive testing frameworks

Diagram: Types of Maintenance

| Corrective | Adaptive | Perfective | Preventive |

Chapter 3: Software Configuration Management (SCM)

Introduction
Software Configuration Management (SCM) is the discipline of identifying, organizing,
and controlling modifications to software during its development and operational life
cycle.
Why:

• To ensure integrity and traceability of software versions.

• Prevent conflicts when multiple developers work on the same software.

SCM Activities
• Configuration Identification: Defining software artifacts (source code, documents,
executables).
• Configuration Control: Managing changes systematically.
• Status Accounting: Tracking changes and versions.
• Configuration Audits: Verifying conformance to requirements.

Change Control Process

Steps:
1. Submit Change Request (CR)
2. Review by Change Control Board (CCB)
3. Approve or reject CR
4. If approved, implement changes
 5. Test changes before deployment
Change Control Board (CCB): A committee responsible for evaluating change requests.

Software Version Control

What: Managing multiple versions of software artifacts.
Why:

• Maintain a history of changes.

• Enable team collaboration.
Tools:

• Git
• Subversion (SVN)
Versioning: Creating separate versions of the software. Revisioning: Minor changes within
a version.

Chapter 4: CASE Tools Overview

What are CASE Tools?
CASE (Computer-Aided Software Engineering) tools are specialized software
applications designed to assist in various activities of software development and
maintenance. These tools help in automating software engineering tasks and improving
productivity, consistency, and software quality.
Why Important:

• Automates tedious, error-prone processes.

• Ensures standardized documentation and code.
• Enhances productivity and quality.
• Facilitates better project management and control.

Categories of CASE Tools

Category Description Examples
Upper CASE Support early SDLC stages like requirements Rational Rose,
Tools and design Lucidchart
Lower CASE Assist later SDLC phases like coding, testing, Selenium, JUnit
Tools and maintenance
Integrated Cover both early and later phases Visual Paradigm, IBM
Category Description Examples
CASE Tools Rational Suite

Architecture of CASE Environment

• User Interface: Manages interactions between user and tools.
• Repository: Central storage for models, documents, and data.
• Object Management System (OMS): Manages objects like diagrams, source code,
ensuring data integrity.

Benefits
• Increased speed and accuracy.
• Standardized deliverables.
• Enhanced documentation.
• Easier project management.

Limitations
• High initial investment.
• Training overhead.
• Tool compatibility issues.

Diagram: CASE Environment Structure

User → User Interface → OMS → Repository

Chapter 5: Software Project Estimation

What is Software Estimation?
Software project estimation involves predicting the resources required to complete a
software project within defined constraints.
Why Important:

• Essential for budgeting and scheduling.

• Prevents cost overruns and delays.

Key Parameters
• Cost: Total financial requirement.
• Effort: Work measured in person-months.
• Schedule/Duration: Project timeline.
Estimation Techniques
1 Lines of Code (LOC)
• Based on estimated total lines of code.
• Merits: Simple and historical data-based.
• Demerits: Language dependent, ignores complexity.
2 Function Point Metrics (FPM)
• Measures delivered functionality.
• Merits: Language independent, complexity aware.
• Demerits: Requires expertise.

Function Point Analysis Steps

6. UFP (Unadjusted Function Points): Calculated from inputs, outputs, inquiries,
files, interfaces.
7. TDI (Total Degree of Influence): Adjustments based on system complexity.
8. VAF (Value Adjustment Factor): Derived from TDI.
9. FPC (Final Function Points Count): UFP × VAF
Example:

• UFP = 24
• TDI = 30 → VAF = 0.65 + (0.01 × 30) = 0.95
• FPC = 24 × 0.95 = 22.8 FP

Chapter 6: Constructive Cost Model (COCOMO)

What is COCOMO?
COCOMO (Constructive Cost Model) is a parametric software cost estimation model
developed by Barry Boehm.
Why Important:

• Provides reliable effort and schedule estimates.

• Helps in risk management and resource planning.

COCOMO Types
Type Description Use-Case
Basic Effort = a × (KLOC)^b Small, simple projects
Intermediate Adds cost drivers Medium projects
Advanced Detailed, includes sub-models Large, complex systems
Project Classifications
• Organic: Small, stable teams, familiar problems.
• Semidetached: Medium-sized, mixed experience.
• Embedded: Complex, hardware-software interaction.

Formulas
Effort (Person-Months): E = a × (KLOC)^b
Development Time (Months): D = c × (E)^d

Example Calculation
For Organic, 50 KLOC:

• a = 2.4, b = 1.05, c = 2.5, d = 0.38

• E = 2.4 × (50)^1.05 = 140 person-months
• D = 2.5 × (140)^0.38 = 14 months
Merits:

• Data-driven.
• Well-tested.
Demerits:

• Dependent on accurate size estimation.

• Outdated for modern agile projects.

Chapter 7: Resource Allocation Models

What is Resource Allocation?
Resource allocation in software project management is the process of assigning available
resources (human, financial, technical, etc.) to various tasks and activities to optimize
productivity and meet project goals within constraints.

Why is it Important?
• Ensures optimal use of limited resources.
• Helps in preventing bottlenecks and idle times.
• Aligns resource capacity with project demand.
• Facilitates scheduling, budgeting, and risk management.
Factors Affecting Resource Allocation
• Project size and complexity
• Skill levels of team members
• Availability of hardware and software tools
• Budget constraints
• Time schedules

Popular Resource Allocation Models

2 Work Breakdown Structure (WBS)
• What: Hierarchical decomposition of project tasks.
• Why: Simplifies estimation, scheduling, and monitoring.
• Merits: Improves visibility, accountability.
• Demerits: Can become overly complex for large projects.
2 Gantt Charts
• What: Bar charts showing project schedule over time.
• Why: Tracks task duration, dependencies, and progress.
• Merits: Simple visualization.
• Demerits: Limited in handling complex dependencies.
3 PERT/CPM (Program Evaluation Review Technique/Critical Path Method)
• What: Network-based scheduling methods.
• Why: Manage task sequences, dependencies, and critical paths.
• Merits: Identifies project duration and delays.
• Demerits: Requires detailed task analysis.

Diagram: Gantt Chart Example

Task A |■■■■■■■■|
Task B |■■■■■■|
Task C |■■■■|

Chapter 8: Software Risk Analysis and Management

What is Software Risk?
Risk in software projects is the possibility of a negative event affecting the project’s
success in terms of cost, schedule, or quality.

Why Important?
• Avoids project failures.
• Enables proactive management.
 • Protects budget, schedule, and deliverables.

Risk Management Activities

10. Risk Identification: Listing possible risks.
11. Risk Assessment: Analyzing probability and impact.
12. Risk Containment: Developing mitigation and contingency plans.

Risk Metrics
• Likelihood: Probability of occurrence.
• Impact: Severity of consequences.
• Priority: Product of likelihood and impact.

Risk Leverage
Formula:
Risk Leverage = (Risk Exposure before – Risk Exposure after) / Cost of Risk Reduction
Example:

• Risk Exposure before: $10,000

• Risk Exposure after: $5,000
• Cost of Risk Reduction: $2,000
Leverage = (10,000 - 5,000) / 2,000 = 2.5
Merits: Quantifiable, supports decision-making. Demerits: Needs accurate data.

Chapter 9: Software Quality Assurance (SQA)

What is SQA?
Software Quality Assurance (SQA) involves planned activities to ensure software
processes and products conform to specified standards and requirements.

Why Important?
• Enhances software reliability and user satisfaction.
• Reduces defects and rework.
• Ensures compliance with standards.

Components of an SQA Plan

• Objectives: Quality goals.
• Organizational Structure: Roles and responsibilities.
 • Standards: Process and product standards.
• Reviews and Audits: Inspections, code reviews.
• Testing Plans: Unit, integration, system testing.
• Error Reporting and Corrective Actions.

ISO 9000 Models

• ISO 9001: Design, development, production.
• ISO 9002: Production and installation.
• ISO 9003: Final inspection and testing.
Merits: Recognized internationally. Demerits: Documentation-heavy.

SEI-CMM Model
Capability Maturity Model (CMM) by SEI assesses software processes on maturity levels.

Level Description
1 Initial (chaotic, ad hoc)
2 Repeatable (basic controls)
3 Defined (standardized)
4 Managed (quantitative)
5 Optimizing (continuous improvement)

Merits: Guides process improvement. Demerits: Time-consuming implementation.