Digital Tech-Chapter 14 Acquiring Information System and Applications
Digital Tech-Chapter 14 Acquiring Information System and Applications IS2080C
Popular in Digital Technologies for Business
verified elite notetaker
Popular in Information technology
verified elite notetaker
verified elite notetaker
verified elite notetaker
verified elite notetaker
Bio 111 - Fundamentals of Biology II
verified elite notetaker
verified elite notetaker
This 10 page Class Notes was uploaded by Tam Notetaker on Tuesday April 12, 2016. The Class Notes belongs to IS2080C at University of Cincinnati taught by David Rapien in Summer 2015. Since its upload, it has received 54 views. For similar materials see Digital Technologies for Business in Information technology at University of Cincinnati.
Reviews for Digital Tech-Chapter 14 Acquiring Information System and Applications
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 04/12/16
Chapter 14 Acquiring Information Systems and Applications 14.1 Planning for and justifying IT applications Planning for and justifying IT apps o Organizations must analyze the need for applications and then justify each purchase in terms of costs and benefits. o The need for information systems is usually related to organizational planning and to the analysis of its performance. o The cost benefit jurisdiction must consider the wisdom of investing in a specific IT application versus spending the funds on alternative projects. o Application Portfolio: When a company examines its needs and performance, it generates a prioritized list of both existing and potential IT applications. Business-IT alignment o Organizational Strategic Plan: Identifies the firm’s overall mission, the goals that follow from that mission, and the broad steps required to reach these goals. The organizational strategic plan and the existing IT architecture provide the inputs in developing the IT strategic plan. The IT architecture delineates the way an organization should utilize its information resources to accomplish its mission. It encompasses both technical and the managerial aspects of information resources. The technical aspects include hardware and operating systems, networking, data management systems, and applications software. The managerial aspects specify how the IT department will be managed, how the functional area managers will be involved, and how IT decisions will be made. The existing IT architecture is a necessary input into the IT strategic plan because it acts as a constraint on future development efforts. It is not an absolute constraint, however, because the organization can change to a new IT architecture. Companies prefer to avoid this strategy, however, because it is expensive and time consuming. Example: You have a Mac system, and you need a new software application. You search and find several such packages for both Mac and Windows. Unfortunately, the best package runs only on Windows. How much better would this package have to be for you to justify switching from Mac and Windows? o IT Strategic Plan: A set of long-range goals that describe the IT infrastructure and identify the major IT initiatives needed to achieve the organization’s goals. The It strategic plan must meet three objectives: 1. It must be aligned with the organization’s strategic plan. Alignment is critical because the organization’s information systems must support the organization’s strategies. Example: An application that improves customer service at a small cost would be considered favorably at Nordstrom, but it would be rejected at Walmart. The reason is that the application would fit in favorably with Nordstrom’s service at-any-cost strategy. However, it would not fit in well with Walmart’s low-cost strategy. You see two department stores, came application, same cost benefits but different answers to the question “Should we develop that application?” 2. It must provide an IT architecture that seamlessly networks users, applications, and databases. 3. It must efficiently allocate IS development among competing projects so that the projects can be completed on time and within budget and still have the required functionality. IT steering Committee: A committee, compromised of a group of managers and staff who represent the various organizational units, is created to establish IT priorities and to ensure that the MIS function is meeting the organization’s needs. The IT steering committee is important to you because it ensures that you get the information systems and applications that you need to do your job. o Major Tasks of an IT Steering Committee: Link corporate strategy with IT strategy Approve the allocation of resources for the MIS function Establish performance measures for the MIS function and ensure they are met IS operational plan: Consists of a clear set of projects that the IS department and the functional area managers will execute in support of the IT strategic plan. o Elements of an IS operational plan: Mission: The mission of the IS function (derived from the IT strategy). IS Environment: A summary of the information needs of the individual functional areas and of the organization as a whole. Objectives of the IS Function: The best current estimate of the goals of the IS function. Constraints on the IS function: Technological, financial, personnel, and other resource limitations on the IS function. Application Portfolio: prioritized inventory of present applications and a detailed plan of projects to be developed or continued during the current year. Resource Allocation and Project Management: A listing of who is going to do what, how, and when. Evaluating and justifying IT investment: o Assessing the costs: Calculating the dollar value of IT investments is not as simple as it may seem. One of the major challenges that companies face is to allocate fixed costs among different IT projects. Fixed costs are those costs that remain the same regardless of any change in the company’s activity level. Fixed IT costs include infrastructure costs and the costs associated with IT services and IT management. For example, the salary of the IT director is fixed, and adding one more application will not change it. Another complication is that the costs of a system do not end when the system is installed. Rather, costs for maintaining, debugging, and improving the system can accumulate over many years. This is a critical point because organizations sometimes fail to anticipate these costs when they make the investment. o Assessing the benefits: Evaluating the benefits of IT projects is typically even more complex than calculating their costs. Benefits may be more difficult to quantify, especially because many of them are intangible – for example, improved customer or partner relations and improved decision making. As an employee, you will probably be asked for input about the intangible benefits that an IS provides for you. The fact that organizations use IT for multiple purposes further complicates benefit analysis. In addition, to obtain a return from an IT investment, the company must implement the technology successfully. In reality, many systems are not implemented on time, within budget, or with all of the features originally envisioned for them. Also, the proposed system may be “cutting edge.” In these cases, there may be no precedent for identifying the types of financial payback the company can expect. Cost benefit analysis: o Net present value (NPV): Analysts use net present value method to convert future values of benefits to their present value equivalent by “discounting” them at the organization’s cost of funds. They can then compare the present value of the future benefits with the cost required to achieve those benefits to determine whether the benefits exceed the costs. o Return on investment (ROI) measures management’s effectiveness in generating profits with its available assets. ROI is calculated by dividing the net income generated by a project by the average assets invested in the project. ROI is a percentage, and the higher the percentage return, the better. o Breakeven analysis determines the point at which the cumulative dollar value of the benefits from a project equals the investment made in the project. o Business case approach: In the business case approach, system developers write a business case to justify funding one or more specific applications or projects. IS professionals will be a major source of input when business cases are developed because these cases describe what you do, how you do it, and how a new system could better support you. 14.2 Strategies for acquiring IT applications Fundamental Decisions in IT Application Acquisition: o How much computer code does the company want to write?: A company can choose to use a totally prewritten application (write no computer code), to customize a prewritten application (write some computer code), or to custom-write an entire application (write all new computer code). o How will the company pay for the application?: Once the company has decided how much computer code to write, it must decide how to pay for it. With prewritten applications or customized prewritten applications, companies can buy them or lease them. With totally custom applications, companies use internal funding. o Where will the application run?: The next decision is whether to run the application on the company’s platform or on someone else’s platform. In other words, the company can employ either a software-as-a-service vendor or an application service provider. o Where will the application originate?: Prewritten applications can be open-source software or they can come from a vendor. The company may choose to customize prewritten open-source applications or prewritten proprietary applications from vendors. Acquisition Methods: o Purchase a Prewritten Application: Many commercial software packages contain the standard features required by IT applications. Therefore, purchasing an existing package can be a cost-effective and time-saving strategy compared with custom-developing the application in-house. Nevertheless, a company should carefully consider and plan the buy option to ensure that the selected package contains all of the features necessary to address the company’s current and future needs. Otherwise, these packages can quickly become obsolete. Before a company can perform this process, it must decide which features a suitable package must include. In reality, a single software package can rarely satisfy all of an organization’s needs. For this reason, a company sometimes must purchase multiple packages to fulfill different needs. It then must integrate these packages with one another as well as with existing software. Advantages of the buy option: 1. Many different types of off-the-shelf software are available. 2. The company can try out the software before purchasing it. 3. The company can save much time by buying rather than building. 4. The company can know what it is getting before it invests in the product. 5. Purchased software may eliminate the need to hire personnel specifically dedicated to a project. Limitations of the buy option: 1. Software may not exactly meet the company’s needs. 2. Software may be difficult or impossible to modify, or it may require huge business process changes to implement. 3. The company will not have control over software improvements and new versions. 4. Purchased software can be difficult to integrate with existing systems. 5. Vendors may discontinue a product or go out of business. 6. Software is controlled by another company with its own priorities and business considerations. 7. The purchasing company lacks intimate knowledge about how and why the software functions as it does. o Customize a Prewritten Application: Customizing existing software is an especially attractive option if the software vendor allows the company to modify the application to meet its needs. However, this option may not be attractive in cases where customization is the only method of providing the necessary flexibility to address the company’s needs. It also is not the best strategy when the software is either very expensive or likely to become obsolete in a short time. Further, customizing a prewritten application can be extremely difficult, particularly for large, complex applications. o Lease the Application: Compared with the buy option and the option to develop applications in-house, the lease option can save a company both time and money. Leased packages (like purchased packages) may not exactly fit the company’s application requirements. However, as noted, vendor software generally includes the features that are most commonly needed by organizations in a given industry. Interested companies commonly apply the 80/20 rule when they evaluate vendor software. Put simply, if the software meets 80 percent of the company’s needs, then the company should seriously consider modifying its business processes so that it can utilize the remaining 20 percent. Many times this is a better long term solution than modifying the vendor software. Otherwise, the company will have to customize the software every time the vendor releases an updated version. Leasing can be especially attractive to small and medium-sized enterprises (SMEs) that cannot afford major investments in IT software. Large companies may also prefer to lease packages to test potential IT solutions before committing to major investments. Leasing can be executed in one of three ways: 1. The first way is to lease the application from a software developer, install it, and run it on the company’s platform. The vendor can assist with the installation and frequently will offer to contract for the support and maintenance of the system. Many conventional applications are leased this way. 2. Use an application service provider 3. Use a software as a service vendor. o Application Service Provider (ASP): An agent or a vendor who assembles the software needed by enterprises and then packages it with services such as development, operations, and maintenance. The customer then accesses these applications via the Internet. o Software-as-a-Service (SaaS): A method of delivering software in which a vendor hosts the applications and provides them as a service to customers over a network, typically the Internet. Customers do not own the software; rather, they pay for using it. SaaS eliminates the need for customers to install and run the application on their own computers. Therefore, SaaS customers save the expense (money, time, IT staff) of buying, operating, and maintaining the software. For example, Salesforce, a well known SaaS provider for CRM software solutions, provides these advantages for its customers. o Open-Source Software: Organizations obtain a license to implement an open-source software product and either use it as is, customize it, or develop applications with it. Unless the company is one of the few that tinker with their source code, open source applications are, basically, the same as a proprietary application except for licensing, payment, and support. Open source software is really an alternative source of applications rather than a conceptually different development option. o Outsourcing: Acquiring IT applications from outside contractors or external organizations is called outsourcing. Companies can utilize outsourcing in many situations. For example, they might want to experiment with new IT technologies without making a substantial up front investment. They also might use outsourcing to obtain access to outside experts. One disadvantage of outsourcing is that companies frequently must place their valuable corporate data under the control of the outsourcing vendor. Outsourcing companies: Many software companies, from IBM to Oracle, offer a range of outsourcing services for developing, operating, and maintaining IT applications. IT outsourcers, such as EDS, offer a variety of services. Also, the large CPA companies and management consultants for example, Accenture, offer outsourcing services. Offshoring: As the trend to outsource is on the rise, so is the trend to relocate these operations offshore, particularly in India and China. Offshoring can save money, but it includes risks as well. The risks depend on which services are being offshored. If a company is offshoring application development, then the major risk is poor communication between users and developers. In response to these risks some companies are bringing outsourced jobs back in house, a process called reverse outsourcing, or insourcing. o Employ Custom Development: Another option is to custom-build an application. Companies can either perform this operation in-house or outsource the process. Although custom development is usually more time consuming and costly than buying or leasing, it often produces a better fit with the organization’s specific requirements. The development process starts with an IT steering committee, having received suggestions for a new system, decides it is worth exploring. These suggestions come from users. Understanding this process will help you obtain the system that you need. Conversely, not understanding this process will reduce your chances, because other people who understand it better will make suggestions that use up available resources. 14.3 The traditional systems development life cycle Systems Development Life Cycle (SDLC): The traditional systems development method that organizations use for large scale IT projects. The SDLC is a structured framework that consists of sequential processes by which information systems are developed. o Systems development projects produce desire results through team efforts. Development teams typically include users, systems analysts, programmers, and technical specialists. 1. Users are employees from all functional areas and levels of the organization who interact with the system, either directly or indirectly. 2. Systems Analysts are IS professionals who specialize in analyzing and designing information systems. 3. Programmers are IS professionals who either modify existing computer programs or write new programs to satisfy user requirements. 4. Technical specialists are experts on a certain type of technology, such as databases or telecommunications. 5. System stakeholders include everyone who is affected by changes in a company’s information systems, for example, users and managers. All stakeholders are typically involved in systems development at various times and in varying degrees. o Advantages and disadvantages of the systems development life cycle: Major advantages: 1. Control 2. Accountability 3. Error detection Major disadvantages: 1. Relatively inflexible 2. Time consuming and expensive 3. Discourages changes once user requirements are gathered (good and bad…) Systems development life cycle steps o Systems Investigation: Addresses the business problem (or business opportunity) by means of the feasibility study. Organizations have three basic solutions to any business problem relating to an information system (1) do nothing and continue to use the existing system unchanged, (2) modify or enhance the existing system, and (3) develop a new system. Feasibility study analyzes which of these three solutions best fits the particular business problem. It also provides a rough assessment of the project’s technical, economic, and behavioral feasibility. Technical Feasibility: Determines whether the company can develop and/or acquire the hardware, soft ware, and communications components needed to solve the business problem. Technical feasibility also determines whether the organization can use its existing technology to achieve the project’s performance objectives. Economic Feasibility: Determines whether the project is an acceptable financial risk and, if so, whether the organization has the necessary time and money to successfully complete the project. You have already learned about the commonly used methods to determine economic feasibility: NPV, ROI, breakeven analysis, and the business case approach. Behavioral Feasibility: addresses the human issues of the systems development project. You will be heavily involved in this aspect of the feasibility study. Go/no-go: After the feasibility analysis is completed, a “go/no-go” decision is reached by the steering committee is there is one or by top management in the absence of a committee. The go/no-go decision does not depend solely on the feasibility analysis. Organizations often have more feasible projects than they can fund. Therefore, the firm must prioritize the feasible projects and pursue those with the highest priority. Unfunded feasible projects may not be presented to the IT department at all. These projects therefore contribute to the hidden backlog, which are projects that the IT department is not aware of. If the decision is a no go, then the project either is put on the shelf until conditions are more favorable or is discarded. If the decision is a go, then the project proceeds, and the systems analysis phase begins. o Systems analysis: Once a development project has the necessary approvals from all participants, the systems analysis stage begins. Systems analysis is the process whereby systems analyst examine the business problem that the organization plans to solve with an information system. The primary purpose of the systems analysis stage is to gather information about the existing system to determine the requirements for an enhanced system or a new system. The end product of this stage, known as the deliverable, is a set of system requirements. Arguably, the most difficult task is systems analysis is to identify the specific requirements that the system must satisfy. These requirements are often called user requirements, because users provide them. When the systems developers have accumulated the user requirements for the new system, they proceed to the systems design stage. o Systems Design: Describes how the system will resolve the business problem. Scope Creep is when the system specifications are approved by all participants, they are “frozen.” That is, they should not be changed. Adding functions after the project has been initiated causes scope creep, in which the time frame and expenses associated with the project expand beyond the agreed upon limits. Scope creep endangers both the project’s budget and its schedule. Because scope creep is expensive, successful project managers place controls on changes requested by users. These controls help to prevent runaway projects. The deliverable of the systems design phase is the set of technical system specifications, which specify the following: 1. System outputs, inputs, and user interfaces 2. Hardware, software, databases, telecommunications, personnel, and procedures 3. A blueprint of how these components are integrated. o Programming and testing: Involves translating the design specifications into computer code. This process can be lengthy and time consuming, because writing computer code is as much an art as a science. Large scale systems development projects can involve hundreds of computer programmers who are charged with creating hundreds of thousands of lines of computer code. These projects employ programming teams. The teams often include functional area users, who help the programmers focus on the business problem. Testing is the process that assesses whether the computer code will produce the expected and desired results. It is also intended to detect errors, or bugs, in the computer code. o Implementation (or deployment): The process of converting from an old computer system to a new one. The conversion process involves organizational change. Only end users can manage organizational change, not the MIS department. The MIS department typically does not have enough credibility with the business users to manage the change process. Organizations use three major conversion strategies: direct, pilot, and phased. Direct Conversion: The old system is cut off , and the new system is turned on at a certain point in time. This type of conversion is the least expensive. It is also the most risky because, if the new system does not work as planned, there is no support from the old system. Because of these risks, few systems are implemented using direct conversation. Pilot Conversion: introduces the new system in one part of the organization, such as in one plant or one functional area. The new system runs for a period of time and is then assessed. If the assessment confirms that the system is working properly, then the system is implemented in other parts of the organization. Phased Conversion: introduces components of the new system, such as individual modules, in stages. Each module is assessed. If it works properly, then other modules are introduced, until the entire new system is operational. Large organizations commonly combine the pilot and phased approaches. That is, they execute a phased conversion using a pilot group for each phase. Parallel Conversion: Old and new systems operate simultaneously for a time, but this strategy is seldom used today. One reason is that parallel conversion is totally impractical when both the old and new systems are online. Imagine that you are completing an order on Amazon, only to be told, “Before your order can be entered here, you must provide all the same information again, in a different form, and on a different set of screens.” The results would be disastrous for Amazon. o Operation and Maintenance: After the new system is implemented, it will operate for a period of time, until it no longer meets its objectives. Once the new system’s operations are stabilized, the company performs audits to assess the system’s capabilities and to determine if it is being utilized correctly. Systems require several types of maintenance: The first type is debugging the program, a process that continues throughout the life of the system. The second type is updating the system to accommodate changes in business conditions. An example is adjusting to new governmental regulations, such as changes in tax rates. These corrections and upgrades usually do not add any new functions. Instead, they simply help the system to continue to achieve its objectives. The third type of maintenance adds new functions to the existing system without disturbing its operation. 14.4 Alternative methods and tools for systems development Alternative methods for system development: o Joint Application Design (JAD): a group-based tool for collecting user requirements and creating system designs. It is most often used within the systems analysis and systems design stages of the SDLC. JAD involves a group meeting attended by the analysts and all of the users that can be conducted either in person or via the computer. During this meeting, all users jointly define and agree on the systems requirements. Advantages: 1. Involves many users in the development process 2. Saves time 3. Generates greater user support for the new system 4. Improves the quality of the new system 5. The new system is easier to implement 6. The new system has lower training costs Disadvantages: 1. It is difficult to get all the users to attend the JAD meeting 2. The JAD approach is subject to all of the problems associated with any group meeting. o Rapid Application Development (RAD): A systems development method that can combine JAD, prototyping, and integrated computer-assisted software engineering (ICASE) tools to rapidly produce a high-quality system. In the first RAD stage, developers use JAD sessions to collect system requirements. This strategy ensures that users are intensively involved early on. The development process in RAD is iterative; that is, requirements, designs, and the system itself are developed and then undergo a series, or sequence, of improvements. RAD uses ICASE tools to quickly structure requirements and develop prototypes. As the prototypes are developed and refined, users review them in additional JAD sessions. RAD produces the functional components of a final system, rather than prototypes. Advantages: 1. Can speed up systems development 2. Users are intensively involved from the start 3. Improves the process of rewriting legacy applications Disadvantages: 1. Produces functional components of final systems, but not the final systems themselves. o Agile Development: A software development methodology that delivers functionality in rapid iterations, which are usually measured in weeks. To be successful, this methodology requires frequent communication, development, testing, and delivery. Agile development focuses on rapid development and frequent user contact to crate software that addresses the needs of business users. This software does not have to include every possible feature the user will require. Rather, it must meet only the user’s more important and immediate needs. It can be updated later to introduce additional functions as they become necessary. The core tenet of agile development is to do only what you have to do to be successful right now. Scrum: A key principle of scrum is that during a project users can change their minds about what they want and need. Scrum acknowledges that a development problem cannot be fully understood or defined from the start. Therefore, scrum focuses on maximizing the development team’s ability to deliver iterations quickly and respond effectively to additional user requirements as they emerge. 1. How Scrum works: During each sprint – typically a 2-4 week period – the team creates a potentially shippable product increment , such as working and tested software. The set of features that goes into each sprint comes from the product backlog, which is a prioritized set of high level work requirements to be completed. The sprint planning meeting determines which backlog items will be addressed during a sprint. During this meeting, the product owner informs the team of the items in the product backlog that he or she wants to be completed. The team members then determine how many of these projects they can commit to during the next sprint, and the record this information in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means tat the requirements are frozen for the next sprint. Each sprint must end on time. If the requirements are not completed for any reason, then they are left out and returned to the product backlog. After each sprint, is completed, the team demonstrates how to use the software. 2. Scrum primary roles: o Scrum master: Maintains the processes (typically replaces a project manager) o Product owner: Represents the business users and any other stakeholders in the project. o The team: A cross functional group of about seven people who perform the actual analysis, design, coding , implementation, testing, and so on. o End-User Development: An approach in which the organization’s end users develop their own applications with little or no formal assistance from the IT department. Advantages: 1. Bypasses the IS department and avoids delays. 2. User controls the application and can change it as needed. 3. Directly meets user requirements 4. Promotes increased user acceptance of new system 5. Frees up IT resources. Disadvantages: 1. May eventually require maintenance from IS department. 2. Documentation may be inadequate. 3. Leads to poor quality control 4. System may not have adequate interfaces to existing systems 5. May create lower quality systems Tools for systems development: o Prototyping: A development approach that defines an initial list of user requirements, builds a model of the system, and then refines the system in several iterations based on users’ feedback. Developers do not try to obtain a complete set of user specifications for the system at the outset, and they do not plan to develop the system all at once. Instead, they quickly develop a smaller version of the system known as a prototype. A prototype can take two forms. In some cases, it contains only the components of the new system that are of most interest to the users. In other cases, it is a small scale working model of the entire system. Users make suggestions for improving the prototype, based on their experiences with it. The developers then review the prototype with the users and utilize their suggestions to refine it. The process continues through several iterations until the users approve the system or it becomes apparent that the system cannot meet the users’ needs. If the system is viable, then the developers can use the prototype to build the full system. Advantages: 1. Help clarify user requirements 2. Helps verify the feasibility of the design 3. Promotes genuine user participation 4. Promotes close working relationship between systems developers and users 5. Works well for ill defined problems. 6. May produce part of the final system. Disadvantages: 1. May encourage inadequate problem analysis 2. Is not practical with large number of users 3. User may not want to give up the prototype when the system is completed 4. May generate confusion about whether the system is complete and maintainable 5. Systems may be built quickly, which can result in lower quality. o Integrated Computer-Assisted Software Engineering Tools (CASE): A group of tools that automate many of the tasks in the SDLC. The tools that are used to automate the early stages of the SDLC (systems investigation, analysis, and design) are called upper CASE tools. The tools used to automate later stages in the SDLC (programming, testing, operation, and maintenance) are called Lower CASE tools. CASE tools that provide links between upper CASE and lower CASE tools are called integrated CASE tools (ICASE). o Advantages: Can produce systems with longer effective operational life Can produce systems that closely meet user requirements Can speed up the development process Can produce systems that are more flexible and adaptable to changing business conditions Can produce excellent documentation o Disadvantages: Systems are often more expensive to build and maintain The process requires more extensive and accurate definition of user requirements. It is difficult to customize the end product. o Component-Based Development: Uses standard components to build applications. Components are reusable applications that generally have one specific function, such as a shopping cart, user authentication, or a catalog. Compared with other approaches, component based development generally involves less programming and more assembly. Component based development is closely linked with the idea if web services and service oriented architectures. Many startup companies are pursuing the idea of component based application development. One example is Ning, which allows organizations to create, customize, and share their own social network. o Object-Oriented Development: Based on a different view of computer systems than the perception that characterizes traditional development approaches. An object-oriented (OO) system begins not with the task to be performed, but with the aspects of the real world that must be modeled to perform that task. How OO development works: The development process for an OO system begins with a feasibility study and an analysis of the existing system. System developers identify the objects in the new system – the fundamental elements in OO analysis and design. Each object represents a tangible, real world entity, such as a customer, bank account, student, or course. Objects have properties or data values. For example, a customer has a ID number, a name, an address, an account number(s), and so on. Objects also contain the operations that can be performed on the properties. For example, operations that can be performed on the customer object may include obtain-account-balance, open-account, withdraw-funds, and so on. Operations are also referred to as behaviors. This approach enables OO analysts to define all the relevant objects needed for the new system, including their properties and operations. The analysts then model how the objects interact to meet the objectives of the new system. In some cases, analysts can reuse existing objects from other applications (or from a library of objects) in the new system. This process saves the analysts the time they otherwise would spend coding these objects. In most cases, however, even with object reuse, some coding will be necessary to customize the objects and their interactions for the new system. Advantages: 1. Objects model real world entities 2. New systems may be able to reuse some computer code Disadvantages: 1. Works best with systems of more limited scope (with systems that do not have huge numbers of objects) 14.5 Vendor and software selection 1. Step 1 Identify potential vendors: Companies can identify potential software applications vendors through various sources. These sources often yield so many vendors and packages that the company must use some evaluation criteria to eliminate all but the most promising ones from further consideration. For example, it can eliminate vendors that are too small or that have a questionable reputation. It can also eliminate packages that do not have the required features or are not compatible with the company’s existing hardware and/or software. Various sources: i. Software catalogs ii. Lists provided by hardware vendors iii. Technical and trade journals iv. Consultants and industry analysts experienced in the application area v. Peers in other companies vi. Web searches 2. Step 2 Determine the evaluation criteria: The most difficult and crucial task in evaluating a vendor and a software package is to develop a detailed set of evaluation criteria. These criteria should be set out in a request for proposal. An RFP is a document that is sent to potential vendors inviting them to submit a proposal that describes their software package and explains how it would meet the company’s needs. The RFP provides the vendors with information about the system’s objectives and requirements. Specifically, it describes the environment in which the system will be used, the general criteria that the company will use to evaluate the proposals, and the conditions for submitting proposals. The RFP may also request a list of current users of the package whom the company may contact. Finally, it can require the vendor to demonstrate the package at the company’s facilities using specified inputs and data files. Some areas in which a customer should identify criteria are the following: i. Characteristics of the vendor ii. Functional requirements of the system iii. Technical requirements that the software must satisfy iv. Amount and quality of documentation provided v. Vendor support of the package 3. Step 3 Evaluate vendors and packages: The responses to an RFP generate massive volumes of information that the company must evaluate. The goal of this evaluation is to determine the gaps between the company’s needs (as specified by the requirements) and the capabilities of the vendors and their application packages. Often, the company gives the vendors and packages an overall score by (1) assessing an importance weight to each of the criteria, (2) ranking the vendors on each of the weighted criteria (say 1 to 10), and then (3) multiplying the ranks by the associated weights. The company can shorten the list of potential suppliers to include only those vendors who achieved the highest overall scores. 4. Step 4 Choose the vendor and package: Once the company has shortened the list of potential suppliers, it can begin negotiations with these vendors to determine how their packages might be modified to remove any discrepancies with the company’s IT needs. Thus, one of the most important factors in the decision is the additional development effort that may be required to tailor the system to company’s needs or to integrate it into the company’s computing environment. The company must also consider the opinions of both the users and the IT personnel who will have to support the system. 5. Step 5 Negotiate a contract: The contract with the software vendor is a vital element in the selection process. It specifies both the price of the software and the type and amount of support that the vendor agrees to provide. The contract will be the only recourse if either the system or the vendor does not perform as expected. It is essential, then, that the contract directly references the proposal, because this is the vehicle that the vendor used to document the functionality supported in its system. Furthermore, if the vendor is modifying the software to tailor it to the company’s needs, then the contract must include detailed specifications (essentially the requirements) of the modifications. Finally, the contract should describe in detail the acceptance tests that the software package must pass. Contracts ae legal documents, and they can be quite tricky. For this reason, companies might need the services of experienced contract negotiators and lawyers. Many organizations employ software purchasing specialists who assist in negotiations and write or approve the contract. These specialists should be involved in the selection process from the start. 6. Step 6 Establish a service level agreement: Service level agreements are formal agreements that specify how work is to be divided between the company and its vendors. These specifications are based on a set of agreed upon milestones, quality checks, and what if situations. They describe how quality checks will be made and how disputes will be resolved. SLAs accomplish these goals (1) defining the responsibilities of both partners, (2) providing a framework for designing support services, and (3) allowing the company to retain as much control as possible over its own system. SLAs include such issues as performance, availability, backup and recovery, upgrades, and hardware and software ownership. For example, the SLA might specify that the application service provider make its system available to the customer 99.9 percent of the time. 7.
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'