The chapter will address the following questions:

The chapter will address the following questions:
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? 576 Systems support involves refining a production system by iterating through the previous four phases on a smaller scale to refine and improve that system. In this chapter, you will learn more about systems support. It is very likely that a young systems analyst or user will become directly involved in a systems support project. Most analysts carry responsibility for one or more legacy systems. Therefore, it is useful to understand the different types of systems support provided for a production system.

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. 578 No additional notes provided.

578 Figure 18.1 Context for Systems Support Projects and Activities
In the figure above, applications maintenance projects are contrasted with systems planning and application development projects. Notice that once applications are implemented, they are said to be in production. Production is the day-to-day, week-to-week, month-to-month, and year-to-year execution of the application programs to process business data (inputs) and generate useful information (outputs).

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. No additional notes provided.

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. 579 Relative to your information systems framework, systems support maintains all of the building blocks (and their documentation) for a production information system. Unlike system analysis, systems design, and systems implementation, systems support cannot be broken down into actual phases that the system goes through. Rather, systems support consists of four ongoing activities each activity is triggered by a particular type of problem encountered with the implemented system.

579 Figure 18.2 Types of Systems Support No additional notes provided.

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. 580 Some bugs will be caused by miscommunication of requirements. Others will be caused by design flaws. Others will be caused by situations that were not anticipated and, therefore, not tested. And finally, bugs may be caused by unanticipated misuse of the programs. To achieve these objectives, you need an appropriate understanding of the programs you are fixing and of the applications in which those programs participate. This prerequisite understanding is often the downfall of system maintenance! How does system maintenance map to your information system building blocks? DATA -- System maintenance rarely impacts data, except for the possibility of improving data editing. PROCESSES -- Business and information system processes are implemented as application programs. System maintenance is all about fixing errors made when those programs were implemented. INTERFACES – Systems maintenance may involve correcting problems related to how the application interfaces with the user(s) or another system. GEOGRAPHY -- System maintenance rarely involves computer networks, although on occasion, computer networks can be the root cause of bugs. TECHNOLOGY -- System maintenance, as defined in this activity, does not deal with changing technology.

580-581 Figure 18.3 Activity Diagram for System Maintenance
No additional notes provided.

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. The input is the errors encountered when using the system (usually called bugs). One possible output is validated change requests. These change requests should define expectations of the solution. Another possible output is an unvalidated problem. In the event that bug reoccurs, users should be instructed as to how to better document circumstances Validated problems and programs that led to the bug and symptoms of the problem. Validated problems and programs are passed to the next task. The analyst or programmer requires appropriate fact-finding skills and interpersonal skills. The analyst or programmer also needs to be familiar with the application.

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. The primary inputs are the validated problems and programs. Test cases can be defined in either of two ways. First, you may find past test data in the repository. If so, that data should be re-executed to provide the benchmark. It should also be analyzed for completeness and, if necessary, revised. The correct responses, including error handling, should be recorded in the repository. Alternatively, test data can be automatically captured using a test tool. The advantage is that the test cases and responses are recorded in the repository for later playback. Test tools also measure response time and throughput using the test cases. SQA Suite by SQA, Inc. Consists of a set of tools for performing a variety of tests upon client/server applications. For either alternative, the outputs are new or revised test data and current performance and benchmarked programs. The analyst or programmer needs to have good testing skills (usually taught in programming courses) and may require training in test tools.

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). 582 Several people may have written parts of any program or application, and those people may no longer be available for clarification. You may be surprised to learn that most analysts and programmers spend more time in this task than any other! Ideally, application knowledge comes from the repository. This assumes, of course, that application knowledge has been maintained throughout the application's lifetime. All too often, this is not true especially for older systems. In non-repository-based shops, application knowledge may be available from prior programmers and analysts, but it is usually not up-to-date. Still, it may be useful for gaining a sufficient understanding of the application and where the problematic programs fit into that application.

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. 582 No additional notes provided

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. There used to be no shortcuts for program understanding. Today, maintenance CASE technology can help. For example, VIASOFT's VIA/Insight provides studies and analyzes programs to provide the programmer with considerable insight and information about unfamiliar code. It reveals program structure, marks or traces related code even if it is in different paragraphs and subroutines, isolates dead code (code that cannot be executed), traces field usage (and nonusage) and relationships between different field names and structures, and provides numerous cross references. This information can reduce the time it takes to understand programs by hours, days, and even weeks. Poorly structured programs can then be modified to conform to accepted structured programming practices. VIASOFT's VIA/Smart Doc can then generate a wealth of information, graphical and textual, for the program(s).

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. 583 There is a big difference between editing a new program and editing an existing program. As the designer and creator of a new program, you are probably intimately familiar with the structure and logic of the program. By contrast, as the editor of the existing program, you are not nearly as familiar (or current) about that 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. Hopefully, the code changes will benefit from your understanding (or review) of the application and program. But testing takes on even greater importance in system maintenance.

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. 583 Tested programs will be returned to production. Generally speaking, when the programs are returned to the program library, they are subject to version control. One example of version control software is INTERSOLV's PVCS (for local area networks).

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. The programmer is responsible for this activity. The input is the modified program. Application changes (changes in models and specifications) are recorded in the repository. The new programs and program changes are stored in the program library. Once returned to the library, they are available for production. Recording application and program changes in the repository and program library will help future programmers and analysts (including yourself) reduce application understanding time during future maintenance. You will forget changes, however small, unless they are properly recorded. The long-term benefit comes when the application is due for major redevelopment. The study phase of systems analysis will pass quickly if existing documentation is up-to-date.

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. 584 System recover activities can be summarized as follows: In many cases the analyst can sit at the user's terminal and recover the system. It may be something as simple as pressing a specific key or rebooting the user's personal computer. Corrective instruction may be required to prevent the crash from reoccurring. In some cases the analyst may arrange to observe the user during the next use of the program or application. In some cases the analyst must contact systems operations personnel to correct the problem. Operations can usually terminate an on-line session and reinitialize the application and its programs.

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. 584 System recover activities can be summarized as follows: In some cases the analyst may have to call data administration to recover lost or corrupted data files or databases. Data backup and recovery is beyond the scope of this book. It is covered extensively in most data and database management courses and textbooks. In some cases the analyst may have to call network administration to fix a local, wide, or internetworking problem. Network professionals can usually log out an account and reinitialize programs.

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. 584 In mission critical applications, the analyst must be on call day and night.

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. The objective of system enhancement is to modify or expand the application system in response to constantly changing requirements. This objective can be linked to your information system building blocks as follows: DATA Many system enhancements are requests for new information that can be derived from existing stored data. Some data enhancements call for expansion of data storage. PROCESSES Most system enhancements require the modification of existing programs or the creation of new programs to extend the overall application system. INTERFACES Many enhancements require modifications to how the users interface with the system, and how the system interfaces with other systems. GEOGRAPHY Most system enhancements are not driven by networks (see reengineering). TECHNOLOGY Most system enhancements are driven by technology (see 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 585 The above objectives can be linked to your information system building blocks as follows: DATA Many reengineering projects are driven by the need to restructure stored data, either to make it more flexible and adaptable or to convert it to a new technology. PROCESSES Many reengineering projects attempt to restructure or reorganize application programs to make them more maintainable or to convert them to a new technology (e.g., language). Many others change the input or output methods for programs (e.g., from batch to on-line or from on-line to graphical user interfaces). INTERFACES Many reengineering projects are driven by the desire to replace old system interfaces with newer easier to use graphical user interfaces. GEOGRAPHY Some application projects seek to change applications to new network technology. TECHNOLOGY Most reengineering projects are driven by changing technology or the need to better exploit existing technology.

585-586 Figure 18.4 Systems Enhancement and Reengineering Activities
No additional notes provided.

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. New programs are generally restricted to those that generate new information from existing data stores. Anything more complex should go through systems analysis and design. The systems analyst should be skilled in project planning, fact finding, and cost/benefit analysis. The latter may be necessary to justify the enhancement project.

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. New program requirements represent the majority of today's enhancements. 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 (such as Q&E), but also becoming available in most PC database packages (such as Access, Approach, and Paradox). With today's fourth-generation and database languages/tools, these programs can be completed within hours. Since they generally do not enter or update data stores, testing requirements are not nearly as stringent. Once implemented, a new program may be stored locally (on a PC or LAN server), or it may be added to the program library (if many people could benefit from its use). Since the ``local'' programs are created for specific users, they generally do not qualify for IS support; however, in most cases the area systems analyst or local end-user computing guru provides some support. Optionally, revised system models may be updated in the repository to reflect the existence of the new processes (programs) added to the system.

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. Network analysts may also be involved if databases are (to be) distributed across computer networks. The key inputs are the existing database structure (which can be read from the file or database management system's dictionary that is included in most data stores) and existing data, process, and network models as stored in the repository. The outputs are new database structure and new data, process, and network model. Data restructuring can and has been done by hand in many businesses. However, database reengineering CASE tools are increasingly used to read the data structure, produce the implementation model, perform data analysis to improve the model, and regenerate the new database structure. For the most part, database reengineering tools only convert data stores. Processes must also be converted to execute the new database retrieval and update commands against the new data structures. Technology for such conversions is available, but generally it is very expensive. Today's systems analyst must be both database literate and data management literate.

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. 588 Software tools such as VIASOFT's VIA/Recap measures your software library using a variety of widely accepted software metrics.

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. 588 The input to this task is all (or most) programs in the library. The output is a candidate program(s) for 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. Code reorganization -. For example, modules may be combined or separated to reduce coupling or increase cohesion. Logic may be restructured to eliminate control flow knots and reduce cycle complexity. Code conversion - Typically, this translation is from one language version to another. There is a debate on the usefulness of translators between different languages. If the languages are sufficiently different, the translation may be very difficult. If the translation is easy, the question is ``why change'' Code slicing - is the most intriguing program-reengineering option. Many programs contain components that could be factored out as subprograms. If factored out, they would be easier to maintain. More importantly, if factored out, they would be reusable. Code slicing cuts out a piece of a program to create a separate program or subprogram. This may sound easy, but it is not! Consider your average COBOL program. The code you want to slice out may be located in many paragraphs and have dependent logic in many other paragraphs. Furthermore, you would have to simultaneously slice out a subset of the Data Division for the new program or subprogram. Code slicing is greatly simplified with reengineering software. VIASOFT's VIA/Renaissance is a code-slicing tool that automatically traces code back to prerequisite code and data structures. It can quickly create a stand-alone executable program from the sliced code. Furthermore, it can modify the original program to call the new program (deleting the sliced code from the original), or it can keep the original program unchanged. The candidate program for reengineering is copied from the program library. It is reengineered using one or more of the preceding methods, it is thoroughly tested (as described earlier in the chapter), and the reengineered program is returned to the program library where it is available for production. Any new data, process and/or network models are updated in the repository.

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. 589 In the early 1960’s and 1970’s storage space was precious. Thus, 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”. For example, the date January 1, 1996 might be stored in a YYMMDD format as Now consider the date January 1, That date would be represented in the YYMMDD format as Many applications developed during the 60’s and 70’s stored dates in this format and used dates in arithmetic operations within applications. A quick comparison reveals that the numbers used to store the January 1, 2000 date is a smaller number (meaning that it occurred earlier in time), implying that the date occurs prior to the January 1, 1996 date. If the dates were stored in a YYYYMMDD format a comparison would have been accurate. The bottom line is that corporations are struggling as they race against time to locate and correctly revise the millions of programs, library utilities, files, and databases that use/store the abbreviated dates. This is a monumental feat in most cases. Simply locating the programs to be modified is made difficult because programmers likely used different names for the data fields. This is even more complicated in those cases where a program passes the data field over to a utility that uses the date which in turn may refer to the date field by a different name. Even when the programs are identified, often times you may be dealing with a program that has been modified and modified until it is now extremely difficult to understand what impact the change will have. Needless to say, this challenge has spurred a number of new software tools and consulting companies specifically targeted to helping companies revise their applications to deal with year Despite millions and millions of dollars spent, it is predicted that many corporations will have applications that fail to handle the turn of the century. To gain an interesting insight into possible fallouts that companies may experience on the arrival of the year 2000 read Warren Keuffels article titled “Coping with the Year 2000 Rollover” (see bibliography).

What is Systems Support? Systems Maintenance - Correcting Errors
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

The chapter will address the following questions:

Similar presentations

Presentation on theme: "The chapter will address the following questions:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The chapter will address the following questions:

Similar presentations

Presentation on theme: "The chapter will address the following questions:"— Presentation transcript:

Similar presentations

About project

Feedback