1. Systems Implementation
PHASE 4: SYSTEMS IMPLEMENTATION
Chapter 9
Systems Implementation

2. Phase Description
Systems Implementation is the fourth of five phases in the systems development life cycle (SDLC)
Includes application development, testing, documentation, training, data conversion, system changeover, and post-implementation evaluation of the results

3. Chapter Objectives
Explain the importance of software quality assurance and software engineering
Describe the application development process
Draw a structure chart showing top-down design, modular design, cohesion, and coupling
Explain the coding process and how code is generated
Explain unit testing, integration testing, and system testing 3

4. Chapter Objectives
Differentiate between program, system, operations, and user documentation
List the main steps in system installation and evaluation
Develop an overall training plan with specific objectives for each group of participants, compare in-house and outside training providers, and describe effective training techniques 3

5. Chapter Objectives Describe the data conversion process
Identify and describe changeover methods
Explain post-implementation evaluation
Describe the final report to management

6. Introduction
The system design specification serves as a blueprint for constructing the new system
The initial task is application development
Before a changeover can occur, the system must be tested and documented carefully, users must be trained, and existing data must be converted
A formal evaluation of the results takes place as part of a final report to management 4

7. Overview of Application Development
Objective is to translate the logical design into program and code modules that will function properly
Creation of the System Design
The tasks involved in system design produced an overall design and a plan for physical implementation

8. Overview of Application Development
Application Development Steps
Module
Start by reviewing documentation from prior SDLC phases and creating a set of program designs
After the design is created, coding can begin
Building a system requires careful planning
After you establish your strategy, individual modules must be designed, coded, tested, and documented.
A module consists of related program code organized into small units
After the modules are developed and tested individually, you perform more testing (integration and finally system testing), along with documentation of the entire system.

9. Overview of Application Development
Project Management
Even a modest-sized project might have hundreds or even thousands of modules
Important to set realistic schedules, meet project deadlines, control costs, and maintain quality
Should use project management tools and techniques

10. Structured Application Development
Top-down approach
Partitioning
Modular design
Constant input from programmers/IT management
Ensure integration capability
Top-Down Design:
In top-down design, sometimes called structured design, a systems analyst starts with the big picture and then zooms in on the details, breaking the original set of requirements into smaller, more manageable sections (called partitioning).
This approach is called modular design and is similar to constructing a leveled set of DFDs.
Programs developed using the top-down approach usually benefit from the simplicity of their design and are reliable and easy to maintain.
Note the importance of proceeding carefully with constant input from programmers and IT management to achieve a sound, well-integrated structure
Must ensure that integration capability is built into each design and thoroughly tested
Although top-down design is the most popular development method, an alternative approach is bottom-up design, which implements the modules at the bottom of a structure chart first.

11. Structured Application Development
Structure Charts
Structure charts show the program modules and the relationships among them
Control module
Subordinate modules
A structure chart, sometimes called a hierarchy chart, shows program modules graphically in a hierarchical arrangement. Figure 9-7, differentiates between a control module and subordinate modules. Control modules control the flow of execution. Subordinate modules are like “worker bees,” containing the program logic to perform the functions.

12. Structured Application Development
Structure Charts
Module
Library module
Data Couple
Control Couple
Flag
Structure Charts
Module
Library module – reusable code and can be invoked from more than one point in the chart
Data Couple – an arrow with an EMPTY circle. Shows data that one module passes to another. A data couple can be an individual data item (such as an account number) or a higher-level data structure (such as a record).
Fig. 9-8, pg. 421  Lookup Customer Name module exchanges data with maintain Customer Data module.
Control Couple – an arrow with a FILLED circle. Shows a message, aka a flag, which one module sends to another.
Fig. 9-9, pg. 421  update Customer File module sends an Account Overdue flag back to maintain Cusomer Data module.
A module uses a flag to signal a specific condition or action to another module

13. Structured Application Development
Structure Charts
Condition
A condition line indicates that a control module determines which subordinate modules will be invoked, depending on a specific condition
Loop
A loop indicates that one or more modules are repeated
Condition
Condition lines indicate that a lower-level module is called only when certain conditions exists.
Fig.9-10, pg 421  Sort Inventory parts is a control module with a condition line that triggers one of the three subordinate modules.
Loop
A loop indicates that one or more modules are repeated
Fig. 9-11, pg 422  Get Student Grades and Calculate GPA modules are repeated

14. Structured Application Development
Cohesion and Coupling
Highly cohesive
Loosely coupled
Tightly coupled
Status flag
Cohesion:
It is desirable to have modules that are highly cohesive and loosely coupled.
Cohesion assesses the internal strength of a module. It measures the modules ability to perform a single function or task. A cohesive module focuses on a single task and is much easier to code and reuse  therefore, desirable For example, a module named Verify Customer Number is highly cohesive. On the other hand Calculate and Print Statements is not as cohesive.
Coupling:
Describes the relationships and interdependence among modules. Modules that are independent are loosely coupled, which is desirable.
Loosely coupled modules are easier to maintain and modify because changing the logic in one does not affect the other modules.
Tightly coupled modules are not desired since one module might refer to internal logic contained in another. If program error  could cause processing sequence error
Fig.9-13, pg. 423

15. Structured Application Development
Structure Chart Examples

16. Testing the System
After coding, a programmer must test each program to make sure that it functions correctly
Syntax errors
Desk checking
Logic errors
Structured walkthrough, or code review
Design walkthrough
After coding, a programmer must test each program to make sure that it functions correctly. Later programs are tested in groups, and finally the development team must test the entire system.
First step is to compile program using a CASE tool or language compiler.
This detects syntax errors which are programming language grammar errors.
Next, the programmer desk checks the program by reviewing the code to spot logic errors  which are flaws in the design of the program.
Many companies require a form type of desk checking called a structured walkthrough or code review peers participate. During the code review, the programmer explains the logic of the program code while other programmers step through the program logic.
The project team also holds a session with users called a design walkthrough to review the interface with a cross-section of people who will work with the new system. They can make sure all necessary and agreed upon features have been included. Note the testing that is performed. Discuss Figure 9-23.

17. Testing the System Unit Testing Test data Stub Testing Test plan
Test Data – should contain correct data and erroneous data and should test all possible situation that could occur. Ex. For a field that allows a range of numeric values, the test data should contain min values, max values, values outside acceptable range, and alphanumeric characters.
Unit testing tests individual modules, or small groups of interrelated modules that always are executed as a group, before they are integrated with other modules. Unit testing attempts to locate and correct errors before modules are combined. Errors are much more difficult to find and fix after many modules are joined.
Stub testing. A stub is a module, developed during testing, that simulates a module that has not yet been written. In stub testing, the programmer stimulates each program outcome or result and displays a message to indicate whether or not the program executed successfully.
Test plan – Someone other than the programmer should write the test plan and create test data. A test plan consists of detailed procedures that specify how and when the testing will be performed, who will participate, and what test data will be used. It should include scenarios for every possible situation the program could encounter.
Regardless of who creates the test plan, the project manager or a designated analyst also reviews the final test results.

18. Testing the System Integration Testing
Integration testing, or link testing
Testing the programs independently does not guarantee that the data passed between them is correct
A testing sequence should not move to the integration stage unless it has performed properly in all unit tests
Integration Testing – testing 2 or more programs that depend on each other
Because few modules operate in isolation, integration testing is important
Unit testing should be performed properly before a testing sequence moves to integration testing.
Errors identified during integration testing can result from a number of problems, including:
The wrong type of data (such as a word instead of a number) being passed from one module to another
An unexpected value (such as a negative number for a price) being passed from one module to another
A module generating an error (such as “file already in use”) due to conflicting resource needs
Unexpected interactions (such as typical records, followed by a blank record) being passed from one module to another

19. Testing the System System Testing - Major objectives:
Perform a final test of all programs
Verify that the system will handle all input data properly, both valid and invalid
Ensure that the IT staff has the documentation and instructions needed to operate the system properly and that backup and restart capabilities of the system are adequate

20. Testing the System System Testing - Major objectives:
Demonstrate that users can interact with the system successfully
Verify that all system components are integrated properly and that actual processing situations will be handled correctly
Confirm that the information system can handle predicted volumes of data in a timely and efficient manner

21. Testing the System System Testing Called Acceptance tests
You should regard thorough testing as a cost-effective means of providing a quality product
If conflicting views exist, management will decide whether or not to install the system after a full discussion of the options

22. Documentation Documentation Program Documentation System Documentation
Operations Documentation
User Documentation
Online documentation
Documentation – describes an information system and helps users, managers, and IT staff interact with it.
Program Documentation – describes the inputs, outputs, and processing logic for all program modules.
Includes process descriptions, report layouts.
System Documentation – describes the system’s functions and how they are implemented.
Includes data dictionary entries, DFD, object models, screen layouts, source documents, system request.
Operations Documentation – If involves minicomputer, mainframe, or centralized servers, must prepare documentation for IT group that supports centralized operations.
Contains information needed for processing and distributing online and printed output.
User Documentation – consists of instructions and information to users who will interact with the system
Includes user manuals, help screens, and tutorials.

23. Management Approval
After system testing is complete, you present the results to management
If system testing produced no technical, economical, or operational problems, management determines a schedule for system installation and evaluation

24. System Installation and Evaluation
Remaining steps in systems implementation:
Prepare a separate operational and test environment
Provide training for users, managers, and IT staff
Perform data conversion and system changeover
Carry out post-implementation evaluation of the system
Present a final report to management

25. Operational and Test Environments
The environment for the actual system operation is called the operational environment or production environment
The environment that analysts and programmers use to develop and maintain programs is called the test environment
A separate test environment is necessary to maintain system security and integrity and protect the operational environment

26. Operational and Test Environments

27. Training Training Plan
The first step is to identify who should receive training and what training is needed
The three main groups for training are users, managers, and IT staff
You must determine how the company will provide training

28. Training Vendor Training
If the system includes the purchase of software or hardware, then vendor-supplied training is one of the features you should include in the RFPs (requests for proposal) and RFQs (requests for quotation) that you send to potential vendors
Often gives the best return on your training dollars

29. Training Outside Training Resources
Many training consultants, institutes, and firms are available that provide either standardized or customized training packages
You can contact a training provider and obtain references from clients
Center for the Application of Information Technologies (CAIT)

30. Training In-House Training
The IT staff and user departments often share responsibility
When developing a training program, you should keep the following guidelines in mind:
Train people in groups, with separate training programs for distinct groups
Select the most effective place to conduct the training
Provide for learning by hearing, seeing, and doing
Prepare effective training materials, including interactive tutorials
Tutorial

31. Training In-House Training
When developing a training program, you should keep the following guidelines in mind:
Rely on previous trainees
Train-the-trainer strategy
When Training is complete, many organizations conduct a full-scale test, or simulation

32. Data Conversion Data Conversion Strategies Data Export – ASCII or ODBC
Program
Some manual entry
When a new system replaces an existing system, you should automate the data conversion process whenever possible. This cuts down on errors.
The old system might be capable of exporting data in an acceptable format for the new system or in a standard format such as ASCII or ODBC
ODBC is a form of middleware that will allow the old system and new to interact and exchange data.
If a standard format is not available, you must develop a program to extract the data and convert it
Often requires additional data items, which might require manual entry

33. Data Conversion Data Conversion Security and Controls
You must ensure that all system control measures are in place and operational to protect data from unauthorized access and to help prevent erroneous input
Some errors will occur
It is essential that the new system be loaded with accurate, error-free data

34. System Changeover Direct Cutover
Involves more risk than other changeover methods
Companies often choose the direct cutover method for implementing commercial software packages
Cyclical information systems usually are converted using the direct cutover method at the beginning of a quarter, calendar year, or fiscal year
There are 4 system changeover methods: Direct cutover, parallel operation, pilot operation, and phased operation. When deciding which method to go with, you need to ask:
How expensive is the changeover method?
How much risk is involved in the changeover method?
How difficult will it be to detect and correct errors?
How much training will be needed for users?
If companies have a choice, direct cutover typically is used when:
They are implementing commercial software packages
The new system is not replacing an older system
Downtime of a few days or weeks can be tolerated
Cyclical information systems are usually converted using the direct cutover method at the beginning of a quarter, calendar year, or fiscal year

35. System Changeover Parallel Operation
Easier to verify that the new system is working properly under parallel operation than under direct cutover
Running both systems might place a burden on the operating environment and cause processing delay
Is not practical if the old and new systems are incompatible technically
Also is inappropriate when the two systems perform different functions
Extra costs associated with parallel operation include:
Hiring temporary (or temporarily reassigning existing) personnel
Acquiring extra space and/or equipment
Increasing managerial complexity
Parallel operation generally is best used when the consequences of system failure are severe. This often is the case with mission critical applications such as transaction processing, production control, accounting functions, and customer service.

36. System Changeover Pilot Operation
The group that uses the new system first is called the pilot site
The old system continues to operate for the entire organization
After the system proves successful at the pilot site, it is implemented in the rest of the organization, usually using the direct cutover method
Is a combination of parallel operation and direct cutover methods

37. System Changeover Phased Operation
You give a part of the system to all users
The risk of errors or failures is limited to the implemented module only
Is less expensive than full parallel operation
Is not possible, however, if the system cannot be separated easily into logical modules or segments
The primary disadvantage of phased operation is increased complexity — dividing the changeover process into phases creates more activities, thus making the process more complicated.
Phased operation is best used when a system is large, complex, and composed of relatively independent subsystems.

38. Post-Implementation Tasks
Post-Implementation Evaluation
Includes feedback for the following areas:
Accuracy, completeness, and timeliness of information system output
User satisfaction
System reliability and maintainability
Adequacy of system controls and security measures
Hardware efficiency and platform performance

39. Post-Implementation Tasks
Post-Implementation Evaluation
Includes feedback for the following areas:
Effectiveness of database implementation
Performance of the IT team
Completeness and quality of documentation
Quality and effectiveness of training
Accuracy of cost-benefit estimates and development schedules

40. Post-Implementation Tasks
Post-Implementation Evaluation
When evaluating a system, you should:
Interview members of management and key users
Observe users and computer operations personnel actually working with the new information system
Read all documentation and training materials
Examine all source documents, output reports, and screen displays
Use questionnaires to gather information and opinions form a large number of users
Analyze maintenance and help desk logs

41. Post-Implementation Tasks
Post-Implementation Evaluation
Users can forget details of the developmental effort if too much time elapses
Pressure to finish the project sooner usually results in an earlier evaluation in order to allow the IT department to move on to other tasks
Ideally, conducting a post-implementation evaluation should be standard practice for all information systems projects

42. Post-Implementation Tasks
Final Report to Management
Your report should include the following:
Final versions of all system documentation
Planned modifications and enhancements to the system that have been identified
Recap of all systems development costs and schedules
A comparison of actual costs and schedules to the original estimates
Post-implementation evaluation, if it has been performed
Marks the end of systems development work

43. Chapter Summary Develop a training program
Data conversion often is necessary when installing a new information system
System changeover is the process of putting the new system into operation
A post-implementation evaluation assesses and reports on the quality of the new system and the work done by the project team 49

44. Chapter Summary Any questions?
The final report to management includes the final system documentation, describes any future system enhancements that already have been identified, and details the project costs
Any questions? 49