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

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

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

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

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

10. 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

11. 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.

12. Fig 13.11
Structured programming includes only three control structures, shown in Figure 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.”

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

14. 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

15. 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

16. 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.

17. 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.

18. 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

19. 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

20. 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

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

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

23. 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

24. 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.

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

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

27. 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

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

29. 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

30. 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

31. 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.

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

33. 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.

34. 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

35. 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

36. 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.

37. 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.

38. 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.

39. 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

40. Questions (?)