Chapter 14

Implementing
and
Maintaining
the System
1
 What is System Implementation?
• Activities that ensure the new system is
fully functional and operational
• Activities that turn over control of the new
system to the end users

2
 System Implementation
• Application testing and user acceptance
• User training and final documentation
• System installation and conversion

3
 Application Testing
• Testing categories
– Code inspection
– Structured walk-through
– Desk check
– Module testing

4
Table 14-1. Classification of Software Tests

5
 Code Inspection
• Inspect the actual code for the occurrence
of certain types of programming errors
• Focus on errors that may not be
syntactically or grammatically incorrect but
may cause the logic of the code to fail

6
 Structured Walkthrough
• To test whether the code actually performs
the functions intended by the designer
• Close examination of the embedded logic
in the code

7
 Desk Check
• Focuses on the actual execution of the
code
• One or more programmers who are not
responsible for the actual writing of the
codes work through a hard copy of source
code

8
 Module Testing
• Also referred to as Unit Test
• Focuses on ascertaining the successful
execution of each application module prior
to integrating it with other tested modules
• One of the primary black-box testing
methods
• Test Driver is written to facilitate the test

9
 Stub Testing
• Top-down testing scenario
– The highest-level control module is tested first
– The lower-level modules are simulated by a
program stub designed to simply accept
control from a high-level module and return it
back to that module

10
Figure 14-2. Stub Testing Using a Top-Down Approach

11
 Integration Testing
• Focus on testing the behavior of an entire
group of modules to identify errors that
either were not, or could not be detected
at the unit level

12
 Integration Testing
• Integration strategies
– All at once (big-bang)
– Top-down
– Bottom-up
– Critical piece first

13
Figure 14-3. Combined Module and Integration Testing Strategy
14
 System Testing
• Focus on the behavior of the entire system
• The goal is to have no errors or anomalies
remaining
• Build-and-smoke test

15
 User Acceptance Test
• User verifies that the delivered and
installed product is ready to be put into
production use
• Alpha Test (verification test)
– Done by the client at the developer’s site
• Beta Test (validation test)
– Conducted by the end users at their own site

16
 User Acceptance Test
• Script
– Designed to verify that the major functions are
properly operating in their most common
mode
– A testing script is hierarchically organized by
subsystem and function

17
Table 14-2. The 16 Commandments of User Acceptance Testing

18
 Installing the System
• Tasks:
– System conversion
– Final documentation
– End user training

19
 System Conversion
• Direct conversion
– The old system is simply turned off, and the new
system is turned on in its place
– Should be considered only in extreme
circumstances where no other conversion strategy
is viable
– Also referred to as slam dunk or cold-turkey
strategy

20
 System Conversion
• Parallel Conversion
– The old and new systems are run
simultaneously until the end users are fully
satisfied that the new system is functioning
correctly and the old system is no longer
necessary

21
 System Conversion
• Pilot Conversion
– Allows for the conversion to the new system,
using either direct or parallel method, at a
single location

22
 System Conversion
• Phased Conversion
– Allows for the new system to be brought on-
line as a series of functional components that
are logically ordered so as to minimize
disruption to the end users and the flow of
business

23
Figure 14-4. Comparison of System Conversion Strategies

24
 User Documentation
• To provide the end users with a detailed
and highly organized description of how to
interact with the system
• On-line documentation (context-sensitive
help)

25
 System Documentation
• Describe the design specification, the
internals of the system, the as-built
program code, and the functionality of all
modules
• To assist and support personnel
responsible for maintaining the final
system

26
 User Training and Support
• User training design and content
– One-size-fits-all training program is not a
desirable structure for training
– Users need to be trained on how to use the
system to perform their respective jobs

27
 User Training and Support
• User training methods and delivery
– Traditional classroom
– One-on-one training
– Self-paced or computer-based training
– Training schedule must be closely linked to
the conversion strategy

28
 Post-Implementation Activities
• To correct errors or faults in the system
• Provide changes to affect performance
improvement
• Adapt the system to changes in the
operating environment

29
 System Maintenance
• Change requests
– Identifying and implementing changes to the
system that add or enhance functionality
– Change control steering committee

30
 System Maintenance
• Corrective Maintenance
– Fix bugs and logical errors not detected
during the implementation testing period
• Adaptive Maintenance
– Modifying existing functions or adding new
functionality to accommodate changes in the
operating environment

31
 System Maintenance
• Perfective Maintenance
– Changes made to an existing system to
improve the performance of a function or
interface
• Preventive Maintenance
– Activities intended to reduce the chances of a
system failure or extend the capacity of a
current system’s useful life

32
 System Maintenance
• Preventive maintenance activities
– Hardware maintenance to keep electromechanical
equipment operating correctly
– Replacement of hardware components to keep the
equipment up to current specifications
– Updating of system software
– Testing and analysis of system reports
– Maintenance of system documentation

33
 System Maintenance
• System Maintenance Costs
– There is a direct link between the cost of
absolute availability and the cost of downtime
– Maintenance can account for a significant
portion of the total IS budget

34
 System Maintenance
• Cost Estimation of Downtime
– Productivity loss
• Downtime that has a negative impact on individual
or workgroup productivity

• Productivity Loss = (# of Affected Users) x (Percentage Effect on Productivity

/ 100) x (Average Burdened Salary per Hour) x (Hours of Downtime)

35
 System Maintenance
• Cost Estimation of Downtime
– Business loss
• Downtime that affects transactions or result in
customer losses
– Business Loss =
(# of Affected Users) x (Percentage Effect on Productivity / 100) x (Average
Profit per Employee Hour) x (Hours of Downtime)
– Or
(# of Transactions per Hour) x (Percentage of Affected Transactions / 100) x
(Average Profit per Transaction) x (Hours of Downtime)

36