14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation (Adapted) Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.

14-1 © Prentice Hall, 2004

Chapter 14:Chapter 14:OOSAD Implementation and OOSAD Implementation and

OperationOperation(Adapted)(Adapted)

Object-Oriented Systems Analysis and Design

Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer

14-2Chapter 14 © Prentice Hall, 2004

OutlineOutline

System Implementation Concept

Coding, Testing, Converting, Training Steps

Installation strategies

14-3Chapter 14 © Prentice Hall, 2004

System Implementation System Implementation ConceptConcept

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.

14-4Chapter 14 © Prentice Hall, 2004

14-5Chapter 14 © Prentice Hall, 2004

CodingCoding

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

14-6Chapter 14 © Prentice Hall, 2004

ReuseReuse

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.

14-7Chapter 14 © Prentice Hall, 2004

Approaches to ReuseApproaches to Reuse 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-houseC

ost a

nd c

omm

itmen

t

low

high

14-8Chapter 14 © Prentice Hall, 2004

Software TestingSoftware 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!

14-9Chapter 14 © Prentice Hall, 2004

Tests can be manual or automated, and may or may not involve code execution.

14-10Chapter 14 © Prentice Hall, 2004

Tests Without Program ExecutionTests 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

14-11Chapter 14 © Prentice Hall, 2004

Manual Tests With Program Manual Tests With Program ExecutionExecution

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

14-12Chapter 14 © Prentice Hall, 2004

Automated Tests With Program Automated Tests With Program ExecutionExecution

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

14-13Chapter 14 © Prentice Hall, 2004

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

14-14Chapter 14 © Prentice Hall, 2004

InstallationInstallation The process of turning over from the old

information system to the new one.

Types:– Direct– Parallel– Single location– Phased

14-15Chapter 14 © Prentice Hall, 2004

Direct – Cold turkey, low cost, greater impact of errors.

14-16Chapter 14 © Prentice Hall, 2004

Parallel – old and new coexist, minimize error impact, high cost in system resources.

14-17Chapter 14 © Prentice Hall, 2004

Single Location – Pilot approach, allows learning and minimizes error impact, lower resource demand than parallel, difficult to coordinate and maintain.

14-18Chapter 14 © Prentice Hall, 2004

Phased – Staged and incremental, supports phased system development, minimize error impact, difficult to coordinate old components and new components.

14-19Chapter 14 © Prentice Hall, 2004

Types of DocumentationTypes 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.

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.

14-20Chapter 14 © Prentice Hall, 2004

User TrainingUser Training Providing on-going educational and problem-

solving 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.

14-21Chapter 14 © Prentice Hall, 2004

Training methods can be interpersonal, manual, or automated.

14-22Chapter 14 © Prentice Hall, 2004

Help Desks and Information Help Desks and Information CentersCenters

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

14-23Chapter 14 © Prentice Hall, 2004