Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Fifth Edition
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
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
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.
Chapter 15
System Implementation
Chapter 15
Chapter 15
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.
Chapter 15
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
Testing
Deliverables:
Test
scenarios (test plan) and test data. 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
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, unit, system and integration test plans are developed. The actual testing is done during implementation. Testing can be done in parallel with coding.
As each program module is produced, it can be tested individually, then as part of a larger program and then as part of a larger system
Chapter 15
10
Test plans provide improves communication among all parties involved in testing the application software. The plan specifies what each persons role will be during testing. The test plans also serve as a checklist that can be used to determine whether all of the master test plan has been completed.
Chapter 15
11
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
12
Dynamic
Walkthroughs
Desk checking
Unit test
Integration test
System test
Chapter 15
13
testing means that the code being tested is not executed (e.g. inspections and syntax testing). Dynamic testing involves execution of the code (e.g. walkthroughs and unit test).
Chapter 15
14
Test is automated or manual. Manual means that people complete the 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. Exactly what the code does is not investigated in an inspection
Chapter 15
15
Chapter 15
16
Syntax Checking: syntax, grammar and some other routine errors can be checked by automated inspection (by a compiler). 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. Integration testing: the process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down incremental fashion. First test the coordinating module and only one of its subordinate modules. After the first test, add one or two other subordinate modules from the same level
2008 by Prentice Hall 17
Chapter 15
System testing: the bringing together of all of the programs that a system comprises for testing purposes.
Programs
Chapter 15
18
Stub testing: a technique used in testing modules, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules.
Chapter 15
19
Planning
gives analysts and programmers an opportunity to think through all the potential problem areas and develop ways to test for problems. One part of the master test plan is creating a set of test cases.
Chapter 15
20
Test case is a specific scenario of transactions, queries or navigation paths. Test cases represent either:
Chapter 15
21
Test cases and results should be thoroughly documented so they can be repeated for each revision of an application.
Chapter 15
22
Chapter 15
23
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. With eXtreme programming and Agile methodology, coding and testing are related parts of the same process. Programmers who write the code also write the test Code is tested soon after it is written
Chapter 15
24
Acceptance testing: the process whereby actual users test a completed information system, the end result of which is the users acceptance of it.
Chapter 15
25
Chapter 15
26
Recovery testing - forces software (or environment) to fail in order to verify that recovery is properly performed.
Security testing - verifies that protection mechanisms built into the system will protect it from improper penetration. Stress testing - tries to break the system (e.g. what happens under extreme online transactions loads or with a large number of concurrent users). Performance testing - determines how the system performs on the range of possible environments in which it may be used (e.g. different hardware configurations, networks, operating systems).
Chapter 15
27
Installation
Installation: the organizational process of changing over from the current information system to a new one. Four installation strategies:
28
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.
Chapter 15
29
Direct Installation
Users are at the mercy of the new system. 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.
Chapter 15
30
Direct Installation
If the new system fails, 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
31
Direct Installation
Direct installation can be very risky. Requires longer time to install the new system, especially for large systems. Thus, delaying system benefits or even missing the opportunities that motivated the system request. It is the least expensive installation method and creates considerable interest in making the installation a success.
Chapter 15
32
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.
Chapter 15
33
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
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
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
36
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. Also known as location or pilot installation.
Chapter 15
37
Single-Location Installation
Limits the potential damage or potential cost by limiting the effects on a single site. Once management has determined that installation has been successful at one location, the new system can be deployed in the rest of the organization, possibly continuing with one installation at a time.
Chapter 15
38
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. Problems with the system can be resolved before deployment to other sites.
Chapter 15
39
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.
Chapter 15
40
Phased Installation
Like single-location installation, phased installation is an attempt to limit the organizations exposure to risk, whether in terms of cost or disruption of the business. By converting gradually, the organizations risk is spread out over time and place. The new system should be able to coexist and probably share data. Usually done through bridge programs.
Chapter 15
41
Planning Installation
Each installation strategy involves converting not only software, but also data, documentation, work methods, job descriptions.
Each installation process involves getting workers to change the way they work. As such, installation should be looked at not as simply installing new computer system, but as an organizational change process
Chapter 15
42
Planning Installation
Considerations
Data
conversion.
Error correction: because existing systems usually contain data required by the new system, current data must be made error free. Loading from current system: current data must unloaded from current files, combined with new data and loaded into new system Planned system shutdown.
Chapter 15
43
System documentation: detailed information about a systems design specifications, its internal workings, and its functionality.
Intended
It includes
System requirements specification Resource requirements specification Architecture design document Prototype design document Test reports
Chapter 15
44
Chapter 15
User documentation: written or other visual information about an application system, how it works, and how to use it. Intended primarily for users and include: Quick reference guide (consist of list of systems 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, including a list of documentation, features and enhancements, known problems, installation information) System administrators guide (contains information about the network on which the system will run, software interfaces for peripherals and setting user accounts) acceptance sign-off
2008 by Prentice Hall 46
Chapter 15
Considerations:
The
source of documentation. Its quality. Whether its focus on the information systems functionality or on the tasks that the system can be used to perform.
Chapter 15
47
Traditional source of user documentation has been information systems department. Most documentation developed during a traditional IS project was system documentation for the analysts and programmers
In todays 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. Application-oriented documentation purpose is to increase user understanding and use of the organizations computing resources.
2008 by Prentice Hall 48
Chapter 15
Chapter 15
49
Computing infrastructure: all of the resources and practices required to help people and adequately use computer systems to do their primary work.
Chapter 15
50
The type of training needed will vary by system type and user expertise. Potential training topics from which to determine whether training will be useful include:
Use of the system. General computer concepts. Information system concepts. Organizational concepts. System management. System installation.
2008 by Prentice Hall 51
Chapter 15
Resident expert. Traditional instructor-led classroom training. E-learning/distance learning. Blended learning (combination of instructorled and e-learning). External sources, such as vendors. Software help components.
Chapter 15
52
Electronic performance support system (EPSS): Online help systems that go beyond simply providing help- they embed training directly into software package. component of a software package or an application in which training and educational information is embedded. An EPSS can take several forms, including an online tutorial, an expert system shell, and hypertext jumps to reference materials.
Chapter 15
53
main idea behind EPSS is that the user never has to leave the application to get the benefits of training. Example, Microsofts Office Assistant.
Chapter 15
54
Support is extremely important to users. Providing support can be expensive and timeconsuming. 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, they find they can no longer bear the cost of providing the support for free
Chapter 15
55
Automating Support
To cut the costs of providing support, vendors have automated their support offering
Internet-based online support forums. On-demand fax. Voice response systems. Knowledge bases (include all of the technical and support information about vendor products) . 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
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
Chapter 15
57
Requires
Technical
skills: extensive knowledge about how to use the system and typical problems that can be encountered. People skills: good listening and communication, dealing with complaints and frustrations.
Chapter 15
58
Support is more than just answering user questions about how to use a system to perform a particular task. Support also consists of :
Recovery and backup. Disaster recovery. PC maintenance. Writing newsletters. Setting up user groups.
It is the responsibility of analysts for a new system to be sure all forms of support are in place.
59
Chapter 15
Despite the best efforts of the system development team to design and build a quality system, the implementation effort sometimes fails. 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
60
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
61
Chapter 15
62
Personal stake of users (how important the domain of the system is for the user) System characteristics (system design as ease of use, reliability and relevance to the task)
User demographics (characteristics of the user, 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
Security Issues
Increasing important issue for organizations and their management. Malicious software (malware): includes Trojan horses, worms, viruses, and other kinds. External sources of threats include laptop theft, system penetration, and denial of service.
Chapter 15
64
Electronic Commerce Application: System Implementation for Pine Valley Furnitures WebStore
Developing test cases for the WebStore include testing categories as follows:
Simple
65
Chapter 15
66
Date
Characteristics (processor, operating system, memory, browser, etc.) Test Result Comments
Chapter 15
67
Number (simple incremental number) Test Case ID that Generate the Bug Is the Bug Replicable? Effects
Chapter 15
68
Date
Comments
As batches of bugs are fixed, the version number of the software is incremented (i.e. 1.0, 2.0, 3.0, etc.).
2008 by Prentice Hall 69
Chapter 15
Alpha Testing:
PVF
employees who actively participated received in received a t-shirt, $100 to shop. Development team conducted extensive recovery, security, stress, and performance testing.
Beta Testing
PVF
Chapter 15
WebStore Installation
WebStore was ready to go online and development team recommended to top management it was time to flip the switch.
Chapter 15
71
Project Close-Down
Evaluate team.
Reassign
Notify all affected parties that the development project is ending and that you are switching to operation and maintenance mode. Conduct post project reviews. Close out customer contract.
Formal
17.72
Chapter 15
signoff.
2008 by Prentice Hall 72
Summary
Chapter 15
Summary (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 endusers. 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.
2008 by Prentice Hall 74
Chapter 15