Topics Lesson 6 System Implementation Software Development Preparation, Installation, Testing, Conversion System Review Audit Trails System Audits

Systems Implementation Implementation occurs after systems design. Implementation includes all the activities necessary to convert the system specifications into an operational information system.

Systems Implementation Figure 13.10: Typical Steps in Systems Implementation Principles of Information Systems, Eighth Edition

Make or Buy Software Steps Review needs & requirements Acquire software Modify customize Acquire software interfaces Test & accept the software Maintain the software After determining that the software will meet the organization’s needs, the software is acquired, and, typically modified. Usually, purchased software requires a software interface, consisting of code to allow the external software to work with the organization’s other programs.

Make or Buy Software Commercial software can considerably reduce system development costs if they meet solution requirements. Solution design using off-the-shelf software packages focuses on package evaluation and fitting the solution design to package characteristics. Some off-the-shelf software packages can be customized for a better fit. Front-end programs can also be built to provide the missing capabilities without modifying the off-the-shelf software.

Make or Buy Software Externally developed software Lower cost Lower risk Ease of installation The “make-or-buy decision” involves deciding whether to buy or lease the software, develop it in-house, have someone else develop it, or a use combination of methods. An organization may choose to buy or lease externally developed software for a variety of reasons. For example, buying or leasing off-the-shelf software eliminates risk about system capabilities and the completion date.

Tools & Techniques for Software Development Cross-platform development Integrated development environments CASE tools (Eg RMS) Structured design Structured programming Structured walkthroughs When software is developed in house, there are a number of tools and techniques that can be used. While some organizations may require the use of particular tools or techniques, most encourage teams to use tools and techniques that fit the project at hand. Cross-platform development allows programmers to write programs that can be run on different platforms – that is, on different hardware and operating system combinations. Integrated development environments, or IDEs, are integrated software that combine a programming language, as well as all the tools needed to program. IDEs typically have graphical user interfaces. Visual Basic, Visual C++, and JIG are examples of IDEs. Structured design is an established design technique that breaks larger problems into individual modules with well-defined interfaces. There are a number of rules that modules and interfaces must adhere to. A well-designed module can be reused in other projects. A structured design can be implemented using structured programming.

Make or Buy Software In-house developed software Chief programmer teams The programming life cycle Software can also be completely developed internally. This gives the organization’s IS department greater control over the software, increasing the chance that the software will meet user and organizational requirements. It is also more difficult for competitors to duplicate custom built software, thus providing an organization a strategic advantage. To be effective and efficient, software is typically developed in a systematic fashion. Chief programmer teams is a common method for developing software.

Acquiring Software: Make or Buy? Table 13.5: Comparison of Off the Shelf and Developed Software Principles of Information Systems, Eighth Edition

Structured design and programming Structured design and programming are software design principles that promote software with a simple structure that is easy to follow and to maintain. Structured design organizes a program into a hierarchy of modules from the top down, with each module performing a limited number of functions. Tools used to document structured design include: Structure charts — document the detailed breakdown of a design into modules and components

Structured design and programming System flowcharts — plan or document the sequence of processing steps for the entire system, showing the sequence of input, process, and output Structured programming is a method of writing programs using only three basic control constructs: sequence, selection, and repetition.

Fig 13.11 Structured programming includes only three control structures, shown in Figure 13.11. This means that all instructions must be ordered in one of three patterns. In a sequence structure, there is a starting and a stopping point – in between, commands are executed in order. In a decision structure, the computer can branch to a different place in the module if it meets a stated condition. The decision structure is an “if-then-else” structure. Finally, a loop structure is a series of commands that executes over and over until a certain condition is met. Examples of a loop may be “Do until class size equals 20” or “Do while class size is less than 21.”

Acquiring Software: Make or Buy? Figure 13.11: Structured Walkthrough Principles of Information Systems, Eighth Edition

Computer-aided software engineering (CASE) CASE is used to manage and automate the systems development process. Benefits of using CASE: increased productivity by automating tedious tasks such as updating DFD improved quality by reducing or eliminating errors and omissions in systems specifications and design

Computer-aided software engineering (CASE) improved documentation by keeping project documentation current in one central place lower system maintenance costs by reducing the amount of effort required to keep documentation current

Additional Implementation Activities Acquiring database and telecommunication systems User preparation Hiring & training IS personnel Site preparation Data preparation After systems have been acquired or developed, critical activities in design still remain. Because databases and networks are the backbone of an information system, implementing them correctly is important. During analysis and design the adequacy of existing database and network facilities were documented. If databases or networks must be modified or upgraded with new equipment, that should be done here following the procedures discussed earlier for hardware acquisition. User preparation involves readying all users & stakeholders for the new system, as well as training users. User preparation should be an ongoing process, starting early in the SDLC by involving users and stakeholders in the development process and informing them of development progress. Similarly, if new IS personnel are required, they are hired and trained at this stage. Site preparation involves getting the location ready for the new system. Physical adjustments may not be needed if no new equipment is involved. If needed, site preparation can range from very minimal, such as rearranging the furniture to accommodate the new equipment, to massive, such as installing a new floor for network cabling, and upgrading the electrical, security, and air conditioning systems. Data preparation involves converting existing data into the format required by the new system. Manual files must be automated – typically organizations hire temporary workers to input all necessary data, since this can be a time consuming task. If the previous system was automated, the data may be in a format incompatible with the new system. Generally programs exist or can be written to convert data into a different file format.

Additional Implementation Activities Installation Testing Unit testing System testing Volume testing Integration testing Acceptance testing Installation is the process of physically placing the hardware and software onsite and making it operational. Testing is done to ensure an information system works as intended. Testing is best conducted at several levels. While they code, programmers test modules of a program individually and in groups to ensure they work.

Testing Unit testing: testing of individual programs System testing: testing entire system of programs Volume testing: testing the application with a large amount of data Integration testing: testing all related systems together Acceptance testing: conducting any tests required by user Principles of Information Systems, Eighth Edition

Testing (continued) Alpha testing: testing an incomplete or early version of system Beta testing: testing a complete and stable system by end users Principles of Information Systems, Eighth Edition

Conversion strategies Startup (conversion): Depending on the complexity of the new system and other constraints, the following four conversion methods can be used: Parallel — need to input data to two systems; costly to run and may not be feasible in some circumstances Direct cutover — the least expensive strategy but more risky

Figure 13.13: Start-Up Approaches Start-Up (continued) Figure 13.13: Start-Up Approaches Principles of Information Systems, Eighth Edition

Figure 13.13: Start-Up Approaches (continued) Start-Up (continued) Figure 13.13: Start-Up Approaches (continued) Principles of Information Systems, Eighth Edition

Conversion strategies Pilot study — a small group of users tries the new system before it is implemented to the whole organization Phased approach — all users use a portion of the new system while the rest of the processes are still performed by the old system

Systems implementation Regardless of the conversion strategy used, the analyst must be sensitive to people considerations in systems design. Users may resist changes for reasons such as: fear of job loss fear of loss of control fear of unfamiliar environment Change management facilitates the implementation of business solutions.

Systems implementation User acceptance — the users agree that the system meets the acceptance criteria (the objectives and functions), known as “signing off”

Systems Maintenance Systems maintenance involves monitoring, changing, fixing and enhancing an operational information system.

Systems maintenance All systems need to be maintained. Reasons for program maintenance include: changes in business processes new requests from stakeholders, users, and managers bugs or errors in programs technical and hardware problems corporate mergers and acquisitions government regulations change in the hardware or operating system

The Financial Implications of Maintenance Figure 13.14: Maintenance Costs as a Function of Age Principles of Information Systems, Eighth Edition

The Relationship Between Maintenance and Design More time and money spent on design means less time and money spent on maintenance Figure 13.15: The Value of Investment in Design Principles of Information Systems, Eighth Edition

Systems maintenance The four categories of software maintenance defined in the industry are: Slipstream upgrade — a minor bug fix or code adjustment Patch — a minor change to correct a problem or make a minor enhancement Release — a new release is a significant change that usually requires alterations to the documentation Version — a new version is a major change that includes numerous features not included on the previous version

Systems Review Systems review is the process of analyzing systems to determine whether or not they are operating as intended. Actual system performance and benefits are compared to the system requirements, and cost, control, and complexity factors are re-examined. When problems or shortcomings are found, maintenance to the system is requested. Systems review is an ongoing process, continuing throughout a system’s life.

Types of Review Procedures Table 13.6: Examples of Review Types Principles of Information Systems, Eighth Edition

Factors to Consider During Systems Review Mission Goals Hardware/ software Database Telecommunications IS personnel Control Training Costs Complexity Reliability Efficiency Response time Documentation Systems review should include many factors, including those listed here. For example, the system should continue to meet the needs and support the goals of the organization, particular departments, and the users. The hardware, software, database, and telecommunications system should be reviewed to ensure they are up-to-date and capable of supporting the system. There should be adequate personnel to support the system, rules, procedures, and controls should be adequate, and training for users and IS personnel should be provided. Systems review often means monitoring the system, called system performance measurement. For example, in order to determine the efficiency of the information system, or determine the amounts of CPU time or memory the system uses, hardware or software monitors need to be used to take actual system measurements. System performance products exist to monitor and measure all components of an information system, including the hardware, software, database, and telecommunications.

Systems review The objectives of the post-implementation review, which is conducted 6-12 months after implementation, are: to determine whether the conversion to a new system has met the objectives originally identified (including performance and cost objectives) to compare the operational performance to the design objectives

Systems review to compare the actual costs of the development effort with the budgeted costs to learn from the project what are the key success factors and identify the costs of any future system enhancements

Systems performance measurement Most system reviews include systems performance measurement, which is measuring and monitoring the performance of the system and its components in terms of errors, memory, speeds, response times, and other criteria. To assist them in this part of the review, team members may use systems performance products that have been developed to measure components.

Audit trails A properly designed system should have an audit trail showing how data is transformed from transaction inputs to report outputs. Results can be re-created from the audit trails if necessary. It is more difficult to create an audit trail for an online processing system than a batch system. A transaction log is usually necessary to preserve the audit trail.

Systems audit An external systems audit of a computer system is used to confirm the adequacy of internal controls and the accuracy of information. An internal systems audit measures the effectiveness of controls used to safeguard the resources of the organization, to operate efficiently, and to achieve the goals within the limits of company policies and procedures. Auditing around the computer confirms that the output correctly reflects the processed input.

Systems audit Auditing through the computer checks the internal logic to ensure components are working according to specifications. Techniques to audit through the computer include: data testing program code checking flowchart verification custom-designed computer programs generalized audit software (GAS) online auditing and remote auditing techniques

Questions (?)