You are on page 1of 74

Modern Systems Analysis and Design

Fifth Edition

Jeffrey A. Hoffer Joey F. George Joseph S. Valacich

Chapter 15 System Implementation

Learning Objectives

   

Describe the process of coding, testing, and converting an organizational information system and outline the deliverables and outcomes of the process. Prepare a test plan for an information system. Apply four installation strategies: direct, parallel, singlelocation, and phased installation. List the deliverables for documenting the system and for training and supporting users. Distinguish between system and user documentation and determine which types of documentation are necessary for a given information system.

Chapter 15

© 2008 by Prentice Hall

2

Learning Objectives (Cont.)


 

Compare the many modes available for organizational information system training, including self-training and electronic performance support systems. Discuss the issues of providing support for end-users. Explain why system implementation sometimes fails. Describe the threats to system security and remedies that can be applied. Show how traditional implementation issues apply to electronic commerce applications.

Chapter 15

© 2008 by Prentice Hall

3

Chapter 15 © 2008 by Prentice Hall 4 .System Implementation  After maintenance. the implementation process is the most expensive and timeconsuming phase in the system development life cycle because of the work that has to be completed.

System Implementation  Six major activities:       Coding Testing Installation Documentation Training Support Chapter 15 © 2008 by Prentice Hall 5 .

) Chapter 15 © 2008 by Prentice Hall 6 .System Implementation (Cont.

)  Purpose:    To convert final physical system specifications into working and reliable software. To document work that has been done. To provide help for current and future users and caretaker of the system.System Implementation (Cont. Chapter 15 © 2008 by Prentice Hall 7 .

Coding   Physical design specifications created by the analysis team are turned into working computer code by the programming team. Deliverables:  Code  Program documentation Chapter 15 © 2008 by Prentice Hall 8 .

 Results of program and system testing What type of test was conducted? What test data were used? How did the system handle the test? Chapter 15 © 2008 by Prentice Hall 9 .Testing  Deliverables:  Test    scenarios (test plan) and test data.

The actual testing is done during implementation. unit. then as part of a larger program and then as part of a larger system Chapter 15 © 2008 by Prentice Hall 10 . it can be tested individually.Software Application Testing     A master test plan is developed during the analysis phase.  Planning involves determining what needs to be tested and collecting test data During the design phase. Testing can be done in parallel with coding.  As each program module is produced. system and integration test plans are developed.

Software Application Testing  Test plans provide improves communication among all parties involved in testing the application software.  The test plans also serve as a checklist that can be used to determine whether all of the master test plan has been completed.  The plan specifies what each person’s role will be during testing. Chapter 15 © 2008 by Prentice Hall 11 .

Software Application Testing  The master test plan may not be a single document. but a collection of documents each represents a complete test plan for one part of the system or for a particular type of test. Chapter 15 © 2008 by Prentice Hall 12 .

Seven Different Types of Tests Manual Static Inspections Automated Syntax checking Dynamic Walkthroughs Desk checking Unit test Integration test System test Chapter 15 © 2008 by Prentice Hall 13 .

Chapter 15 © 2008 by Prentice Hall 14 . inspections and syntax testing).g.  Static testing means that the code being tested is not executed (e.Seven Different Types of Tests  Static or dynamic techniques.  Dynamic testing involves execution of the code (e.g. walkthroughs and unit test).

 Inspection: a testing technique in which participants manually examine program code for predictable language-specific errors. Code inspection participants compare the code they are examining with a checklist of well known errors for that particular language.  Manual means that people complete the test.Seven Different Types of Tests  Test is automated or manual.  Exactly what the code does is not investigated in an inspection  Chapter 15 © 2008 by Prentice Hall 15 .

Seven Different Types of Tests  Test is automated or manual.  Manual Walkthroughs: examine what the code does.  Desk checking: a testing technique in which the program code is sequentially executed manually by the reviewer. mentally checking each step and its result for the entire set of computer instruction  Chapter 15 © 2008 by Prentice Hall 16 .  The reviewer acts as the computer. It should be done frequently when the pieces of work reviewed are relatively small and before the work is formally tested.

 Errors in syntax are uncovered but the code is not executed (static) Unit testing: each module is tested alone in an attempt to discover any errors in its code.   Syntax Checking: syntax. Integration testing: the process of bringing together all of the modules that a program comprises for testing purposes.Seven Different Types of Tests (Cont.  Modules are typically integrated in a top-down incremental fashion.)  Automated  means computer conducts the test. add one or two other subordinate modules from the same level © 2008 by Prentice Hall 17 Chapter 15 .  First test the coordinating module and only one of its subordinate modules. After the first test. grammar and some other routine errors can be checked by automated inspection (by a compiler).

Seven Different Types of Tests (Cont.)  System testing: the bringing together of all of the programs that a system comprises for testing purposes.  Programs are typically integrated in a topdown. incremental fashion. Chapter 15 © 2008 by Prentice Hall 18 .

especially where modules are written and tested in a top-down fashion.)  Stub testing: a technique used in testing modules. where a few lines of code are used to substitute for subordinate modules.Seven Different Types of Tests (Cont. Chapter 15 © 2008 by Prentice Hall 19 .

 One part of the master test plan is creating a set of test cases.The Testing Process The purpose of the testing is to confirm that the system satisfies requirements  Testing must be planned   Planning gives analysts and programmers an opportunity to think through all the potential problem areas and develop ways to test for problems. Chapter 15 © 2008 by Prentice Hall 20 .

queries or navigation paths. Chapter 15 © 2008 by Prentice Hall 21 .The Testing Process (Cont. Test cases represent either:  Typical system use.  Critical system use.  Abnormal system use.)   Test case is a specific scenario of transactions.

)  Test cases and results should be thoroughly documented so they can be repeated for each revision of an application. Chapter 15 © 2008 by Prentice Hall 22 .The Testing Process (Cont.

The Testing Process (Cont.) Chapter 15 © 2008 by Prentice Hall 23 .

coding and testing are related parts of the same process. With eXtreme programming and Agile methodology.Combining Coding and Testing   Big projects often have dedicated testing staffs that develop test plans and then use the plans to test the software after it has been written.  Programmers who write the code also write the test  Code is tested soon after it is written Chapter 15 © 2008 by Prentice Hall 24 .

Chapter 15 © 2008 by Prentice Hall 25 . the end result of which is the users’ acceptance of it.Acceptance Testing by Users  Acceptance testing: the process whereby actual users test a completed information system.

) Acceptance testing include  Alpha testing: user testing of a completed information system using simulated data.  Beta testing: user testing of a completed information system using real data in the real user environment.  Chapter 15 © 2008 by Prentice Hall 26 .Acceptance Testing by Users (Cont.

verifies that protection mechanisms built into the system will protect it from improper penetration.g.Acceptance Testing by Users Types of Alpha Test:  Recovery testing .    Chapter 15 © 2008 by Prentice Hall 27 . different hardware configurations.tries to break the system (e. Security testing .forces software (or environment) to fail in order to verify that recovery is properly performed. what happens under extreme online transactions loads or with a large number of concurrent users). Stress testing . Performance testing . networks.determines how the system performs on the range of possible environments in which it may be used (e.g. operating systems).

Four installation strategies:  Direct Installation.Installation   Installation: the organizational process of changing over from the current information system to a new one.  Single-location installation. Chapter 15 © 2008 by Prentice Hall 28 .  Parallel Installation.  Phased Installation.

Chapter 15 © 2008 by Prentice Hall 29 .Direct Installation  Direct installation: changing over from the old system to a new one by turning off the old system when the new system is turned on.

Any errors resulting from the new system will have a direct impact on the users and how they do their jobs and how the organization performs its business.Direct Installation  Users are at the mercy of the new system. Chapter 15 © 2008 by Prentice Hall 30 .

considerable delay may be occur until the old system can again be made operational and business transactions are reentered to make the database up to date. Chapter 15 © 2008 by Prentice Hall 31 .Direct Installation  If the new system fails.

especially for large systems.  It is the least expensive installation method and creates considerable interest in making the installation a success.Direct Installation Direct installation can be very risky. delaying system benefits or even missing the opportunities that motivated the system request. Thus.  Requires longer time to install the new system.  Chapter 15 © 2008 by Prentice Hall 32 .

Chapter 15 © 2008 by Prentice Hall 33 .Parallel Installation  Parallel installation: running the old information system and the new one at the same time until management decides the old system can be turned off.

Parallel Installation
All the work done by the old system is concurrently performed by the new system.  Outputs compared to help determine whether the new system is performing as well as the old.

Chapter 15

© 2008 by Prentice Hall

34

Parallel Installation
Errors discovered in the new system do not cost the organization much, if anything, because errors can be isolated and the business can be supported by the old system.  Parallel installation can be expensive because all work is done twice, running two systems implies employing two staffs to operate and maintain both systems.

Chapter 15

© 2008 by Prentice Hall

35

Parallel Installation
Can be confusing to users because they must deal with both systems.  There can be considerable delay until the new system is completely ready for installation.  Parallel installation may not be feasible, especially if the users of the system (such as customers) can not tolerate redundant efforts or if the size of the system is large.

Chapter 15

© 2008 by Prentice Hall

36

 Also known as location or pilot installation.  Chapter 15 © 2008 by Prentice Hall 37 .Single-Location Installation Single-location installation or pilot installation: Trying out an information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization.

possibly continuing with one installation at a time.  Chapter 15 © 2008 by Prentice Hall 38 .  Once management has determined that installation has been successful at one location. the new system can be deployed in the rest of the organization.Single-Location Installation Limits the potential damage or potential cost by limiting the effects on a single site.

 Chapter 15 © 2008 by Prentice Hall 39 .  Problems with the system can be resolved before deployment to other sites.Single-Location Installation Success at the pilot site can be used to convince reluctant personnel at other sites that the system can be worthwhile for them as well.

Chapter 15 © 2008 by Prentice Hall 40 .Phased Installation  Phased Installation: changing from the old information system to the new one incrementally. starting with one or a few functional components and then gradually extending the installation to cover the whole new system.

Phased Installation Like single-location installation.  The new system should be able to coexist and probably share data.  By converting gradually. phased installation is an attempt to limit the organization’s exposure to risk.  Chapter 15 © 2008 by Prentice Hall 41 . the organization’s risk is spread out over time and place. Usually done through bridge programs. whether in terms of cost or disruption of the business.

documentation.Planning Installation  Each installation strategy involves converting not only software. but as an organizational change process  Chapter 15 © 2008 by Prentice Hall 42 . work methods. installation should be looked at not as simply installing new computer system. Each installation process involves getting workers to change the way they work. but also data. job descriptions. As such.

Planning Installation  Considerations  Data  conversion.  Error correction: because existing systems usually contain data required by the new system.  Install the system during the light loads of the organization Chapter 15 © 2008 by Prentice Hall 43 . current data must be made error free.  Off-hours are used for installation  Business cycle of organization.  Loading from current system: current data must unloaded from current files. combined with new data and loaded into new system Planned system shutdown.

Documenting the System  System documentation: detailed information about a system’s design specifications. and its functionality.  Intended primarily for maintenance programmer  It includes      System requirements specification Resource requirements specification Architecture design document Prototype design document Test reports Chapter 15 © 2008 by Prentice Hall 44 . its internal workings.

External documentation: system documentation that includes the outcome of all of the structured diagramming techniques such as data flow and E-R diagrams.)   System documentation can be divided into : Internal documentation: system documentation that is part of the program source code or is generated at compile time.Documenting the System (Cont. © 2008 by Prentice Hall 45  Chapter 15 .

)  User documentation: written or other visual information about an application system. known problems. software interfaces for peripherals and setting user accounts)  acceptance sign-off © 2008 by Prentice Hall 46 Chapter 15 . installation information)  System administrator’s guide (contains information about the network on which the system will run. including a list of documentation.Documenting the System (Cont. how it works. features and enhancements.  Intended primarily for users and include:  Quick reference guide (consist of list of system’s functions and commands in alphabetic order)  User guide (provide information on how users can use a computer system to perform specific tasks)  Release description (contain information about a new system release. and how to use it.

 Its quality.  Whether its focus on the information system’s functionality or on the tasks that the system can be used to perform.Preparing User Documentation  Considerations:  The source of documentation. Chapter 15 © 2008 by Prentice Hall 47 .

Application-oriented documentation purpose is to increase user understanding and use of the organization’s computing resources. © 2008 by Prentice Hall 48 Chapter 15 .  Most documentation developed during a traditional IS project was system documentation for the analysts and programmers  In today’s end-user IS. users interact directly with many computing resources and are able to develop local applications themselves   Application-oriented documentation is now often supplied by vendors and users themselves.Preparing User Documentation  Traditional source of user documentation has been information systems department.

support materials and jobs will have to be prepared or designed as part of the implementation process.  Chapter 15 © 2008 by Prentice Hall 49 .Training and Supporting Users Support: providing ongoing educational and problem-solving assistance to information system users.  For in-house developed systems.

Chapter 15 © 2008 by Prentice Hall 50 .)  Computing infrastructure: all of the resources and practices required to help people and adequately use computer systems to do their primary work.Training and Supporting Users (Cont.

System installation. Potential training topics from which to determine whether training will be useful include:       Use of the system. General computer concepts. Organizational concepts.Training Information Systems Users   The type of training needed will vary by system type and user expertise. Information system concepts. System management. © 2008 by Prentice Hall 51 Chapter 15 .

Chapter 15 © 2008 by Prentice Hall 52 . Traditional instructor-led classroom training. Software help components. E-learning/distance learning. such as vendors. Blended learning (combination of instructorled and e-learning).Training Information Systems Users  Types of training methods:       Resident expert. External sources.

an expert system shell.they embed training directly into software package. Chapter 15 © 2008 by Prentice Hall 53 . An EPSS can take several forms.)     Electronic performance support system (EPSS): Online help systems that go beyond simply providing help. and hypertext jumps to reference materials. including an online tutorial.Training Information Systems Users (Cont. component of a software package or an application in which training and educational information is embedded.

Training Information Systems Users (Cont. Microsoft’s Office Assistant.  Example. Chapter 15 © 2008 by Prentice Hall 54 .)  Electronic performance support system (EPSS)  The main idea behind EPSS is that the user never has to leave the application to get the benefits of training.

they find they can no longer bear the cost of providing the support for free Chapter 15 © 2008 by Prentice Hall 55 .Supporting Information Systems Users  Support is extremely important to users. Many organizations rely on vendor support    Vendors are able to provide the necessary support but as they have shifted their offerings from expensive mainframe to inexpensive off-shelf software. Providing support can be expensive and timeconsuming.

Electronic support service (vendor support services tailored specifically for the corporation) Priority access to vendor support personnel (get help via telephone or email from a person at the vendor within prespecified response time) © 2008 by Prentice Hall 56 Chapter 15 . Knowledge bases (include all of the technical and support information about vendor products) .Automating Support  To cut the costs of providing support. Voice response systems. On-demand fax. vendors have automated their support offering       Internet-based online support forums.

Providing Support Through a Help Desk  Help desk: a single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department.  It is an IS department function and is staffed b IS personnel. Chapter 15 © 2008 by Prentice Hall 57 .

dealing with complaints and frustrations. Chapter 15 © 2008 by Prentice Hall 58 .Providing Support Through a Help Desk (Cont.  People skills: good listening and communication.)  Requires  Technical skills: extensive knowledge about how to use the system and typical problems that can be encountered.

Disaster recovery. 59 Chapter 15 © 2008 by Prentice Hall . Support also consists of :      Recovery and backup.Support Issues for the Analyst to Consider  Support is more than just answering user questions about how to use a system to perform a particular task. Setting up user groups. PC maintenance.  It is the responsibility of analysts for a new system to be sure all forms of support are in place. Writing newsletters.

the implementation effort sometimes fails.Organizational Issues in Systems Implementation  Despite the best efforts of the system development team to design and build a quality system. Conditions necessary for successful implementation:     Management support of the system under development Involvement of users in the development process However the link between user involvement and implementation success is sometimes weak Chapter 15 © 2008 by Prentice Hall 60 .

Organizational Issues in Systems Implementation  Conditions necessary for successful implementation:  commitment to the project (managing the systems development project so that the problem being solved is well understood and the developed system deal with the problem actually solves it) Commitment to change (willing to change behaviors. procedures and other aspects of the organization) Extent of project definition and planning   Chapter 15 © 2008 by Prentice Hall 61 .

Organizational Issues in Systems Implementation  Measures of implementation success: The extent to which the system is used Users’ satisfaction  Chapter 15 © 2008 by Prentice Hall 62 .

reliability and relevance to the task)   User demographics (characteristics of the user.Organizational Issues in Systems Implementation  Major factors influencing likelihood of system use:  Personal stake of users (how important the domain of the system is for the user) System characteristics (system design as ease of use. such as the age. computing experience) Organizational support Performance (the higher the level of performance. the more use) Satisfaction (the more satisfied the users with the system. the more the will use it) © 2008 by Prentice Hall 63    Chapter 15 .

 Malicious software (malware): includes Trojan horses.  External sources of threats include laptop theft. viruses. system penetration. and denial of service.  Chapter 15 © 2008 by Prentice Hall 64 . and other kinds. worms.Security Issues Increasing important issue for organizations and their management.

 Multiple functionality.  Elective functions.  Function chains.Electronic Commerce Application: System Implementation for Pine Valley Furniture’s WebStore  Developing test cases for the WebStore include testing categories as follows:  Simple functionality.  Emergency/crisis Chapter 15 © 2008 by Prentice Hall 65 .

Developing Test Cases for WebStore  Test case forms had the following sections:  Test Case ID  Category/Objective of Test  Description  System Version Chapter 15 © 2008 by Prentice Hall 66 .

memory.)  Completion  Participants  Machine Date Characteristics (processor.)  Test Result  Comments Chapter 15 © 2008 by Prentice Hall 67 . operating system.Developing Test Cases for WebStore (Cont. etc. browser.

Bug Tracking and System Evolution  Bug-tracking form has the following categories:  Bug Number (simple incremental number)  Test Case ID that Generate the Bug  Is the Bug Replicable?  Effects Chapter 15 © 2008 by Prentice Hall 68 .

2.0. etc. 3.)  Description  Resolution  Resolution Date  Comments  As batches of bugs are fixed. the version number of the software is incremented (i.0.Bug Tracking and System Evolution (Cont.).0.e. © 2008 by Prentice Hall 69 Chapter 15 . 1.

and performance testing.Alpha and Beta Testing the WebStore  Alpha Testing:  PVF employees who actively participated received in received a t-shirt. security.  Development team conducted extensive recovery. © 2008 by Prentice Hall 70 Chapter 15 .  Beta Testing  PVF recruited several of their established customers to help in beta testing. stress. $100 to shop.

Chapter 15 © 2008 by Prentice Hall 71 .WebStore Installation  WebStore was ready to go online and development team recommended to top management it was time to “flip the switch”.

 Conduct post project reviews. Notify all affected parties that the development project is ending and that you are switching to operation and maintenance mode.72 Chapter 15 signoff.  Reassign members to other projects.  Close out customer contract.Project Close-Down   Evaluate team. © 2008 by Prentice Hall 72 .  Formal 17.

parallel. © 2008 by Prentice Hall 73     Chapter 15 . singlelocation. Prepare a test plan for an information system. Distinguish between system and user documentation and determine which types of documentation are necessary for a given information system. List the deliverables for documenting the system and for training and supporting users.Summary   In this chapter you learned how to: Describe the process of coding. Apply four installation strategies: direct. and converting an organizational information system and outline the deliverables and outcomes of the process. and phased installation. testing.

Discuss the issues of providing support for endusers.)      Compare the many modes available for organizational information system training. Show how traditional implementation issues apply to electronic commerce applications. Explain why system implementation sometimes fails. © 2008 by Prentice Hall 74 Chapter 15 .Summary (Cont. including self-training and electronic performance support systems. Describe the threats to system security and remedies that can be applied.