Chapter 8.

SYSTEMS DEVELOPMENT
New information systems are an outgrowth of a process of organizational problem solving. A new
information system is built as a solution to some type of problem or set of problems the organization
perceives it is facing. The problem may be one in which managers and employees realize that the
organization is not performing as well as expected or that the organization should take advantage of
new opportunities to perform more successfully. In recent years, a growing number of organizations
have implemented enterprise ISs such as ERP, SCM and CRM systems, or other systems that serve
the entire organization or many of its units.

The investment of resources in such systems, both in financial and other terms, is substantial, as is the
risk in implementing large systems. If the implementation is successful, the new system can
significantly change the manner in which the organization conducts business and help it attain
competitive advantage. Hence it is necessary to plan the implementation of information systems,
whether they are developed in-house, made to order by another company, or purchased and adapted
for the organization. Planning and developing large information systems is a very demanding task for
even the most experienced professionals. Information systems tend to grow in complexity as they
grow in size. Because information systems are so critical to competitive advantage in so many
companies, their timely and careful development is of very high priority.

Systems development is the entire set of activities needed to construct an information system solution
to a business problem or opportunity. These activities consist of systems analysis, systems design,
programming, testing, conversion and, production and maintenance.

Understanding systems development is important to all professionals, not just those in the field of
information systems. In today’s businesses, managers and employees in all functional areas use
business information systems. Inspiration for development and/or implementation of new
information technologies come from several sources, including users like you.

SYSTEMS ANALYSIS
Systems analysis involves an analysis of the business problem that the organization plans to solve
with an information system. It consists of defining the problem, identifying its causes, specifying the
solution, and identifying the information requirements that must be met by a system solution.

The systems analyst creates a road map of the existing organization and systems, identifying the
primary users of data and existing hardware and software used in the organization.

The systems analyst then details the problems of the existing system. Understanding the business
problem requires understanding the various processes involved in the organization. These can often
be quite complicated. By examining documents, forms, reports, and procedures, observing system
operations, and interviewing key users of the systems, the analyst can identify the problem areas and
determine the objectives a solution should achieve. Often, the solution requires building a new
information system or improving an existing one.

The systems analysis also includes a feasibility study to determine whether that solution is feasible,
or achievable, from a financial, technical, and organizational standpoint. The feasibility study
determines whether the proposed system is expected to be a good investment, whether the technology
1
needed for the system is available and can be handled by the firm’s information systems specialists,
and whether the organization can handle the changes introduced by the system.

Feasibility Analysis
A key step of the preliminary investigation phase is the feasibility analysis. The feasibility of a
proposed business system can be evaluated in terms of three major categories.

Technical feasibility determines if the hardware, software, and communications components can be
developed and/or acquired to solve the business problem. Technical feasibility also determines if the
organization’s existing technology can be used, upgraded or added to in order to achieve the project’s
performance objectives. The team must consider the organization’s existing investment in hardware,
software, and telecommunications equipment. For example, if the company recently purchased
hundreds of units of a certain computer, it is unlikely that management will approve the purchase of
computers of another model for a new application. Thus, the investigators must find out whether the
proposed system can run properly on existing hardware.

Operational feasibility, also known as behavioral feasibility, is a measure of whether the project can
be put into action or operation in the organization’s environment. The organizational culture can
impact on the success of the new IS. If a solution makes technical sense but conflicts with the way
the organization does business, the solution is not feasible. No matter how elegant the technology, the
system will not work if the end users and managers do not perceive it to be relevant and, therefore, do
not support it.

In this category, we assess the degree of resistance to the proposed system, the degree of change to
the end users’ working environment as a result of the new system, and the current state of human
resources available to conduct the project and to manage and use the system on completion. Thus, an
organization might reject a solution because it forces a change in management responsibilities, status
and chains of command, or reporting structures. Power and politics may come into play, and some
people may resist the new system. Another concern of behavioral feasibility is assessing the skills
and training needs that often accompany a new information system. In some organizations, a
proposed system may require skills beyond what the workforce currently possesses. Behavioral
feasibility is as much about “can they use it” as it is about “will they use it.”

Financial feasibility. Like any project, the development of a new IS must be economically justified,
so organizations conduct an economic or financial feasibility study. The purpose of the financial
feasibility assessment is to determine the extent to which the proposed system will provide positive
economic benefits to the organization. This determination involves the identification, and
quantification of all benefits expected from the system, as well as the explicit identification of all
expected costs of the project.

In the early stages of the project, defining and assessing all of the benefits and costs associated with
the new system is impossible. Thus, the financial feasibility assessment is an ongoing process in
which the definable short-term costs are constantly being weighed against the definable long-term
benefits. If a project cannot be accurately judged as economically feasible using hard costs, then the
project should not proceed, regardless of the other assessment category outcomes.

The assessment of economic feasibility typically involves the preparation of a cost/benefit analysis.
If costs and benefits can be quantified with a high degree of certainty, they are referred to as tangible;
if not, they are called intangible.

2
Examples of tangible costs are the costs of hardware and software, employee salaries, and other
quantifiable costs needed to develop and implement an IS solution. Intangible costs are difficult to
quantify; they include the loss of customer goodwill or employee morale caused by errors and
disruptions arising from the installation of a new system.

Tangible benefits are favorable results, such as the decrease in payroll costs caused by a reduction in
personnel or a decrease in inventory carrying costs caused by reduction in inventory. Intangible
benefits are harder to estimate. Such benefits as better customer service or faster and more accurate
information for management fall into this category.

Normally, the systems analysis process identifies several alternative solutions that the organization
can pursue and assesses the feasibility of each. A written systems proposal report describes the costs
and benefits, and the advantages and disadvantages of each alternative. It is up to management to
determine which mix of costs, benefits, technical features, and organizational impacts represents
the most desirable alternative.

Requirements Analysis: Establishing Information Requirements

The end product (the “deliverable”) of the Analysis phase is a set of specific information
requirements that must be met by the chosen system solution. At its most basic level, the information
requirements of a new system involve identifying who needs what information, where, when, and
how.

Requirements analysis carefully defines the objectives of the new or modified system and develops a
detailed description of the functions that the new system must perform. Faulty requirements analysis
is a leading cause of systems failure and high systems development costs. A system designed around
the wrong set of requirements will either have to be discarded because of poor performance or will
need to undergo major modifications. Some problems do not require an information system solution
but instead need an adjustment in management, additional training, or refinement of existing
organizational procedures.

The end product (the “deliverable”) of this stage is a set of systems requirements identified in the
Functional Requirements document. Functional requirements are the functions that the system is
expected to fulfill and the features through which it will perform its tasks. In other words, functional
requirements are what the system should be able to do. For example, the following are examples of
functional requirements for a proposed e-commerce application for a business.

• Easy-to-use data entry screens for Web customers

• Fast, automatic calculation of sales totals and shipping costs
• Fast retrieval and update of data from product, pricing and customer databases
• Alerts for data entry errors

3
SYSTEMS DESIGN
Systems analysis describes what a system must do to solve the business problem, and systems design
describes how the system will accomplish this task.

The systems design phase is the phase in which the new system is actually planned. The purpose of
this phase is to detail the system specifications that will meet all the business requirements detailed in
the requirements report. The deliverable of the systems design phase is the technical design that
specifies the following:
• System outputs, inputs, and user interfaces
• Hardware, software, databases, telecommunications, personnel, and procedures
• How these components are integrated

Some activities involved at this stage are: designing output screens and reports, planning input data
forms and procedures, planning file access methods and record formats, planning database and data
communications interfaces, and designing system security controls.

User information requirements drive the entire system design effort. End users must therefore have
sufficient control over the design process to ensure that the system reflects their business priorities
and information needs, not the biases of the technical staff. Working with the systems professionals
during this phase increases users’ understanding and acceptance of the system.

Completing the Systems Development Process

The remaining steps in the systems development process translate the solution specifications
established during the systems analysis and design phases into a fully operational information system.
These concluding steps consist of programming, testing, conversion, production, and maintenance.

PROGRAMMING
During the programming stage, system specifications that were prepared during the design stage are
translated into software program code. Today, many organizations no longer do their own
programming for new systems. Instead, they purchase the software that meets the requirements for a
new system from external sources such as software packages from a commercial software vendor,
software services from a software service provider, or outsourcing firms that develop custom
application software for their clients.

TESTING
Exhaustive and thorough testing must be conducted to ascertain whether the system produces the
right results. Testing requires a large amount of time, effort, and expense to do properly. In some
instances, parts of the system may have to be redesigned. However, the costs of improper testing,
which could possibly lead to a system that does not meet its objectives, are enormous.

4
CONVERSION
Conversion is the process of switching from using a legacy system to using a new system. A legacy
system is an old system that is fast approaching or beyond the end of its useful life within an
organization. Conversion can be a difficult time of stress and confusion for an organization.
Operators need to get used to new systems, and even though the system might have been thoroughly
tested, conversion can hold some unpleasant surprises if bugs or problems have not been discovered
earlier. Services to other departments and to customers might be delayed.

Four basic conversion strategies can be employed to manage the transition: parallel conversion, direct
cutover conversion, pilot conversion, and phased conversion.

In parallel conversion, the old system is used along with the new system for a predetermined period
of time until everyone is assured that the new one functions correctly. This is the safest conversion
approach because, in the event of errors or processing disruptions, the old system can still be used as
a backup. It also makes it possible to check the results from the new system against the legacy system
and ensure that the new system is giving correct results. However, this approach is very expensive,
and additional staff or resources may be required to run the extra system.

In direct cutover conversion, the old system is discarded and the new one takes over the entire
business operation for which it was developed. This strategy can be inexpensive, if successful,
because no resources are spent on running two systems in parallel, and the benefits of the entire new
system are immediately realized. While this method is comparatively cheap, it is a very risky
approach that can potentially be more costly than running two systems in parallel if serious problems
with the new system are found. There is no other system to fall back on. System or program
corrections are difficult to make while the system has to remain operational.

Pilot conversion involves running the new system initially for one group of users rather than all
users. If the new system is to be used in more than one business unit, it might first be introduced for
a period of time in a single unit, where problems can be addressed and the system can be refined
before implementing it in the other business units. For example, a manufacturing company with a
number of retail outlets throughout the country could use the pilot approach and install a new
inventory control system at one of the retail outlets. When this pilot retail outlet runs without
problems, the system can be implemented at other retail outlets. Obviously, piloting reduces risks
because it confines any problems to fewer units. It is especially useful for determining how
comfortable staff members and other users such as suppliers and customers, are with a new system—
a lesson that can be applied to the later units.

Information Systems, especially large ones, can often be broken into functional modules and phased
into operation one at a time, a process called phased conversion. This is a popular technique
preferred by many organizations. In this approach, sometimes called a piecemeal approach,
components of the new system are slowly phased in, while components of the old one are slowly
phased out. For example, conversion of an accounting IS can be phased, with the accounts receivable
module converted first, then the accounts payable, then the general ledger, and so on. A supply chain
management system might be implemented one module at a time: first, the customer order module,
then the shipment module, then the inventory control module, and so on. This phased approach also
reduces risk, although the benefits of using the entire integrated system are delayed. Also, users can
learn how to use one module at a time, which is easier than learning the entire system at once.
However, when parts of both systems are used, there might be data inconsistencies between the two.
5
Moving from an old system to a new one requires that end users be trained to use the new system.
Detailed documentation showing how the system works from both a technical and end-user
standpoint is finalized during conversion time for use in training and everyday operations. Lack of
proper training and documentation contributes to system failure, so this portion of the systems
development process is very important.

PRODUCTION AND MAINTENANCE

After the new system is installed and conversion is complete, the system is said to be in production.
During this post implementation stage, the system will be reviewed by both users and technical
specialists to determine how well it has met its original objectives and to decide whether any
revisions or modifications are in order.

After the system has been fine-tuned, it must be maintained while it is in production to correct errors,
meet requirements, or improve processing efficiency. Changes in hardware, software, documentation,
or procedures to a production system to correct errors, meet new requirements, or improve processing
efficiency are termed maintenance. The maintenance process is an ongoing activity, one that lasts
the lifetime of the system. In many computer installations a very high percentage of personnel and
effort is dedicated to maintenance. When it comes to making necessary changes, most companies
modify their existing programs instead of developing new ones. Old programs are repeatedly
modified to meet changing needs.

Company surveys show that up to 80 percent of IS budgets is spent on maintenance, the cost of which
varies widely from system to system. The major reason for this huge proportion is that support is the
longest phase in a system’s life cycle. While development takes several months to about three years,
the system is expected to yield benefits over many years. Systems analysts will always try to design
flexibility into computer systems so that the system can adapt to change. However, there will come a
point at which redevelopment is necessary, for example, where hardware upgrades or the need for
new software make radical change necessary.

ALTERNATIVE METHODS FOR SYSTEMS DEVELOPMENT

Systems differ in terms of their size and technological complexity and in terms of the organizational
problems they are meant to solve. A number of systems building approaches have been developed to
deal with these differences. This section describes two alternative methods: the traditional systems
life cycle, and prototyping.

6
THE TRADITIONAL SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
The systems life cycle is the oldest method for building information systems. Systems development is
divided into formal stages, as illustrated in the figure.

The systems life cycle methodology maintains a formal division of labor between end users and
information systems specialists. Technical specialists, such as systems analysts and programmers, are
responsible for much of the systems analysis, design, and implementation work; end users are limited
to providing information requirements. The life cycle also emphasizes formal specifications and
paperwork, so many documents are generated during the course of a systems project.

The systems life cycle is still used for building large complex systems that require a rigorous and
formal requirements analysis, predefined specifications, and tight controls over the system-building
process. However, the systems life cycle approach can be costly, time-consuming, and inflexible.
Although systems builders can go back and forth among stages in the life cycle, the systems life cycle
is predominantly a “waterfall” approach in which tasks in one stage are completed before work for
the next stage begins. Activities can be repeated, but volumes of new documents must be generated
and steps retraced if requirements and specifications need to be revised which can add to the costs of
development. This encourages freezing of specifications relatively early in the development process.
The life cycle approach is also not suitable for many small desktop systems, which tend to be less
structured and more individualized.

Development managers who must develop large, enterprise wide applications therefore find it useful
to mix and match development methods and tools in order to reduce development time, complexity,
and costs. They are perhaps best considered as options to complement or replace portions of the
SLDC. One of these methods is Prototyping.

PROTOTYPING

Prototyping is the rapid development and testing of working models, or prototypes, of new
applications in an interactive, iterative process. Prototyping, as a development tool, makes the
development process faster and easier, especially for projects where end user requirements are hard to
define. Thus, prototyping makes possible a quicker and more responsive development process called
7
agile systems development. This method is often used for smaller systems where users are unsure of
the functional requirements for their system.

Large business systems still require using a traditional systems development approach, but parts of
such systems can frequently be prototyped. The prototype system is then repeatedly refined until it is
acceptable.

The process of building a preliminary design, trying it out, refining it, and trying again has been
called an iterative process of systems development because the steps required to build a system can
be repeated over and over again. Prototyping is more explicitly iterative than the conventional life
cycle, and it actively promotes system design changes, with each planned iteration, each version more
accurately reflecting users’ requirements.

The prototype is a working version of an information system or part of the system, but it is meant to
be only a preliminary model. The user is encouraged to work with the system to determine how well
the prototype meets his or her needs and to make suggestions for improving the prototype. The
system builder notes all changes the user requests and refines the prototype accordingly. After the
prototype has been revised, it is tested again by the users. This process continues until the user is
satisfied. The approved prototype then becomes an operational prototype that furnishes the final
specifications for the application. Once operational, the prototype will be further refined until it
conforms precisely to users’ requirements. Once the design has been finalized, the prototype can be
converted to a polished production system.

Prototyping is most useful when there is some uncertainty about requirements or design solutions and
often used for designing an information system’s end-user interface (the part of the system with
which end users interact, such as online display and data entry screens, reports, or Web pages). It
promotes close working relationship between systems developers and users and helps clarify user
requirements. It is more likely to produce systems that fulfill user requirements.

However, rapid prototyping can gloss over essential steps in systems development. If the completed
prototype works reasonably well, management may not see the need for reprogramming, redesign, or
full documentation and testing to build a polished production system. Some of these hastily
constructed systems may not easily accommodate large quantities of data or a large number of users
in a production environment.