MSIS 630: Week 13 System Implementation and Support 4/21/2017 The last step in SDLC before we do maintenance is the systems implementation. In short, system implementation is actually building a system and giving it to the users. Usually, the construction part of implementation takes the most time in systems development (although one should take more time on requirements determination, changes in technology, environment, market, etc. will not allow any faster implementation).

Class 13: System Implementation System Support Broadway Entertainment Co. Inc., Case Group Discussion In this module you will learn about the system implementation phases in the systems development life cycle methodology. The systems implementation phases serve to construct and deliver the final system into operation. Also, this covers system support, which involves refining a production system by iterating through the previous four phases on a smaller scale to refine and improve that system. In this presentation, you will learn more about systems support. It is very likely that a young systems analyst 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 Implementation? Systems implementation is the construction of the new system and the delivery of that system into production (meaning day-to-day operation). The construction phase is actually part of a design/construction loop that implements rapid application development. Given some aspect of the system design, we construct and test the system components in that design. After several iterations of the design/construction loop, we will have the functional system to be implemented.

System Implementation Seven major activities Coding Testing Installation Documentation Training Support Purpose To convert final physical system specifications into working and reliable software To document work that has been done To provide help for current and future users Coding Physical design specifications are turned into working computer code Testing Tests are performed using various strategies Testing can be performed in parallel with coding Installation Process during which the current system is replaced by the new system Documentation System documentation User documentation User training plan Classes Tutorials User training modules Training materials Computer-based training aids User support plan Help desk On-line help Bulletin boards and other support mechanisms

Software Application Testing The purpose of the testing is confirming that the system satisfies requirements Testing must be planned Types of Testing Test Case Acceptance Testing by Users Alpha Testing Beta Testing Unit Testing Each module is tested alone in an attempt to discover any errors in its code, also called module testing Integration Testing The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion System Testing The bringing together of all the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion Stub Testing A technique used in testing, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substituted for subordinate modules Test Case A specific scenario of transactions, queries or navigation paths that represent a typical, critical or abnormal use of the system Test cases and results should be thoroughly documented so they can be repeated for each revision of an application Alpha Testing User testing of a completed information system using simulated data Beta Testing User testing of a completed information system using real data in the real user environment

Types of Testing There are three levels of testing to be performed: stub testing, unit or program testing, and systems testing. Stub testing is the test performed on individual modules, whether they be main program, subroutine, subprogram, block, or paragraph. Unit or program testing is a test whereby all the modules that have been coded and stub tested are tested as an integrated unit. Systems testing is a test that ensures that application programs written in isolation work properly when they are integrated into the total system. Testing is not an activity to be deferred until after the entire program has been completely written. How can you test a higher-level module before coding its lower-level modules? You simulate the lower-level modules. These lower-level modules are often called stubs. Stub modules are subroutines, paragraphs, and the like that contain no main logic. Perhaps all they do is print that they have been correctly called, and then control goes back to the parent module. Eventually, all modules will have been implemented, and that unit equals the program itself. Unit testing uses the test data that was created during the design phase. Just because a single program works properly doesn't mean that it works properly with other programs. The integrated set of programs should be run through a systems test to make sure that one program properly accepts, as input, the output of other programs.

Planning Installation Considerations Data conversion Error correction Loading from current system Planned system shutdown Business cycle of organization Four approaches Direct Installation (Plunge) Changing over from the old information system to a new one by turning off the old system when the new one is turned on Parallel Installation Running the old information system and the new one at the same time until management decides the old system can be turned off Single location installation (Pilot) Trying out an information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization Phased Installation Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system

Conversion Prepare a detailed conversion plan to provide a smooth transition from the old system to the new system. Convert to the new system from the old system and evaluate the project experience and final system. Know the different methods of conversion, and the advantages and disadvantages of each. Conversion to the new system from the old system is a significant milestone. After conversion, the ownership of the system officially transfers from the analysts and programmers to the owners and users. The analyst completes this activity by carefully carrying out the conversion plan. Recall that the conversion plan includes detailed installation strategies to follow for converting from the existing to a new production information system. This activity also involves completing what is called a systems audit. Four approaches Direct Installation (Plunge) Changing over from the old information system to a new one by turning off the old system when the new one is turned on Parallel Installation Running the old information system and the new one at the same time until management decides the old system can be turned off Single location installation (Pilot) Trying out an information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization Phased Installation Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system

Train System Users Provide training and documentation to system users to prepare them for a smooth transition to the new system. Change may be good, but it’s not always easy. Converting to a new system necessitates that system users be trained and provided with documentation (user manuals) that guide them through using the new system. Training can be performed one on one; however, group training is generally preferred. It is a better use of your time, and it encourages group learning possibilities. Think about your education for a moment. Isn't it true that you really learn more from your fellow students and colleagues than from your instructors? Instructors facilitate learning and instruction, but you master specific skills through practice with large groups because, with them, common problems and issues can be addressed more effectively. Take advantage of the ripple effect of education. The first group of trainees can then train several other groups. Fortunately, user involvement during this activity is rarely overlooked. The most important aspect of their involvement is training and advising of the users. They must be trained to use equipment and to follow the procedures required of the new system. But no matter how good the training is, users will become confused at times. Or perhaps they will find mistakes or limitations (an inevitable product, despite the best of planning, analysis, design, and implementation techniques). The analyst will help the users through the learning period until they become more familiar and comfortable with the new system.

What is Systems Support? 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. 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. -- Correct errors, Backup databases and Recover the system after a crash, Assist end-users, and Enhance and reengineer the system

The Year 2000 and Systems Support The year 2000 problem was the potential of triggering widespread computer application disasters across many corporations. 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 960101. Now consider the date January 1, 2000. That date would be represented in the YYMMDD format as 000101. 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 struggled but succeeded in correcting this problem 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 was 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 was even more complicated in those cases where a program passed the data field over to a utility that used the date which in turn may refer to the date field by a different name. Even when the programs were identified, often times you may be dealing with a program that had been modified and modified until it was now extremely difficult to understand what impact the change would 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 2000. Thanks to millions and millions of dollars spent, many corporations did not have applications that fail to handle the turn of the century. To gain an interesting insight into possible fallouts that companies might have experience on the arrival of the year 2000, read Warren Keuffels article titled “Coping with the Year 2000 Rollover.”