System Implementation 1. Software and Hardware Acquisition Recognize Need, Appoint Committee and/or...

SystemSystemImplementationImplementation

1

Software and Hardware Acquisition

Recognize Need, Appoint Committee and/or Project Manager: For large systems, the majority of the appointed committee members should be users from functional areas and end users, joined by information technology staff. Throughout the process committee members should represent their constituencies.

2

It should inform and seek advice and input from a broad spectrum of users, and from specialists such as technical support staff, Procurement, and legal staff. The committee as a whole should represent the entire business committee to be affected by the software.

3

Software and Hardware Acquisition cont…

Define Procurement Process: This

document is comprised of policy, practices,

principles, and recommended procedures.

How these apply to a specific software or

hardware acquisition should be addressed

with Procurement. 4


Define General Needs and Develop Budget Projection: General needs should be identified based on the problems to be solved as well as what could reasonably be expected to be available in the marketplace. Care should be taken to avoid defining needs too narrowly too early in the process. Preliminary budget projections may cover only the cost of hardware/software and a general estimate of other expenses. 5


Investigate the Market: Investigating the

market may involve site visits,

communication with other institutions using

the product, vendor demonstrations, or a

Request for Information (RFI). A broad base

of potential vendors should be given an

opportunity to participate. 6


Refine the Budget and Identify a Funding Plan: Before proceeding with the project, a refined budget plan should be prepared which covers all costs of consulting, acquisition, licensing, hardware, additional staffing, implementation, testing, training, maintenance, and upgrades, for a three to five year period.

7

Consideration should also be given to costs of integration with existing systems, and to savings which may be obtained from phasing out systems that are no longer needed. Identify funding sources and obtain appropriate approvals.

8


Define Detailed Needs: A thorough needs analysis

of software capabilities should be conducted. For

example, for a Human Resources system, this

analysis should encompass the needs of functional

staff (such as Human Resources), end users (such

as general departmental users), and technical staff

(such as IT staff responsible for maintaining the

system). 9


The analysis should distinguish between

required and desired capabilities and should

also cover such things as maintenance, support,

training, upgrades, existing or proposed

hardware, and the computing infrastructure. If

necessary, the budget plan should be revised.

10


Prepare and Issue an Request for Procurement (RFP): If not determined to be a sole source, an RFP should be prepared based on the required (and desired) capabilities identified in the needs analysis.

11

Items to be included are: life cycle costing, maintenance, service / support, availability, implementation schedule,

installation/training, financial viability experience of company,

12

price (basis),

the evaluation process and criteria,

documentation to be provided by vendor, source

code escrow(third party),

example contract,

options such as lease/purchase.

Evaluation criteria, points and process should be

identified.

13


Evaluate Bids or Proposals: Evaluation

methods should be summarized in the

specifications, and evaluations should be

conducted by a designated evaluation committee.

For major acquisitions, a Procurement

representative should observe and advise the

evaluation committee regarding the evaluation

process. 14


In addition to reviewing technical and financial

responses in the written proposals, activities that may

occur as part of the evaluation process include:

product demonstrations, site visits, contacting

references, determining responsiveness (e.g. all

questions answered, required submittals provided,

e.t.c.). The evaluation process must be well

documented.15


Negotiate Contract Language: Typically the

hardware/software vendor will provide a

contract to be used. A Procurement

representative, and if appropriate, a committee

designee will work with the Legal Office to

remove or modify language which is

unacceptable to the institution, and to add

provisions to safeguard the institution’s

interests. 16


Obtain Final Approvals: Appropriate

approvals should be sought and availability

of funds verified.

Execute the Contract: With the proper

approvals, the contract should be executed.

17

Software Acquisition Dynamics

Commercial-Off-The-Shelf (COTS)

software is commercial available software.

The supplier might not be willing to modify and the

customer has no control of the quality of the software.

The vender controls the maintenance of the software

Delivery time is immediate

Cost is less

18

Software Acquisition Dynamics…

Modified-Off-The –Shelf (MOTS)

The supplier is willing to modify the software

according to customer requirements

Customer is in control of maintaining the

customized part

Delivery time depends on the modification

requirements

Cost depends on the modification requirement 19

Software Acquisition Dynamics…Full developed software Customer has full control of maintenance and

quality of the software The cost could be high Delivery time long Could follow water fall method of analysis,

design, code and test. Or extreme programming of developing by iterations (incremental) whereby a subset of the requirements is developed in each iteration.

Method of development depends on project20

Outsourcing Software Development

Can outsource software development

when the services are not available in-house.

If it is cheaper

If high quality software is required

Lack of resources

21

Challenges of Outsourcing Could lose control over the software, risk is high

due to competition

Do not build internal competence

Development costs could exceed the budget

Time schedule could be overrun

The outcome might not meet expectations

Some projects could be canceled before end of

development period

Customer might not take active part in development22

Challenges of Outsourcing cont… Focus of client could be more on administrative

activities rather than technical issues Creeping scope - customer keeps adding and

changing scope and functionality Team working on many projects at a time Introducing new and sophisticated technical

solutions rather than simple and proven technology Performance levels poorly set, qualitative rather

than quantitative No user involvement –important for usability and

functionality of the product 23

Challenges of Outsourcing cont… Lack of discipline of the development team –

reverting to ad hoc development

Unrealistic expectation form the client – having an

impossible schedule and/or being unaware of the

limitations of the technology being used

Lack of effective communication channels – unable

to reach the right people in a timely manner

Conflicts in the team

The above problems can be avoided by proper

software acquisition management24

Implementation Phase

Conduct System Test

Testing of software packages, custom

built programs, and any existing

programs that comprise the new

system to ensure they work together

Task involves Analysts, owners, users

and builders

25

Implementation Phase….

System Analysts- communicates test problems

and issues with project team members

System owners and Users – determine if

project is operating correctly

System builders – involved in system testing

System tests may result in program

modification26


Prepare conversion plan

Using design Specification for new system, system analyst prepares a detailed conversion plan

Plan identifies, databases to install, end-user training and documentation to develop and conversion strategy from old system to new system.

• Tasks facilitated by project manager

27


Installation strategies for conversion plan Abrupt cut-over / Direct: On a specific

date old system is converted and new system starts to operate;

High risk approach as system may encounter

major problems not yet known,

No transition costs

Is necessary when policy changes or if system

can only be implemented at a given date28


Parallel Conversion: Both Old and New system

are operated at the same time period

Allows detection and solving of problems in new

system. Final cut-over may be abrupt or gradual.

Strategy minimizes risk of major flaws in new

system

Costs incurred in running two systems over the

period.

Increased demand on computing resources

29


Location Conversion: If the system is to be used in several geographical locations, it is converted at one location first. Once approved in one site, it’s then rolled to the rest. (done either thro’ abrupt or parallel conversion) Others can be cut-over. First site usually called beta test site

Staged Conversion: It’s a variation on the abrupt and parallel conversions.

Each successive version of the new system is converted as it is developed. Can be done either thro’ abrupt, parallel, or location strategy.

30


Abrupt cutover

Parallel conversion

Location conversion

Staged conversion

31

Implementation Phase…. The Conversion plan typically includes a systems

acceptance test plan; Systems Acceptance test is the final system test

performed by end users using real data over extended period. It’s extensive test and covers 3 levels;

– Verification testing (Alpha testing) :- running system in simulated environment using simulated data. The simulation looks for errors and omissions regarding end-user and design specifications as earlier specified but may have not been fulfilled during construction.

32


– Validation testing (beta testing):- runs system

in live environment using real data. Several

things are tested here as follows:

Systems performance - is throughput and

response time for processing adequate to meet

normal processing workload?; If not programs can

be written to improve efficiency or hardware may

be replaced or upgraded 33


Peak workload processing performance- can the system handle workload during peak processing periods? If not, improved hardware and / or software may be needed to increase efficiency or processing; consider doing some of less critical processing during nonpeak periods.

Human engineering test :- is the system as easy to learn and use as anticipated? If not, is it adequate? Can enhancements to human engineering be deferred until after the system has been placed into operation.

34


Methods and procedure test :- during conversion, the methods and procedures for new system will be put to their first real test. Methods and procedures may have to be modified if they prove to be awkward and inefficient from users opinion.

Backup and recovery testing:- all backup and recovery procedures should be tested. This includes simulating data loss disaster to find and error in recovery procedures.

35


Audit testing – certifies that the system is free

of errors and is ready to be placed into

operation. Audit not required by all

organization, but many firms use independent

audit or quality assurance staff that certify

systems acceptability and documentation before

the system is placed into final operation.

36


Install Databases

To place system into operation you need fully loaded databases. Hence installation of databases

Purpose of the task is to populate the new system’s databases with existing data from old system.

System builders are required in this activity i.e. programmers write special programs to extract data from existing databases and populate new databases

37


System analysts and designers only perform role

of calculating database sizes and time required to

perform installation.

Main output restructured existing data populated

in new system.

38


Train Users

Change to new system requires system users to

be trained and documentation provided to guide

through the new system.

One on One or Group training may be

conducted. Group training encouraged

System analysts provide end-user

documentation and training for system users

but must be supported by system owners39


Conversion to New System

After conversion, the ownership of the system is transferred from analysts and programmers to the end users.

Analysts completes task by carefully carrying out the conversion plan.

This involves completing a systems audit

Task involves System owners, users, analysts, designers and builders. Project

40


– manager oversees the conversion plan

– System owners provide feedback regarding

their experiences with the overall project.

– System users provide feedback on actual use

of the new system.

– The feedback may be used by system analysts,

designers and builders to correct

shortcomings. Thus an operational system is

placed into production process of business.41

Post Implementation ReviewA Post-Implementation Review should

be scheduled some time after the solution has been deployed. Typical periods range from 6 weeks to 6 months, depending on the type of solution and its environment. The PIR is intended to be an assessment and review of the final working solution.

42

There should have been at least one full processing and reporting cycle completed.

It should not be performed while the initial snags are still being dealt with or while users are still being trained, coached and generally getting used to its operation.

43

Post Implementation Review… There is often a difference of opinion as to

who should perform the Post-Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to work, how to fix problems, etc.

44

There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review.

45

Post Implementation Review… A solution is to do both. An independent audit team,

working in consultation with the business users and

project team, could examine whether the results are

satisfactory. The project team might then reconvene

to consider that input and also to examine how to

generate further value from the solution.

A cost/benefit analysis of the system should be done.

46

Post Implementation Review…Post Implementation should include such questions as: Is the required functionality available? Have users received adequate training and coaching to

take advantage of the new facilities? Are staffing levels and skill sets appropriate for the

actual workloads? Are staff displaying appropriate attitudes to get the

best out of the system (confidence in its capabilities, belief in its purpose, willingness to make it work, etc)?

Are third parties such as customers and suppliers satisfied with the service?

47

Post Implementation Review… Is data integrity being maintained within the system

and in relation to other integrated or interfaced systems?

Are systems controls being applied correctly?

Is the system able to process transactions at an adequate speed?

Does the system have the capacity to deal with the actual peak loadings as encountered and foreseen?

Are staff following operational procedures including backup, recovery, security and disaster recovery?

48

Post Implementation Review… These questions will be investigated through a

combination of investigative techniques including

interviews, examination of documentation,

performance statistics, hands-on tests and checks,

etc. Implications and potential remedial options

would then be assessed and evaluated. The

findings and recommended actions would be

prepared, normally in the form of a report or

presentation.49

SYSTEMS SYSTEMS SUPPORTSUPPORT

50

System support

This is the ongoing technical support for users, as

well as the maintenance required to fix any

errors, omissions, or new requirements that may

arise.

Before an information system can be supported it

must be in operation.

51

System support….

System operation is the day-to-day, week-to-week,

month to month, and year to year execution of an

information system’s business processes and

application programs

Unlike system analysis and design and

implementation systems support cannot be sensibly

decomposed into actual phases that a support project

must perform.52

System support

Each activity is a type of a support project that is

triggered by a particular problem, event, or

opportunity encountered with the implemented

system.

Program maintenance – Unfortunately, most

systems suffer from software defects or bugs,

errors that slipped through the testing of software

53

System support

System recovery – from time to time, a system

failure may result in a program “crash” and/or loss

of data. Human error or a hardware or software

failure may have caused this. The systems analyst

or technical support specialist may then be called

on to recover the system – that is to restore a

system’s files and databases and to restart the

system.54

System support

Technical support - Regardless of how well the

users have been trained and how good the end-

user documentation is, users will eventually

require additional assistance – unanticipated

situations arise and even new users are added.

System enhancement – New requirements may

include new business problems, new business

requirements, new technical problems, or new

technology requirements.55

System Maintenance

Regardless of how well designed, constructed, and

tested a system or application be, errors or bugs will

inevitable occur. Bugs can be caused by any of the

following. Poorly communicated requirements Misinterpreted requirements Poorly validated requirements Incorrectly implemented requirements or designs Simple misuse of the programs

56

System Maintenance - Objectives

To make predictable changes to existing programs

to correct errors that are made during systems

design or implementation.

To preserve those aspects of the programs that

were correct and to avoid the possibility that

“fixes” to programs cause other aspects of those

programs to behave differently.

57

System Maintenance - Objectives

To avoid as much as possible, degradation of

system performance, poor system maintenance

can gradually erode system throughput and

response time.

To complete the task as quickly as possible

without sacrificing quality and reliability. Few

operational information systems can afford to be

down for any extended period.

58

System Maintenance

Tasks involved are

– Validate the problem

– Benchmark the problem

– Study and debug the program

– Test the program

59

Validate the problem

System maintenance (miniprojects) are

triggered by the identification of the problem,

usually called a bug. Most such bugs are

identified by users when they discover some

aspect of the system that does not appear to be

working as it should. The first task of the

systems analyst or programmer is to validate

the problem.

60

Validate the problem…

Working with the users, the team should

attempt to validate the problem by reproducing

it. If the problem cannot be reproduced, the

project should be suspended until the problem

recurs and the user can explain the

circumstance under which it occurred.

61

Validate the problem

The “as-is” program is executed, as closely as

possible approximating the circumstances and

the data that were present when the problem

was first encountered. In most cases, the user

who encountered the problem should be the

one who re-creates it.

Do not blame the user.

62

Benchmark program

Given a copy of the program with a substantiated

bug, the analyst should benchmark the program.

A program is not all bad, or it would have never

been placed into operation. System maintenance

can result in unpredictable and undesirable side

effects that impact the program’s or application’s

overall functionality and performance.

63

Validate the problem….

For this reason, before making any changes to

programs, the programs should be executed and

tested to establish a baseline against which the

modified programs and applications can later be

measured.

This task can be performed by the systems analyst

and/or programmer. Users should also participate to

ensure the test is conducted under circumstances that

simulate as closely as possible a normal working

environment.64

Study and Debug the Program

The primary task in system maintenance is to

make the required changes to the programs. This

task is performed by the application programmer.

Essentially, the programmer responds to “bug-

fix” requirements that establish the expectation

for fixing the problem.

65

Study and Debug the Program…

The programmer “debugs” (edits) a copy of the

problem program. Changes are not made to the

production program. The result is a corrected

version of the program. This is a candidate

release, meaning a candidate to become the next

production version of the program.

66

Study and Debug the Program…Application and program knowledge usually comes from

studying the source code. Program understanding can take

considerable time. This activity is slowed by some combination

of the following limitations:

Poor program structure – examples include structural

programs written with non-structured techniques and Visual

Basic or Java programs written with non-object-oriented

techniques.

Unstructured logic (from pre-structured era coding styles).

67


– Prior maintenance (quick fixes and poorly

designed extensions).

– Dead code (instructions that cannot be reached

or executed – often leftovers from prior testing

and debugging).

– Poor or inadequate documentation

68


Changes that you make may have an undesirable

ripple through other parts of the program or, worse

still, other programs in the application and

information system.

A candidate release of the program must be tested

before it can be placed into operation as the next new

version of the production program. The following

tests are essential or recommended:69

Study and Debug the Program...

Unit testing (essential) ensure that the stand-alone

program fixes the bug without undesirable side

effects to the program. The test data and current

performance that you recovered, created, or

generated when the programs were benchmarked are

used here.

System testing (essential) ensures that the entire

application, of which the modified program was a

part, still works. Again, the test data and current

performance are used here.70


– Regression testing (recommended)

extrapolates (predict) the impact of the

changes on program and application

throughput and response time from the before-

and-after results using the test data and current

performance.

71

System Recovery

From time to time a system failure is inevitable.

It generally results in an aborted or “hung”

program (also called a “crash”) and may be

accompanied by loss of transactions or stored

business data. The systems analyst often fixes the

system or acts as intermediary between the users

and those who can fix the system.

72

Technical Support

Another relatively routine ongoing activity of

systems support is technical support.

No matter how well users have been trained or

how well documentation has been written, users

will require additional assistance. The systems

analyst is generally on call to assist users with the

day-to-day use of specific applications.

73

Technical Support…

The most typical tasks include:

Routinely observing the use of the system.

Conducting user-satisfaction surveys and

meetings.

Changing business procedures for clarification

(written and in the repository).

Providing additional training as necessary.

Logging enhancement ideas and requests in the

repository.74

System EnhancementAdapting an existing system to new requirements is

the norm for all information systems. Business is

change! The pace of change in today’s economy is

accelerated, and rapid response is the expectation.

System enhancement requires that the systems analyst

evaluate a new requirement to either effect change or

direct the change request through an appropriate

subset of the original systems development process.

75

System Enhancement…System enhancement is an adaptive process. Most

such enhancement is in response to one of the

following events:

New business problems – A new or anticipated

business problem will make a portion of the current

system unusable or ineffective.

New business requirements – A new business

requirement (e.g. New report, transaction, policy or

event) is needed to sustain the value of the current

system.

76

System Enhancement…

New technology requirements – A decision to

consider or use a new technology (eg. New

software or version, or different type of hardware)

in an existing system needs to be made.

New design requirements – An element of the

existing system needs to be redesigned against the

same business requirements (e.g. Add new

database tables or fields, add or change to a new

interface, etc).

77


Systems enhancement is reactionary in nature –

fix it when it breaks or when users or managers

request change. System enhancement extends

the useful life of an existing system by adapting

it to inevitable change.

78


This objective can be linked to your information

system building blocks as follows:

KNOWLEDGE/DATA – Many system

enhancements are requests for new information

(reports or screens) that can be derived from

existing stored data. But some data

enhancements call for the restructuring or

stored data.

79


PROCESSES – Most system enhancements require

the modification of existing programs or the creation

of new programs to extend the overall application

system. But some enhancement requests can be

accomplished through careful redesign of existing

business processes.

COMMUNICATION – Many enhancements require

modifications to how the users interface with the

system and how the system interfaces with other

systems.80

System Obsolescence

At some point, it will not be cost-effective to

support and maintain an information system. All

systems degrade over time. And when support

and maintenance become cost-ineffective, a new

systems development project must be started to

replace the system.

81

THE END

THANK YOU

82

System Implementation 1. Software and Hardware Acquisition Recognize Need, Appoint Committee and/or...

Documents

Transcript of System Implementation 1. Software and Hardware Acquisition Recognize Need, Appoint Committee and/or...