Copyright Irwin/McGraw-Hill 1998 1 Systems Support Prepared by Kevin C. Dittman for Systems Analysis...
-
Upload
alexia-chapman -
Category
Documents
-
view
213 -
download
0
Transcript of Copyright Irwin/McGraw-Hill 1998 1 Systems Support Prepared by Kevin C. Dittman for Systems Analysis...
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19981
Systems Support
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?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19982
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19983
Systems Support
Program Library
Systems Planning Project
System Owners & Users
Applications Development
Project
Ongoing Application Production
Assisst System Users
Central Repository
Business Files and
Databases
System Users
Project Repository
Databases
Project Repository
System Owners
Planning Directive
System Models &
Specifications
Existing & Revised Models
Existing & Revised
Models & Specifications
Check-out and Check-in of Models &
Specifications
Problem, Opportunity, or Directive
Initial Data Population or Data Migration
to New StructureExisting Code New or
Revised Code
Data Retrievals
Information (outputs)
Data (inputs)
Problems and Enhancements
Existing Documenation
Existing and Revised Models
Existing, New, or Revised Programs
Program to be
Executed
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19984
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19985
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19986
Systems Support
Program Library
Correct Errorrs
System Users
Recover the System
Adapt to New Requirements
Assisst System Users
Repository Databases
System UsersSystem
Users
Errors Encountered When Using the System
System "Crash"
Models and
Specifications
Code with Bug(s) Restored Program Restored Data
Corrected Code
New or Revised Code
Existing Documentation
Problems Using System
New Business Problems
or Ideas For Enhancement
Technical Problems or New
Technology
Technical Limitation
Existing Code
Improved Documentation
Models and
Specifications
Additional Training or Coaching
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19987
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19988
Systems Support
Repository
Define and
Validate Problems
System Users
Benchmark Programs
and Application
Understand Application
and Programs
Update Documentation
Program Library
Errors Encountered When Using the System
Corrective Instructions
Edit and
Test Programs
Problem Programs
Programs and
Program Changes
Modified Program
Application and Program Knowledge
Programs to be Modified
Application Knowledge
New or Revised Test Data and
Current Performance
Benchmarked Programs
Validated Changes
Test Data and
Current Performance
Application Changes
Past Test Data
Validated Problems and Programs
Unvalidated Problem
Validated Change Request
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19989
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199810
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199811
Systems Support
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).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199812
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199813
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199814
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199815
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199816
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199817
Systems Support
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:1 In many cases the analyst can sit at the user's terminal and
recover the system. 2 In some cases the analyst must contact systems operations
personnel to correct the problem.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199818
Systems Support
System Recovery - Overcoming the “Crash”
Introduction System recover activities can be summarized as follows:
(continued)3 In some cases the analyst may have to call data administration
to recover lost or corrupted data files or databases. 4 In some cases the analyst may have to call network
administration to fix a local, wide, or internetworking problem. 5 In some cases the analyst may have to call technicians or
vendor service representatives to fix a hardware problem.6 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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199819
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199820
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199821
Systems Support
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
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199822
Systems Support
Analyze Enhancement
Request
System Designers or Builders
Write Sample
New Programs
Analyze Program
and Maintenance
Costs
Restructure Databases
Program Library
Reengineer and
Test Programs
Databases
Repository
System Designers or Builders
System Users
From End-User Support To Systems Analysis
To Systems Design
New Business Problem or Idea for
Enhancement
Technical Limitation or Problem
New Technology
Existing Data, Process, and/or Network Models
Existing Database Structure
New Database Structure
New Data, Process and/or Network Models
New Data, Process, and/or
Network Models
Candidate Programs for
Reengineering
All Programs in the Library
Existing Program
Reengineered Program
New Program
Revised System Models
Current System Models
New Program Requirements
Enhancement IdeaNew
Business Requirement
New Technical Requirements
Program Reengineering Directive
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199823
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199824
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199825
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199826
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199827
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199828
Systems Support
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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199829
Systems Support
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 1960’s and 1970’s 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.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 199830
Systems Support
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