system implementation 1. software and hardware acquisition recognize need, appoint committee and/or...
TRANSCRIPT
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Software and Hardware Acquisition cont…
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
Implementation Phase….
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
Implementation Phase….
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
Implementation Phase….
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
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
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
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
Implementation Phase….
– 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
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 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
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.
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
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 and documentation before
the system is placed into final operation.
36
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.
System builders are required in this activity i.e. programmers write special programs to extract data from existing databases and populate new databases
37
Implementation Phase….
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
Implementation Phase….
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
Implementation Phase….
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
Implementation Phase….
– 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
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
Study and Debug the Program…
– 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
Study and Debug the Program…
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
Study and Debug the Program…
– 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
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.
78
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.
79
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.
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