Maintaining Information Systems and Reengineering

1
COSC4406 Software Engineering

• Lecture 18
• Maintaining Information Systems and Reengineering

18.1
2
Learning Objectives

• Explain and contrast four types of maintenance
• Describe several factors that influence the cost
  of maintaining an information system
• Describe maintenance management issues including
  alternative organizational structures, quality
  measurement, processes for handling change
  requests and configuration management
• Explain the role of CASE when maintaining
  information systems

18.2
3
The Process of Maintaining Information Systems

• Process of returning to the beginning of the SDLC
  and repeating development steps focusing on
  system change until the change is implemented
• Four major activities
• Obtaining maintenance requests
• Transforming requests into changes
• Designing changes
• Implementing changes

18.3
4
The Process of Maintaining Information Systems

• Maintenance
• Changes made to a system to fix or enhance its
  functionality
• Deliverables and Outcomes
• Development of a new version of the software and
  new versions of all design documents created or
  modified during the maintenance effort

18.4
5
Conducting System Maintenance

• Corrective maintenance
• Changes made to a system to repair flaws in its
  design, coding, or implementation
• Adaptive maintenance
• Changes made to a system to evolve its
  functionality to changing business needs or
  technologies
• Perfective maintenance
• Changes made to a system to add new features or
  to improve performance
• Preventive maintenance
• Changes made to a system to avoid possible future
  problems

18.5
6
Types
7
Conducting System MaintenanceThe Cost of
Maintenance

• Many organizations allocate eighty percent of
  information systems budget to maintenance
• Factors that influence system maintainability
• Latent defects
• Number of customers for a given system
• Quality of system documentation (Fig. 18-7)
• Maintenance personnel
• Tools
• Software structures

18.7
8
Budget change for maintenance
9
Documentation eases maintenance
10
Conducting System MaintenanceManaging Maintenance

• Number of people working in maintenance has
  surpassed number working in development
• Three possible organizational structures
• Separate
• Maintenance group consists of different personnel
  than development group
• Combined
• Developers also maintain systems
• Functional
• Maintenance personnel work within the functional
  business unit
• Table 18-4 presents the advantages and
  disadvantages to each approach

18.10
11
Different Maintenance Structures
12
Conducting System MaintenanceManaging Maintenance

• Assignment of personnel
• Maintenance work is often viewed negatively by IS
  personnel
• Organizations have historically have rewarded
  people involved in new development better than
  maintenance personnel
• Organizations often rotate personnel in and out
  of maintenance roles in order to lessen negative
  feelings about maintenance

18.12
13
Conducting System MaintenanceMeasures of
Effectiveness

• Number of failures
• Time between each failure
• Type of failure
• Mean time between failures (MTBF)
• A measurement of error occurrences that can be
  tracked over time to indicate the quality of a
  system

18.13
14
Controlling Maintenance Requests

• Determine type of request
• Error
• Adaptation
• Enhancement
• Figure 18-9 shows a flowchart for a request
  procedure

18.14
15
Figure 18-9Flowchart of how to control
maintenance requests (Adapted from Pressman, 1992)
18.15
16
Configuration Management

• The process of assuring that only authorized
  changes are made to the system
• Baseline modules
• Software modules that have been tested,
  documented, and approved to be included in the
  most recently created version of a system
• System librarian
• A person responsible for controlling the checking
  out and checking in of baseline modules when a
  system is being developed or maintained
• Build routines
• Guidelines that list the instructions to
  construct an executable system from the baseline
  source code

18.16
17
Role of CASE and Automated Development Tools in
Maintenance

• Traditional systems development
• Emphasis on coding and testing
• Changes are implemented by coding and testing
  first
• Documentation is done after maintenance is
  performed
• Keeping documentation current is often neglected
  due to time-consuming nature of task

• Development with CASE
• Emphasis is on design documents
• Changes are implemented in design documents.
• Code is regenerated using code generators
• Documentation is updated during maintenance

18.17
18
Website Maintenance

• Special considerations
• 24 X 7 X 365
• Nature of continuous availability makes
  maintenance challenging
• Pages under maintenance can be locked
• Date and time stamps
• Check for broken links
• HTML Validation
• Pages should be processed by a code validation
  routine before publication

18.18
19
Website Maintenance

• Special considerations (continued)
• Re-registration
• When content significantly changes, site may need
  to be re-registered with search engines
• Future Editions
• Consistency is important to users
• Post indications of future changes to the site
• Batch changes

18.19
20
Business Process Reengineering (BPR)
21
BPR Principles

• Organize around outcomes, not tasks.
• Have those who use the output of the process
  perform the process.
• Incorporate information processing work into the
  real work that produces the raw information.
• Treat geographically dispersed resources as
  though they were centralized.
• Link parallel activities instead of integrated
  their results.
• Put the decision point where the work is
  performed, and build control into the process.
• Capture data once, at its source.

22
Software Reengineering
i
n
v
e
n
t
o
r
y
f
o
r
w
a
r
d
a
n
a
l
y
s
i
s
e
n
g
i
n
e
e
r
i
n
g
d
a
t
a
d
o
c
u
m
e
n
t
r
e
s
t
r
u
c
t
u
r
i
n
g
r
e
s
t
r
u
c
t
u
r
i
n
g
r
e
v
e
r
s
e
c
o
d
e
e
n
g
i
n
e
e
r
i
n
g
r
e
s
t
r
u
c
t
u
r
i
n
g
23
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

24
Restructuring

• Document Restructuring
• options range from doing nothing to regeneration
  of all documentation for critical system
• Reverse Engineering
• the intent here is to achieve design recovery
• Code Restructuring
• rebuild code
• Data Restructuring
• data architecture

25
Reverse Engineering

• Magic slot
• We feed an unstructured, undocumented source
  listing into the slot and our the other end comes
  full documentation for the program.
• RE
• Understand processing
• Data
• Interfaces

26
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.
27
Summary

• Maintenance
• Corrective
• Adaptive
• Perfective
• Preventive
• Cost of maintenance
• Managing Maintenance
• Measuring effectiveness of maintenance

18.27
28
Summary

• Controlling maintenance requests
• Configuration management
• Role of CASE and Automated Development Tools in
  Maintenance
• Website Maintenance
• Reengineering
• Reverse engineering

18.28