This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Chapter 11 – IT Projects and Acquiring Information Systems
HOW CAN INFORMATION SYSTEMS BE ACQUIRED The 4 basic methods for acquiring software applications are:
1. Buy it and use it 2. Buy it and customize it 3. Rent or lease it 4. Build it yourself All methods are used, but the second option is the most common. The model of information systems in Chapter 1 suggested that information systems are the combination of hardware, software, data, procedures, and people. Acquiring one therefore involves more than just obtaining and installing software. It involves incorporating the software into the current technological infrastructure and integrating the software into the data and procedures people use to make things happen in an organization. Even if software is free, businesses face the cost of interacting the software with the current hardware, data, and procedures in the organization. WHAT ARE INFORMATION TECHNOLOGY PROJECTS AND WHY ARE THEY RISKY Projects often are attempted to accomplish something new, so projects often represent change in an organization. There are risky and difficult because:
o You cannot see what you are creating so it is difficult to assess where you stand, unlike a physical item like a bridge, where you know how much of it you’ve completed.
o Tools for building IT are constantly changing, whereas components for physical items are stable.
o Being able to monitor its progress is difficult WHAT IS INFORMATION TECHNOLOGY PROJECT MANAGEMENT Information technology project management (ITPM) is the collection of techniques and methods that project managers use to plan, coordinate, and complete IT projects. The most important skill for a successful project manager, in IT and other industries, is communication. WHAT IS ANALYSIS AND DESIGN AND THE SDLC Systems analysis and design is the process of creating and maintaining information systems. In addition to technical application, it involves establishing the system’s goals, setting up the project, determining requirements and etc. Many methodologies have been developed over the years concerning acquiring and developing information systems. The following are some examples. THE SYSTEMS DEVELOPMENT LIFE CYCLE The systems development life cycle (SDLC) is the classical process used to acquire information. It was developed in the “school of hard knocks”. Many early projects met with disaster, but by the 1970s, project managers had agreed on a set of basic tasks that needed to be performed to successfully acquire and maintain information systems. It involves:
1. System definition 2. Requirements analysis 3. Component design 4. Implementation 5. System maintenance Acquisition begins when a business-planning process identifies a need for a new system. Developers in the first SDLC phase, system definition, use managements statement of the system needs in order to begin to define the new system. The resulting project plan is the input to the second phase, requirements analysis. Here, developers identify the particular features and functions of the new system. The output of that phase is a set of approved user requirements, which become the primary input used to design system components. In the 4th phase, developers implement, test, and install the new system. Over time, users will find errors and problems and will also develop new requirements. The description of fixes and new requirements is input to a system maintenance phase, which starts the process all over again. STEP 1: SYSTEM DEFINITION In response of the need for the new system, the organization will assign a few employees to define the new system, to assess its feasibility, and to plan the project, and typically someone from the IS department will lead this team. Define System Goals and Scope: The first step is to define the goals and scope of the new information system. Scope: people involved, business processes involved etc. Assess Feasibility: We must answer questions like “Does this project make sense?”. The aim here is to eliminate obviously inappropriate projects before forming a project development team and investing significant labour. Feasibility has 4 dimensions:
o Cost – feasibility is approximate. o Schedule – is difficult estimate the time it will take to acquire the system. As these are only approximates, they are just used to rule out any obvious unacceptable projects.
o Technical – whether existing information technology is likely to be able to meet the needs of the new system.
o Organizational – concerns whether the new system fits within the organization’s customs, culture, charter, or legal requirements. STEP 2: REQUIREMENTS ANALYSIS If the defined project is determined to be feasible, the next step is to form the project team and develop requirements. The team normally consists of both IT personnel and user representatives. Systems analysts are IT professionals who understand both business and technology. They are active throughout the systems development process and play a key role in moving the project through the systems development process. They integrate the work of the programmers, testers, and users. The important point is for users to have active involvement and to take ownership of the project throughout the entire development process. Requirements analysis phase is as follows:
o Conduct user interviews o Evaluate existing systems o Determine new forms/reports/queries o Identify new application features and functions o Consider security o Create the data model o Consider all five components WHAT IS THE USER’S ROLE IN REQUIREMENTS DEVELOPMENT The primary purpose of the requirements analysis phase is to determine and document the specific features and functions of the new system. DETERMINE REQUIREMENTS This is the most important phase in the systems development process. If the requirements are wrong, the system will be wrong. But if requirements are determined completely and correctly, then design and implementation will be easier and more likely to result in success. Requirements include not only what is to be produced, but also how frequently and how fast it is to be produced. APPROVE REQUIREMENTS Once the requirements have been specified, the users must review and approve them before the project continues. The easiest and cheapest time to alter the information system is in this requirements phase, since doing so is simply a matter of changing a description. HOW ARE I.S. DESIGNED, IMPLEMENTED, AND MAINTAINED There are 4 ways to acquire an information system (as described earlier) and since 3 of these 4 methods involve purchasing the I.S., they do not have to be designed; only altered to the company’s specifications. When there are discrepancies present however, the organization faces one of 3 choices:
1. Modify the software 2. Modify the organizational procedures and data 3. Live with the problem It is important to realize that commercial-off-the-shelf (COTS) software will never fit your organizational requirements exactly. However, regardless of whether you buy, rent, or build the information system, the basic steps for acquiring are all the same. First you have to understand your objectives and analyze your requirements. Then you design the system using either COTS or a custom design. Then you implement it and maintain it. STEP 3: COMPONENT DESIGN Each of the 5 components of an information system must be designed. This is usually done by developing alternatives, evaluating each of those alternatives against requirements, and then selecting among those alternatives.
o Hardware design – the team determines specifications for the hardware it wants to acquire.
o Software design – depends on the source of the programs. For COTS software, the team must determine candidate products and evaluate them against the requirements. For custom developed programs, the team produces design documentation for writing program code.
o Database design – o Procedure design – the system developers and the organization must design procedures for both users and operations personnel. Procedures need to be developed for normal processing, backup, and failure recovery operations.
o Design of Job Descriptions – developing job descriptions for both users and operations personnel. STEP 4: IMPLEMENTATION Once the design is complete, the next phase in the SDLC is implementation. Tasks in this phase are to build, test, and convert the users to the new system. Developers construct each of the components independently.
o They obtain, install, and test hardware. o They license and install off-the-shelf programs; they write adaptations and custom programs as necessary.
o They construct a database and fill it with data o They document, review, and test procedures, and they create training programs.
o Finally, the organization hires and trains needed personnel. System Design: Once developers have constructed and tested all the components, they integrate the individual components and test the system. Developers need to design and develop test plans and record the results of tests. They need to devise a system to assign fixes to people and to verify that fixes are correct and complete. A test plan consists of sequences of actions that users will take when using the new system. Test plans include not only the normal actions that users will take, but also incorrect actions. A comprehensive test plan should cause every line of program code to be executed and every error message to be displayed. Today, many IT professionals work as testing specialists. Testing, or product quality assurance (PQA) is an important career, PQA personnel usually construct the test plan with the advice and assistance of users. Users should also be involved in testing, as they have the final say on whether the system is ready for use. Beta testing is the process of allowing future system users to try out the new system on their own. Such users report problems back to the vendor and it is the last stage of testing. Normally these products are complete and fully functioning; they typically have few serious errors. System Conversion: Once the system has passed integrated testing, the organization installs the new system. The term system conversion is often used for this activity because it implies the process of converting business activity from the old system to the new. Organizations can implement a system conversion in one of 4 ways:
o Pilot installation – the organization implements the entire system on a limited portion of the business. The advantage of this is that if the system fails, the failure is contained within a limited boundary. This reduces exposure of the business and also protects the new system from developing a negative reputation throughout the organization
o Phased installation – the new system is installed in phases across the organization. Once a given piece works, the organization installs and tests another piece of the system, until the entire system has been installed. However, some systems are so tightly integrated that they cannot be installed in phased pieces. o Parallel installation – the new system runs in parallel with the old one until the new system is tested and fully operational. It is expensive because the organization incurs the costs of running both systems. Users must work double time to run both systems. Then considerable work is needed to determine if the results of the new system are consistent with those of the old system. However, some organizations consider the costs of parallel installation to be a form of the insurance. It is the slowest and most expensive style but it does provide an easy fallback position if the new system fails.
o Plunge installation or direct cutover installation – the organization shuts off the old system and starts the new stem. If the new system fails, the organization must wait to fix it or reinstall the old one. This shouldn’t be used, unless it provides a new capability that is vital to the organization. Experts recommend the first 3 methods. STEP 5: MAINTENANCE Maintenance is a misnomer; the work done during this phase is either to fix the system so that it works correctly or to adapt it to changes in requirements. The tasks include:
o Record requests for change • • Failures Enhancements o Prioritize requests o Fix failures • • • Patches Service packs New releases First, there needs to be a means for tracking both failures and requests for enhancements to meet new requirements. This can be tracked using word-processing documents. As systems and the organization become larger, it is usually necessary to develop a failuretracking database. Such a database contains a description of each failure or enhancement and records who reported the problem, who will make the fix or enhancement, what the status of that work is, and whether the fix or enhancement has been tested and verified by the originator. Patches – are developed to fix security and other critical problems and are distributed for free usually. They usually bundle fixes of low-priority problems into larger groups called service packs. Users apply service packs in much the same way that they apply patches, except that service packs typically involve fixes to hundreds or thousands of problems. Note: most commercial software products are shipped with known failures. Usually vendors test their products and remove only the most serious problems. Because an enhancement is an adaptation to new requirements, developers usually prioritize enhancement requests separately from failures. The decision to make an enhancement includes a business decision that the enhancement will generate an acceptable rate of return. Major enhancement requests usually result in a complete new release of a product. Note: there can also be failures and enhancements to hardware, in procedures and people, although the latter is usually expressed in more human terms than failure or enhancement. The underlying idea is the same, however. The maintenance phase starts another cycle of the SDLC process. PROBLEMS WITH THE SDLC Although it has had much success, some problems have still arisen:
o One reason is for the waterfall nature of the SDLC. Like a series of waterfalls, the process is supposed to operate in a sequence of nonrepetitive phases. However, problems often occur and teams have to “climb back up the waterfall” to a previous step to fix something.
o The difficulty of documenting requirements in a usual way. It often takes a lot of time to record requirements and usually once it is thought to be complete and implementation occurs, it is realized that more specific requirements are needed. Projects that spend so much time documenting requirements are sometimes said to be in analysis paralysis. These difficulties with the SDLC have led some companies to leave the job of designing, implementing, and maintaining systems to another organization (outsourcing). WHAT IS OUTSOURCING AND WHAT ARE APPLICATION SERVICE PROVIDERS Outsourcing is the process of hiring another organization to perform a service. However, when outsourcing is overseas, it is referred to as offshoring. It is popular because:
o It is an easy way to gain expertise o Cost reductions o Reduce development risk – setting specific prices on components of the system and having a certain standard of quality ensured. The risks involved however are:
o Loss of control o The outsource vendor may change its pricing strategy over time. o Could end up paying for the outsourcing vendors mismanagement and poor use of labour.
o Ending the agreement – since the outsourcing company has gained great knowledge of your company. APPLICATION SERVICE PROVIDERS Application service providers (ASPs) are a special form of outsourcing. In an ASP agreement, an organization contracts with a vendor to “rent” applications from the vendor company on a fee for service basis. In traditional outsourcing the vendor often maintains the systems at the organization’s location. But that is not the case for ASP. In ASP the vendor maintains the system at its own web location and the client organization accesses the application on the vendors website. The vendor can then offer standardized software to many companies while maintaining only a single site. This reduces the costs of supporting the application and theoretically reduces the cost associated with outsourcing. Payments are usually based on the number of “users or employees” of the software. It does have some significant risks:
o Any failure over the internet means the client company cannot operate even internally.
o Potential for “lock in” of the ASP, which may not allow corporate data to be easily ported to competitors sites. Ownership has to be clearly stated in the ASP contract. ...
View Full Document
This note was uploaded on 03/23/2010 for the course COMP SCI 1032 taught by Professor Goldstein during the Winter '10 term at UWO.
- Winter '10