System Implementation

Strategies

Week 14
1

Learning Objective

To elaborate and build implementation

diagrams;
To discuss implementation conversion
strategies
To discuss implementation mistakes

Use of Implementation
Diagrams
Can be used architecturally to show how
elements of system will work together
Typically used for simple diagrams
Full documentation of dependencies and
location of all components may be better
handled by configuration management
software or in a spreadsheet or database

Implementation Diagrams
1.

Component Diagrams

2.

used to document dependencies between

components, typically files, either compilation
dependencies or run-time dependencies

Deployment Diagrams

used to show the configuration of run-time

processing elements and the software
components and processes that are located on
them

Component Diagrams

Components

rectangles with two small rectangles

superimposed at one end
may implement interfaces, shown as
circles connected by a line
can be stereotyped, for example to
represent files

Dependencies

Components

Components should be physical components of

a system
Packages can be used to manage the grouping of
physical components into sub-systems
Components can be shown on deployment
diagrams to document their deployment on
different processors

Component Diagrams

A Component diagram shows the dependencies among

software components.
A software component can be any of these:

Source component

Binary component

A binary component is typically object code that is the result of

compiling a source component.

Executable component

A source component is meaningful at compile time. It is typically

a source code file implementing one/more classes.

An executable component is an execute program file that is the

result of linking all library component.

Some components exist at compile time, some exist at

link time, and some exist at run time.

Notation of Component
Diagrams

Compilation dependencies
Header
SalesOrder.h

includes

Body
SalesOrder.cpp

Object Code
SalesOrder.o

Executable
PrintOrder.exe
8

Notation of Component
Diagrams

Dependency of a component on the

interface of another component

Component

Specification

Dependent
Component

Notation of Component
Diagrams

Dependency between high-level

components

Production
scheduler

Staff planner

10

Stereotyped Components

Production
Scheduler

Scheduler.hlp

Scheduler.ini
11

Deployment Diagrams

Nodes

rectangular prisms
represent processors, devices or other resources

Communication Associations

lines between nodes

represent communication between nodes
can be stereotyped

12

Notation of Deployment
Diagrams

TCP/IP
swift:PC

aardvark:DECAlpha

13

Notation of Deployment
Diagrams

Can be shown with active objects or

components located on the nodes
In a component diagram, components are
component types, in a deployment
diagram, they are component instances

14

Notation of Deployment
Diagrams

PC Client

sun.jdbc

Sales
system

aardvark:DECAlpha
JDBC

SalesDB:
Database

15

System Implementation &

Operation

System implementation and operation is made

up of seven major activities:

Coding
Testing
Installation
Documentation
Training
Support
Maintenance

The purpose:

- Leads to
system going
on operation

- For successful
system
operation
- To keep system working and
up-to-date

to convert the final physical system specification into

working and reliable software & hardware
To document the work that has been done
To provide help for current and future users and
caretakers of the system
16

17

18

Coding
Translation of physical design
specifications into working computer code
Coding involves use of programming
languages such as Java or Visual Basic
eXtreme programming(XP) an intensive
coding and testing approach involving twoperson teams and customer involvement

19

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
Purpose:

To find out if its requirement have been met.

To confirm the system satisfies requirements.

20

Tests can be manual or automated, and may

or may not involve code execution.

21

Tests Without Program

Execution

Inspections (manual)

Participants examine program code for

predictable, language-specific errors
Compare the code that are examining to a
checklist of well-known errors for that
particular language

Syntax checking (automated)

Compiler or interpreter tests source code for

grammatical errors while translating to
executable format
22

Manual Tests With Program

Execution

Desk checking

trace through the logic of the code, identifying

possible logical errors
Informal process (programmers work through
the code with a paper and pencil)

Walkthroughs

Like desk-checking, but in a group-oriented,

more structured process

23

Code walkthrough is one of many

types of structured
walkthroughs.

24

Automated Tests With

Program Execution

Unit tests
- a module tested in isolation for internal consistency
- each object/component is tested alone in an attempt to discover
any errors.
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 (in actual environment)
- is implemented once system tests have been completed
satisfactorily

25

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

26

Installation/CONVERSION

The organizational process of turning over

from the old information system to the new
one

Types:
1.
2.
3.
4.

Direct
Parallel
Single location
Phased

27

Direct low cost, greater impact of errors

28

Direct Changeover

On a certain date the old system stops and the

new system starts
+ brings immediate benefits
+ forces users to use the new system
+ simple to plan
no fallback if problems occur
contingency plans required for the unexpected
the plan must work without difficulties

Suitable for small-scale, low-risk systems

29

Parallel old and new coexist, safe,

minimize error impact, high cost in
system resources
30

Parallel Running

Old system runs alongside the new system for a

period of time
+ provides fallback if there are problems
+ outputs of the two systems can be compared, so testing
continues into the live environment
high running cost including staff for dual data entry
cost associated with comparing outputs of two systems
users may not be committed to the new system

Suitable for business-critical, high-risk systems

31

Single Location Pilot approach, allows learning

and minimizes error impact, lower resource
demand than parallel, difficult to coordinate and
maintain
32

Single Location/Pilot Project

Complete system is tried out in one department

or at one site
+ can be used as a learning experience
+ can feed back into design before system is launched
organization-wide
+ decision on whether to go ahead across the whole
organization can depend on the pilot outcome
+ reduces risk
there is an initial cost without benefits across the whole
organization

Suitable for smaller systems and packaged

software
33

Phased Staged and incremental, supports

phased system development, minimize error
impact, difficult to coordinate old components
and new components
34

Phased Changeover

The new system is introduced in stages,

department by department or geographically
+ attention can be paid to each sub-system in turn
+ sub-systems with a high return on investment can be
introduced first
+ thorough testing of each stage as it is introduced
if there are problems rumours can spread ahead of the
implementation
there can be a long wait for benefits from later stages

Suitable for large systems with independent

sub-systems

35

Key Factors in Selecting a

Conversion Strategy

Risk

Cost

Seriousness of consequences of remaining bugs

Parallel is less risky then direct, because it has a greater chance of
detecting bugs that have gone undiscovered in testing.
Pilot is less risky than phased because if bugs do occur, they occur in
pilot test locations.
Eg.: Salaries, travel expenses, operation and communication expenses,
hardware leases.
Parallel is more expensive then direct because its requires paying for
two systems for a period of time

Time

Refers to amount of time required to convert between old system and

new system.
Parallel and phased require more time
36

Types of Documentation

System records detailed information

about a systems design specifications, its
inner workings, and its functionality

User consists of written or other visual

information about an application system,
how it works, and how to use it.

37

Types of System
Documentation

Internal comments in source code, generated

during the coding process or automatically by
software compilers or documenters

External outcomes of all structured diagrams,

including use cases, design classes, activity and
sequence diagrams, etc.

38

User documentation is
often in the form of
online help, sometimes
with Web connections
for further information.

39

Training and Support

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

40

Training methods can be interpersonal,

manual, or automated.

41

Electronic Performance Support

Systems (EPSS), like Microsoft
Office Assistant, are components
of software applications that
embed training and information
for the user, in the form of
tutorials, expert systems, and
hyperlink jumps to reference
topics.

42

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

43

Systems Maintenance

Changes made to a system to fix or enhance

its functionality

44

System maintenance operates as repeated,

miniaturized systems development cycles.
45

Maintenance
requests can
be frequent.
Priorities
among
requests
should be
made based
on the type
and urgency of
the request.
46

Maintenance Cost Factors

Latent defects
- Number of unknown error existing in the system after it
is installed.

Number of customers for the system

- number of customer, cost

Quality of system documentation

Quality of maintenance personnel
Availability of automated tools
Quality of program code and system design
- well-structured programs are easier to understand

and fix.

47

Classic Implementation
Mistakes
Mistakes
Research-oriented development
the project team attempts to use the
latest new technology, which is not
well understood and/or documented

Solution
The project manager needs to
significantly increase project time and
cost estimates when state-of-the-art
technology that is used

Use low-cost personnel if cost is a Assigning entry-level persons to handle

critical issues, assign the best, most
complex task is expected to cost the
expensive personnel to the project
project in other ways.
Not having a source code control
source code developed in a large
programming teams needs to be
controlled so that programmers
accidentally do not undo each others
work.

Using source control where each

programmer checks out the modules
he/she need to work on, and checks
them back in when they complete
changes is required in moderate to large
programming teams

Inadequate testing ad hoc testing

is the number one reason for project
failures during the implementation
phase.

The project manager should allocate

sufficient time in the project plan for
formal testing.

48