CHAPTER 20

INTRODUCTION TO SYSTEMS DEVELOPMENT AND SYSTEMS ANALYSIS

Learning Objectives:
1. Explain the five phases of the systems development life cycle.
2. Discuss the people involved in systems development and the roles
they play.
3. Explain the importance of systems development planning and
describe planning techniques.
4. Discuss the various types of feasibility analysis and calculate
economic feasibility.
5. Explain why system changes triggers behavioral reactions, what
form does this resistance to change take, and how to avoid or
minimize the resulting problems.
6. Discuss the key issues and steps in systems analysis.
Questions to be addressed in this chapter include:
1. What process must be followed to obtain and implement a new
system?
2. What planning is necessary to ensure the systems success? Who
will be involved, and how? Do special committees need to be
formed? What resources are needed? How should the planning be
documented?
3. How will employees react to a new system? What problems might this
change cause, and how can they be minimized?
4. How should the new system be sold to top management? How can
expected costs and benefits be quantified to determine whether the
system will be cost-effective?

Introduction
Companies in a very competitive global business world are constantly
looking for new, faster, and more reliable ways of obtaining
information.
Companies usually change their systems for one of the following reasons:
1. Changes in user or business needs
2. Technological changes
3. Improved business processes
4. Competitive advantage

Page 1 of 16

5. Productivity gains
6. Growth
7. Downsizing
8. Systems integration
9. Systems age and need to be replaced
Developing quality, error-free software is a difficult, expensive, and
time-consuming task.
Most software development projects deliver less than one expects, and
take more time and money than expected.
Developers start cutting corners by omitting some of the basic systems
development steps. Omitting these steps will only lead to disaster.
This is illustrated by the following statistics:
1. An American Management Systems study revealed that 75 percent
of all large systems are not used, not used as intended, or
generate meaningless reports or inaccurate data.
2. The Gartner Group estimates the following:

More than 40 percent of information technology (IT) projects

do not produce a satisfactory outcome.

The average company spends more than $1 million a year for

these unsatisfactory outcomes.

Ten percent of a typical organizations IT staff worked on

projects that have no business value.

3. A Standish Group International study found that

More than 70 percent of software development projects are

delivered late,

Fifty-four percent were over budget.

Sixty-six percent were unsuccessful.

Thirty percent were cancelled before they were completed.

4. A KPMG survey found that 35 percent of all major information

systems projects were classified as runawayshopelessly
incomplete and over budget.
Runaways can consume a great deal of time and money, and in the end
produce no usable results, as illustrated by the following examples:

Page 2 of 16

1. Pacific Gas & Electric (PG&E) pulled the plug on a

client/server information system for all of its residential and
commercial customers. People in and out of the utility labeled
the system, five years in development, a financial disaster
with no end product.
2. Californias Department of Motor Vehicles decided to overhaul
its system, which was originally developed in 1965. It took an
equivalent of 18 programmers working for an entire year to add
a Social Security number file to the drivers license and
vehicle registration file.
After seven years, $44 million, and not a single usable
application, the state canceled the project.
A similar project for the state of Washington ended up
wasting $40 million after seven years.
FOCUS 20-1 illustrates how the IRS made attempts to replace its aging
system.
The IRS concluded that it needed to modernize its 40-year-old
computer system and operations.
The system is responsible for processing and storing all taxpayer
records and currently takes in more than $2 trillion a year.
Critics claimed that the system had already been update, fixed,
and improved so many times that a software meltdown is a real
possibility.
What effect would this collapse have on the U.S. Government? In
the worst case scenario:
1. The IRS would not be able to tell who had paid their
taxes.
2. Tax revenues, hundreds of billions of dollars worth,
would not be collected.
3. To meet its obligation, the government would have to
borrow money, throwing the financial markets into a
panic.
A number of years ago, the IRS spent $3.3 billion on an upgrade
effort that failed.
In the late 1990s the IRS embarked on an $8 billion effort called
the Business Systems Modernization (BSM) program. The BSM spent
almost $4 million on a project that was never finished and was
eventually cancelled.

Page 3 of 16

Systems Development
Whether systems changes are major or minor, most companies go through a
systems development life cycle.

The Systems Development Life Cycle

Figure 20-1 provides the five step process for the Systems Development
Life Cycle (SDLC):
1. Systems Analysis

The information needed to purchase or develop a new

system is gathered.

Requests for systems development are prioritized.

If a project passes, the current system is surveyed to

define the nature and scope of the project and to
identify its strengths and weaknesses.

Then an in-depth study of the proposed system is

conducted to determine its feasibility.

If the system is found feasible, the information needs

of system users and managers are identified and
documented.

A report is prepared and submitted to the information

systems steering committee.

2. Conceptual Design
During the conceptual design, the company decides how to meet
user needs.
The first step is to identify and evaluate appropriate design
alternatives:

Purchase the software.

Develop the software in-house.

Outsource system development to someone else.

3. Physical Design

Input and output documents are designed.

Computer programs are written.

Files and databases are created.

Procedures are developed.

Page 4 of 16

Controls are built into the new system.

4. Implementation and Conversion

Implementation and conversion constitute the capstone phase
during which all the elements and activities of the system come
together.
New hardware or software is installed and tested.
Standards and controls for the new system are established and
system documentation completed.
The final step is to deliver the operational system to the
organization.
A final report is sent to the information systems steering
committee.
5. Operations and Maintenance
Modifications are made as problems arise or as new needs become
evident.

The Players
Management
Top managements most important roles are providing support and
encouragement for the development projects.
The principal roles of user management are to determine
information requirements, to assist systems analysts, to assign
key staff members to development projects, and to allocate
appropriate funds.
Accountants
Accountants may play three roles during systems design:
First, accountants must determine their information needs
and system requirements.
Second, accountants help manage systems development.
Third, accountants take an active role in designing system
controls and periodically monitoring and testing the system.
Information Systems Steering Committee
The purpose of the information systems steering committee is to
plan and oversee the information systems function.
The steering committee sets policies that govern the AIS and
ensures top-management participation, guidance, and control.
Project Development Team

Page 5 of 16

Each development project has a team of systems specialists,

managers, accountants and auditors, and users that guides its
development.
Team members plan each project, monitor the project, make sure
proper consideration is given to the human element, and
communicate project status to top management and the steering
committee.
Systems Analysts and Programmers
Systems analysts study existing systems, design new ones, and
prepare specifications that are used by computer programmers.
Computer Programmers write programs using the specifications
developed by the analysts.

Planning Systems Development

As shown in Figure 20-1 several activities must be performed at various
times throughout the SDLC. One such activity is planning.
Systems development planning is an important step for the following key
reasons:
1. Consistency. Planning enables the systems goals and objectives
to correspond to the organizations overall strategic plan.
2. Efficiency. Systems are more efficient, subsystems are
coordinated, and there is a sound basis for selecting new
applications for development.
3. Cutting edge. The company remains abreast of the ever-present
changes in information technology.
4. Lower costs. Duplication, wasted effort, and cost and time
overruns are avoided. The system is less costly and easier to
maintain.
5. Adaptability. Management is better prepared for future resource
needs, and employees are better prepared for the changes that
will occur.
Poorly planned development efforts result in a company returning to the
prior phase to correct errors and design flaws. This process is costly
and results in delays, not to mention frustration and low morale. Figure
20-2 lists reasons for returning to a prior SDLC phase.
Two types of systems development plans are needed: 1) individual project
plans prepared by project teams and 2) a master plan developed by the
information systems steering committee.

Page 6 of 16

Project Development Plan

The basic building block of information systems planning is
the project development plan.
Each project development plan contains 1) a cost/benefit
analysis, 2) developmental and operational requirements, and
3) human resource, hardware, software and financial resource
requirements.
1. The Master Plan
A master plan is a long-range planning document that
specifies:

What the system will consist of

How it will be developed

Who will develop it

How needed resources will be acquired

Where the AIS headed

FOCUS 20-2 explains why inadequate planning was one of the reasons why
EDS lost a significant amount of money in its contract with the U.S.
military.
The U.S. military hired Electronic Data Systems to develop a
secure, hacker-proof network to link almost 350,000 computers at
more than 4,000 Navy sites.
However, the almost $10 billion contract has resulted in
significant headaches and losses at one point estimated to total
almost $1.7 billion.
EDS made the following mistakes:
1. Had little previous experience with the military and did
not adequately plan for some of the requests
2. Did not verify Navy estimates
3. Did not properly plan and coordinate project tasks
4. Underestimated the cost and time requirements to
customize computers for individuals
5. Did not give the Navy adequate instructions
6. Did not track the inventory of computers

Page 7 of 16

Planning Techniques
Two techniques for scheduling and monitoring systems development
activities are the PERT and the GANTT Chart.
The program evaluation and review technique (PERT) requires that all
activities and the precedent and subsequent relationships among them be
identified.
Completion time estimates are made, and the critical paththe path
requiring the greatest amount of timeis determined.
Below is an example of a PERT chart. The numbers represent weeks.

The critical path is A(5) + D(4) + G(9) = 18 weeks.

A Gantt chart is a project scheduling technique that divides each
project into activities with estimated start and completion times.

Feasibility Analysis
As shown in Figure 20-3, a feasibility study (also called a business
case) is prepared during systems analysis and updated as necessary
during the remaining steps in the SDLC.
At major decisions points (refer to Figure 20-3), the steering committee
uses the study to decide whether to terminate a project, proceed
unconditionally, or proceed if specific problems are resolved.
Although uncommon, systems have been scrapped after implementation
because they did not work or failed to meet an organizations needs.
For example, Bank of America hired a software firm to replace a
20-year-old batch system used to manage billions of dollars in
institutional trust accounts.
After two years the new system was implemented despite
warnings that it was not adequately tested.

Page 8 of 16

Ten months later the system was scrapped, the banks top
systems and trust executives had resigned and the company
had taken a $60 million write-off to cover expenses.
During the ten months, the company lost 100 institutional
accounts with $4 billion in assets.
FOCUS 20-3 on page 668 describes a project at Blue Cross/Blue
Shield that was scrapped after 6 years of work and a $120 million
investment.
Five important aspects to be considered during a feasibility study are
as follows:
1. Economic feasibility. Will system benefits justify the time,
money, and other resources required to implement it?
2. Technical feasibility. Can the planned system be developed and
implemented using existing technology?
3. Legal feasibility. Does the system comply with all applicable
federal and state laws and statutes, administrative agency
regulations, and the companys contractual obligations?
4. Scheduling feasibility. Does the organization have access to
people who can design, implement, and operate the proposed
system? Can people use the system and will they use it?

Calculating Economic Feasibility Costs and Benefits

In a recent survey, 9 out of 10 executives agree that information
technology could greatly enhance their competitive edge; however, only 6
out of 10 agreed that the necessary IT spending would be justified.
Many companies overspend on information technology. The best business
strategy is to spend only on IT projects where the expected benefits
exceed the costs.
The basic framework for feasibility analysis is the capital budgeting
model, in which cost savings and other benefits as well as initial
outlay costs, operating costs, and other cash outflows, are translated
into dollar estimates.
Some of the tangible and intangible benefits a company might obtain from
a new system are cost savings; improved customer service, productivity,
decision making, and data processing; better management control; and
increased job satisfaction and employee morale.
Equipment costs are an initial outlay cost if the system is purchased
and an operating cost if rented or leased.
The primary operating cost is maintaining the system. Studies show that
between 65 percent and 75 percent of an organizations systems efforts
are spent in maintaining current information systems.
Initial outlay and operating costs are summarized in Table 20-2.

Page 9 of 16

1.

Hardware

2.

Software

3.

Staff

4.

Supplies and overhead

5.

Maintenance/backup

6.

Documentation

7.

Site preparation

8.

Installation

9.

Conversion

10. Financial

Capital Budgeting
Various feasibility measures are used to narrow the list of alternative
approaches that meet system requirements.
The following are three commonly used capital budgeting techniques:
1. Payback period. This is the number of years required for the
net savings to equal the initial cost of the investment.
2. Net present value (NPV). All estimated future cash flows are
discounted back to the present, using a discount rate that
reflects the time value of money
3. Internal rate of return (IRR). The IRR is the effective
interest rate that results in an NPV of zero. A projects IRR
is compared with a minimum acceptable rate to determine
acceptance or rejection.

Behavioral Aspects of Change

The behavioral aspects of change are crucial, because the best system
will fail without the support of the people it serves.
Organizations must be sensitive to and consider the feelings and
reactions of persons affected by change.

Why Behavioral Problems Occur

To minimize adverse behavioral reactions, one must first understand why
resistance takes place. Some of the more important factors include the
following:

Page 10 of 16

1. Personal characteristics and background. Generally speaking,

the younger and more highly educated people are, the more
likely they are to accept change.
2. Manner in which change is introduced. Resistance is often a
reaction to the methods of instituting change rather than to
change itself.
3. Experience with prior changes. Employees who had a bad
experience with prior changes are more reluctant to cooperate
when future changes occur.
4. Top-management support. Employees who sense a lack of topmanagement support for change wonder why they themselves should
endorse it.
5. Biases and natural resistance to change. People with emotional
attachments to their duties or coworkers may not want to change
if those elements are affected.
6. Disruptive nature of the change process. Requests for
information and interviews are distracting and place additional
burdens on people. These disturbances can create negative
feelings toward the change that prompted them to occur.
7. Fear. Many people fear the unknown and the uncertainty
accompanying change. They also fear losing their jobs, losing
respect or status, failure, technology, and automation.

How People Resist AIS Changes

FOCUS 20-4 explains the resistance to change that the U.S. Department of
Defense has experienced in trying to update its information systems.
Major resistance often takes one of three forms: aggression, projection
or avoidance.
1. Aggression is behavior that is usually intended to destroy,
cripple, or weaken the systems effectiveness. It may take the
form of increased error rates, disruptions, or deliberate
sabotage.
2. Projection involves blaming the new system for any and every
unpleasant occurrence.
3. Dealing with problems through avoidance is a common human
trait. One way for employees to deal with a new AIS is to avoid
using it in the hope that the problem can be ignored or that it
will eventually go away.

Preventing Behavioral Problems

Peoples reactions to change can be improved by observing the following
guidelines:

Page 11 of 16

1.

Meet users needs. It is essential that the form, content,

and volume of system output be designed to satisfy user
needs.

2.

Keep communication lines open. Managers and users should be

fully informed of system changes as soon as possible.

3.

Maintain a safe and open atmosphere. It is imperative that

everyone affected by systems development have an attitude of
trust and cooperation.

4.

Obtain management support. When possible, a powerful

champion, who can provide resources for the system and
motivate others to assist and cooperate with systems
development, should be appointed.

5.

Allay fears. The organization should provide assurances that

no major job losses or responsibility shifts will occur.

6.

Solicit user participation. Those who will use or be affected

by the system should participate in its development by
providing data, making suggestions, and helping make
decisions.

7.

Provide honest feedback. To avoid misunderstandings, users

should be told which suggestions are being used and how,
which suggestions are not being used and why, and which ones
will be incorporated at a later date.

8.

Make sure users understand the system. Effective use or

support cannot be obtained if users are confused about or do
not understand the system.

9.

Humanize the system. System acceptance is unlikely if

individuals believe the computer is controlling them or has
usurped their positions.

10. Describe new challenges and opportunities. System developers

should emphasize important and challenging tasks that can be
performed with the new system.
11. Reexamine performance evaluation. Users performance
standards and criteria should be reevaluated to ensure that
they are satisfactory in view of changes brought on by the
new system.
12. Test the systems integrity. The system should be properly
tested prior to implementation to minimize initial bad
impressions.
13. Avoid emotionalism. When logic vies with emotion, it rarely
stands a chance. Emotional issues related to change should be
allowed to cool, handled in a nonconfrontational manner, or
sidestepped.
14. Present the system in the proper context. Users are vitally
interested in how system changes affect them personally.

Page 12 of 16

15. Control users expectations. A system is sold too well if

users have unrealistic expectations of its capabilities and
performance. Be realistic when describing the merits of the
system.
16. Keep the system simple. Avoid complex systems that cause
radical changes. Make the change seem as simple as possible
by conforming to existing organizational procedures.

Systems Analysis
When a new or improved system is needed, a written request for systems
development is prepared.
The five steps in the analysis phase and their objectives are shown in
Figure 20-4 and discussed in this section.

Initial Investigation
An initial investigation is conducted to screen projects.
During the initial investigation, the exact nature of the problem(s)
under review must be determined.
The projects scope (what it should and should not seek to accomplish)
also must be determined.
If a project is approved, a proposal to conduct systems analysis is
prepared.
Table 20-3 provides the contents of the Shoppers Mart proposal,
representative of the information in a proposal to conduct systems
analysis.

Systems Survey
During the systems survey, an extensive study of the current AIS is
undertaken.
The objectives of a systems survey are as follows:
1. Gain a thorough understanding of company operations, policies, and
procedures; data and information flow; AIS strengths and
weaknesses; and available hardware, software, and personnel.
2. Make preliminary assessments of current and future processing
needs, and determine the extent and nature of the changes needed.
3. Develop working relationships with users and build support for the
AIS.
4. Collect data that identify user needs, conduct a feasibility
analysis, and make recommendations to management.

Page 13 of 16

The advantages and disadvantages of four common methods of gathering

data are summarized here and in Table 20-4.
1. Interviews
An interview helps gather answers to why questions:

Why is there a problem?

Why does the AIS work this way?
Why is this information important?

2. Questionnaires
Questionnaires are used when the amount of information to be
gathered is small and well defined, and is obtained from many
people. Questionnaires take relatively little time to
administer, but are time consuming to develop.
3. Observation
Observation is used to verify information gathered using other
approaches and to determine how a system actually works, rather
than how it should work.
4. Systems documentation
Systems documentation describes how the AIS is intended to
work.
Document Findings and Model the Existing System
The information gathered during the analysis phase must be documented so
it can be used throughout the systems development project.
Physical models illustrate how a system functions by describing the flow
of documents, the computer processes performed and the people performing
them, the equipment used, and any other physical elements of the system.
Logical models illustrate what is being done, regardless of how the flow
is actually accomplished.
Table 18-5 on page 677 provides a list of system analysis and design
tool techniques.
Analyze the Existing System
Once data gathering is complete, the survey team evaluates the AISs
strengths and weaknesses to develop ideas for designing and structuring
the new AIS.
Prepare Systems Survey Report
The systems survey culminates with a systems survey report. Table 20-3
shows the table of contents for the Shoppers Mart systems survey report.
Feasibility Study

Page 14 of 16

At this point in systems analysis, a more thorough feasibility analysis

is conducted to determine the projects viability.

Information Needs and Systems Requirements

Once a project is deemed feasible, the company identifies the
information needs of AIS users and documents systems requirements.
Table 20-6 is an example of systems requirements.
Figure 20-5 is a humorous view of the types of communication problems
associated with this process.
To illustrate the importance of accurately determining systems
requirements, consider the example of Corning Corporation. The company
began investigating the quality of the ophthalmic pressings it
manufactures and sells to the makers of prescription lenses. It found
that 35 percent of its drafting documents contained errors.
It costs $250 if the errors were discovered before the tool makers
cut the tools, $20,000 if discovered before the assembly line
began production, and up to $100,000 after the tools were sent to
the customer.
Systems Objectives and Constraints
Many organizations take a systems approach to determining information
needs and system requirements.
It is important to determine system objectives so that analysts and
users can focus on those elements most vital to the AISs success.
Table 20-7 provides the list of AIS objectives.
Organizational constraints usually make it impossible to develop all
parts of a new AIS simultaneously. Therefore, the system is divided into
smaller subsystems or modules.
A systems success often depends on the project teams ability to cope
with the constraints the organization faces.
Common constraints include:
1. Governmental agency requirements
2. Management policies and guidelines
3. Lack of sufficiently qualified staff
4. The capabilities and attitudes of system users
5. Available technology
6. Limited financial resources

Page 15 of 16

Strategies for Determining Requirements

1. Ask users what they need.
2. Analyze existing systems.
3. Examine existing system use.
4. Create a prototype.
Documentation and Approval of User Requirements
Detailed requirements for the new AIS that explain exactly what the
system must produce should be created and documented.
The requirements list should be supported by sample input and output
forms, as well as charts, to make it easier for readers to conceptualize
the system.
When user requirements have been determined and documented, the project
team meets with the users.

Systems Analysis Report

Systems analysis is concluded by preparing a systems analysis report to
summarize and document the analysis activities and serve as a repository
of data from which systems designers can draw.
A go/no go decision may be made up to three times during systems
analysis:
1. During the initial investigation
2. At the end of the feasibility study
3. At the completion of the analysis phase

Page 16 of 16