Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Chapter 17 System Implementation


Rachel Evangelista

on 16 January 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Chapter 17 System Implementation

tries to break the system (for example, what happens when a record is written to the database with incomplete information or what happens under extreme on-line transaction loads or with a large number of concurrent users) Steps in System Implementation Deliverables
Software Application Testing Different Types of Test Installation Phased Installation DOCUMENTING THE SYSTEM 2 Types of Documentation User Documentation Other types of User Documentation: 1. User’s guide Steps in System Implementation 5. Acceptance sign-off - As a future analyst you need to consider the source of documentation, its quality, and whether its focus is on the information system’s functionality or on the tasks the system can be used to perform.
- Even though the traditional source of user documentation has been the organization’s information system department, for much of the history of data processing the primary focus of documentation was the system.
- In a traditional information systems environment, the user interacted with an analyst and computer operations staff for all of his or her computing needs.
- The analyst acts as intermediary between the user and all computing resources.
- Any reports or other output that went to the user were generated by the operations staff.
- Most documentation developed during a traditional information systems development project was system documentation for the analysts and programmers who had to know how the system worked. Nearly all of the documentation was intended to assist maintenance programmers who tended to the system for years after the analysis team had finished its work. End user information system environment and its focus on user documentation
(Adapted from Torkzadeh and Doll, 1993 Training Information Systems Users The type of necessary training will vary by type of system and expertise of users. The list of potential topics from which you must determine if training will be useful include the following: Training and Supporting Users Seven Common Methods for Computer Training in 1987 (Adopted from Nelson and Cheney, 1987) Information staff might do the following: Providing Support Through a Help Desk Factor Models of Implementation Success Several searches have found other factors that are important to a successful implementation process. Although there are many ways to determine if an implementation has been successful, the two most common and trusted are the extent to which the system is used and the user’s satisfaction with the system. Organization Support The factors found by Lucas and the relationships they have to each other are shown in this model: Example (Markus (1981)) Use and satisfaction also represent a two-way relationship. The more satisfied the users are with the system. The more they will use it. The more they use it, the more satisfied they will be What individuals can do with a system to support their work will have an impact on extent of system use. The more users can do with a system and the more creative ways they can develop to benefit from the system the more likely they will use it. The relationship between the performance and use goes both ways. The higher the levels of performance, the more use; the more use, the greater the performance. Alpha and Beta Testing Webstore Installation Bug Tracking and System Evolution These are identified for the PVF webstore, but still apply to any other system application. System Implementation and Operation Political Implementation Methods Your first task in closing down the project, involves many different activities, from dealing with project personnel to planning a celebration of the project’s ending. You will likely have to evaluate your team members, reassign most to other projects and perhaps terminate others. As project manager, you will also have to notify all the affected parties that the development of the project is ending and you are now switching to maintenance mode. A big part of successful system testing is to make sure that no information is lost and that all tests are described in a consistent way. To achieve this, Jim provided all teams with standard forms for documenting each case and for recording the results of each test. This form has the following sections: Coding • process whereby physical design specification created by the analyst team are turned into working computer code by the programming team Testing • process to determine whether the system meets its requirements Installation • process during which the current system is replaced by the new system at technical and user sites Documentation • process of creating documents that reveal all of the important information about the system Training and Support • providing ongoing educational and problem-solving assistance to information system users Coding • code
• documentation of the code Testing • test and result documents Installation • user guides
• installation plan Documentation • paper-based modules
• computer-based modules Training and Support • training plan • Master plan a collection of documents that represents a complete test plan for one part of the system or for a particular type of test
a project within the overall systems development life cycle • Test plan specifies what each person's role during testing
serves as a checklist whether all master plan has been completed
to improve communication skill among all the people involved in testing the application software • Testing managers responsible for developing test plans, establishing testing standards, integration testing, and development activities in the life cycle, and ensuring that test plans are completed • Static testing - the code being tested is not executed • Dynamic testing - involves execution of the code • Automated testing - computer conducts the test • Manual testing - people conducts the test • Inspections - formal group activities where participants manually examine code for occurrences of well-known errors. • Walkthrough - a very effective method of detecting errors in code • Desk checking - an informal process where the programmer acts as the computer, mentally checking each step and its results for the entire set of computer instructions • Syntax checking - typically done by a compiler where errors are uncovered but the code is not executed • Unit testing - each module is tested alone in an attempt to discover any errors that may exist in the modules code • Integration testing - the process of bringing together all of the modules that a program comprises for testing purpose • System testing - the process of integrating programs into system for testing purpose • Stub testing - a technique used in testing modules, especially modules that are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules Nonlive test data the data and situation are artificial, developed specifically for testing purposes, although both data and environment are similar to what users would encounter in everyday system use 1. The purpose of testing is confirming that the system satisfies requirements.
2. Testing must be planned. The Testing Process Two Important Things to Remember about Testing Information Systems: Test case is a specific scenario of transactions, queries, or navigation paths that represent a typical, critical, or abnormal use of the system symbolic debugger a sophisticated debugging tool that allows to be run on-line, even one intruction at a time if the programmer desires, and allows the programmer to observe how different areas of data are affected as the instructions are executed The Testing Process eXtreme programming by Kent Beck - coding and testing are intimately related parts of the same

- all coding and testing is done by two people working together,
writing code and writing tests Acceptance Testing testing the system in the environment where it will eventually be used The most important testing include: alpha testing - where stimulated but typical data are used for system testing beta testing - which live data are used in the users' real working environment system audit - conducted by organization's internal auditors or by members of the quality assurance group The types of tests performed during alpha testing include the following: Recovery testing forces the 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 if from improper penetration Stress testing Performance testing determines how the system performs on the range of possible environments in which it may be used; often the goal is to have ths system perform with similar response time and other performance measures in each environment Direct Installation the process of moving from the current information system to the new one - the direct or abrupt approach to installation (also called "cold-turkey") is a sudden as the name indicates
- where the old system is shut off just as the new is ready to be used exclusively Parallel Installation - where both old and new systems run together until it is clear the new system is ready to be used exclusively Comparison of Installation (a) Direct Installation Single Location Installation - also known as location and pilot installation
- where one site is selected to test the new system Current System Install New
System New System Time (b) Parallel Installation Current System Install New
System New System Time (c) Single Location Installation (with direct installation at each location) Current System Install New
System New System Current System Install New
System New System (d) Phased Installation Current System Current System
Without Module 1 Install
Module 1 Install
Module 2 Current System Without Module 1 & 2 ... ... New Module 1 New Module 2 Location 1 Location 2 - also called staged installation
- where the system is installed bit by bit Planning Installation - each installation strategy involves converting not only software but also data and (potentially) hardware, documentation, work methods, job descriptions, offices and other facilities, training materials, business forms, and other aspects of the system • Conversion of data is of special interest to the installation process, since existing systems usually contain data required by the new system, current data must be made error-free, unloaded from current files, combined with new data, and loaded into new files. Data may need to be reformatted to be consistent with more advanced data types supported by newer technology used to build the new system. Taking a physical inventory is needed in order to validate data before they are transferred to the new files. This process is tedious since it may require that current systems be shut off while the data are extracted so that updates to old data, which would contaminate the extract process, cannot occur. • Any decision that requires the current system to shut down, in whole or in part, before the replacement system is in place must be done with care. Installation schedule should be announced to users well in advance to let them plan their work schedules around outages in service and periods when their system support might be erratic. Successful installation steps should also be announced, and special procedures put in place so that users can easily inform you of problems they encounter during installation periods.
• Plan for emergency staff to be available in case of system failure so That business operations can be recovered and made operational as quickly as possible.
• The business cycle of the organization should also be considered, since you have to understand the cyclical nature of the business before you schedule installation.
• Planning for installation may begin as early as the analysis of the organization supported by the system.
• The project team leader is responsible for anticipating all installation tasks and assigns responsibility for each different analyst. SDLC and Generic Documentation Corresponding to Each Phase
Bell and Evans (1989) illustrate how generic systems development life cycle maps onto a generic list of when specific ystems development documentation elements are finalized. Generic Life-cycle Phase Generic Document Requirements Specification

Project control structuring

System Development

Architectural Design
Prototype design
Detailed design and implementation
Test specification
Test implementation System delivery System requirements specification
Resource requirements specification
Management Plan
Engineering change proposal

Architecture design document
Prototype design document
Detailed design document
Test specifications
Test reports
User’s guide
Release description
System Administrator’s guide
Reference guide
Acceptance sign-off 1. System Documentation detailed information about a system’s design specifications, its internal workings, and its functionality. Divided into: • Internal documentation - system documentation that is part of the program source code or is generated at compile time. • External documentation - system documentation that includes the outcome of structured diagramming techniques such as data flow and entity-relationship diagrams. Although not part of the code itself, external documentation can provide useful information to the primary users of system documentation- maintenance programmers. 2. User Documentation written or other visual information about an application system, how it works, and how to use it. Outline of a Generic User’s Guide Preface
1.2Function Flow
2.User Interface
2.1Display Screen
2.2Command Types
3.Getting started
3.4Error recovery
3.n [Basic procedure name]
n. [Task name]
Appendix A—Error messages
Index) This figure represents the content of a reference guide, just one type of user documentation. • The reference guide consists of an exhaustive list of the system’s functions and commands, usually in alphabetical order.
• In this table, sections with an “n” and a title in square brackets mean that there would likely be many such sections, each for a different topic.
• The items in parentheses are optional, included as necessary.
• An index becomes more important the larger the user’s guide. provides information on how users can use computer systems to perform specific tasks. The information in a user’s guide is typically ordered by how often tasks are performed and how complex they are. 2. Quick Reference guide provides essential information about operating a system in a short, concise format. 3. Release description contains information about a new system release, including a list of complete documentation for the new release, features and enhancements, known problems and how they have been dealt with in the new release, and information about installation. 4. System Administrator’s guide is intended primarily for those who will install and administer a new system and contains information about the network on which the system will run, software interfaces for peripherals such as printers, troubleshooting, and setting up user accounts. allows user to test for proper system installation and then signify their acceptance of the new system with their signatures. PREPARING USER DOCUMENTATION - regardless of format, use documentation is an upfront investment hat should pay off in reduced training and consultation costs later (Torkzadeh and Doll, 1993) Traditional Information System environment and its focus on system documentation (Adapted from Torkzadeh and Doll, 1993) -In today’s end-user information systems environment, users interact directly with many computing resources , users have many options or querying
capabilities from which to choose when using a system, and users are able to develop many local applications themselves.
-For end-user applications, the nature and purpose of documentation has changed from documentation intended for the maintenance programmer to documentation for the end user.
-Application-oriented documentation whose purpose is to increase user understanding and utilization of the organization’s computing resources. two aspects of an organization’s computing infrastructure • Computing Infrastructure - made up of all the resources and practices required to help people adequately use computer systems to do their primary work.
- analogous to the infrastructure of water mains, electric power lines, streets, and bridges that form the foundation for the providing essential services in a city. • Use of the system e.g., how to enter a class registration request • General computer concepts e.g., computer files and how to copy them • Information system concepts e.g., batch processing • Organizational concepts e.g., FIFO inventory accounting • System management e.g., how to request changes to a system • System installation e.g., how to reconcile current and new systems during phased installation 1. Tutorial – one person taught at a time 2. Course – several people taught at a time 3. Computer - aided instruction 4. Interactive training manuals – combination of tutorials and computer-aided instruction 5. Resident expert 6. Software help components 7. External sources, such as vendors
Supporting Information Systems Users • Information Center - an organizational unit whose mission is to support users in exploiting information technology.
- comprises a group of people who can answer questions and assist users with a wide range of computing needs, include the use of particular information systems. o Install new hardware or software.
o Consult with users writing programs in fourth-generation languages.
o Extract data from organizational database onto personal computers.
o Set up user accounts.
o Answer basic on-demand questions
o Provide a demonstration site for viewing hardware and software.
o Work with users to submit systems change requests. Automating Support Common methods for automating support include: On-line support: provide users access to information on new releases, bugs, an tips for more effective usage Bulletin board systems/forums : are offered on on-line services such as America OnLine™, over the Internet, and over company intranets. On-demand fax : allows users to order support information through an 800 number and receive that information instantly over the fax machines. Voice response systems : allows users to navigate option menus that lead to prerecord messages about usage, problems, and workarounds. 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
is an information systems department function, staffed by IS personnel, possibly part of the information center unit Help desk staff either deals with the users’ questions or refers the users to the most appropriate person Support Issues for the Analyst to Consider Support consists of such tasks as providing for recovery and backup, disaster recovery, and PC maintenance; writing newsletters and offering other types of proactive information sharing; and setting up user groups. Organizational Issues in Systems Implementation Why do systems implementation efforts fail? The conventional wisdom that has emerged over the years is that there are at least two conditions necessary for a successful implementation effort: • Management support of the system under development
• The involvement of the users in the development process • Ginzberg (1981b)
• Lucas (1997) Ginzberg (1981b) found important factors that can affect the success of implementing a software/ information system and these are: Commitment to the Project This involves managing the system development project so that the problem being solved is well understood and the system being developed to deal with the problem actually solves it. Commitment to Change This involves being willing to change behaviours, procedures, and other aspects of the organization. Extent of Project Definition and Planning This is a measure of how well planned the project is. The more extensive the planning effort, the less likely is implementation failure.This involves being willing to change behaviours, procedures, and other aspects of the organization. User Expectation The more realistic a user’s expectations about a new system and its capabilities, the more likely it is that the user will be satisfied with the new system and actually use it. Lucas (1997) has extensively studied information systems implementation, and has identified six factors that influence the extent to which a system is used. User’s Personal Stake How important the domain of the system is for the user; in other words, how relevant the system is to the work the user performs. The user’s stake in the system is itself influenced by the level of support management provides for implementation, and by the urgency to the user if the problem addressed by the system. The higher level of management support and the more urgent the problem, the higher the user’s personal stake in the system. System Characteristics This includes such aspects of the system’s design as ease of use, reliability, and relevance to the task the system supports. User Demographics These are characteristics of the user; such as age and degree of computer experience. This pertains to the system infrastructure. The better the system infrastructure, the more likely an individual will be to use the system. Performance Satisfaction Factors model of implementation process have helped analysts in understanding implementation and why it may or may not be successful. Certainly, taking the different factors into account and realizing how they work together to influence implementation is important.

Political models consider different factors that may influence the success of the implementation process and these are the following: • Political Models have been proposed as another perspective to help you understand how a systems development project can succeed.
• Political models assume that individuals who work in an organization have their own self-interested goals, which they pursue in addition to the goals of their departments and the goals of their organizations.
• These models also recognize that power is not distributed evenly in organizations. Some workers have more power than others. Markus presents a political interpretation of the story that provides another explanation of events. He begins by examining the history and power relationships within the division and the two manufacturing plants. Illustrating the political explanation of system success at Athens and Capital City: Like many other analysis and design activities, system implementation and operation of an Internet-based e-commerce application is no different from the process followed for other types of applications. Here we will examine how test cases were developed, how bugs were recorded and fixed, and how alpha and beta tests were conducted. Developing Test Cases for the Webstore To begin the system-wide testing process, Jim and the PVF development team developed test cases to examine every aspect of the system. System testing, like all other aspects of SDLC, needed to be very structured and a planned process. Before opening the webstore or any information system to the users, every module and component of the system needed to be tested within a controlled environment. To help focus the development of the test cases and to assign primary responsibility to members of his team to specific areas of the system, Jim developed the following list of testing categories: • Simple Functionality: Add to cart, list section, calculate tax, change personal data
• Multiple Functionality: Add item to cart and change quantity, create user account and change address
• Function Chains: Add item to cart, check out, create user account, purchase
• Elective Functions: Returned items, lost shipments, item out of stock
• Emergency/ Crisis: Missing orders, hardware failure, security attacks, The development group broke down into five separate teams, each working to develop an extensive set of cases for each of the testing categories. Once developed, each team would lead a walkthrough, so that everyone would know the totality of the testing process and to facilitate extensive feedback to each team so that the testing process would be as comprehensive as possible. • Test Case ID
• Category/Objective of the test
• Description
• System version
• Completion Date
• Participants
• Machine Characteristics (Processor, Operating System, memory, etc.)
• Test results
• Comments An outcome of the testing process is the identification of system bugs. Consequently, in addition to setting a standard method for writing and documenting test cases, The Project team may establish several other rules to assure a smooth testing process. Experienced developers have long known that an accurate bug tracking process is essential for rapid troubleshooting and repair during the testing process. To make sure that all bugs were documented in a similar way (paper trails), the team developed a bug tracking form that had the following categories: • Bug number (simple incremental number)
• Test Case ID that generated the bug
• Is the Bug Replicable
• Affects
• Description
• Resolution
• Resolution Date
• Comments After completing all system test cases and resolving all known bugs, Jim moved the webstore into the alpha testing phase, where the entire PVF development team as well as the personnel around the company would put the Webstore (any application) into its paces. To motivate the employees throughout the company to actively participate in testing the webstore , several creative promotions and give-aways were held. After completing alpha testing, PVF recruited several of their established customers to help in beta testing the Webstore. As the real-world customers used the system, Jim was able to monitor the system and fine tune the servers for optimal system performance. As the system moved through the testing process, fewer and fewer bugs were found. After several days of clean usage, Jim felt confident that the Webstore can be operated for business purposes. Throughout the testing process, Jim kept PVF management aware of each success and failure. Fortunately, because Jim and the development team followed a structured and disciplined development process, there were far more successes than failures, Project Close-Down In chapter 3 we learned about the various phases of project management, from project initiation to closing down the project. If you are the project manager and you have successfully guided your project through all the phases of the SDLC, you are now ready to close down your project. Although the maintenance phase is just about to begin, the development of the project itself is over. Maintenance may be thought of as a series of smaller development projects, each with its own series of project management phases. Your second task is to conduct post-project reviews with both your management and your customers. In some organizations, these post-project reviews will follow formal procedures and may involve internal or EDP (electronic data processing) auditors. The point of a project review is to critique the project, its methods, its deliverables, and its management. Your third major task in project close-down is closing out the customer contract. Any contract that has been in effect between you and your customers during the project must be completed, typically through the consent of all contractually involved parties. This may involve a formal “signing –off” by the clients that your work is done and is acceptable. The maintenance phase will be covered under new contractual agreements. If your customer is outside of your organization, you will likely negotiate a separate support agreement. eXtreme programming Pair programming
Full transcript