Systems Analysis & Design

Sixth Edition

Chapter 9
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
2
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
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
4
Chapter Objectives
● Describe the data conversion
process
● Identify and describe changeover
methods
● Explain post-implementation
evaluation
● Describe the final report to
management

5
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 6
Software Quality Assurance
● Quality assurance
● Software Engineering
– Software Engineering Institute (SEI)
– Capability Maturity Model (CMM)
– Capability Maturity Model Integration
(CMMI)
– Process improvement
– CMMI tracks an organization's processes,
using five maturity layers

7
Software Quality Assurance
● International Organization for
Standardization (ISO)
– Many firms seek assurance that software
systems will meet rigid quality standards
– In 1991, ISO established a set of
guidelines called ISO 9000-3
– ISO requires a specific development
plan, which outlines a step-by-step
process for transforming user
requirements into a finished product

8
Overview of Application
Development
● 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

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

11
Structured Application
Development
● Top-down approach
● Partitioning
● Modular design
● Must proceed 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
12
Structured Application
Development
● Structure Charts
– Structure charts show the program
modules and the relationships among
them
– Control module
– Subordinate modules

13
Structured Application
Development
● Structure Charts
– Module
• Library module
– Data Couple
– Control Couple
• Flag
• A module uses a flag to signal a specific
condition or action to another module

14
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

15
Structured Application
Development
● Cohesion and Coupling
– If you need to make a module more
cohesive, you can split it into separate
units, each of which performs a single
function
– Loosely coupled
– Tightly coupled
– Status flag

16
Structured Application
Development
● Structure Chart Examples

17
Structured Application
Development
● Drawing a Structure Chart
– Step 1: Review the DFDs
– Step 2: Identify Modules and
Relationships
– Step 3: Add Couples, Loops, and
Conditions
– Step 4: Analyze the Structure Chart and
the Data Dictionary

18
Structured Application
Development
● Other Structured Development
Tools
– Program Flowcharts
– Pseudocode

19
Object-Oriented Application
Development
● Object-Oriented Application
Development Compared to
Structured Development
– When implementing an object-oriented
design, relationships between objects
already exist
– The application's structure is represented
by the object model itself
– Attributes
– Methods

20
Object-Oriented Application
Development
● Implementation of Object-Oriented
Design
– Programmer makes necessary revisions
and updates to class diagrams, sequence
diagrams, state transition diagrams, and
activity diagrams
– Main objective is to translate object
methods into program code modules and
determine what event or message will
trigger the execution of each module

21
Coding
● Coding
● Programming Environments
– Each IT department has its own
programming environment and
standards
– Integrated development environments
(IDEs)
● Generating Code
– Can generate editable program code
directly from macros, keystrokes, or
mouse actions
22
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

23
Testing the System
● Unit Testing
– Test data
– Programmers must test programs that
interact with other programs and files
individually
– Stub testing
– Regardless of who creates the test
plan, the project manager or a
designated analyst also reviews the
final test results

24
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

25
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

26
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

27
Testing the System
● System Testing
– 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

28
Documentation
● Documentation
● Program Documentation
● System Documentation
● Operations Documentation
● User Documentation
– Online documentation

29
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

30
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

31
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
32
Operational and Test
Environments

33
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

34
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

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

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

38
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

39
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

40
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

41
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

42
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

43
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

44
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

45
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

46
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
47
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

48
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
49
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 50
Chapter Summary
● 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

● Chapter 9 complete
51