1. Com 3kd3 Midterm Exam Time: 3:30 -5:30 pm Monday Oct. 25
Place: classroom KTH B104
Coverage: Lecture note and textbook
Format:
True/False 15 points
Multiple choice: 15 points
Short answer questions: 20 points

2. Requirement Priority and Implementation Strategy

3. Learning Objectives
Describe the strategic decisions that integrate the application deployment environment and the design approach for the new system
Determine alternative approaches for system implementation

4. Learning Objectives (continued)
Evaluate and select an implementation approach based on the needs and resources of the organization
Describe key elements of a request for proposal (RFP) and evaluate vendors’ proposals for outsourced alternatives
Develop a professional presentation of findings to management

5. Overview Last three activities of analysis Refocus project direction
Prioritize systems requirements
Generate and evaluate alternatives
Review recommendation with management
Refocus project direction
Transition from discovery and analysis to solutions and design
Set direction for design and implementation of solution system

6. Deciding on Scope and Level of Automation
Prioritize the system requirements based on the desired scope and level of automation for the new system
Scope determines which business functions will be included in system
Level of automation is how much computer support exists for functions included in scope
Users typically request more business functions than budget allows

7. Determining the Level of Automation
Low level
Functions automated for simple computer record keeping
Medium level
Midrange point that combines features from low and high alternatives
High level
System automates most processing of business functions

8. RMO Customer Support System Functions, Priority, and Three Levels of Automation

9. Selecting Alternatives
Entire group of alternatives is evaluated together to provide “big picture” view of proposed system
Key criteria that are used
Strategic plan
Economic feasibility
Schedule and resource feasibility
Technological feasibility
Operational, organizational, and cultural feasibility

10. Defining the Application Deployment Environment
Configuration of
Computer hardware
System software
Networks
Development tools
Existing environment generally considered and compared with proposed environment

11. Range of Application Types
Stand-alone applications on mini- and personal computers
Online interactive applications
Distributed applications
Web-based applications

12. Deployment Environment Characteristics to Consider
Compatibility with system requirements
Compatibility among hardware and system software
Required interfaces to external systems
Conformity with IT strategic plan and architecture plans
Cost and schedule

13. Development Tools
Development environment – programming languages, CASE tools, and other software used to develop application software
Java and Visual Studio .NET are examples
Application deployment environment decisions limit development tool choices
Operating system environment
Database management system (DBMS)
Distributed software standard

14. Sun’s JavaEE
Java Platform, Enterprise Edition or Java EE is a widely used platform for server programming in the Java programming language. It adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server.

16. IBM's WebSphere
WebSphere is IBM’s integration software platform. It includes the entire middleware infrastructure -- such as servers, services, and tools--needed to write, run, and monitor 24x7 industrial-strength, on demand Web applications and cross-platform, cross-product solutions. WebSphere provides reliable, flexible, and robust integration software.

18. Microsoft .NET framework
The Microsoft .NET Framework is a software framework that can be installed on computers running Microsoft Windows operating systems. It includes a large library of coded solutions to common programming problems and a virtual machine that manages the execution of programs written specifically for the framework.

20. Existing Processing Environment at RMO

21. Processing Environment Alternatives

22. Strategic Directions for RMO Processing Environment

23. Implementation Strategy

24. Choosing Implementation Alternatives
Variations on obtaining system
Facilities management – outsource all IS support
Packaged software, turnkey system, ERP system
Custom-built software systems
In-house development
Selection dimensions
Buy vs. build
In-house vs. outsource

25. Implementation Alternatives

26. The impact of the Internet
Traditional vs. Web-based development
Software as a service (SaaS)

27. Traditional vs. Web-based Development
Traditional development
System design is influenced by compatibility issues
Security issues are less complex
Web-based development
Treats the Web as the platform rather than a communication channel
Treat software application as a service
Easily scalable, enterprise-wide solution

28. Software as a Service (SaaS)
A model of software deployment where an application is hosted as a service provided to customers across the Internet.
Reduce the up-front expense of software purchases, through less costly, on-demand pricing.
Alleviates the customer's burden of software maintenance, ongoing operation, and support.
Relinquish control over software versions or changing requirements; costs to use the service become a continuous expense.

30. Outsourcing
Outsourcing is the transfer of information systems development, operation, or maintenance to an outside firm that provides these services.
A way of controlling costs and dealing with rapid technological change
Has become part of an overrall IT strategy

32. The Growth of outsourcing services
Application service providers
Deliver a software application or access to an application by charging a usage or subscription fee
Internet business services or managed hosting
Provide Web-based support for transactions such as order processing, billing, and customer relationship management.

33. Common features associated with ASPs
ASP fully owns and operates the software application(s)
ASP owns, operates and maintains the servers that support the software
ASP makes information available to customers via the Internet or a "thin client"
ASP bills on a "per-use" basis or on a monthly/annual fee

35. Oracle CRM On Demand
Oracle CRM On Demand bring clarity to your sales processes; build loyal, long-term customer relationships; accelerate productivity; boost call center efficiency; and derive customer intelligence.
With Oracle CRM On Demand you can do all this and more – leveraging an easy-to-use and highly tailorable solution offered at a predictable per user, per month price.

36. Advantages of using ASP
Cost control
Software costs for the application are spread over a number of clients
Reduction of internal IT costs to a predictable monthly fee.
Redeploying IT staff and tools to focus on strategic technology projects that impact the enterprise's bottom line

37. Advantages of using ASP
Better Service
Vendors have more application experience
Systems are kept up to date, available, and managed for performance by experts
Improved reliability, availability, scalability and security of internal IT systems
Guarantees a certain level of service
Access to product and technology experts dedicated to available products

41. Outsourcing issues and concerns
Cost control / lack of technology expertise
Self control of mission-critical IT
Operation and security issue
Quality and stability of the service provider
Internal IT job security

42. Offshore outsourcing
Shifting IT development, support, and operations to other countries
Driven by global Internet connection and wage differences
Lower bottom-line cost
Risks and concerns regarding project control, security issues, disparate cultures, and communication problems

43. In-house software development
Make or Buy decision
Make: develop in-house software system
Buy: purchase a software package

44. Reasons for in-house development
Satisfy unique business requirement
Minimize changes in business procedures and policies
Meet constraints of existing systems
Meet constraints of existing technology
Develop internal resources and capabilities
Satisfy unique security requirements

45. Reasons for purchasing a software package
Lower costs
Requires less time to implement
Proven reliability and performance benchmarks
Requires less technical development staff
Future upgrades provided by the vendor
Obtain input from other company

46. Customizing a software package
Request vendor customize it to meet your needs
Paying vendor extra for enhancement
Make your own modification with vendor’s permission

47. The software acquisition process
Evaluate the information system requirements
Identify potential vendors or outsource options
Evaluate the alternatives
Perform cost-benefit analysis
Prepare a recommendation
Implement the solution

48. Selecting an Implementation Alternative
Identifying criteria for selection
Comparisons can be difficult
Different proposed systems have strengths in different areas
Three major areas to consider
General requirements
Functional requirements
Technical requirements

49. General Requirements
Considerations that are important but not directly associated with the computer system. Such as:
Development cost
Length of time until deployment
Requirement for internal resource
Organizational impact
Warranties and support services …

50. Functional Requirement
The functions that must be included within the system. For example, for an order processing system, they could be:
Handling orders and backorders
Support discount and sales promotion
Allowing different payment methods
Order tracking and reporting …

51. Technical requirement
The operation, performance, and maintenance requirements, such as:
Robustness
Performance
Scalability
Flexibility
Compatibility …

52. Making the Selection
First, rate each implementation alternative with raw score for each criterion.
Weighted scores are then tabulated and compared to make a choice

53. Contracting with Vendors
Generate request for proposal (RFP)
Formal document sent to vendors if in-house development is not selected
States requirements and solicits proposed solutions
Considered a competitive contract offer
Bid on supplying hardware, software, and/or support services

54. How to write an RFP

55. Sample RFP Table of Contents

56. Sample RFP Table of Contents
I. Introduction and Background
II. Overview of Need
III. Description of Technical Requirements
IV. Description of Functional Requirements

57. Sample RFP Table of Contents (continued)
V. Description of General Requirements
VI. Requested Provider and Project Information
VII. Details for Submitting Proposal
IV. Evaluation Criteria and Process

58. Benchmarking and Choosing a Vendor
Observe in use or install trial version
Benchmark – evaluate the system against a standard
Visit another company using a particular system
Develop a contract
Fixed-dollar – risk is on vendor
Cost-plus-percentage – risk is on purchaser
Cost-plus-fixed-fee – risk is shared by both

59. Presenting Results and Making Decisions
Compile and organize documentation
Present alternatives and critical issues in easy-to-understand but complete manner
Final choice generally made by executive steering committee
Format of documentation and presentation style varies with organization

60. The Transition to Systems Design
If the management decides to develop the system in-house, then the transition to systems design begins
From logical design (what is required) to physical design (how is implemented)

61. System Design Objectives
The goal of system design is to build a system that is effective, reliable, and maintainable.
Data design
Interface design
Architecture design