lOMoARcPSD|63503577

M5 se - module 5

software engineering ([Link] Institute of Technology)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])
 lOMoARcPSD|63503577

Se

Module -5

SOFTWARE MAINTENANCE AND SOFTWARE CONFIGURATION MANAGEMENT:

Software maintenance:
1. What is Software Maintenance?
2. Factors that Mandate Change
3. Lehman’s Laws of system evolution
4. Types of software maintenance
5. Software maintenance process and actives
6. Reverse Engineering, Software Re-engineering
7. Patterns for Software Maintenance
8. Tool support for Software Maintenance
Software Configuration Management:
9. The baseline of Software Life Cycle
10. What is Software Configuration Management
11. Why Software Configuration Management
12. Software Configuration Management Functions
13. Software Configuration Management Tools.

Software maintenance:
What is Software Maintenance?

It begins almost immediately. Software is released to end users, and within days, bug reports filter back
to the software engineering organization. Within weeks, one class of users indicates that the software
must be changed so that it can accommodate the special needs of their environment. And within
months, another corporate group who wanted nothing to do with the software when it was released
now recognizes that it may provide them with unexpected benefit. They’ll need a few enhancements to
make it work in their world.

The challenge of software maintenance has begun. You’re faced with a growing queue of bug fixes,
adaptation requests, and outright enhancements that must be planned, scheduled, and ultimately
accomplished. Before long, the queue has grown long and the work it implies threatens to overwhelm
the available resources. As time passes, your organization finds that it’s spending more money and time
maintaining existing programs than it is engineering new applications. In fact, it’s not unusual for a
software organization to expend as much as 60 to 70 percent of all resources on software maintenance.

You may ask why so much maintenance is required and why so much effort is expended. Osborne and
Chikofsky [Osb90] provide a partial answer:

Much of the software we depend on today is on average 10 to 15 years old. Even when these programs
were created using the best design and coding techniques known at the time [and most were not], they
were created when program size and storage space were principle concerns. They were then migrated to
new platforms, adjusted for changes in machine and operating system technology and enhanced to meet
new user needs—all without enough regard to overall architecture. The result is the poorly designed

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

structures, poor coding, poor logic, and poor documentation of the software systems we are now called
on to keep running . . .

Another reason for the software maintenance problem is the mobility of software people. It is likely that
the software team (or person) that did the original work is no longer around. Worse, other generations
of software people have modified the system and moved on. And today, there may be no one left who
has any direct knowledge of the legacy system.

As I noted in Chapter 22, the ubiquitous nature of change underlies all software work. Change is
inevitable when computer-based systems are built; therefore, you must develop mechanisms for
evaluating, controlling, and making modifications.

Throughout this book, I’ve emphasized the importance of understanding the problem (analysis) and
developing a well-structured solution (design). In fact, Part 2 of the book is dedicated to the mechanics
of these software engineering actions, and Part 3 focuses on the techniques required to be sure you’ve
done them correctly. Both analysis and design lead to an important software characteristic that we call
maintainability. In essence, maintainability is a qualitative indication1 of the ease with which existing
software can be corrected, adapted, or enhanced. Much of what software engineering is about is
building systems that exhibit high maintainability.

But what is maintainability? Maintainable software exhibits effective modularity (Chapter 8). It makes
use of design patterns (Chapter 12) that allow ease of understanding. It has been constructed using well-
defined coding standards and conventions, leading to source code that is self-documenting and
understandable. It has undergone a variety of quality assurance techniques (Part 3 of this book) that
have uncovered potential maintenance problems before the software is released. It has been created by
software engineers who recognize that they may not be around when changes must be made. Therefore,
the design and implementation of the software must “assist” the person who is making the change.

. What is Software Maintenance?

In the context of Masters of Technology ([Link]) students, Software Maintenance refers to the complex
and ongoing process of modifying, updating, and optimizing a software system after its initial
deployment, to ensure it continues to meet evolving user requirements, operational environments, and
business goals. This is a critical activity in the software lifecycle because software, even once deployed,
requires constant attention to address issues, improve functionality, and adapt to external changes.

Software maintenance involves:( 😊types of s/w maintenance)

 Corrective Maintenance: This involves identifying and fixing defects, bugs, or issues in the
software that arise after deployment. These problems could be discovered through user reports
or testing in the production environment.

 Adaptive Maintenance: This ensures the software remains functional as external systems, such
as hardware, operating systems, or third-party libraries, evolve over time. This may involve
updating the software to support newer versions of operating systems or adapting it to work
with newly introduced hardware components.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

 Perfective Maintenance: This focuses on refining the software by implementing new features or
enhancements based on user feedback, changing business needs, or new technology
developments. The goal is to improve the software's performance, usability, and overall value.

 Preventive Maintenance: This involves analyzing and modifying the system to prevent future
issues. It may include optimizing code to reduce complexity, refactoring code to improve
maintainability, or addressing design flaws that could cause problems in the future.

Software maintenance is essential because, in real-world scenarios, no software is ever truly finished; it
evolves based on new requirements, technological advancements, and user expectations.

2. Factors that Mandate Change

Several key factors drive the need for software maintenance and mandate changes to the software. For
[Link]-level students, it’s important to understand both technical and non-technical drivers of software
change:

1. Technological Evolution:

o Software must evolve to keep pace with the rapid advancement of technology. New
frameworks, tools, programming languages, and hardware advancements often require
that the software be updated for compatibility. For example, integrating with new cloud
platforms or adopting modern programming paradigms like microservices may
necessitate significant changes.

2. User Requirements and Feedback:

o As users interact with the software, they may identify new needs, issues, or potential
areas for enhancement. Software must be continuously refined to meet changing user
expectations, which can range from minor feature enhancements to major user interface
redesigns or completely new modules.

3. Security and Privacy Concerns:

o As cyber threats evolve, vulnerabilities in the software may emerge, necessitating

security updates or patches. In addition, changing regulatory environments, such as the
introduction of new data protection laws like GDPR, often require software updates to
ensure compliance with legal and privacy standards.

4. Performance and Scalability Issues:

o As the user base grows or the system is expected to handle more data or traffic,
performance and scalability become critical issues. The software may need to be
optimized, refactored, or even re-architected to handle increased loads, reduce latency,
or improve system responsiveness.

5. Changing Business Goals or Market Conditions:

o The business context in which software operates is dynamic. New business strategies,
market opportunities, or shifts in customer demand may necessitate changes to the

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

software. For instance, a software application designed for one market may need to be
adapted for use in different regions or industries.

6. End-of-Life of External Dependencies:

o Software often relies on third-party libraries, platforms, or APIs. When these

dependencies reach their end of life (EOL), they may no longer be supported, leading to
security risks or compatibility issues. This forces developers to update or replace those
dependencies to maintain the software's integrity.

7. Regulatory and Legal Compliance:

o Changes in legal frameworks (e.g., tax laws, intellectual property rights, or industry-
specific standards) may require software modifications to ensure compliance. This can
be particularly relevant in regulated industries like healthcare, finance, and
telecommunications.

8. Integration with New Systems or Technologies:

o As organizations adopt new technologies, software might need to be modified to

integrate with other systems, databases, or services. For example, incorporating artificial
intelligence or machine learning capabilities could require significant changes to the
underlying software architecture.

9. Legacy System Compatibility:

o Older systems or software versions often need to be updated to ensure compatibility

with newer technologies. Legacy systems may have constraints that require gradual
refactoring, optimization, or even migration to new platforms.

10. Maintenance of Quality and Reliability:

o Over time, software may degrade in quality due to growing complexity, code rot, or
accumulation of technical debt. Regular maintenance ensures that the software remains
reliable, maintainable, and of high quality. This includes addressing code smells,
refactoring, and conducting thorough testing to avoid future issues.

Lehman’s Laws of System Evolution

M.M. Lehman’s Laws of System Evolution describe the fundamental principles that govern the evolution
of software systems over time. These laws are critical for understanding the dynamics of large, complex
software systems and their ongoing development. They provide insight into how software evolves in
response to changing needs, technologies, and environments. Lehman’s Laws are particularly useful for
Masters of Technology ([Link]) students, as they can guide engineers in managing long-term software
projects effectively.

Here’s a breakdown of Lehman’s Laws of System Evolution:

1. Continuing Change

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

 Law: "A system must be continually adapted or it becomes progressively less useful in
supporting the user's needs."

 Explanation: Software systems must constantly evolve to meet the ever-changing needs of users,
new technologies, business requirements, and environmental changes. Failure to evolve results
in "software aging," where the system becomes obsolete and less effective over time.

 Example: A mobile app must be updated regularly to work with newer versions of mobile
operating systems (e.g., iOS or Android).

2. Increasing Complexity

 Law: "As a system evolves, its complexity increases unless steps are taken to reduce it."

 Explanation: Software systems tend to become more complex as new features, enhancements,
and fixes are added over time. This increasing complexity can make the system harder to
understand, maintain, and modify.

 Example: A web application with multiple features and integrations over time may become
harder to scale or update if the codebase is not managed well (e.g., through refactoring).

3. Self-Regulation

 Law: "The process of software evolution is self-regulating, with the rate of change stabilizing
over time."

 Explanation: Software systems evolve at a predictable rate due to feedback mechanisms within
the system. Initially, changes might be frequent and large, but as the system matures, changes
tend to become smaller and more incremental. This stabilization can be influenced by
organizational processes and system design.

 Example: A mature product may have a slower rate of updates compared to a new product
version, where frequent bug fixes and feature additions are common.

4. Conservation of Organizational Stability

 Law: "The number of people involved in maintaining a system tends to remain constant or
increases slowly over time."

 Explanation: Despite ongoing changes in the software, the organizational structure surrounding
the software system tends to remain stable. The development, maintenance, and support teams
typically maintain a consistent size and set of roles. However, if the system grows too large,
additional resources might be needed.

 Example: As a system scales, more developers, testers, and support staff may be needed, but the
organization typically adapts gradually to handle this growth.

5. Conservation of Familiarity

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

 Law: "The functionality of a system is preserved over time, and users and developers prefer
incremental changes that maintain the system’s familiar interface, structure, and user
experience."

 Explanation: Software systems tend to evolve in ways that preserve the familiarity of their
design. Users and developers resist drastic changes to functionality, interfaces, or behavior.
Keeping the user experience stable helps maintain trust and usability.

 Example: A software application may update its features or backend, but it often retains its core
design and layout, even if new features are added.

6. Incremental Change

 Law: "Changes to the system occur in small, manageable increments, rather than large,
disruptive modifications."

 Explanation: Software evolves gradually through incremental changes, such as small updates,
bug fixes, and minor feature additions. Large-scale changes, like complete rewrites or radical
overhauls, are risky and generally avoided unless absolutely necessary.

 Example: An enterprise resource planning (ERP) system may evolve through a series of patches
and feature expansions rather than a complete redesign of the system architecture.

7. Declining Quality

 Law: "The quality of a system tends to decline over time unless corrective actions are taken."

 Explanation: As software evolves, its quality can degrade due to factors such as the
accumulation of bugs, technical debt, lack of refactoring, or outdated architecture. Regular
maintenance, testing, and refactoring are essential to maintain quality.

 Example: A legacy system may show signs of declining performance due to the increasing
difficulty in adding new features without addressing underlying issues like code complexity or
outdated technologies.

Summary of Lehman’s Laws

1. Continuing Change: Systems must evolve continuously to remain relevant.

2. Increasing Complexity: Systems become more complex over time unless actively managed.

3. Self-Regulation: Evolution processes stabilize over time due to feedback mechanisms.

4. Conservation of Organizational Stability: The size and structure of the team remain stable,
though they may slowly grow.

5. Conservation of Familiarity: Changes maintain the system's familiar structure to avoid disrupting
users and developers.

6. Incremental Change: Changes happen in small, manageable increments.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

7. Declining Quality: The quality of the system declines unless properly maintained.

Implications for [Link] Students

For [Link] students, understanding Lehman’s Laws is crucial when dealing with large-scale software
systems. These laws provide insight into the natural progression of software evolution and the
challenges associated with maintaining complex systems over time. Key takeaways for students include:

 The importance of continuous maintenance and evolution of software systems.

 The need to manage complexity through modularity, code refactoring, and careful design.

 The benefit of adopting incremental change strategies (e.g., agile development).

 The necessity to monitor and preserve system quality through regular testing, optimization, and
addressing technical debt.

By applying Lehman’s Laws, software engineers can better plan for long-term software development,
anticipate challenges, and develop strategies for maintaining the stability, usability, and relevance of
software over time.

Type of Maintenance:

Type of
Purpose Focus Examples
Maintenance

- Fixing crashes
Corrective Fixing defects and bugs in the Error resolution and bug - Correcting incorrect
Maintenance system. fixing outputs
- Resolving reported bugs

- Updating software for

new OS versions
Adaptive Adapting the software to System adaptation to new - Adjusting for new
Maintenance changes in the environment. environments hardware
- Integrating with updated
APIs

- Adding new features

Perfective Improving performance, Enhancements and
- Improving UI/UX
Maintenance features, and user experience. optimization
- Optimizing performance

- Refactoring code
- Removing deprecated
Preventive Preventing future issues and Proactive changes and
libraries
Maintenance ensuring software longevity. code improvement
- Updating
documentation

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

5. Software Maintenance Process and Activities

Software maintenance is a critical part of the software lifecycle, aimed at ensuring that software
continues to function effectively over time. It involves the process of modifying, updating, and improving
a system after it has been delivered to the user. The software maintenance process includes several
activities, each designed to handle different aspects of the system’s ongoing evolution. Below is a
detailed explanation of the software maintenance process and the main activities involved.

Software Maintenance Process

The software maintenance process can be broken down into a series of steps that guide the changes,
improvements, and fixes to a system after its deployment. While the specifics can vary depending on the
organization or project, a general process includes the following stages:

1. Problem/Request Identification

 Objective: This stage involves identifying the need for maintenance, which may come from
users, testers, or automated monitoring systems. Problems could be bugs, performance issues,
or user requests for new features.

 Inputs: User feedback, bug reports, system logs, and monitoring data.

 Key Activities:

o Gathering information on the problem.

o Analyzing the severity and priority of the issue.

o Recording the problem in a maintenance log or issue tracking system.

2. Impact Analysis

 Objective: In this stage, the maintenance team evaluates the impact of the change on the
existing system. This includes analyzing how the fix or enhancement will affect other parts of the
software, including the dependencies, interfaces, and performance.

 Inputs: Detailed reports on the problem, source code, system architecture, and design
documentation.

 Key Activities:

o Assessing the scope of the change (is it a minor fix or a major change?).

o Identifying affected components, subsystems, and modules.

o Considering how the change might impact users or existing functionality.

o Evaluating testing and validation requirements.

3. Planning

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

 Objective: Planning involves deciding the approach and timeline for implementing the changes,
as well as allocating resources and tasks. In this stage, the team will prioritize maintenance
activities based on business needs, criticality, and complexity.

 Inputs: Impact analysis, project timelines, resource availability.

 Key Activities:

o Prioritizing issues based on urgency, business value, and resources.

o Assigning responsibilities to team members.

o Estimating time and effort for the changes.

o Defining the strategy for implementing and testing the maintenance.

4. Design and Development

 Objective: In this stage, the maintenance team designs and implements the required changes to
the software. The design phase ensures that the maintenance solution aligns with the software
architecture and does not introduce new issues.

 Inputs: Impact analysis, requirements from the user, design documentation.

 Key Activities:

o Making design modifications if needed (especially for adaptive or perfective

maintenance).

o Writing or updating code to fix bugs, add features, or improve performance.

o Refactoring code for maintainability or efficiency.

o Applying patches to third-party libraries or external dependencies if needed.

5. Testing and Verification

 Objective: Once the changes are implemented, they need to be thoroughly tested to ensure
they do not introduce new bugs or regressions. Testing verifies that the maintenance activities
meet the intended objectives.

 Inputs: Modified software, test cases, testing tools, and environments.

 Key Activities:

o Unit testing: Ensuring that individual components work as expected after the change.

o Integration testing: Verifying that new changes integrate well with existing systems.

o System testing: Ensuring that the overall system works after the maintenance.

o Regression testing: Making sure that the changes do not break any existing features or
functionality.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

o Performance testing: Ensuring that the changes do not negatively impact the system’s
performance.

6. Implementation/Deployment

 Objective: Once the changes have passed testing, they are deployed to the production
environment. This phase also includes user acceptance testing (UAT) and the actual rollout of the
new version of the software.

 Inputs: Tested software, deployment plan, rollback strategies.

 Key Activities:

o Deploying the fix, update, or enhancement to the production environment.

o Monitoring the system post-deployment to ensure it works as expected.

o Handling any emergency patches or fixes if issues arise immediately after deployment.

o Informing users or customers about new features, fixes, or changes.

7. Documentation and Reporting

 Objective: After deployment, it is essential to document the changes and keep records for future
reference. This documentation is useful for both internal teams and for providing users with
updated information.

 Inputs: Change logs, deployment notes, testing reports.

 Key Activities:

o Updating technical and user documentation to reflect changes made during

maintenance.

o Writing detailed release notes or patch notes.

o Documenting issues faced and resolutions for future reference.

o Maintaining logs of maintenance activities, fixes, and enhancements.

8. Post-Implementation Review

 Objective: After the maintenance is complete, a review is conducted to evaluate the

effectiveness of the changes and the overall maintenance process. This step helps to improve
future maintenance efforts.

 Inputs: Maintenance logs, user feedback, performance metrics.

 Key Activities:

o Reviewing user feedback to assess if the issue was resolved successfully.

o Analyzing system performance and user experience post-deployment.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

o Identifying any lessons learned from the maintenance process.

Key Software Maintenance Activities

The main activities within the software maintenance process can be grouped into four categories based
on the type of maintenance being performed. These include:

1. Bug Fixing (Corrective Maintenance)

 Identifying and resolving software defects.

 Debugging code to resolve unexpected behaviors or system crashes.

 Validating that the fix does not introduce new issues or regressions.

2. Enhancements (Perfective Maintenance)

 Implementing new features based on user feedback or market demands.

 Optimizing existing code to improve performance or reduce complexity.

 Updating user interfaces (UI) to enhance user experience.

3. Adaptation (Adaptive Maintenance)

 Modifying the software to work with new operating systems, hardware, or third-party tools.

 Updating dependencies (e.g., libraries or APIs) that have become obsolete or incompatible.

 Ensuring that the software continues to function in a changing technical environment.

4. Preventive Maintenance

 Refactoring or restructuring the codebase to reduce technical debt.

 Optimizing code and improving maintainability, performance, and scalability.

 Removing outdated or unused features, and ensuring that documentation is up to date.

Reverse engineering.

The term reverse engineering has its origins in the hardware world. A company disassembles a
competitive hardware product in an effort to understand its competitor’s design and manufacturing
“secrets.” These secrets could be easily understood if the competitor’s design and manufacturing
specifications were obtained. But these documents are proprietary and unavailable to the company
doing the reverse engineering. In essence, successful reverse engineering derives one or more design
and manufacturing specifications for a product by examining actual specimens of the product.

Reverse engineering for software is quite similar. In most cases, however, the pro gram to be reverse
engineered is not a competitor’s. Rather, it is the company’s own work (often done many years earlier).
The “secrets” to be understood are obscure because no specification was ever developed. Therefore,

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

reverse engineering for software is the process of analyzing a program in an effort to create a
representation of the program at a higher level of abstraction than source code. Reverse engineer ing is a
process of design recovery. Reverse engineering tools extract data, architec tural, and procedural design
information from an existing program.

10.3.4 Reverse Engineering

Reverse engineering is applied to a set of source code elements and results in a set of model elements.
The purpose of this type of transformation is to recreate the model for an existing system, either
because the model was lost or never created, or because it became out of sync with the source code.
Reverse engineering is essentially an inverse transformation of forward engineering. Reverse engineering
creates a UML class for each class declaration statement, adds an attribute for each field, and adds an
operation for each method. However, because forward engineering can lose information (e.g.,
associations are turned into collections of references), reverse engineering does not necessarily recreate
the same model. Although many CASE tools support reverse engineering, CASE tools provide, at best, an
approximation that the developer can use to rediscover the original model.

Reengineering:

In a seminal article written for the Harvard Business Review, Michael Hammer [Ham90] laid the
foundation for a revolution in management thinking about business processes and computing: It is time
to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we
should obliterate them and start over. We should “reengineer” our businesses: use the power of modern
information technology to radically redesign our business processes in order to achieve dramatic
improvements in their performance.

Every company operates according to a great many unarticulated rules. . . . Reengi neering strives to
break away from the old rules about how we organize and conduct our business.

Like all revolutions, Hammer’s call to arms resulted in both positive and negative changes. During the
1990s, some companies made a legitimate effort to reengineer, and the results led to improved
competitiveness. Others relied solely on downsizing and outsourcing (instead of reengineering) to
improve their bottom line. “Mean” organizations with little potential for future growth often resulted
[DeM95a].

By the end of the first decade of the twenty-first century, the hype associated with reengineering waned,
but the process itself continues in companies large and small. The nexus between business
reengineering and software engineering lies in a “system view.”

Software is often the realization of the business rules that Hammer discusses. Today, major companies
have tens of thousands of computer programs that support the “old business rules.” As managers work
to modify the rules to achieve greater effectiveness and competitiveness, software must keep pace. In
some cases, this means the creation of major new computer-based systems.2 But in many others, it
means the modification or rebuilding of existing applications.

In the sections that follow, I examine reengineering in a top-down manner, begin ning with a brief
overview of business process reengineering and proceeding to a more detailed discussion of the
technical activities that occur when software is reengineered.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

A reengineering project is the redesign and reimplementation of an existing system triggered by

technology enablers or by business processes [Hammer & Champy, 1993]. Sometimes, the functionality
of the new system is extended, but the essential purpose of the system remains the same. The
requirements of the new system are extracted from an existing system.

Software Reengineering:

The scenario is all too common: An application has served the business needs of a company for 10 or 15
years. During that time it has been corrected, adapted, and enhanced many times. People approached
this work with the best intentions, but good software engineering practices were always shunted to the
side (due to the press of other matters). Now the application is unstable. It still works, but every time a
change is attempted, unexpected and serious side effects occur. Yet the application must continue to
evolve. What to do?

Unmaintainable software is not a new problem. In fact, the broadening emphasis on software
reengineering has been spawned by software maintenance problems that have been building for more
than four decades.

A Software Reengineering Process Model

Reengineering takes time, it costs significant amounts of money, and it absorbs resources that might be
otherwise occupied on immediate concerns. For all of these reasons, reengineering is not accomplished
in a few months or even a few years. Reengineering of information systems is an activity that will absorb
information technology resources for many years. That’s why every organization needs a pragmatic
strategy for software reengineering

A workable strategy is encompassed in a reengineering process model. I’ll discuss the model later in this
section, but first, some basic principles.

Reengineering is a rebuilding activity. To better understand it, consider an analogous activity: the
rebuilding of a house. Consider the following situation. You’ve purchased a house in another state.
You’ve never actually seen the property, but you acquired it at an amazingly low price, with the warning
that it might have to be completely rebuilt. How would you proceed?

• Before you can start rebuilding, it would seem reasonable to inspect the house. To determine whether
it is in need of rebuilding, you (or a profes sional inspector) would create a list of criteria so that your
inspection would be systematic.

• Before you tear down and rebuild the entire house, be sure that the structure is weak. If the house is
structurally sound, it may be possible to “remodel” without rebuilding (at much lower cost and in much
less time).

• Before you start rebuilding be sure you understand how the original was built. Take a peek behind the
walls. Understand the wiring, the plumbing, and the structural internals. Even if you trash them all, the
insight you’ll gain will serve you well when you start construction.

• If you begin to rebuild, use only the most modern, long-lasting materials. This may cost a bit more now,
but it will help you to avoid expensive and time-consuming maintenance later.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

• If you decide to rebuild, be disciplined about it. Use practices that will result in high quality—today and
in the future.

Although these principles focus on the rebuilding of a house, they apply equally well to the
reengineering of computer-based systems and applications. To implement these principles, you can use a
software reengineering process model that defines six activities, shown in Figure 29.2. In some cases,
these activi ties occur in a linear sequence, but this is not always the case. For example, it may be that
reverse engineering (understanding the internal workings of a program) may have to occur before
document restructuring can commence.

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])

 lOMoARcPSD|63503577

Downloaded by Mahadevaswamy S N (snmahadevaswamy@[Link])