Systems analysis and design methods 7th whitten and benley chapter 18

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? 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 Systems Support System Owners Project Repository Existing & Revised Models Planning Directive Systems Planning Project System Models & Specifications System Owners & Users Problem, Opportunity, or Directive Applications Development Project Check-out and Check-in of Models & Specifications Databases Existing Code New or Revised Code Program Library Central Repository Ongoing Application Production Existing Documenation Data (inputs) Assisst System Users Information (outputs) Problems and Enhancements System Users Initial Data Population or Data Migration to New Structure Business Files and Databases Program to be Executed Existing, New, or Revised Programs Existing and Revised Models Project Repository Existing & Revised Models & Specifications Data Retrievals 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 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 Systems Support Errors Encountered When Using the System Correct Errorrs System Users Code with Bug(s) System "Crash" Restored Program Recover the System Restored Data Models and Specifications Corrected Code Program Library Repository Improved Documentation Existing Documentation Assisst System Users Models and Specifications New or Revised Code Databases Existing Code Adapt to New Requirements Additional Training or Coaching Problems Using System System Users New Business Problems or Ideas For Enhancement Technical Limitation Technical Problems or New Technology System Users 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 Systems Support Errors Encountered When Using the System System Users Corrective Instructions Define and Validate Problems Unvalidated Problem Validated Problems and Programs Validated Change Request Past Test Data Benchmark Programs and Application Problem Programs New or Revised Test Data and Current Performance Program Library Repository Programs and Program Changes Application Changes Update Documentation Modified Program Test Data and Current Performance Application Knowledge Benchmarked Programs Understand Application and Programs Validated Changes Edit and Test Programs Programs to be Modified Application and Program Knowledge 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 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 10 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 16 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: 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 17 Systems Support 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 18 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 dayto-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 19 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 20 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 21 Systems Support To Systems Analysis From End-User Support Enhancement Idea System Users New Business Problem or Idea for Enhancement New Business Requirement To Systems Design New Technical Requirements Analyze Enhancement Request New Program Requirements Technical Limitation or Problem System Designers or Builders New Program Current System Models Revised System Models New Technology Existing Data, Process, and/or Network Models Restructure Databases New Data, Process and/or Network Models Write Sample New Programs Program Library Reengineered Program Repository All Programs in the Library Existing Database Structure New Database Structure Databases New Data, Process, and/or Network Models System Designers or Builders 22 Reengineer and Test Programs Existing Program Candidate Programs for Reengineering Program Reengineering Directive Analyze Program and Maintenance Costs 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 23 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, not update existing data, and 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 24 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 25 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 26 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 27 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 28 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 29 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 30 ... program maintenance and system improvements Systems support often requires developers to revisit activities typically performed in systems analysis, design, and implementation Systems Support System... 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. .. code) • Prior maintenance (quick fixes and poorly designed extensions) 11 Systems Support Systems Maintenance - Correcting Errors  Understand the Application and its Programs  This activity is