IS 341
Business Systems Analysis
Chapter 2 - Notes
I. Introduction – in the early years, an
organization had to produce all its own software because there was nowhere that
it could be purchased. Today, software
production is an industry (and a career) in itself. Outsourcing is a major method of software
acquisition today.
II. Systems Acquisition – the first
administrative systems were developed in the U.K at J. Lyons & Sons, and in
the U.S.A. at General Electric (payroll system, 1954). At that time and for at least 10 years
thereafter, the only way to obtain a system was in-house development. The six (6) options (below) may be separate,
hybrid, or used partially in the acquisition of systems. These are not exclusive, and new means may
appear at any time.
A.
Outsourcing – turning over responsibility for some or all of an
organization’s information systems applications and operations to an outside
firm. Outsourcing is a viable alternative
that should be considered. Outsourcing
issues:
1. Cost effectiveness – a firm specializing in
payroll may do the job more effectively/efficiently than you can do it yourself
2. Overcome operating problems – if a unionized
group of employees is too troublesome, a firm may eliminate the department and
outsource the work
3. Core mission – a firm’s core competencies may
not revolve around information systems and management may wish to have another
firm take responsibility for those operations
B.
Sources of Software
1. I.T. service firms – these firms develop,
host, and run applications for clients, and provide other services. This solution is preferred when a firm does
not have the in-house capabilities of doing the work themselves and a suitable
off-the-shelf solution is not available.
Hardware manufacturers such as IBM that produce software for their own hardware
may become experts at providing custom solutions for other organizations.
2. Packaged Software Producers – if a particular
software package suits your needs, or can be modified to do so, why do it
yourself? Prepackaged or Off-the Shelf
systems are prepared to solve a wide variety of information systems needs (MS
Office and Project, Intuit Quicken and QuickBooks). Some of the largest computer companies in the
world produce software exclusively.
3.
a. Benefits – a single repository ensures more
consistent and accurate data, and less maintenance.
b. Disadvantages – these can work very well, but
are extremely complex, take a long time to complete, and are extremely
expensive. In some cases an organization
must entirely change the way it does business in order to benefit from an
enterprise system (but they believe the benefits are worth the change).
4. Cloud Computing – rent or lease systems from
third parties who run the applications from remote (Internet) sites, paying
(usually) monthly. This has been done
for years (under various names), but has become popular in the last couple
years and is currently called Cloud Computing.
Clients do not need to run or maintain all the hardware or software, the
vendor does that, with access provided over the Internet.
a. Benefits – 1.
freeing time for internal I.T. staff; 2.
faster access to applications than via internal development; 3. lower cost for higher quality applications;
4. easier to walk away from an
unsatisfactory system.
b. Disadvantages – 1. reliability; 2. security; 3.
compliance (e.g., with government regulations)
5. Open-Source Software – available for free,
both as final product and source code (OpenOffice, Linux, Firefox). Source code may be manipulated by anyone to
satisfy their own needs, then made available publicly. Profits are made by offering maintenance and
other services, or by offering a basic version for free, but charging for more
extensive versions.
6. In-House Development – do it yourself, but do
you have the time, finances, or talent available? You can create it, but it is also entirely
your own responsibility – development, maintenance, etc.
NOTE:
Average lead time for major systems development in the U.S. today is 5-6
years!
C.
Choosing Off-the-Shelf Software – must consider Costs, Functionality,
Vendor (support and viability), Flexibility (for you to customize),
Documentation, Response time, Ease of Installation, Ease of Use
1. Validating Purchased Software Information –
better check it out WELL before you buy!
Promises are made, but not always kept.
RFP – Request For Proposal – ask vendors to submit
proposals to meet your needs and requirements, then compare the various
responses
III. Reuse – using previously written software resources
in new applications. Many bits and
pieces of software are relatively generic, so instead of re-writing them for
each application they can be reused (saves time and increases productivity, but
also increases complexity of the inter-woven/inter-leavened system.
A. Typically
applied to Object-Oriented and Component-Based (similar to O-O, focus on
general-purpose code that can be reused interchangeably between a number of
programs) systems
B.
There is evidence that reuse can be effective by building libraries of
the reusable code, but there is a marked increase in system complexity &
therefore a significant increase in costs.
Complexity – is it easier to take the time & resources to fully understand
someone else’s objects, or just go ahead & develop your own?
1. Four (4) Approaches for Reuse: (Table 2-3)
a. Ad Hoc – low
or no reuse, low cost, no policies, not really reuse at all, just do it if you wish
b. Facilitated – low reuse, low cost, reuse
encouraged but not required
c. Managed – moderate reuse, moderate cost,
mandated reuse with organizational policies; more structured, more expensive
d. Designed – high reuse, high cost, reuse
mandated, code/assets designed for reuse from the beginning of project,
policies in place to measure effectiveness of reuse; most expensive/complex
2. Successful reuse requires an understanding of
how reuse fits into organizational goals/strategies, and an understanding of
the social and technical world into which the assets must fit.
3. Reuse is not a “given” in the real world,
regardless of what is taught on college campuses. Experienced developers trust their own code
more than that of others, while novice developers want to use a
tried/true/trusted product (someone else’s).
4. Note on Reuse – In the instructor’s
personal experience, many more experienced programmers see formal “reuse” as
more of an organizational philosophy/attitude than something new. Code and assets have been reused (even if
simply copied from one program to another) since the early days of coding as a
way to shorten the coding process and lower costs of development. Formal libraries and formal policies on the
subject are what make reuse a “new” idea.
While reuse is now taught as a formal methodology in college and tech courses,
the truth as to time & cost savings is still questionable in real life, and
varies between organizations.