Modern Systems Analysis

and Design
Seventh Edition

Jeffrey A. Hoffer
Joey F. George
Joseph S. Valacich

Chapter 13
System Implementation
 FIGURE 13-1
Systems development
life cycle with the
implementation phase
highlighted

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 2

System Implementation
 Implementation is the most expensive and time-
consuming phase of the entire life cycle.
 Implementation is expensive because so many
people are involved in the process;
 it is time consuming because of all the work that
has to be completed
 Six major activities:
 Coding
 Testing
 Installation
 Documentation
 Training
 Support

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 3

System Implementation (Cont.)
 Purpose:
 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

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 4

 The Process of Coding, Testing, and
Installation
 Coding
 Physical design specifications (created by the analysis team)
are turned into working computer code(by the programming
team).
 Testing
 Tests are performed using various strategies.
 Testing is performed in parallel with coding.
 Installation
 The current system is replaced by a new system.
 This includes conversion of existing data, software,
documentation, and work procedures to those consistent with
the new system.
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 5
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 6
 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

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 7

 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.
 Written test plans provide improved
communication among all parties involved in
testing.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 8

The Testing Process
 The purpose of testing is to confirm that the
system satisfies the requirements.
 Testing must be planned.
 Test case is a specific scenario of transactions,
queries or navigation paths.
 Test cases need to determine that new software
works with other existing software with which it
must share data.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 9

 The Testing Process (Cont.)

 Testing harness
 special purpose testing software, called
a testing harness
An automated testing environment used
to review code for errors, standards
violations, and other design flaws.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 10

 Categorization of Test Types
 Static or dynamic techniques
 Static
testing means that the code being tested is not
executed.
 Dynamic testing involves execution of the code.

 Test is automated or manual

 Automatedmeans computer conducts the test.
 Manual means that people complete the test.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 11

Different Types of Tests
 Inspection: a testing technique in which participants
manually examine program code for predictable
language-specific errors
 Walkthrough: a peer group review of any product
created during the systems development process,
including code and are widely used by professional
development organizations.
 Desk checking: a testing technique in which the
program code is sequentially executed manually by the
reviewer(with a paper and pencil )

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 12

Different Types of Tests (Cont.)

 Unit testing(module testing): each module is

tested alone in an attempt to discover any errors
in its code
 Integration testing: the process of bringing
together all of the modules that a program
comprises for testing purposes
 System testing: the bringing together of all of
the programs that a system comprises for testing
purposes
Each module supports an individual, traditional business function
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 13
Combining Coding and Testing
 Coding and testing often go together.
 Big companies have dedicated test staff.
 With eXtreme programming (XP) a
common technique is refactoring.
 Refactoring = making a program simpler
after adding a new feature

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 14

Acceptance Testing by Users
 Acceptance testing: the process whereby
actual users test a completed information
system, the end result of which is the users’
acceptance of it
 Alpha testing: user testing of a completed
information system using simulated data
 Beta testing: user testing of a completed
information system using real data in the real
user environment
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 15
Installation
 Installation: The organizational process
of changing over from the current
information system to the new one
 Four installation strategies:
 Direct Installation
 Parallel Installation
 Single-location installation
 Phased Installation

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 16

Direct Installation
 Direct installation: changing over from the old
system to a new one by turning off the old system
when the new system is turned on

 Parallel installation: running the old information

system and the new one at the same time until
users and management are satisfied that system
is effectively performing, management decides
the old system can be turned off
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 17
Single-Location Installation
 Single-location installation: Rather than
convert all of the organization at once, single-
location installation involves changing from the
current to the new system in only one place or in
a series of separate sites over time.
Also known as location or pilot installation
 The key advantage to single-location installation
is that it limits potential damage and potential
cost by limiting the effects to a single site.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 18

Phased Installation
 Phased(staged) Installation: changing
from the old information system to the new
one incrementally, starting with one or a
few functional components and then
gradually extending the installation to
cover the whole new system
 By converting gradually, the organization’s
risk is spread out over time and place

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 19

Documenting the System
 System documentation: detailed
information about a system’s design
specifications, its internal workings, and its
functionality
 User documentation: written or other
visual information about an application
system, how it works, and how to use it

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 20

Documenting the System (Cont.)

 Internal documentation: system

documentation that is part of the program
source code or is generated at compile
time
 External documentation: system
documentation that includes the outcome
of structured diagramming techniques
such as data flow and E-R diagrams
Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 21
Training and Supporting Users
 Support: providing ongoing educational
and problem-solving assistance to
information system users
 For in-house developed systems, support
materials and jobs will have to be
prepared or designed as part of the
implementation process.

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 22

 Training Information Systems
Users
Potential training topics
 Use of the system (e.g., how to enter a class registration request)
 General computer concepts (e.g., computer files and how to copy them)
 Information system concepts (e.g., batch processing)
 Organizational concepts (e.g., FIFO inventory accounting)
 System management (e.g., how to request changes to a system)
 System installation (e.g., how to reconcile current and new systems
during phased installation)

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 23

Supporting Information Systems
Users
 Support is important to users, but has
often been inadequate.
 Providing support can be expensive and
time-consuming.
 Providing Support through Automatic
Support and a Help Desk

Chapter 13 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 24

 Chapter 14
Maintaining Information
Systems
Maintaining Information
Systems

FIGURE 14-1
Systems development life cycle

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 26

 The Process of Maintaining
Information Systems
 Maintenance: changes made to a system to fix or
enhance its functionality
 Process of returning to the beginning of the SDLC
and repeating development steps focusing on system
change until the change is implemented
 Maintenance is the longest phase in the SDLC.
 The maintenance phase of the SDLC is basically a
subset of the activities of the entire development
process.

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 27

 Deliverables and Outcome
the deliverables and outcomes from the
process are the development of a new
version of the software and new versions
of all design documents developed or
modified during the maintenance process.

FIGURE 14-3
Maintenance activities parallel those of
the SDLC

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 28

 The Process of Maintaining
Information Systems (Cont.)
 Four major activities:
Obtainingmaintenance requests
Transforming requests into changes
Designing changes
Implementing changes

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 29

some person within the
systems development
group is responsible for
collecting maintenance
requests

FIGURE 14-2
System Service Request
for purchasing
fulfillment system (Pine
Valley Furniture)

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 30

Types of System Maintenance
 Corrective maintenance: changes made
to a system to repair defects in its design,
coding, or implementation
corrective maintenance problems surface
soon after installation,75 %of all
maintenance activity
 Adaptive maintenance: changes made
to a system to evolve its functionality to
changing business needs or to migrate it
to a different operating environment
Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 31
Types of System Maintenance
(Cont.)
 Perfective maintenance: involves
making enhancements to improve
processing performance or interface
usability or to add desired, but not
necessarily required, system features
Preventive maintenance: changes
made to a system to avoid possible
future problems

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 32

Types of System Maintenance
(Cont.)

Figure 14-4
Value and non-value adding of different types of maintenance
(Sources: Based on Andrews and Leventhal,1993; Pressman,
2005.)

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 33

 Managing Maintenance Personnel

 Three possible organizational structures:

 Separate — maintenance group consists of
different personnel than development group
 Combined — developers also maintain
systems
 Functional — maintenance personnel work
within the functional business unit

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 34

Managing Maintenance Personnel
(Cont.)
Maintenance
Organization Advantages Disadvantages
Type
Separate Improved system Ignorance of critical
and documentation undocumented
quality information

Combined Maintenance group Less emphasis on

knows all about good documentation
system

Functional Personnel have Limited job mobility

vested interest and human or
technical resources

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 35

Measuring Maintenance
Effectiveness
 Must measure the following factors:
Number of failures
Time between each failure
Type of failure
 Mean time between failures (MTBF):
a measurement of error occurrences
that can be tracked over time to indicate
the quality of a system
Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 36
Role of CASE and Automated
Development Tools in Maintenance
 Traditional systems development
 Emphasis is on coding and testing.
 Changes are implemented by coding and
testing first.
 Documentation is done after maintenance is
performed.
 Keeping documentation current is often
neglected due to time-consuming nature of
task.

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 37

Role of CASE and Automated
Development Tools in Maintenance
(Cont.)
 Development with CASE
 Emphasis is on design documents.
 Changes are implemented in design
documents.
 Code is regenerated using code generators.
 Documentation is updated during
maintenance.

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 38

Role of CASE and Automated
Development Tools in Maintenance
(Cont.)
 Reverse engineering: automated tools
that read program source code as input
and create graphical and textual
representations of design-level information
such as program control structures, data
structures, logical flow, and data flow

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 39

Role of CASE and Automated
Development Tools in Maintenance
(Cont.)
 Reengineering: automated tools that read
program source code as input; perform an
analysis of the program’s data and logic;
and then automatically, or interactively
with a systems analyst, alter an existing
system in an effort to improve its quality or
performance

Chapter 14 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 40