The chapter will address the following questions:

1
Introduction

• The chapter will address the following questions
• What is systems support?
• What is the role of a repository in systems
  support?
• What is the difference between maintenance,
  enhancement, reengineering, and design recovery?
• What is the maintenance challenge presented by
  the year 2000?

2
What is Systems Support?

• Introduction
• Systems support is the on-going maintenance of a
  system(s) after it has been placed into
  operation. This includes program maintenance and
  system improvements.
• Systems support often requires developers to
  revisit activities typically performed in systems
  analysis, design, and implementation.

3
(No Transcript)
4
What is Systems Support?

• Introduction
• There are three distinct types of system-level
  data storage.
• Central repository. This repository stores all
  system models and detailed specifications.
• Subsets of the central repository are checked out
  to support various planning and development
  projects.
• These subsets are stored as project repositories,
  usually implemented through various CASE tools.
• Program libraries. Store the actual application
  programs that have been placed into production.
• In most shops, a software-based librarian will
  track changes and maintain a few previous
  versions of the software in case a problem arises
  with a new version.

5
What is Systems Support?

• Introduction
• There are three distinct types of system-level
  data storage. (continued)
• Business databases. Store the operational data
  created and maintained by the production
  application programs.
• Systems support is primarily driven by systems
  designers and system builders in support of
  system users.

6
(No Transcript)
7
Systems Maintenance - Correcting Errors

• Introduction
• Regardless of how well designed, constructed, and
  tested a system or application may be, errors or
  bugs will inevitably occur.
• The correcting of bugs is called system
  maintenance, or program maintenance.
• The fundamental objectives of system maintenance
  are
• To make predictable changes to existing programs
  to correct errors that were made during systems
  design and implementation. Consequently, we
  exclude enhancements and new requirements from
  this activity.
• To preserve those aspects of the programs that
  were already correct. Inversely, we try to avoid
  the possibility that fixes'' to programs cause
  other aspects of those programs to behave
  differently.

8
(No Transcript)
9
Systems Maintenance - Correcting Errors

• Define and Validate the Problems
• The first task of the assigned team is to define
  and validate problems.
• This activity will be facilitated by the analyst
  and/or programmer, but it should clearly involve
  the user(s).
• The problem programs are retrieved from the
  program library.
• Working with the user(s), the team should attempt
  to validate the problem(s) by reproducing it.
• If the problem cannot be reproduced, the project
  should be suspended until the problem reoccurs
  and the user can explain the circumstances under
  which it occurred.
• In some cases the bug arises from simple
  misunderstandings or misuse, and corrective
  instructions can bring the entire project to
  closure.

10
Systems Maintenance - Correcting Errors

• Benchmark the Programs and Application
• The program(s) isn't all bad, or it would have
  never been placed into production in the first
  place.
• System maintenance can result in unpredictable
  and undesirable side effects that impact the
  programs or application's overall functionality
  and performance.
• Before making any changes to programs, the
  programs should be executed and tested to
  establish a baseline against which the modified
  programs and applications can be measured.
• This step is performed by the systems analyst
  and/or programmer.
• The users may also participate.

11
Systems Maintenance - Correcting Errors

• Understand the Application and its Programs
• Frequently, system maintenance is not performed
  by the same persons who wrote the program.
• For this reason, we need to gain an understanding
  of the application and the problematic programs.
• Application and program knowledge usually comes
  from studying the source code from the
  benchmarked programs.
• Program understanding can take considerable time.
  
• This activity is slowed by some combination of
  the following limitations
• Poor modular structure.
• Unstructured logic (from prestructured era code).
• Prior maintenance (quick fixes and poorly
  designed extensions).

12
Systems Maintenance - Correcting Errors

• Understand the Application and its Programs
• This activity is slowed by some combination of
  the following limitations (continued)
• Dead code (instructions that cannot be reached or
  executed -- often leftovers from prior testing
  and debugging).
• Poor or inadequate documentation.
• The purpose of application understanding is to
  see the big picture -- that is, how the programs
  fit into the total application and how they
  interact with other programs.

13
Systems Maintenance - Correcting Errors

• Understand the Application and its Programs
• The purpose of program understanding is to gain
  insight into how the program works and doesn't
  work.
• You need to understand the fields (variables) and
  where and how they are used, and you need to
  determine the potential impact of changes
  throughout the program(s).
• Program understanding can also lead to better
  estimates of the time and resources that will be
  required to fix the errors.

14
Systems Maintenance - Correcting Errors

• Edit and Test the Programs
• Given application and program knowledge and
  validated changes, the programmer can now make
  changes to the programs to be modified.
• There is a big difference between editing a new
  program and editing an existing program.
• Changes that you make may have an undesirable
  ripple effect through other parts of the program
  or, worse still, other programs in the
  application.
• The following tests are essential and
  recommended
• Unit testing (essential) ensures that the
  stand-alone program fixes the bug without side
  effects.

15
Systems Maintenance - Correcting Errors

• Edit and Test the Programs
• The following tests are essential and
  recommended (continued)
• System testing (essential) ensures that the
  entire application, of which the modified program
  was a part, still works.
• Regression testing (recommended) extrapolates
  the impact of the changes on program and
  application throughput and response time from the
  before-and-after results using the test data and
  current performance.
• Version control is a process whereby a librarian
  (usually software-based) keeps track of changes
  made to programs.
• This allows recovery of prior versions of the
  programs in the event that new versions cause
  unexpected problems.

16
Systems Maintenance - Correcting Errors

• Update Documentation
• The high cost of system maintenance is due, in
  large part, to failure to update application and
  program documentation.
• If application documentation has changed in the
  slightest, it should be modified in the
  repository and program library.
• Application documentation is usually the
  responsibility of the systems analyst who
  supports that application.
• Program documentation is usually the
  responsibility of the programmer who made the
  program changes.
• Recording application and program changes in the
  repository and program library will help future
  programmers and analysts reduce application
  understanding time during future maintenance.

17
System Recovery - Overcoming the Crash

• Introduction
• A system failure is inevitable.
• It generally results in an aborted or hung''
  program (also called an ABEND'' or crash'')
  and possible loss of data.
• The systems analyst often fixes the system or
  acts as intermediary between the users and those
  who can fix the system.
• System recover activities can be summarized as
  follows
• In many cases the analyst can sit at the user's
  terminal and recover the system.
• In some cases the analyst must contact systems
  operations personnel to correct the problem.

18
System Recovery - Overcoming the Crash

• Introduction
• System recover activities can be summarized as
  follows (continued)
• In some cases the analyst may have to call data
  administration to recover lost or corrupted data
  files or databases.
• In some cases the analyst may have to call
  network administration to fix a local, wide, or
  internetworking problem.
• In some cases the analyst may have to call
  technicians or vendor service representatives to
  fix a hardware problem.
• In some cases the analyst will discover a bug
  caused the crash.
• The analyst attempts to quickly isolate the bug
  and trap it (automatically or by coaching users
  to manually avoid it) so that it can't cause
  another crash.

19
End-User Assistance

• Introduction
• No matter how well users have been trained or how
  well documentation has been written, users will
  require additional assistance.
• The systems analyst is generally on call to
  assist users with the day-to-day use of specific
  applications.
• The most typical activities include
• Routinely observing the use of the system.
• Conducting user-satisfaction surveys and
  meetings.
• Changing business procedures for clarification
  (written and in the repository).
• Providing additional training.
• Logging enhancement ideas and requests in the
  repository.

20
Systems Enhancement and Reengineering

• Introduction
• Adapting an existing system to new requirements
  is an expectation for all newly implemented
  systems.
• Adaptive maintenance forces an analyst to analyze
  the new requirement and return to the appropriate
  phases of systems analysis, design, and
  implementation.
• Most adaptive maintenance is in response to new
  business problems, new information requirements,
  or new ideas for enhancement.
• It is reactionary in nature -- fix it when it
  breaks or when users make a request. This is
  called system enhancement.
• The objective of system enhancement is to modify
  or expand the application system in response to
  constantly changing requirements.

21
Systems Enhancement and Reengineering

• Introduction
• Another type of reactionary maintenance deals
  with changing technology.
• More frequently information system staffs have
  chose to analyze their program libraries to
  determine which applications and programs are
  costing the most to maintain or which ones are
  the most difficult to maintain.
• These systems might be adapted to reduce the
  costs of maintenance. This is classified as
  reengineering.
• The objectives of reengineering are
• To either adapt the system to a major change in
  technology
• Fix the system before it breaks
• Make the system easier to fix when it breaks or
  needs to be adapted

22
(No Transcript)
23
Systems Enhancement and Reengineering

• Analyze Enhancement Request
• The purpose of this activity is to determine the
  appropriate course of action to either a new
  business problem or idea for enhancement,
  technical limitation or problem, or enhancement
  idea (from other system support activities).
• Based on analysis of current system models, that
  action may include
• Define new business requirements and return to
  systems analysis.
• Define new technical requirements and return to
  systems design.
• Define new program requirements and proceed to
  the next task.

24
Systems Enhancement and Reengineering

• Write Simple, New Programs
• Many enhancements can be accomplished quickly by
  writing simple, new programs.
• Simple programs are those that use existing data,
  do not update existing data, and do not input new
  data (for purposes of storing that data).
• These programs generate new reports and answer
  new inquiries.
• Most such programs can be easily written by
  end-users with a minimal knowledge of a
  fourth-generation languages or a PC-to-host
  database retrieval language, but also becoming
  available in most PC database packages.
• Programmers and analysts are also capable of
  writing such programs, but some shops question
  whether this is a valuable use of their time.

25
Systems Enhancement and Reengineering

• Restructure Files or Databases
• Many of today's data stores are implemented with
  traditional file structures or early database
  structures.
• Today's database technology of choice is
  SQL-based relational databases with
  object-oriented database technology gaining more
  and more popularity.
• Migrating data structures from one data storage
  technology to another is a major endeavor which
  risks corrupting essential business data and
  programs.
• The key player in database restructuring is the
  database analyst (or database administrator).
• The systems analyst plays a role because of the
  potential impact on existing applications.

26
Systems Enhancement and Reengineering

• Analyze Program Library and Maintenance Costs
• Many businesses are questioning the return on
  investment in corrective and adaptive
  maintenance.
• If complex and high-cost software can be
  identified, it might be reengineered to reduce
  complexity and maintenance costs.
• The first activity required to achieve this goal
  is to analyze program library and maintenance
  costs.
• This activity almost always requires software
  capable of performing the analysis.

27
Systems Enhancement and Reengineering

• Analyze Program Library and Maintenance Costs
• Software metrics are mathematically proven
  measurements of software quality and
  productivity.
• Examples of software metrics applicable to
  maintenance include
• Control flow knots The number of times logic
  paths cross one another. Ideally, a program
  should have zero control flow knots. (We have
  seen knot counts in the thousands on some older,
  poorly structured programs.)
• Cycle complexity The number of unique paths
  through a program. Ideally, the fewer, the
  better.
• Software metrics, in combination with cost
  accounting (on maintenance efforts) can help
  identify those programs that would benefit from
  restructuring.

28
Systems Enhancement and Reengineering

• Reengineer and Test Programs
• There are three types of reengineering that can
  be performed on that program code
  reorganization, code conversion, and code
  slicing.
• Code reorganization restructures the modular
  organization and/or logic of the program.
• Code conversion translates the code from one
  language to another.
• Code slicing cuts out a piece of a program to
  create a separate program or subprogram.

29
The Year 2000 and Systems Support

• Introduction
• The the year 2000 the potential of triggering
  widespread computer application disasters across
  many corporations.
• In the early 1960s and 1970s storage space was
  precious and Millions of applications were built
  with efforts to utilize as little storage space
  as possible.
• In order to save two bytes of storage space,
  dates for this century were stored without the
  first two digits 19.
• Many applications use these dates in arithmetic
  operations.
• Numbers used to store a January 1, 2000 date is a
  smaller number (meaning that it occurred earlier
  in time), than the number storing a January 1,
  1996 date, implying that January 1, 2000 occurs
  prior to the January 1, 1996 date.
• If the dates were stored with a four digit year
  the comparison would have been accurate.

30
Summary

• Introduction
• What is Systems Support?
• Systems Maintenance - Correcting Errors
• System Recovery - Overcoming the Crash
• End-User Assistance
• Systems Enhancement and Reengineering
• The Year 2000 and Systems Support