Chapter 14:
OOSAD Implementation and
Operation
(Adapted)
Object-Oriented Systems Analysis and
Design
Joey F. George, Dinesh Batra,
Joseph S. Valacich, Jeffrey A. Hoffer
© Prentice Hall, 2004
14-1
Outline

System Implementation Concept

Coding, Testing, Converting, Training Steps
Installation strategies
Chapter 14
© Prentice Hall, 2004
14-2
System Implementation
Concept

Activities that transform design into a working
system and set the system into the production
stage.

In OO methodology, these activities fall mostly
into the construction and transition stages.

Note: As opposed to common sense, coding is
part of implementation - not design.
Chapter 14
© Prentice Hall, 2004
14-3
Chapter 14
© Prentice Hall, 2004
14-4
Coding

Translation of physical design specifications into working
computer code

Coding involves use of programming languages such as
Java or Visual Basic

eXtreme programming – an intensive coding and testing
approach involving two-person teams and customer
involvement
Chapter 14
© Prentice Hall, 2004
14-5
Reuse

The use of previously written software
resources, especially objects and components,
in new applications

Results in great savings of system
development time

Object-oriented systems are very conducive to
reuse.
Chapter 14
© Prentice Hall, 2004
14-6
Approaches to Reuse
Cost and commitment
low

Ad hoc – individual, unplanned use

Facilitated – use informally managed and
disseminated by expert guru evangelists

Managed – organizationally enforced reuse policies
and practices

Designed – reusable components developed and
maintained in-house
high
Chapter 14
© Prentice Hall, 2004
14-7
Software Testing

Manual and automated procedures for validating
correctness of program code, including syntactical and
execution issues

Testing Syntax – grammatical rules applied to
programming languages

Testing Execution – logic and performance of the
software during operation

Note: Bug-free software remains a dream!
Chapter 14
© Prentice Hall, 2004
14-8
Tests can be manual or automated, and
may or may not involve code execution.
Chapter 14
© Prentice Hall, 2004
14-9
Tests Without Program Execution

Inspections (manual)
– Participants examine program code for
predictable, language-specific errors

Syntax checking (automated)
– Compiler or interpreter tests source code
for grammatical errors while translating to
executable format
Chapter 14
© Prentice Hall, 2004
14-10
Manual Tests With Program
Execution

Desk checking
– trace through the logic of the code,
identifying possible logical errors

Walkthroughs
– Like desk-checking, but in a group-oriented,
more structured process
Chapter 14
© Prentice Hall, 2004
14-11
Automated Tests With Program
Execution

Unit tests – a module tested in isolation for
internal consistency

Integration tests – testing all modules and
components of the application together for
interaction compatibilities

System tests – testing all programs and
applications together to ensure performance
and reliability

Acceptance tests – user-satisfaction tests
Chapter 14
© Prentice Hall, 2004
14-12
A test case is a
specific scenario of
transactions,
queries, or
navigation paths
that represent a
typical, abnormal,
or critical use of
the system.
Allows repeated
testing with each
application change
Chapter 14
© Prentice Hall, 2004
14-13
Installation

The process of turning over from the old
information system to the new one.

Types:
– Direct
– Parallel
– Single location
– Phased
Chapter 14
© Prentice Hall, 2004
14-14
Direct – Cold turkey, low cost, greater impact
of errors.
Chapter 14
© Prentice Hall, 2004
14-15
Parallel – old and new coexist, minimize error
impact, high cost in system resources.
Chapter 14
© Prentice Hall, 2004
14-16
Single Location – Pilot approach, allows learning and
minimizes error impact, lower resource demand than
parallel, difficult to coordinate and maintain.
Chapter 14
© Prentice Hall, 2004
14-17
Phased – Staged and incremental, supports phased system
development, minimize error impact, difficult to coordinate
old components and new components.
Chapter 14
© Prentice Hall, 2004
14-18
Types of Documentation


System – detailed
information about a
system’s design
specifications, its inner
workings, and its
functionality.
User – written or other
visual information
about an application
system, how it works,
and how to use it.
Chapter 14

Internal – comments in
source code, generated
during the coding process
or automatically.

External – outcomes of all
structured diagrams,
including use cases, design
classes, activity and
sequence diagrams, etc.
© Prentice Hall, 2004
14-19
User Training

Providing on-going educational and problemsolving assistance to information systems
users.

Training and support material and jobs must
be designed along with the associated
information systems.
User documentation is often in the form of online
help, sometimes with Web connections for further
information.
Chapter 14
© Prentice Hall, 2004
14-20
Training methods can be interpersonal, manual,
or automated.
Chapter 14
© Prentice Hall, 2004
14-21
Help Desks and Information
Centers

Help desk – a single point of contact for all
user inquiries and problems about a particular
information system or for all users in a
particular department

Information center – an organizational unit
whose mission is to support users in exploiting
information technology
Chapter 14
© Prentice Hall, 2004
14-22
Chapter 14
© Prentice Hall, 2004
14-23