introduction system construction and implementation

Introduction

System Construction and Implementation

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

2

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.

3


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.

4


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


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

6


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


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.

8


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. Items to be included are

life cycle costing, maintenance, service /

support, availability, implementation schedule,

installation/training, financial viability and

experience of company,

9


price (basis), the evaluation process and

criteria, documentation to be provided by

vendor, source code escrow(third party),

example contract, and options such as

lease/purchase. Evaluation criteria,

points and process should be identified.

10


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.

11


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.

12


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


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.

14

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 15

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 requirement16

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 project17

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 resources18

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

development 19

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

20

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 management 21

22

DefinitionsSystem Construction

Development, installation and testing of System components

System Implementation

Installation and delivery of entire system into production or

23

Definitions…..

Making the new system available to a prepared set of users (the deployment), and positioning on-going support and maintenance of the system.

24

Construction Phase Purpose of construction phase is to:

Develop and test system functionality that fulfils business and design requirements

Implement the interfaces between the new system and existing production systems i.e. Programming, or acquisition of software packages

25

1. Build and Test Networks (if necessary)Involves analysts, designers, and builders- Network designer – designs local and wide area networks and the connectivity - Network administrator – builds and test network technology for the new system and security

Tasks / Activities include

26

Tasks/Activities include…- System analysts facilitates and ensures compliance with requirements- Use of technical design specifications to implement the network architecture for an information system is a prerequisite for construction and implementation activities

27

Tasks/Activities include…2. Build and Test databases

Involves System users, analysts, designers and builders

- System Users tasks could be to provide and approve test data for use in database

28

Tasks/Activities include…-Systems analysts ensures compliance with requirements

- Database designers builds and populates initial database

- Database administrator tunes database performance and security controls

29

Tasks/Activities include…

Database model/schema as specified during systems design and test data details are products of this task.

30

Tasks/Activities include…3. Install and Test New Software Packages (if necessary)

Some Systems solution may require purchase or lease of software packages

Involves System users, analysts, designers, builders, vendors and consultants

31


Main outputs of the task is new software packages and documentation from system vendors. Installed and tested software package is the product of the task.

32


4 Write and Test New ProgramsDevelopment of prototype – as part of technical design specifications. To complete systems construction and implementation by refining the programs.

33


Involves System users, analysts, designers and builders

Teams – may be used for large projects.

34

Tasks/Activities include… The Primary inputs to the activity are

technical design statement, plan for programming and test data developed during systems design. Main outputs are new programs and reusable software components (placed in software library), software documentation

35


Testing is done after entire program is written

3 levels of test performed may include, - Stub test - done on individual events or modules of program

36

Tasks/Activities include… Unit or Program test - done on events &

modules coded & stub tested for a program and tested as integrated unit. Entire program test Systems test – ensures application

programs written and tested in isolation work properly when integrated into total system

37

System Implementation Phase Consists of the following processes:

Prepare for System Implementation, where all steps needed in advance of actually deploying the application are performed, including preparation of both the production environment and the Consumer communities.

38

System Implementation Phase.. Conduct System Test

Prepare conversion plan Deploy System, where the full

deployment plan, initially developed during System Design and evolved throughout subsequent lifecycle phases, is executed and validated.

39

System Implementation Phase..Transition to Performing Organization,

where responsibility for and ownership of the application are transitioned from the Project Team to the unit in the Performing Organization that will provide system support and maintenance.

Train Users

41

Implementation Phase

1. Conduct System Test Testing of software packages,

custom built programs, and any existing programs that comprise the new system to ensure they work together

42

Implementation Phase .. Task involves Analysts,

owners, users and buildersSystem Analysts-

communicates test problems and issues with project team members

43

Implementation Phase ..

System owners and Users – determine if project is operating correctly

System builders – involved in system testing

System tests may result in program modification

44

Implementation Phase .. 2. 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

45


3. Installation strategies for conversion plan

Abrupt cut-over / Direct: On a specific date old system is converted and new system starts to operate;

46


High risk approach as system may encounter major problems not yet known,

No transition costs It is necessary when policy

changes or if system can only be implemented at a given date

47


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.

48


Strategy minimizes risk of major flaws in new system

Costs are incurred in running two systems over the period.

Increased demand on computing resources

49

Implementation Phase .. 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

50

Implementation Phase .. 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.

51

Implementation Phase .. Abrupt cutover

Parallel conversion

Location conversion

Staged conversion

52


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 is an extensive test and covers 2 levels;

53

Implementation Phase ..1.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

54

Implementation Phase .. 2.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

55

Implementation Phase .. 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 non-peak periods

56

Implementation Phase .. 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.

57

Implementation Phase .. 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.

58


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.

59

Implementation Phase .. 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 & documentation before the system is placed into final operation

60

Implementation Phase .. 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.

61


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

62


System analysts and designers only perform role of calculating database sizes and time required to perform installation.

Main output could restructure existing data populated in new system.

63


Train Users Change to new system

requires system users to be trained and documentation provided to guide users through the new system.

64


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 owners

65


Conversion to New System After conversion, the

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

66


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.

67

Implementation Phase .. Project 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.

68


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.

System Operation and

Support

70

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.

71

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

72

System Support…

Unlike system analysis and design and implementation systems support cannot be sensibly decomposed into actual phases that a support project must perform.

73

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 e.g.

Program maintenance: Unfortunately most systems suffer from software defects or bugs, errors that slipped through the testing of software

74

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.

75

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.

76

System Support…

System enhancement – New requirements may include new business problems, new business requirements, new technical problems, or new technology requirements

77

System Maintenance

Regardless of how well designed,

constructed, and tested a system or

application may be, errors or bugs

will inevitable occur. Bugs can be

caused by any of the following

78

System Maintenance…

Poorly communicated requirements Misinterpreted requirements Poorly validated requirements Incorrectly implemented

requirements or designs Simple misuse of the programs

79

System Maintenance-Objectives

To make predictable changes

to existing programs in order

to correct errors that are

made during systems design

or implementation

80

System Maintenance-Objectives….

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.

81


To avoid as much as possible,

degradation of system performance,

poor system maintenance can

gradually erode system throughput

and response time.

82


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.

83

Tasks in System Maintenance

Tasks involved are

Validate the problem

Benchmark the problem

Study and debug the program

Test the program

84

A. Validate the Problem System maintenance (mini-projects)

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.

85

A. Validate the Problem…

The first task of the systems analyst or programmer is to validate the problem. Working with the users, the team should attempt to validate the problem by reproducing it.

86


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.

87


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.

88

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

89

B. Benchmark program…

System maintenance can result in unpredictable and undesirable side effects that impact the program’s or application’s overall functionality and performance.

90

B. Benchmark program… 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.

91

B. Benchmark program…

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.

92

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

93


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.

94


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:

95


Poor program structure – examples include COBOL 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).

96


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

97


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.

98


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:

99


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.

100


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.

101


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.

102

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.

103

System Recovery …

The systems analyst often fixes the system or acts as intermediary between the users and those who can fix the system.

104

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.

105

Technical Support …

The most typical tasks include:Routinely observing the use

of the system.Conducting user-satisfaction

surveys and meetings.

106

Technical Support …

Changing business procedures for clarification (written and in the repository).

Providing additional training as necessary.

Logging enhancement ideas and requests in the repository.

107

System Enhancement

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

108

System Enhancement….

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.

109

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.

110


New business requirements – A new business requirement (eg. New report, transaction, policy or event) is needed to sustain the value of the current system.

111


New technology requirements – A decision to consider or use a new technology (e.g. New software or version, or different type of hardware) in an existing system needs to be made.

112


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

113

System Enhancement … 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.

114

System Enhancement…. 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.

115

System Enhancement….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.

116

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.

117

Measuring System Success 1. High levels of system use.

2. User satisfaction with the system.

3. Favorable attitudes of users about information systems and the information.

4. Achieved objectives.

5. Financial payoff to the organization.

118

Measures of IS Success

Measures of IS Success

High level of System use

UserSatisfaction

Favorableattitude

Achievedsystem

objectives

Financialpayoff

119

Methods of Procurement of a Computer System

The four methods of acquiring and/or financing the computer costs are:

a) Rental, b) Purchasing c) Leasing d) Using Bureau e) Facilities Management

120

THE ENDTHANK

YOU

introduction system construction and implementation

Documents

hardware acquisition

proposed hardware

specific software

implementation slide

general needs

needs of functional

technical staff

end users