publishing as Prentice Hall 10-5• Steps for purchasing application packages fit into the three SDLC phases referred to as the modified SDLC approach The Purchasing Steps Fig 10.1... publ
Trang 1Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-1
CHAPTER 10
METHODOLOGIES FOR PURCHASED SOFTWARE PACKAGES
Trang 2Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-2
- In large companies today, application software is typically both custom developed and purchased
- In small businesses, software is typically purchased
Why?
Trang 3Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-3
Advantages and Disadvantages of Purchasing
Trang 4Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-4
• Development of a high-level cost estimate - with business manager and IS analyst input
Initiating the Purchasing process
Trang 5Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-5
• Steps for purchasing application packages fit into the three SDLC phases (referred to as the modified SDLC approach)
The Purchasing Steps
Fig 10.1
Trang 6Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-6
• In comparison to an SDLC methodology, the Definition phase has additional steps, and the Construction phase is greatly reduced
• In special circumstances, if the package is new, the purchaser may play a major role as an Alpha or Beta site for the vendor:
- Alpha site: plays a role in determining the final functionality and user interface design for the new
package
- Beta site: plays a role in user acceptance testing
The Purchasing Steps , continued
α
β
Trang 7Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-7
• Two traditional SDLC steps:
• Five additional steps:
Definition Phase
Trang 8Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-8
• Determine whether the proposed system is economically, technically, and operationally feasible
• In addition, the feasibility of purchasing rather than building the system is considered
- Preliminary investigation of available packaged systems
- Detailed cost-benefit analysis for budgeting and monitoring purposes
Feasibility Analysis
Trang 9Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-9
• As when creating custom software, Requirements Definition is a critical step in the purchase methodology
• But rather than create detailed requirements for in-house custom development, this step focuses on defining functional requirements needed to develop a Request for Proposal (RFP)
Requirements Definition
Trang 10Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-10
• Eliminate all but a few promising candidate packages
• Evaluate:
- Available features of a package
- Compatibility with current hardware and software
- Vendor track record
Create Short List of Suitable Packages
Trang 11Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-11
• Business and IS team members work together to determine relevant criteria to select the best package
• Some criteria may be mandatory, while others may be desirable
Establish Criteria for Selection
Trang 12Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-12
• Request for Proposal (RFP): A formal document sent to potential vendors inviting them to submit a
proposal describing their software package and how it meets the company’s needs
• Gives vendors information about:
- System’s objectives and requirements
- Environment in which the system will be used
- General criteria used to evaluate proposals
- Conditions for submitting proposals
Develop and Distribute RFP
Trang 13Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-13
Example of Content in RFP
Trang 14Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-14
• Collect data from:
- Vendors’ responses from RFPs
- Vendor demonstrations (for a few leading packages)
- References from users in other companies
• Project team evaluates how well available packages meet company’s needs
Choose Package
Trang 15Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-15
• Use of an attorney for contracting with a vendor reduces likelihood of future legal problems
• Contract type has implications for the risk level of the purchasing company
- for fixed-price contracts, the purchasing company knows the total price in advance
- for cost-reimbursement contracts, the purchasing company pays the vendor’s direct and indirect costs
and thus assumes a much greater risk
Negotiate Contract
Trang 16Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-16
Discrepancies between needs and package capabilities will need to be dealt with by:
- Modifying the package
- Changing internal procedures
- Living with the differences
Trang 17Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-17
• System Design and Building steps are only necessary if modifications are to be made to the package
• However, essentially all packages will require “configuring” the package to meet the organization’s needs
by making choices using pre-programmed templates by the vendor
Trang 18Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-18
• System Design and Building:
- Typically the vendor does not provide the source code for the package, so the company typically contracts with the vendor (or a certified third party firm) for modifying the package
- Changes may also be required for other existing company systems that interface with the package
• System Testing:
- User acceptance testing of configured package (and/or modified package)
- IS specialist or vendor testing on organization’s equipment
Trang 19Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-19
• Same three steps as for Implementation phase for custom development:
Trang 20Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-20
• Installation planning, training, data cleanup, and conversion
• Success dependent on:
- Quality of vendor support
- Package size and complexity
• Special attention needs to be given to training, especially if there are significant changes in the way
employees do their work
• Change management is a set of activities designed to help overcome resistance by business users to the new system
Installation
Trang 21Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-21
• Operations is the same, whether the package was built or bought
• Initial success highly dependent on good communication with the vendor
• Long-term success also dependent on how well the system has been integrated into the company’s ongoing
operations
Operations
Trang 22Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-22
• Most common = vendor handles package maintenance, as specified in the contract
• Advantage:
- Can lead to significant cost avoidance over the life of the system
• Disadvantages:
- Purchasing company totally dependent on vendor for future system changes
- May not get specific changes that the company wants
Maintenance
Trang 23Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-23
• Project manager: usually is an IS manager, but may be a business manager (or both)
• IS analysts and IS specialists who will operate the system
• Representatives of key business managers and users
• Software vendor personnel
• Sometimes a third-party implementation partner (other than vendor)
• For contracting:
purchasing specialists and attorneys
Project Team
Trang 24Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-24
• Enterprise Resource Planning (ERP) systems are software packages designed to integrate all departmental
and functional systems into a single integrated system
• Packages are more complex to implement because they can impact an entire enterprise
• Companies purchase to achieve business benefits and IT platform benefits, such as:
- Enables access to integrated data for better decision making
- Takes advantage of client/server platform
Trang 25Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-25
Source: Brown and Vessey, MIS Quarterly Executive, 2003
Trang 26Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-26
Open Source Software
• Free to acquire, so lower upfront costs
• Ability to access and modify the source code
• Third parties also provide fee-based products:
- Advanced features for the product
- Maintenance and training
- Documentation and manuals
Trang 27Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-27
• Open Source Software Licensing
• There are many different licenses for open source software
• All allow for the modification and redistribution of source code, but some have conditions or restrictions
• It is important for managers to be aware of the specific terms of a license so that they are not violated
Open Source Licenses
Trang 28Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-28
- Large pool of volunteer testers and developers
- Ability to modify source code
- Not dependent on a single vendor
- Acquisition cost is the same for one copy or thousands
- May use the software for any purpose
- May be easier to interface open source packages with each other
Open Source Applications Open Source in the Enterprise
Trang 29Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-29
- No complete documentation without paying for it
- May not be viable for software that is not common to many organizations
- Different adopters may duplicate efforts in development
- Must be careful in choosing a licensing agreement that fits the company’s needs
Trang 30Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-30
Application Service Providers (ASPs)
• Purchaser elects to use a “hosted” application rather than to purchase the software application and operate it in-house
• Company pays ASP vendor for delivering the software functionality over the Internet to company employees (and sometimes business partners)
• ASP vendor = an ongoing service provider
Trang 31Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-31
- Cost savings and faster speed of implementation
- Usually involves monthly fees rather than large infrastructure investment
- Dependence on an external vendor for both software and ongoing operations
- Contract based on initial estimates of required service levels
Customization by ASPs by 2004 Customization by ASPs by 2004
Trang 32Copyright © 2011 Pearson Education, Inc publishing as Prentice Hall 10-32
• Service Level Agreement (SLA) specifies performance expectations for the ASP, including:
- System uptime
- Recovery time
- Wait time on calls to the help desk
- Notifications about software upgrades
- Other factors important to the customer
• This agreement should be a key part of the ASP contract