Solution

Correct Answer: (iii) Breadth test and depth test

Explanation

Maintenance testing (after bug fix/enhancement) uses:

• Breadth test - test entire system / affected areas broadly
• Depth test - test modified part deeply

Plus Retesting + Regression testing and Confirmation testing are components, but Breadth and depth is the specific methodology pair taught for maintenance testing in Pressman/Jalote curriculum. Retesting alone (i) or Sanity (ii) are subsets.

Answer: (iii) Breadth test and depth test

Solution

Correct Answer: (c) Maintenance cost

Explanation

Lifecycle cost distribution (typical Boehm data):

• Design ~10%, Coding ~15%, Testing ~20%, Maintenance 60-70% (largest).

Software lives long; corrective/adaptive/perfective maintenance dominates.

Answer: (c) Maintenance cost

Answer: (i) Improving the software design and structure without changing functionality

Software re-engineering is "the examination and alteration of a subject system to reconstitute it in a new form" — in practice its primary focus is to improve the software's design/structure and maintainability (restructuring existing code, recovering documentation, modernizing architecture) while preserving the existing functionality, so the value of the legacy system is retained with reduced maintenance cost.

Why the others are wrong:

• (ii) Adding new features — that would be perfective maintenance/enhancement, not re-engineering per se.
• (iii) Building a new system from scratch — that is new development/forward engineering; re-engineering works on the existing system.
• (iv) Fixing bugs — that is corrective maintenance, not re-engineering.

So re-engineering is concerned with improving the software design and structure without changing the functionality — option (i).

Answer: (ii) Ensure recent changes didn't affect existing functionality

Regression testing re-runs previously passed test cases (and adds new ones) after a change — a bug fix, enhancement, or integration — to verify that the modifications have not broken existing, already-working functionality. It guards against "regressions": defects introduced in code that used to work.

Why the others are wrong:

• (i) Test a new module — testing new code alone is unit/development testing; regression testing focuses on existing behaviour after a change.
• (iii) Improve system performance — performance tuning is not the purpose of regression testing.
• (iv) Identify hardware errors — hardware faults are outside the scope of software regression testing.

So regression testing ensures recent changes didn't affect existing functionality — option (ii).

Solution

Correct Answer: (i) Software versions and changes

Explanation

Software Configuration Management (SCM) controls how the items that make up a software product (code, documents, test cases, build scripts) change over time. Its main activities are:

• Configuration identification - naming and versioning items
• Version control - managing versions and branches
• Change control - reviewing and approving changes
• Configuration auditing and status reporting

Why other options are incorrect:

• (ii) Hardware temperature and (iv) Employee attendance - unrelated to SCM.
• (iii) Language syntax - handled by compilers and coding standards.

Answer: (i) Software versions and changes

Controlling Future Software Maintenance Costs

The question lists six factors: module independence, programming style, documentation, staff stability, hardware stability and software age.

A software engineer can directly control or strongly influence the following during development:

1. Module independence

Design modules with high cohesion and low coupling.

How to reduce future cost:

• Give each module a clear responsibility.
• Minimize unnecessary dependencies.
• Use well-defined interfaces.
• Avoid shared global data where possible.

This localizes changes and reduces regression risk.

2. Programming style

Use consistent, readable and maintainable coding standards.

How to reduce future cost:

• Follow naming and formatting conventions.
• Use meaningful identifiers.
• Avoid unnecessary complexity.
• Apply code reviews and static analysis.
• Keep functions/classes reasonably focused.

Readable code reduces the time needed to understand and modify the system.

3. Documentation

Maintain accurate technical and user documentation.

How to reduce future cost:

• Document architecture and interfaces.
• Explain important design decisions.
• Keep API and configuration documentation current.
• Document installation, operation and troubleshooting.

Good documentation reduces knowledge-transfer and maintenance effort.

Factors not directly controlled by the software engineer

• Staff stability: strongly influenced by organizational management and retention policies.
• Hardware stability: depends on hardware, infrastructure and external operational factors.
• Software age: increases naturally as the system remains in use.

An engineer can design for portability and maintainability to reduce the impact of these factors, but cannot directly control them.

Conclusion: During development, the strongest direct levers are module independence, programming style and documentation.

Software Maintenance — Definition & Types

Definition

Software maintenance is the process of modifying and updating a delivered software system after it has been released for use — to correct defects, adapt to a changed environment, improve performance/features, or prevent future problems. It is the final and longest phase of the software life cycle, often consuming 60–80% of total life-cycle cost.

Types of software maintenance

1. Corrective Maintenance

• Fixing errors/defects found in the software after delivery.
• Example: fixing a crash when entering a negative number; correcting a wrong tax calculation.

2. Adaptive Maintenance

• Modifying the software to adapt to changes in the external environment (OS, hardware, compilers, databases, regulations).
• Example: porting the application to a new Windows version; updating for new GST rules; supporting a new browser.

3. Perfective Maintenance

• Improving/enhancing the software — adding new features, improving performance, usability, and maintainability — to satisfy new/changed user needs.
• Example: adding a new report; optimizing a slow query; redesigning the UI.

4. Preventive Maintenance

• Changes that prevent future problems — improving maintainability and reliability without changing external behaviour in the short term.
• Example: refactoring complex code, adding documentation/metadata, restructuring modules, using reverse/forward engineering (re-engineering).

Summary table

Type	Trigger	What is done	Example
Corrective	Bugs/defects	Fix errors	Crash fix, wrong-output fix
Adaptive	Environment change	Adjust to new environment	Port to new OS/DB
Perfective	New user needs	Enhance/improve	New feature, better performance
Preventive	Future risk	Re-engineer/harden	Refactor, add documentation

Relative distribution (Lientz & Swanson)

• Perfective ~ 50%
• Adaptive ~ 25%
• Corrective ~ 21%
• Preventive ~ 4%

Why it matters

• Keeps the software correct, current, improved, and robust over a long operational life.
• Requires strong configuration management, good documentation, and modular design to be economical.
• The largest share of software cost — managing it well is essential to organizational productivity.

Summary: maintenance is the continuous post-delivery process covering corrective (fixing), adaptive (environment change), perfective (enhancing), and preventive (hardening) activities — the dominant cost phase of the software life cycle.

Need for Software Maintenance and Categories of Maintenance

Software maintenance is the modification of software after delivery to correct faults, improve performance or adapt it to a changed environment.

Need for maintenance

1. Defects remain after delivery: testing cannot find every fault.
2. Environment changes: new operating systems, hardware, databases, laws or tax rules.
3. New user requirements: users ask for new features or improvements once they use the system.
4. Prevent decay: repeated changes degrade the structure; software must be restructured to stay maintainable.
5. Long life of software: maintenance is typically the largest part (often 60% or more) of total life-cycle cost.

Types of maintenance

Type	Purpose	Trigger
Corrective	Fix errors/bugs found after delivery	Defects
Adaptive	Modify software to work in a changed environment	OS, hardware, platform, regulation changes
Perfective	Add or improve features and performance	New or changed user requirements
Preventive	Improve structure/readability to avoid future problems	Reduce future maintenance cost

Mapping the given changes

Cause of change	Maintenance category	Example
Defects	Corrective	Fixing a wrong tax calculation
Operating-environment changes	Adaptive	Porting the app to a new OS version or database
New user requirements	Perfective	Adding a report or a new payment option

Preventive maintenance (code cleanup, refactoring, updating documentation) applies when there is no immediate trigger but the code is becoming hard to change.

Typical effort split

Perfective is usually the largest share (about 50%), then adaptive (about 25%), corrective (about 20%) and preventive (about 5%).

Regression Testing — Definition, Significance & Challenges

Definition

Regression testing is the re-execution of existing (previously passed) test cases — along with new tests for the change — after a modification to the software (bug fix, enhancement, integration, refactoring) to verify that the change did not break existing functionality. It confirms that no regression (new defect in previously working code) has been introduced.

Change (fix/feature) ──▶ re-run old tests + new tests ──▶ all pass ⇒ no regression

Significance in software maintenance

1. Protects existing functionality — the most important safety net during the constant stream of maintenance changes.
2. Reduces risk of "fix one, break many" — changes interact with many modules; regression testing catches side effects early.
3. Supports iterative/agile development — each sprint's changes are validated against previous behaviour.
4. Contributes to confidence & quality — ongoing evidence that the system remains stable across versions.
5. Needed in every maintenance type — corrective, adaptive, perfective, and preventive changes all require regression testing.

How to implement

• Regression test suite — a reusable, automated suite of previous tests (unit, integration, system, acceptance).
• Selective vs complete — for a large system, may re-run only tests affected by the change (impact analysis) or the full suite (safe, but slower).
• Automation — CI/CD pipelines run regression tests on every commit (e.g., Jenkins, GitHub Actions).

Challenges in regression testing

1. Large test suites — full re-runs are slow and expensive (hours/days), delaying releases.
2. Test maintenance — the suite itself must be updated as requirements/UI change; obsolete tests cause false failures.
3. Test selection problem — deciding which tests to re-run (selective regression) requires accurate impact/change analysis; wrong selection can let regressions slip through.
4. Redundancy/minimality — many test cases overlap; redundant cases waste effort, while prioritization (test-case prioritization) is needed to run the most critical first.
5. Environment/data dependencies — regression tests need stable test environments and data; flaky tests (nondeterministic failures) erode confidence.
6. Resource constraints — dedicated regression machines/builds and automation tools cost money and maintenance effort.

Summary table

Aspect	Details
Purpose	Ensure changes don't break existing functionality
When used	After any code change (maintenance, bug fix, feature)
Core practice	Re-run old tests + add new ones; automate in CI
Main challenges	Suite size/time, test selection, flakiness, maintenance, data dependency

Summary: regression testing guards existing behaviour during maintenance — it is essential for safety and quality, but implementation faces challenges of scale (big suites, slow runs), test selection, and maintenance that demand automation and careful impact analysis.

Configuration Management in Software Maintenance

What is Configuration Management (SCM)?

Software Configuration Management is the discipline of identifying, organizing, and controlling changes to the software throughout its life cycle — especially during maintenance, when the software is constantly being modified. It ensures that changes are made systematically and that the system remains consistent and traceable at every point.

Core activities (the 5 pillars of SCM)

1. Configuration Identification — defining and labelling the configuration items (CI): source files, documents, data, build scripts, executables — each assigned a unique identifier/version.
2. Version Control — tracking every version/revision of each configuration item, enabling retrieval of any historical state (e.g., Git, SVN).
3. Change Control — a formal process for requesting, evaluating (CCB — Change Control Board), approving, implementing, and reviewing changes:

   Change request → impact analysis → CCB approval → implement → verify → update baselines
   

4. Configuration Status Accounting — recording and reporting the status of all CIs and change requests (what changed, when, by whom, why).
5. Configuration Audit / Review — verifying (functional & physical audits) that the delivered configuration matches the approved specifications and that records are accurate.

Baselines

A baseline is a formally reviewed and agreed-upon snapshot of configuration items (e.g., the SRS baseline, design baseline, code baseline). After a baseline is set, changes are made only through formal change control; baselines provide stable reference points for development, testing, and delivery.

Why is it important (especially in maintenance)?

1. Control of change chaos — maintenance is a long stream of fixes and enhancements; without SCM, uncontrolled changes corrupt the system ("code drift").
2. Traceability & reproducibility — you can always reconstruct exactly which versions produced a given build/release; critical for debugging field failures and for legal/audit compliance.
3. Team coordination — prevents conflicting edits; multiple maintainers can work in parallel safely.
4. Risk reduction — rollback to a known-good state is always possible if a change fails.
5. Support for multiple versions/sites — maintenance often involves supporting several releases (customer-specific versions); SCM manages all of them.
6. Quality assurance — audits and baselines give management confidence that delivered software matches what was approved and tested.

Summary: Configuration management is the backbone of software maintenance — it keeps every change identified, controlled, recorded, and auditable so the evolving software never loses its consistency, traceability, or recoverability.

Models of Software Maintenance (Corrective, Adaptive, Perfective, Preventive)

After delivery, software undergoes changes. Software maintenance is traditionally classified into four types (per IEEE and Pressman/Sommerville):

1. Corrective Maintenance

• What: fixing errors/defects (bugs) discovered in the software after it has been delivered.
• Purpose: restore the software to its intended, correct behaviour.
• Examples: fixing a crash when a specific input is entered; correcting a wrong calculation; patching a security vulnerability.

2. Adaptive Maintenance

• What: modifying the software to respond to changes in its environment — new operating systems, new hardware, new compilers, changed regulations, or new external interfaces.
• Purpose: keep the software working in a changed external environment.
• Examples: porting the application to run on a new Windows/Linux version; updating to support a new database server or browser; changing tax calculations for new government rules.

3. Perfective Maintenance

• What: improving/enhancing the software — adding new features, improving performance, usability, or maintainability — to meet new or changed user needs.
• Purpose: make the software better from the user's perspective (not fixing bugs).
• Examples: adding a new reporting feature; optimizing the response time of a query; redesigning a user interface for better usability.

4. Preventive Maintenance

• What: preventing future problems by making changes that improve the software's maintainability and reliability without changing its external functionality in the short term.
• Purpose: reduce the risk of future failures and lower future maintenance cost (like servicing a machine before it breaks).
• Examples: refactoring complex code; updating comments/documentation; adding comments, restructuring modules, applying better error handling — often using reverse/forward engineering for re-engineering.

Summary table

Type	Trigger	Activity	Example
Corrective	Bugs/defects	Fix errors	Crash fix, wrong output fix
Adaptive	Environment change	Adjust to new environment	Port to new OS, new DB
Perfective	User needs	Enhance/improve	Add features, boost performance
Preventive	Future risk	Re-engineer/harden	Refactor, improve docs, code restructuring

Note: reports on maintenance distribution (Lientz & Swanson) show perfective (~50%) and adaptive (~25%) dominate, while corrective is often overestimated; preventive is the smallest but pays off over the long term.

Reverse Engineering vs Software Re-engineering

Reverse engineering = analysing an existing system (usually just the code or binary) to recover its design, specification and understanding. It does not change the software.
Re-engineering = restructuring or rewriting an existing system to improve quality or move it to a new platform, while keeping its functionality. It includes reverse engineering as a first step.

Comparison

Basis	Reverse engineering	Software re-engineering
Objective	Understand the system and recover design/requirements when documentation is missing	Improve maintainability, performance or platform of a legacy system
Changes the software?	No (analysis only)	Yes (restructure, convert, rewrite)
Main activities	Code reading and analysis, extracting data and control flow, building structure charts, UML/ER diagrams, documentation	Reverse engineering, restructuring/refactoring code and data, translating to a new language/platform, forward engineering, retesting
Outputs	Design documents, models, call graphs, recovered requirements	A restructured/migrated system that behaves the same way, plus updated documentation
Direction	Backward (code to design)	Backward then forward (code to design to new code)
Effort and cost	Lower	Higher, but lower than a full rewrite

Re-engineering process

Inventory analysis, document restructuring, reverse engineering, code restructuring, data restructuring, forward engineering, testing.

Role in modernizing legacy systems

Legacy systems are old, poorly documented and costly to maintain.

1. Reverse engineering first recovers lost knowledge of how the system works.
2. Re-engineering then restructures it or moves it to modern technology (new language, database, cloud) without rewriting from scratch.
3. Result: lower maintenance cost, better quality, longer system life, and less risk than building a new system.

Reverse engineering is the analysis stage; re-engineering is the full modernization process that uses it.

Configuration-Management Structure for a Product with Five Released Versions

Software Configuration Management (SCM) keeps every released version identifiable, reproducible and controlled while several versions are maintained at the same time.

1. Configuration items (CIs)

Category	Items
Requirements/design	SRS, design documents, architecture diagrams
Source	Source code, libraries, configuration files
Build/deploy	Build scripts, installers, environment settings
Test	Test plans, test cases, test data, results
Data	Database schema and migration scripts
User	User manual, release notes

2. Version identification

Use semantic versioning: MAJOR.MINOR.PATCH (e.g. 3.2.1)

• MAJOR: incompatible or large changes
• MINOR: new backward-compatible features
• PATCH: bug fixes only

Baselines are frozen, approved sets of CIs (e.g. v1.0, v2.0). Each CI and each build is tagged with its version.

main (latest development)
 |--- release/1.x  --> 1.0, 1.0.1, 1.1 ... (maintenance branch)
 |--- release/2.x  --> 2.0, 2.0.1 ...
 |--- release/3.x  --> 3.0, 3.1 ...
 |--- release/4.x  --> 4.0, 4.2 ...
 |--- release/5.x  --> 5.0, 5.1 ...   (current)

Each released version has its own maintenance branch; a fix is applied to the affected branches and merged back to main.

3. Change control process

1. Change request raised (bug, enhancement, environment change)
2. Impact analysis: which CIs and versions are affected
3. Change Control Board (CCB) reviews and approves or rejects
4. Implementation on a branch
5. Verification: review and regression testing
6. Merge and baseline update, change log recorded
7. Status reporting and audit

4. Release management

Activity	Purpose
Release planning	Decide which fixes/features go into which version
Build and package	Reproducible build from tagged CIs
Release notes	List changes, known issues, upgrade steps
Deployment and rollback plan	Safe installation with a way back
Support policy	Define how long each version is maintained
Audit	Check that the released build matches the approved baseline

Tools

Git/SVN for version control, Jenkins/CI for builds, Jira for change requests.

Benefit

Any of the five versions can be rebuilt exactly, bugs can be traced to the version they affect, and changes are controlled and recorded.

Short Notes

(a) Software Reuse

Software reuse means using existing software assets—such as components, libraries, frameworks, designs or services—in a new system instead of developing everything from scratch.

Benefits

• Reduces development time and cost.
• Improves reliability when proven components are reused.
• Promotes standardization.
• Reduces duplicated effort.

Example

A developer may reuse an existing authentication library rather than implementing password hashing and session management from the beginning.

---

(b) Capability Maturity Model (CMM)

The Capability Maturity Model is a framework for assessing and improving the maturity of an organization's software development process.

Five maturity levels

1. Initial — process is ad hoc and unpredictable.
2. Repeatable — basic project-management practices are established.
3. Defined — processes are documented and standardized across the organization.
4. Managed — processes are measured and controlled quantitatively.
5. Optimizing — continuous process improvement is emphasized.

CMM helps organizations make their software processes more disciplined, measurable and predictable.

---

(c) Functional and Non-functional Requirements

Functional requirements

Describe what the system must do—its services, behaviors and responses.

Example: "The ATM shall allow a customer to withdraw cash after successful authentication."

Non-functional requirements

Describe how well the system must operate or constraints under which it must operate.

Examples: performance, security, reliability, usability and availability.

Functional	Non-functional
Specifies system behavior/services	Specifies qualities and constraints
Example: process a withdrawal	Example: respond within 2 seconds

---

(d) Software Re-engineering

Software re-engineering is the systematic examination and transformation of an existing software system to improve its maintainability, structure, performance or technology while preserving useful functionality.

Typical activities

• Inventory analysis: identify systems/components that need attention.
• Document restructuring: improve missing or outdated documentation.
• Reverse engineering: recover higher-level design/knowledge from existing code.
• Code restructuring: improve source code structure without changing intended behavior.
• Data restructuring: reorganize or migrate data.
• Forward engineering: rebuild or modernize the system using recovered knowledge.

Benefits

• Extends software life.
• Reduces maintenance difficulty.
• Preserves valuable business functionality.
• Can be cheaper and less risky than replacing a mature system completely.

Software Maintenance — Definition & Why It Is Inevitable

Definition

Software maintenance is the process of modifying a delivered software system to correct defects, adapt it to a changed environment, improve its performance or add features, and prevent future faults — after the software has been released for use. It is the final (and longest) phase of the SDLC.

Maintenance is classified into four types:

1. Corrective — fixing bugs/errors.
2. Adaptive — adjusting to changes in the environment (OS, hardware, regulations).
3. Perfective — enhancing/improving the product (new features, better performance).
4. Preventive — refactoring/hardening to avoid future problems.

Why maintenance is inevitable

1. Errors are never fully eliminated. Testing can never prove the absence of defects; latent bugs always surface during real use, requiring corrective maintenance.

2. The environment always changes. New operating systems, browsers, hardware, compilers, databases, and legal/regulatory requirements appear continuously — the software must be adapted (adaptive maintenance).

3. User requirements keep evolving. As users gain experience with the system, they discover new needs and improvements; organizations also change their business processes, driving perfective changes.

4. Software is "soft" — change is expected. Unlike hardware, software is expected to be changeable; users and managers naturally request modifications after delivery.

5. Systems live a long life. Software often outlives its original architecture and developers. The working system becomes a valuable asset that must be kept alive through maintenance rather than rewritten (rewriting risks losing behaviour, and is expensive).

6. Maintenance is huge. Maintenance typically consumes 60–80% of total life-cycle cost and the majority of the effort of software organizations — proof that it cannot be avoided; it is the dominant phase of the life cycle.

7. Prevention requires maintenance too. Even "do-nothing" software eventually needs preventive/re-engineering to remain maintainable.

The maintenance paradox / last phase reality

Since both the software and its environment keep changing while the software is in use, some form of modification is unavoidable — making maintenance intrinsically inevitable, not optional. The only practical choice is to plan for it (good documentation, modular design, configuration management) so it is manageable.

Summary: maintenance is unavoidable because (a) defects always remain, (b) the environment always changes, and (c) requirements always evolve — and because delivered software is a long-lived asset that must be kept both working and cost-effective.

Reverse Engineering and Software Re-engineering

Reverse Engineering

Reverse engineering is the process of analyzing an existing software system (or hardware) to identify its components and their interrelationships and to create representations of the system at a higher level of abstraction — deriving design information from the code. The system itself is not changed; it is a recovery/'understanding' activity.

• Typical outputs: design models recovered from code — e.g., structure charts, UML class/sequence diagrams, dataflow diagrams, pseudo-code or architecture-level descriptions.
• Activities: extracting program structures, identifying modules, building call graphs, regenerating documentation.
• Purpose:
  • Understanding legacy systems whose documentation is lost/outdated,
  • Re-documentation (create/update documentation),
  • Design recovery (reconstruct design decisions),
  • Preparing for future changes, migration, or re-implementation;
  • also used in security (e.g., malware analysis) and interoperability research.

Legacy code ──[reverse engineering]──▶ High-level design / documentation (no code change)

Re-engineering (Software Re-engineering)

Re-engineering is the examination and alteration of a subject system to reconstitute it in a new form with the goal of improving quality, maintainability, and evolvability — it is a forward-engineering-like reconstruction of the existing system. It changes the system.

• Typical re-engineering process (the "re-engineering model"):
  1. Inventory analysis — catalogue existing system/quality.
  2. Reverse engineering — understand the existing system (recover design).
  3. Restructuring — reorganize code/data without changing functionality (improve structure, remove dead code, convert to structured forms).
  4. Forward engineering — introduce new functionality/changes applying modern techniques, generate a new improved system.

Legacy system ──reverse──▶ understand ──restructure/forward──▶ Re-engineered system (improved)

How they relate to legacy systems

• Legacy systems are old, often critical systems built with outdated technology, poorly documented, and hard to maintain; yet they embody valuable business logic.
• Reverse engineering is the first step — it recovers the true structure/behaviour of the legacy system so that its logic is understood (essential when documentation is inadequate or the original developers are gone).
• Re-engineering then uses that understanding to renovate the legacy system — improving maintainability, moving to modern platforms/languages, fixing architectural weaknesses — while preserving the system's functional value, rather than rewriting from scratch (which is riskier and slower).

Key difference table

Aspect	Reverse Engineering	Re-engineering
Goal	Understand/analyze the system	Improve/reconstruct the system
Changes code?	No	Yes
Direction	Code → design (backwards)	Design → new code (forwards, after reverse)
Output	Models/documentation	An improved, modernized system
Input	Existing (often legacy) system	Existing system (understood via reverse eng.)
Typical use	Documentation recovery, legacy analysis	Modernization/restructuring of legacy software

Summary: reverse engineering extracts knowledge from a legacy system without changing it; re-engineering uses that knowledge to rebuild/restructure the legacy system into a higher-quality, more maintainable one.