1 Chapter 14 Building Information Systems. 2 Learning Objectives Explain the concept of a systems...
-
date post
20-Dec-2015 -
Category
Documents
-
view
219 -
download
4
Transcript of 1 Chapter 14 Building Information Systems. 2 Learning Objectives Explain the concept of a systems...
1
Chapter 14
Building Information Systems
2
Learning Objectives
Explain the concept of a systems development life cycle (SDLC) Compare and contrast prototyping, rapid application
development (RAD), joint application design (JAD), and traditional SDLC approaches to systems development
Identify advantages and disadvantages of object-oriented (OO) development
Describe component-based development Evaluate alternatives to in-house systems development Discuss the major strategies, methods, and tools for building e-
commerce applications Identify advantages and disadvantages of CASE tools Describe alternative approaches to software process quality
improvement
3
Case: Snap-On Sets up an EC Site
Problem: Snap-On, a tool and equipment maker in Washington state wanted to
set up an e-commerce site and went for the in-house option.
Solution: Snap-On hired application service provider (ASP) OnLink Technologies
to implement a catalog for the company's e-commerce site.
Results: The creation of an in-house ASP consulting service for Snap-On. Skill transferring to other departments and subsidiaries that want to put
up catalogs on their own Web sites.
4
Systems Development Life Cycle
SDLC represents a set of general categories that show the major steps, over time, of an information systems development project.
There is no universal, standardized version of the SDLC, but the phrase has two distinct meanings. An SDLC can be a general conceptual framework for all the
activities involved in systems development or acquisition. An SDLC can also be a very structured and formalized design and
development process.
5
An Eight-Stage SDLC
6
Stages 1 & 2
Stage 1: Project Initiation
Stage 2: Systems Analysis & Feasibility Studies Systems Analysis - the investigation of the existing situation. Feasibility Studies - the major areas of feasibility investigation are;
• Technology• Economics • Organizational factors• Legal, ethical, and other constraints
7
Stages 3 & 4 Stage 3: Logical Analysis and Design
Systems analysts determine 2 major aspects of the system: (1) what it needs to do(2) how it will accomplish these functions.
Logical Design – the design of an IS from the user’s point of view.
Physical Design -translates the abstract logical model into the specific technical design (the “blueprints”)
Stage 4: Actual Acquisition or Development The logical design of the new system guides the actual development
or acquisition
8
Stages 5 & 6
Stage 5: Implementation Approaches to conversion from a previous system include:
• Parallel conversion• Direct cutover• Pilot conversion• Phased (or modular) conversion
Stage 6: Operation After a successful conversion, the system will operate for an
indefinite period of time.
9
Stages 7 & 8 Stage 7: Post-audit Evaluation
An organization should evaluate all its larger system projects after their completion.
These post-audits introduce an additional element of discipline into the development process.
Stage 8: Maintenance Every system needs two kinds of maintenance:
• Fixing bugs• Updating systems to accommodate changes in the
environment
10
Implementing SDLCs
IS groups considering the implementation of a formal SDLC methodology should look for the following characteristics:
Minimal overhead Flexibility and responsiveness Concurrent tasks Focused analysis
11
Alternatives to Conventional SDLCs
Four Possibilities:
1. Prototyping 2. Joint application design
3. Rapid application development
4. Object-oriented development
12
Prototyping Instead of spending a lot of time producing very detailed
specifications, the developers find out only what the users want.
Developers quickly create a prototype. This contains portions of the system of most interest to the users,
or is a small-scale working model of the entire system.
After reviewing the prototype with the users, the developers refine & extend it.
This approach is also known as evolutionary development.
13
Joint Application Design Joint application design (JAD) is a group-based method for
collecting user requirements and creating system designs.
JAD is most often used within the systems analysis and systems design stages of the SDLC.
In contrast to the SDLC requirements analysis, JAD has a group meeting in which all users meet simultaneously with analysts.
An electronic JAD session can be conducted offsite/online with technology support. JAD may not be an easy task for Web site design since in some
cases the stakeholders may be outside of an organization.
14
Rapid Application Development
Rapid application development (RAD) methodologies and tools make it possible to develop systems faster, especially systems where the user interface is an important component. E.g., Blue Cross & Blue Shield
Develop an award-winning application using RAD.
Typical RAD packages include the following:
GUI development environment
Reusable components Code generator Programming language
15
Rapid Application Development
16
Object-Oriented Development
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.
Object technology enables the development of purchasable, sharable, and reusable information assets (objects) existing in a worldwide network of interorganizational information systems.
The techniques and notations that are incorporated into a standard object-oriented language are called unified modeling language or UML.
The object-oriented approach is ideal for developing Web applications.
17
Component-based Development
Components are self-contained packages of functionality that have clearly defined, open interfaces with high-level application services. E.g., interface icons (small), online ordering (a business component)
Components can be distributed dynamically for reuse across multiple applications and heterogeneous computing platforms.
The major reasons for using components-based development are: Code reusability, which make programming faster, with fewer errors. Support for heterogeneous computing infrastructure and platforms. Rapid assembly of new business applications Ability of an application to scale.
18
Systems Developed Outside the ISD
Many organizations are using approaches that shift the construction task from the IS department to others.
Of the various ways of doing this, three are most common:
Let users build their own systems Outsource the entire systems development process Let end-users and/or the ISD use packages
19
Trends Favoring End-User Development
Increasingly powerful desktop hardware
Declining hardware costs
Increasingly diverse software capabilities
Increasingly computer-literate population
Backlog of IS projects
Development speed
Business orientation
Small applications
Control
Apparent cost savings
The following list presents existing factors that lead to higher levels of end-user development:.
20
Outsourcing
Firms that provide outsourcing cite numerous benefits:
Hardware economies of scale
Staffing economies of scale
Specialization
Tax benefits
Outsourcing can also create problems for companies:
Limited economies of scale
Staffing
Lack of business expertise
Contract problems
Internal cost reduction opportunities
21
External Acquisition of Software
The choice between developing software in-house and purchasing existing software is called the make-or-buy decision.
The initial cost of off-the-shelf software is often lower and the software should be of high quality, because many customers have used and helped debug it.
However, buying off-the-shelf software may mean that an organization has to pay for features and functions that are not needed.
22
External Acquisition of Software
The most prominent advantages of buying off-the-shelf software are:
On-timeOn-budgetFull functionality
The following outcomes are also important:
User acceptance Favorable costs-to-benefits ratio Low maintenance Scalability Integration with other systems Minimal negative cross-impacts Reusability
23
Managerial Considerations
The traditional SDLC approach often works well for large projects with well-defined requirements, where there is not a lot of time pressure.
Prototyping requires effective management to make sure that the iterations of prototyping do not continue indefinitely.
RAD may be less appropriate than conventional programming languages for larger projects, or those with a lot of real-time processing.
JAD is easy for senior management to understand, yet it is difficult and expensive to get all people in the same place at the same time.
24
Managerial Considerations
Object-Oriented development is becoming increasingly popular, but usage is limited by a shortage of personnel with OO skills.
A component-based application architecture provides several business
benefits, but the execution of component-based development requires special training and skill.
End-user development is also a possibility for larger projects whose priorities are not high enough to lead to a timely response from the central IS unit.
Outsourcing should always be considered by large and complex systems with a significant risk of failure, yet the disadvantages should be reviewed carefully.
25
The Development of EC Applications
26
The Development of EC Applications
Step 1: System Analysis
Step 2: Select a Development Option
Step 3: Installation, Connection, and More
Step 4: Deployment
Step 5: Operation and Maintenance
27
Development Strategies for EC Applications
1. Buy the EC Applications The following are the major criteria for consideration in buying e-
commerce applications:
• The functionalities of development packages & criteria of choice• User-friendliness • Information requirements • Hardware and software resources • Installation • Maintenance services • Security • Vendor quality • Cost
28
Development Strategies for EC Applications
2. Lease the EC Applications Leasing is advantageous in cases where extensive maintenance is
required, or where the cost of buying is very high. Two ways to lease:
Lease the application from an outsourcer and install it on the company’s premises.
Lease from either an application service provider or a CSP.
3. Develop EC Applications In House: Insourcing Build from scratch. Build from components. Enterprise application integration.
29
Other Development Options
Join An E-Marketplace
Join An Auction or Reverse Auction Third-Party Site
Joint Ventures
Join a Consortium
Hybrid Approach
30
Application Service Provider
An Application service provider (ASP) is an agent who assembles functionality needed by enterprises, and packages it with outsourced development, operation, maintenance, and other services.
The essential difference between an ASP and an outsourcer is that an ASP will manage application servers in a centrally controlled location, rather than on a customer’s site.
31
Benefits & Risks of ASP LeasingType Benefit Potential Risk
Business Reduces the need to attract and retain skilled IT professionals.
Loss of control and high level of dependence on ASP.
Enables company to concentrate on strategic use of IT.
Inability of ASP to deliver quality of service: lack of skills and experience.
Technical Fast and easy application deployment.
Level of customization and legacy application integration offered by ASP may be insufficient.
Higher degree of application standardization.
Reliability and speed of delivery due to bandwidth limitations.
Economic Low total cost of ownership. Pricing changes by ASP unpredictable for application updates and services.
32
Criteria for Selecting an ASP Vendor
Track record
Scope of service
Application & data storage
Support services
Integration
Database format & portability
33
Java Programming Language
Java has established itself as the most important programming language for putting extra features into Web pages.
Java is an object-oriented language.
The Java Web page programs, called applets, need to be relatively
small to avoid delays in transmitting them over the Internet.
Prototyping is probably the most suitable approach for developing
Java applets.
34
CASE Tools
Computer-aided software engineering (CASE) tools are marketed as individual items or in a set (toolkit) that automates various aspects of the development process.
CASE can be used in two different ways: To automate certain SDLC activities on a piecemeal basis. To provide an integrated (I-CASE) package for IS groups.
The relatively high turnover rate among systems personnel creates problems for use of I-CASE systems as new employees will need to take the time to learn the integrated package.
35
Software Quality
Contract review Purchaser’s requirements
specification Development planning Quality planning Design and implementation
Testing and validation
Acceptance
Replication, delivery, and
installation
Maintenance
The International Organization for Standardization (ISO) first published its quality standards in 1987, and then republished an updated version in 2000.
The ISO allows organizations to use any SDLC that includes the following:
36
Project Planning
Project planning provides an overall framework with which the systems development life cycle can be planned, scheduled, and controlled.
Milestones, or checkpoints, are established to allow a periodic review of progress.
37
Project Planning
Critical Path Method (CPM), PERT, and Gantt Charts. These generic project management tools are suitable for
systems development projects.
Project Properties and PrioritiesThe following five properties most significantly influence the
overall nature of an IT project:• Predefined structure• Stability of technology• Size• User proficiency• Developer proficiency
38
Managerial Issues
Building interorganizational and international information systems can be very complicated.
Importance. Functional managers must participate in the development process and should understand all the phases.
Ethical and legal issues. Developing systems across organizations and countries could result in problems in any phase of system development.
39
Managerial Issues
User involvement is important.
Traditional approaches vs. prototyping.
Tool use by developers.
Quality assurance vs. schedules.
Behavior problems.
Perpetual development.