10.1

System implementation and maintenance

IMS9001 - Systems Analysis and Design

10.2

Implementation (Build)

Build and deliver the system

Build, test, installand deliver the

new system

User acceptance testing

User Documentation

Technical Design Report

MAINTENANCE

DESIGN

SystemVendors Hardware/

Software

System Owners

User Training

Production System

System and Technical

Documentation

SystemUsers

Project Report

10.3

implementation planning Build and test software Build/modify databases, networks etc. finalise documentation prepare the site convert data into required form and

media conduct training install system monitor system transition to maintenance mode post-implementation review

Implementing the System

10.4

Systems ImplementationAcceptance Checklist, Implementation Schedule, Training Schedule, Re-estimate

Training Guides, User Manuals

Test Data Preparation, System Test: Functional & Performance, Test Conversion

Acceptance Test

Computer Documents, I/O Documents, Operating Guide

REVIEW

REVIEW

REVIEW

REVIEW

REVIEW

FINALISE DOCUMENTATION

CONDUCT SYSTEM TESTING

CONDUCT ACCEPTANCE TESTING

OPERATIONS HANDOVER

IMPLEMENTATIONPLANNING

10.5

Distribute Manuals, Test Equipment, Conduct Training, Set up / Convert Files

System Installation, Monitor Operations, Secure Acceptance, Run Benchmark Tests, Tune System

Hand over Technical Documentation, Post Implementation Review (What went wrong ?)

REVIEW

REVIEW

REVIEW

CONDUCT TRAINING

GET SYSTEM READY

FOR START-UP

CONDUCT SYSTSEM

ACCEPTANCE

WRAP UP

Systems implementation cont.

10.6

Implementation stage of the project requires a great deal of co-ordination with

professionals outside the development team Implementation plan

will have been developed at earlier stage of project

will need to be extended in greater detail must be updated to reflect the current

situation Poor planning can cause significant delays

in deadline! Tasks

finalise acceptance checklist complete and confirm training schedule review and revise implementation plan

Implementation Planning

10.7

Documentation describes how a system works to a wide audience

The four main areas are:

Training documentation used specifically during the training sessions especially designed to put the novice user at ease

User documentation tells users how to work with the system and

perform their tasks may be a user manual, on-line help, quick

reference guide etc

Finalise Documentation

10.8

System documentation a communications tool and to review and

revise the system during development also facilitates maintenance and

enhancement of the system Operations documentation

aimed at a centralised operations group (not on-line operators)

details what tasks an operator needs to carry out for a particular program

Finalise documentation cont.

10.9

Testing is ... " the process of exercising or evaluating

a system by manual or automatic means to verify that it satisfies specified requirements or to identify differences between expected and actual results "

(IEEE, 1983)

Testing

10.10

All testing involves the following steps: select what is to be measured by the test decide how it is to be tested develop the test cases determine the expected or correct results

(you must ensure that expected results can be measured - vagueness does not encourage adequate testing)

execute the test cases compare actual results to expected results

Testing Steps

10.11

Stages of Testing

Performance test

Function test

Unit (module) test

Installation test

Acceptance test

Integration test

tested modules

integrated modules

functioning system

validated software

accepted system

system in use

Systems design

Systems implementation

Systems analysis &

design

User requirements

Systems specifications

Program specifications

Programs, procedures,

data

10.12

Each module is tested individually Lists what is being tested

Lists expected outcome

Identifies data to be used .. all possible combinations

Who carries out Module Testing? Programmer - tests at code level

Analyst - tests at application level

Module or Unit Testing

10.13

Integration Testing

Verifies that system components work together: data can be lost across interfaces a function may not perform as expected

when combined with another function one module can have an adverse effect on

another Use an incremental approach to integrate

modules- easier to detect and correct errors: Top-down testing Bottom-up testing Sandwich testing

10.14

The process of testing the integrated software in the context of the total system it supports

Performed after all unit and integration testing is complete

Tests conducted at this stage include: Function tests - demonstrate that all the

functions specified for the system in the requirements specification are operational

Performance tests - demonstrate that the system meets the non-functional requirements specified.

System Testing

10.15

Performed after all programming and integration testing is finished

Test cases must cover every aspect of the system’s

functionality should have a high probability of

detecting errors Test plan

should be developed from the original specification

must include expected results that are measurable

Function Testing

10.16

Compares the integrated modules with the non-functional system requirements such as speed, performance Stress tests Volume tests Configuration tests Compatibility tests Security tests Documentation

tests Timing tests Environmental tests Quality tests Recovery tests Maintenance tests Human factors tests

Performance Testing

10.17

Acceptance Testing

Involves installing the system at user sites and is required when acceptance testing has not been performed on site

The test focuses on completeness of the installed system and verification of any functional or nonfunctional characteristics that may be affected by site conditions

Testing is complete When the customer is satisfied with the results The system can then be formally delivered

10.18

Ensure that facilities are adequate: adequate space for all resources, ergonomic furniture,

noise reduction, privacy, security, appropriate electrical connections, uninterrupted power, etc.

Install the hardware and software required to run the system must be tested to ensure no damage during transportation,

product not defective, product changes between purchase and delivery are acceptable etc

People responsible Vendor Engineer, Technical Support Group

Prepare the Site

10.19

Current production data needs to be converted Format, Content, Storage Medium Done according to the conversion plan Manual file conversion is a time-consuming task Often needs specially written conversion programs e.g.

Database Load Program Record Transformation Program

Data must be confirmed to be correct May need to support both old and new systems’ files

can introduce time lag files may be out of step

Data Conversion

10.20

Need to consider: who is the audience? what level of detail should be imparted to

the audience? who should conduct the training? where should the training be conducted? when should the training be conducted?

Conduct Training

10.21

Training - a complete and concentrated course in system use at the time of delivery

Ongoing training needs; new staff, staff changes etc.

Training must be planned methods resources should also consider Help during and after

installation for new users, infrequent users and users who want to "brush up"

User Training

10.22

Training aids must be easy to use reliable demonstrations and classes documentation on-line help and icons expert users

Supportive User Manager who provides training, motivation, support

User training

10.23

Method of installation depends on several criteria Cost - if there are cost constraints certain choices are

not viable System criticality - if system failure would be disastrous,

the safest approach should be selected regardless of cost

User computer experience - the more experience the users have, the less necessary it is to delay changeover

System complexity - the more complex the system, the greater the chance of flaws ... a safer approach is better

User resistance - need to consider what the users are best able to cope with

Install the System

10.24

Alternatives

Direct installation or Abrupt cut-over Parallel installation Phased installation or Staged installation Pilot installation or Single Location

conversion

Install the System

10.25

Old system New system

Total cutover

Old system stops and new system starts

Direct Installation(Abrupt Cutover)

10.26

This approach is meaningful when the system is not replacing any other system the old system is judged absolutely without value the old system is either very small and/or very

simple the new system is completely different from the

old and comparisons would be meaningless

Advantages costs minimised

Disadvantages high risk

Direct Installation(Abrupt Cutover)

10.27

Old system

New system

Total cutover

Old and new systems operated concurrently

Parallel Installation

10.28

Old and new systems operated concurrently Cut-over at end of a business cycle Balancing between both systems Advantages

risks low if problems occur

Disadvantages cost of operating both systems 2.5 times the

resources

Parallel Installation

10.29

Old system

Total cutover

New system

System installed in stages

Phased Installation(Staged Installation)

10.30

System installed in stages Subsequent stages provide more

features Phases or stages need to be identified

at general design Advantages

lower costs for earlier results benefits can be realised earlier rate of change for users minimised

Phased Installation(Staged Installation)

10.31

Disadvantages close control of systems development is

essential costs associated with the development of

temporary interfaces to old systems limited applicability demoralising - no sense of completing a

system.

Phased Installation(Staged Installation)

10.32

Old system

New system

Total cutover

Old system New system

Old system New system

Old and new systems operated concurrently

Pilot Installation

10.33

Old and new systems operated concurrently Only part of the organisation tries out the new

system The pilot system must prove itself at the test site Advantages

risks relatively low if problems occur errors are localised can be used to train users before implementation at their

own site

Disadvantages lack of consistency between different parts of organisation

Pilot Installation

10.34

Monitor user satisfaction with functional requirements with system performance

Run benchmark tests

Tune system

Monitor Operations

10.35

Most organisations have formal procedures set up

A "maintenance" section is responsible!

Procedures should be set up to request maintenance

Owners of the new system must be informed of relevant procedures

Transition to Maintenance

10.36

Maintenance

Fix it / Make it better

Maintain the new system

Project staff

Problems/New ideas

Technical problems and new technology

PRODUCTION SYSTEM

System

Users

Fixes andenhancem

ents

Additional training anddocumentation

Modifications

back to INITIATION

Escalating maintenance

10.37

Maintenance

Corrective - fix errors Adaptive - satisfy changing needs Perfective - enhance performance Preventative - fix potential problems

If the cost of maintenance is too high consider other options: new development, purchase a software

package, re-engineer/modify

10.38

Corrects analysis, design and implementation errors

Can be the most expensive kind of maintenance costs of functions not working correctly having to undo what has been developed

Requires immediate attention typically urgent, interfere with normal operations

Needs skilled maintenance staff to ensure rapid diagnosis of errors and their correction must have or quickly develop high level of familiarity

with the system May use software tools for diagnosis

Corrective Maintenance

10.39

To satisfy changes in the environment, changing business needs or new user requirements changes in tax laws, takeovers and mergers, new

OS, etc new type of report, new class of customer etc.

Less urgent - changes occur over time Adaptive maintenance is inevitable, does add

value Maintenance staff need strong analysis and

design skills as well as programming skills changes often require a complete SDLC also need good understanding of the system

Adaptive Maintenance

10.40

Pay now or pay more later defects or potential problems found and corrected

before they cause any damage reduce chance of future system failure eg expand number of records beyond needs,

standardise formats across platforms

A natural by-product of maintenance work - identify and fix any potential problems noted while fixing other errors

Ideally have periodic (monthly / half-yearly / annual) reviews of system to uncover and anticipate problems

Preventative Maintenance

10.41

To enhance performance, maintainability, usability adds desired features rather than required better run times, faster transaction processing etc.

To meet user requirements not previously recognised or given high priority missed in development or not known about considered unimportant

Legacy systems (old systems running for at least 10 years) are likely candidates for perfective maintenance

May involve technical systems specialists as well as general maintenance staff network specialist to change network design for

improved performance

Perfective Maintenance

10.42

Maintainability the ease with which software can be

understood, corrected, adapted and enhanced

Low maintainability results in uncontrollable maintenance expenses

The following factors affect ‘maintainability’ Defects Customers Documentation Personnel Tools Software structure

Cost Elements of Maintenance

10.43

Defects the number of latent or unknown errors

existing after system installation influences most maintenance costs, drives

all other cost factors few errors --> low maintenance costs

Customers the number of customers/users of system more customers, more maintenance

effort/cost greater need for high maintainability

Cost Elements of Maintenance

10.44

Documentation quality of system documentation exponential effect on maintenance costs

Personnel quality of maintenance personnel highly skilled programmers, typically not

original programmers, to quickly understand and carefully change system

separate from development? in-house? dedicated end-user support?

Cost Elements of Maintenance

10.45

Tools appropriate automated development tools programming tools, code generators,

debuggers, hardware, CASE, diagnostics, etc reverse engineering for no documentation

Software structure quality of software structure and

maintainability formalisation of code, comments, versioning structure charts, OO

Cost Elements of Maintenance

10.46

There is a need to measure maintenance understand quality of development/maintenance

effort

We measure the following factors number of failures time between each failure type of failure

Mean Time Between Failures (MTBF) calculated using number of failures and time between

each failure, widely used measure of quality

Measuring Maintenance Effectiveness

10.47

Software Maintenance Life Cycle (SMLC) receive a Maintenance Request transform the Maintenance Request to a Change (analysis) specify the Change (design) develop the Change (code) test the Change train users and run an acceptance test convert and release to operations update the documentation conduct a Post-Maintenance Review

Chapin, 1988

Maintenance Life Cycle

10.48

Review

What went wrong/right? Why?

System Audit Report

Review thesystem and the

project

Project staff

Problems/New ideas

Project issues andsystem bugs

MAINTENANCE

System

Users

Auditor

Fixes andenhancem

ents

Steering Committee

Project Review Report

10.49

A PIR analyses what went right and wrong with a project. It is conducted 2 to 6 months after conversion by a team which includes user reps, development staff, internal auditors and sometimes external consultants - development team is not in charge look at original requirements and objectives evaluate how well they were met compare costs of development and operation against

original estimates (maintenance costs ??) compare original and actual benefits new system reviewed to see whether more of original

or additional benefits can be realised

Post Implementation Review

10.50

References

HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapters 15, 16

WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 16, 17