Chapter 36

■ Maintenance and Reengineering

Slide Set to accompany

Software Engineering: A Practitioner’s Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 1
Software Maintenance
■ 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.
■ 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.
■ All of this work is software maintenance

2
Maintainable Software
■ Maintainable software exhibits effective modularity
■ It makes use of design patterns 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 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

3
Software Supportability
■ “the capability of supporting a software system over its whole product life.
■ This implies satisfying any necessary needs or requirements, but also the provision of
equipment, support infrastructure, additional software, facilities, manpower, or any other
resource required to maintain the software operational and capable of satisfying its
function.” [SSO08]
■ The software should contain facilities to assist support personnel when a defect is
encountered in the operational environment (and make no mistake, defects will be
encountered).
■ Support personnel should have access to a database that contains records of all
defects that have already been encountered—their characteristics, cause, and cure.

4
Reengineering
Reengineering is most commonly defined as the redesign of business
processes—and the associated systems and organizational structures—to
achieve a dramatic improvement in business performance. ... It is the
examination and change of five components of the business strategy, process,
technology, organization, and culture.

Business
processes

IT Software
systems Reengineering applications

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 5
 Business Process Reengineering
■ Business definition. Business goals are identified within the context of four key drivers:
cost reduction, time reduction, quality improvement, and personnel development and
empowerment.
■ Process identification. Processes that are critical to achieving the goals defined in the
business definition are identified.
■ Process evaluation. The existing process is thoroughly analyzed and measured.
■ Process specification and design. Based on information obtained during the first three
BPR activities, use-cases are prepared for each process that is to be redesigned.
■ Prototyping. A redesigned business process must be prototyped before it is fully
integrated into the business.
■ Refinement and instantiation. Based on feedback from the prototype, the business
process is refined and then instantiated within a business system.

6
Business Process Reengineering

7
Software Reengineering

Forward inventory
engineering analysis

Data document
restructuring restructuring

code reverse
restructuring engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 8
Inventory Analysis
■ build a table that contains all applications
■ establish a list of criteria, e.g.,
■ name of the application
■ year it was originally created
■ number of substantive changes made to it
■ total effort applied to make these changes
■ date of last substantive change
■ effort applied to make the last change
■ system(s) in which it resides
■ applications to which it interfaces, ...
■ analyze and prioritize to select candidates for
reengineering

9
 Document Restructuring
■ Weak documentation is the trademark of
many legacy systems.
■ But what do we do about it? What are our
options?
■ Options …
■ Creating documentation is far too time
consuming. If the system works, we’ll live
with what we have. In some cases, this is the
correct approach.
■ Documentation must be updated, but we have
limited resources. We’ll use a “document
when touched” approach. It may not be
necessary to fully redocument an application.
■ The system is business critical and must be
fully redocumented. Even in this case, an
intelligent approach is to pare documentation
to an essential minimum.

10
 Reverse Engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 11
Code Restructuring
■ Source code is analyzed using
a restructuring tool.
■ Poorly design code segments
are redesigned
■ Violations of structured
programming constructs are
noted and code is then
restructured (this can be done
automatically)
■ The resultant restructured code
is reviewed and tested to
ensure that no anomalies have
been introduced
■ Internal code documentation is
updated. 12
 Data Restructuring
■ Unlike code restructuring, which occurs at a
relatively low level of abstraction, data
structuring is a full-scale reengineering activity
■ In most cases, data restructuring begins with a
reverse engineering activity.
■ Current data architecture is dissected and necessary
data models are defined (Chapter 9).
■ Data objects and attributes are identified, and existing
data structures are reviewed for quality.
■ When data structure is weak (e.g., flat files are
currently implemented, when a relational approach
would greatly simplify processing), the data are
reengineered.
■ Because data architecture has a strong influence
on program architecture and the algorithms that
populate it, changes to the data will invariably
result in either architectural or code-level
changes. 13
14
Forward Engineering
1. The cost to maintain one line of source code may
be 20 to 40 times the cost of initial development of that
line.
2. Redesign of the software architecture (program
and/or data structure), using modern design concepts,
can greatly facilitate future maintenance.
3. Because a prototype of the software already exists,
development productivity should be much higher than
average.
4. The user now has experience with the software.
Therefore, new requirements and the direction of
change can be ascertained with greater ease.
5. CASE tools for reengineering will automate some
parts of the job.
6. A complete software configuration (documents,
programs and data) will exist upon completion of
preventive maintenance.

15