*

System Implementation Strategies

Week

14

*

*

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

Component Diagrams

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

*

A Component diagram shows the dependencies among software components.

A software component can be any of these:

Source component

A source component is meaningful at compile time. It is typically a source code file implementing one/more classes.

Binary component

A binary component is typically object code that is the result of compiling a source component.

Executable component

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.

Component Diagrams

*

Notation of Component Diagrams

Compilation dependencies

Header

SalesOrder.h

Body

SalesOrder.cpp

includes

Executable

PrintOrder.exe

Object Code

SalesOrder.o

*

Dependency of a component on the interface of another component

Notation of Component Diagrams

Component

Dependent
Component

Specification

*

Dependency between high-level components

Notation of Component Diagrams

Production
scheduler

Staff planner

*

Stereotyped Components

?

Production
Scheduler

Scheduler.hlp

Scheduler.ini

*

Deployment Diagrams

Nodes

rectangular prisms

represent processors, devices or other resources

Communication Associations

lines between nodes

represent communication between nodes

can be stereotyped

*

Notation of Deployment Diagrams

swift:PC

aardvark:DECAlpha

TCP/IP

*

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

Notation of Deployment Diagrams

*

Notation of Deployment Diagrams

PC Client

JDBC

aardvark:DECAlpha

SalesDB:

Database

sun.jdbc

Sales

system

*

System Implementation & Operation

System implementation and operation is made up of seven major activities:

Coding

Testing

Installation

Documentation

Training

Support

Maintenance

The purpose:

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

- Leads to system going on operation

- For successful system operation

- To keep system working and up-to-date

*

*

*

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 two-person teams and customer involvement

*

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.

*

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

*

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

*

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

*

Code walkthrough is one of many types of structured walkthroughs.

*

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

*

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

*

Installation/CONVERSION

The organizational process of turning over from the old information system to the new one

Types:

Direct

Parallel

Single location

Phased

*

Direct low cost, greater impact of errors

*

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

*

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

*

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

*

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

*

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

*

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

*

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

*

Key Factors in Selecting a Conversion Strategy

RiskSeriousness of consequences of remaining bugsParallel 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.CostEg.: 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 timeTimeRefers to amount of time required to convert between old system and new system.Parallel and phased require more time

*

*

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.

*

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.

*

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

*

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

*

Training methods can be interpersonal, manual, or automated.

*

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.

*

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

*

Systems Maintenance

Changes made to a system to fix or enhance its functionality

*

System maintenance operates as repeated, miniaturized systems development cycles.

*

Maintenance requests can be frequent.

Priorities among requests should be made based on the type and urgency of the request.

*

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.

*

Classic Implementation Mistakes

MistakesSolutionResearch-oriented development the project team attempts to use the latest new technology, which is not well understood and/or documentedThe project manager needs to significantly increase project time and cost estimates when state-of-the-art technology that is usedUse low-cost personnel if cost is a critical issues, assign the best, most expensive personnel to the projectAssigning entry-level persons to handle complex task is expected to cost the 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 teamsInadequate 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.