Phase 4: System

Implementation
 Learning Objectives
 Describe the process of coding, testing, and system
conversion.
 Prepare a test plan for an information system.
 Apply four installation strategies.
 List deliverables for documentation, training, and user
support.
 Distinguish between system and user documentation.
 Compare different user training modes.
 Discuss issues of end-user support.
 Explain factors influencing implementation success.
 Purpose of System
Implementation
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
Six major activities:
 Coding
 Testing
 Installation
 Documentation
 Training
 Support
 The Process of Coding,
Testing and Installation
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
 The current system is replaced by the new
system.
Deliverables
The Process of Documenting the
System, Training Users, and
Supporting Users
Two audiences for final documentation
 Information systems personnel who will
maintain the system throughout its
productive life
 People who will use the system as part of
their daily lives
User Training
 Application-specific
 General: for operating system and off-
the-shelf software
Deliverables
Software Application Testing
A master test plan is developed during the
analysis phase.
During the design phase, unit, system and
integration test plans are developed.
The actual testing is done during
implementation.
Test plans provide improved communication
among all parties involved in testing.
 Test Classification
Manual vs. Automated
Static (syntax only) vs. Dynamic (execution)
Manual Testing Techniques
Inspection
 A testing technique in which participants examine
program code for predictable language-specific
errors
Walkthrough
 A peer group review of any product created during
the systems development process; also called a
structured walkthrough
Desk Checking
 A testing technique in which the program code is
sequentially executed manually by the reviewer
 Automated Testing
Techniques
Syntax Checking
 The compiler is run against the source code to identify
syntax errors.
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.
 Automated Testing
Techniques (cont.)
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
substitute for subordinate modules.
 Test Cases
Test case: a scenario or condition used
to validate whether a system or
application behaves as expected.
Can represent either:
 Typical system use
 Critical system use
 Abnormal system use
Test cases and results should be
thoroughly documented so they can be
repeated for each revision of an
application.
 Test Cases (cont.)
Test cases are usually developed by
analysts.
Test cases should not be created by the
programmers.
Separate people should program and
test in order to ensure objectivity.
Programmers use symbolic debuggers
to isolate causes for errors.
User Acceptance Testing
Actual users test a completed
information system.
End result is the users’ final acceptance
of the system.
Alpha testing: use simulated data
Beta testing: use real data in real user
environment
 Types of Alpha Tests
Recovery testing
 Forces software (or environment) to fail in order to
verify that recovery is properly performed
Security testing
 Verifies that protection mechanisms built into the
system will protect it from improper penetration
Stress testing
 Tries to break the system
Performance testing
 Determines how the system performs on the range
of possible environments in which it may be used
 Risk Analysis
A risk is the possibility of losing something of value. Risk analysis starts with
planning for secure system by identifying the vulnerability of system and impact
of this. The plan is then made to manage the risk and cope with disaster. It is
done to access the probability of possible disaster and their cost.
Risk analysis is a teamwork of experts with different backgrounds like
chemicals, human error, and process equipment.
The following steps are to be followed while conducting risk analysis −
•Identification of all the components of computer system.
•Identification of all the threats and hazards that each of the components faces.
•Quantify risks i.e. assessment of loss in the case threats become reality.
Risk Analysis – Main Steps
As the risks or threats are changing and the potential loss are also changing,
management of risk should be performed on periodic basis by senior managers.
 Risk management is a continuous process
and it involves the following steps −
• Identification of security measures.
• Calculation of the cost of implementation of
security measures.
• Comparison of the cost of security measures
with the loss and probability of threats.
• Selection and implementation of security
measures.
• Review of the implementation of security
measures.
 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
 Training
Vendor Training
 If the system includes the purchase of
software or hardware, then vendor-
supplied training is one of the features you
should investigate in the RFPs (requests
for proposal) and RFQs (requests for
quotation) that you send to potential
vendors
 Vendor training often gives the best return
on your training dollars
 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)
 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
 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
 Data Conversion
Data Conversion
During data conversion, existing data is
loaded into the new system
You should develop a data conversion
plan as early as possible, and the
conversion process should be tested
when the test environment is developed
 Data Conversion
Data Conversion Strategies
 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
 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
 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
 Installation
The organizational process of changing
over from the current information system to
a new one
Four installation strategies:
 Direct Installation
 Parallel Installation
 Single-location installation
 Phased Installation
 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
 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
 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
 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
System Changeover
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
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
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
Post-Implementation Tasks
Post-Implementation Evaluation
 When evaluating a system, you should:
 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
 Whenever possible, people who were not
directly involved in developing the system
should conduct the post-implementation
evaluation
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
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
 A recap of all systems development costs and
schedules
Post-Implementation Tasks
Final Report to Management
 Your report should include the following:
 A comparison of actual costs and schedules to
the original estimates
 The post-implementation evaluation, if it has
been performed.
 Marks the end of systems development
work
Documenting the System
Software documentation is a written
piece of text that is often accompanied
by a software program. This makes the
life of all the members associated with
the project easier. It is a very critical
process in software development. It’s
primarily an integral part of any
computer code development method.
 Types of Software
Documentation
System Documentation
User Documentation
 Documenting the System
System documentation- is intended to help
programmers and systems analysts understand the
application software and enable them to build it or
maintain it after the system is installed.
System documentation is a by-product of the systems
analysis and design process and is created as the
project unfolds. Each step and phase produces
documents that are essential in understanding how
the system is built or is to be built, and these
documents are stored in the project binder(s).
 User Documentation
User documentation (such as user manuals,
training manuals, and online help systems) is
designed to help the user operate the system.
Although most project teams expect users to
have received training and to have read the
user manuals before operating the system,
unfortunately, this is not always the case. It is
more common today—especially in the case
of commercial software packages for
microcomputers—for users to begin using the
software without training or reading the user
manuals.
User documentation is often left until the end of the
project, which is a dangerous strategy. Developing good
documentation takes longer than many people expect,
because it requires much more than simply writing a few
pages. Producing documentation requires designing the
documents (whether paper or online), writing the text,
editing them, and testing them. For good-quality
documentation, this process usually takes about 3 hours
per page (single-spaced) for paper-based documentation
or 2 hours per screen for online documentation. Thus, a
“simple” set of documentation such as a 10-page user
manual and a set of 20 help screens takes 70 hours.
The time required to develop and test user
documentation should be built into the
project plan. Most organizations plan for
documentation development to start once
the interface design and program
specifications are complete. The initial draft
of documentation is usually scheduled for
completion immediately after the unit tests
are complete.
Types of Documentation

Reference documents
Procedures manuals
Tutorials
 Reference Documents
They are designed to be used when the user
needs to learn how to perform a specific
function (e.g., updating a field, adding a new
record). Typically, people read reference
information only after they have tried and
failed to perform the function. Writing
reference documents requires special care
because users are often impatient or
frustrated when they begin to read them.
 Procedures manuals
Procedures manuals describe how to perform
business tasks (e.g., printing a monthly
report, taking a customer order). Each item in
the procedures manual typically guides the
user through a task that requires several
functions or steps in the system. Therefore,
each entry is typically much longer than an
entry in a reference document.
 Tutorials
Tutorials teach people how to use major
components of the system (e.g., an
introduction to the basic operations of the
system). Each entry in the tutorial is typically
longer still than the entries in procedures
manuals, and the entries are usually designed
to be read in sequence, whereas entries in
reference documents and procedures manuals
are designed to be read individually.
User documentation is typically in the
form of online help
Training Information Systems
Users

Potential training topics

 Use of the system
 General computer concepts
 Information system concepts
 Organizational concepts
 System management
 System installation
By far the most common training
method is informal, via
interaction with an in-house
expert on the software
Electronic
Performance
Support Systems
(EPSS), like
Microsoft Office
Assistant, are
components of
software
applications that
embed training and
information for the
user, in the form of
tutorials, expert
systems, and
hyperlink jumps to
reference topics.
Supporting Information Systems
Users
Support is extremely important to users
Providing support can be expensive and
time-consuming
One approach is through automation
 Internet-based online support forums
 On-demand fax
 Voice response systems
 Knowledge bases
 Support Issues
User questions and problems
Recovery and backup
Disaster recovery
PC maintenance
Writing newsletters
Setting up user groups
 Chapter Summary
The systems implementation phase consists
of application development, testing,
installation, and evaluation of the new
system
Analysts also prepare operations
documentation and user documentation
During the installation process, you
establish an operational, or production,
environment for the new information system
that is completely separate from the test
environment
 Summary
In this chapter you learned how to:
 Describe the process of coding, testing, and system
conversion.
 Prepare a test plan for an information system.
 Apply four installation strategies.
 List deliverables for documentation, training, and
user support.
 Distinguish between system and user
documentation.
 Compare different user training modes.
 Discuss issues of end-user support.
 Explain factors influencing implementation success.