System Construction and Implementation

System Construction and Implementation
Introduction

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.

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.

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.

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.

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.

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

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.

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,

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.

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.

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.

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.

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.

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

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

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 project

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

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

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

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

Definitions System Construction
Development, installation and testing of System components System Implementation Installation and delivery of entire system into production or

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

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

Tasks / Activities include
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…
- 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

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

-Systems analysts ensures compliance with requirements - Database designers builds and populates initial database - Database administrator tunes database performance and security controls

Database model/schema as specified during systems design and test data details are products of this task. System Analyst- participates in testing of the software package by clarifying requirements System designer – involved in task of clarifying integration requirements & Program documentation Network Admin- installing software vendors & Consultants – assist in the installation & testing process

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

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.

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

Involves System users, analysts, designers and builders Teams – may be used for large projects.

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

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

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

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.

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.

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

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

Implementation Phase .. Task involves Analysts, owners, users and builders System Analysts- communicates test problems and issues with project team members

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

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

Implementation Phase .. 3. Installation strategies for conversion plan
Abrupt cut-over / Direct: On a specific date old system is converted and new system starts to operate;

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

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.

Implementation Phase .. Strategy minimizes risk of major flaws in new system Costs are incurred in running two systems over the period. Increased demand on computing resources

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

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.

Implementation Phase .. Abrupt cutover Parallel conversion
Location conversion Staged conversion

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

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

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

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

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.

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.

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

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

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.

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

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

Implementation Phase .. Train Users
Change to new system requires system users to be trained and documentation provided to guide users through the new system.

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

Implementation Phase .. Conversion to New System
After conversion, the ownership of the system is transferred from analysts and programmers to the end users.

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

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.

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

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.

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

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

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

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.

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 Support… System enhancement – New requirements may include new business problems, new business requirements, new technical problems, or new technology requirements

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

System Maintenance… Poorly communicated requirements
Misinterpreted requirements Poorly validated requirements Incorrectly implemented requirements or designs Simple misuse of the programs

System Maintenance-Objectives
To make predictable changes to existing programs in order to correct errors that are made during systems design or implementation

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.

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.

Tasks in System Maintenance
Tasks involved are Validate the problem Benchmark the problem Study and debug the program Test the program

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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:

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.

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.

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.

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

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.

Technical Support … The most typical tasks include:
Routinely observing the use of the system. Conducting user-satisfaction surveys and meetings.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

Measures of IS Success Measures of IS Success High level of System use
User Satisfaction Favorable attitude Achieved system objectives Financial payoff

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

THE END THANK YOU

System Construction and Implementation

Similar presentations

Presentation on theme: "System Construction and Implementation"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

System Construction and Implementation

Similar presentations

Presentation on theme: "System Construction and Implementation"— Presentation transcript:

Similar presentations

About project

Feedback