System development life cycle

The systems development life cycle (SDLC) is the process of determining how an
information system (IS) can support business needs, designing the system, building
it, and delivering it to users.

The key person in the SDLC is the systems analyst, who analyzes the business situation,
identifies opportunities for improvements, and designs an information system to implement the
improvements. It is important to remember that the primary objective of the systems analyst is
not to create a wonderful system. The primary goal is to create value for the organization, which
for most companies means increasing profits.

THE SYSTEMS ANALYST

The systems analyst plays a key role in information systems development projects. The systems
analyst works closely with all project team members so that the team develops the right system
in an effective way. Systems analysts must understand how to apply technology to solve business
problems. In addition, systems analysts may serve as change agents who identify the
organizational improvements needed,
design systems to implement those changes, and train and motivate others to use the systems.
Understanding what to change, knowing how to change it, and convincing others of the need for
change require a wide range of skills. These skills can be broken down into six major categories:
technical, business, analytical, interpersonal, management, and ethical.
Analysts must have the technical skills to understand the organization’s existing technical
environment, the new system’s technology foundation, and the way in which both can be fit into
an integrated technical solution. Business skills are required to understand how IT can be applied
to business situations and to ensure that the IT delivers real business value. Analysts are
continuous problem solvers at both the project and the organizational level, and they put their
analytical skills to the test regularly. Often, analysts need to communicate effectively, one-on-
one with users and business managers (who often have little experience with technology) and
with programmers (who often have more technical expertise than the analyst does).

The systems analyst role focuses on the IS issues surrounding the system. This person develops
ideas and suggestions for ways that IT can support and improve business processes, helps design
new business processes supported by IT, designs the new information system, and ensures that
all IS standards are maintained. The systems analyst will have significant training and experience
in analysis and design and in programming.

The business analyst role focuses on the business issues surrounding the system. This person
helps to identify the business value that the system will create, develops ideas for improving the
business processes, and helps design new business processes and policies. The business analyst
will have business training and experience, plus knowledge of analysis and design. The
requirements analyst role focuses on eliciting the requirements from the stakeholders associated
with the new system. As more organizations recognize the critical role that complete and
accurate requirements play in the ultimate success of the system, this specialty has gradually
evolved. Requirements analysts understand the business well, are excellent communicators, and
are highly skilled in an array of requirements elicitation techniques (discussed in Chapter 3).

The infrastructure analyst role focuses on technical issues surrounding the ways the system will
interact with the organization’s technical infrastructure (hardware, software, networks, and
databases). This person ensures that the new information system conforms to organizational
standards and helps to identify infrastructure changes that will be needed to support the system.
The infrastructure analyst will
have significant training and experience in networking, database administration, and various
hardware and software products. Over time, an experienced infrastructure analyst may assume
the role of software architect, who takes a holistic view of the organization’s entire IT
environment and guides application design decisions within that context.

The change management analyst role focuses on the people and management issues surrounding
the system installation. This person ensures that adequate documentation and support are
available to users, provides user training on the new system, and develops strategies to overcome
resistance to change. The change management analyst will have significant training and
experience in organizational behavior and specific expertise in change management.
The project manager role ensures that the project is completed on time and within budget and
that the system delivers the expected value to the organization. The project manager is often a
seasoned systems analyst who, through training and experience, has acquired specialized project
management knowledge and skills.

THE SYSTEMS DEVELOPMENT LIFE CYCLE

Building an information system using the SDLC follows a similar set of four fundamental
phases: planning, analysis, design, and implementation. Each phase is itself composed of a series
of steps, which rely on techniques that produce deliverables (specific documents and files that
explain various elements of the system).

The SDLC is a process of gradual refinement. The deliverables produced in the analysis phase
provide a general idea what the new system will do. These deliverables are used as input to the
design phase, which then refines them to produce a set of deliverables that describes in much
more detailed terms exactly how the system should be built.
These deliverables in turn are used in the implementation phase to guide the creation of the
actual system.

Planning
The planning phase is the fundamental process of understanding why an information system
should be built and determining how the project team will go about
building it. It has two steps:
1. During project initiation, the system’s business value to the organization is identified—how
will it lower costs or increase revenues? Most ideas for new systems come from outside the IS
area (from the marketing department, accounting department, etc.) in the form of a system
request. A system request presents a brief summary of a business need, and it explains how a
system that supports the
need will create business value. The IS department works together with the person or department
generating the request (called the project sponsor) to conduct a feasibility analysis. The
feasibility analysis examines key aspects of the proposed project:
■ The technical feasibility (Can we build it?)
■ The economic feasibility (Will it provide business value?)
■ The organizational feasibility (If we build it, will it be used?)
The system request and feasibility analysis are presented to an information systems approval
committee (sometimes called a steering committee), which decides whether the project should be
undertaken.
2. Once the project is approved, it enters project management. During project management, the
project manager creates a work plan, staffs the project, and puts techniques in place to help the
project team control and direct the project through the entire SDLC. The deliverable for project
management is a
project plan that describes how the project team will go about developing the system.
Analysis
The analysis phase answers the questions of who will use the system, what the system will do,
and where and when it will be used. During this phase, the project team investigates any current
system(s), identifies improvement opportunities, and develops a concept for the new system.
This phase has three
steps:

1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy
usually includes a study of the current system (called the as-is system) and its problems,
and envisioning ways to design a new system (called the to-be system).
2. The next step is requirements gathering (e.g., through interviews, group workshops, or
questionnaires). The analysis of this information—in conjunction with input from the
project sponsor and many other people—leads to the development of a concept for a new
system. The system concept is then used as a basis to develop a set of business analysis
models that describes how the business will operate if the new system were developed.
The set typically includes models that represent the data and processes necessary to
support the underlying business
process.
3. The analyses, system concept, and models are combined into a document called the
system proposal, which is presented to the project sponsor and other key decision makers
(e.g., members of the approval committee) who will decide whether the project should
continue to move forward.
 The system proposal is the initial deliverable that describes what business requirements
the new system should meet. Because it is really the first step in the design of the new
system, some experts argue that it is inappropriate to use the term analysis as the name
for this phase; some argue a better name would be analysis and initial design. Because
most organizations continue to use the name analysis for this phase, we will use it in this
book as well. It is important to remember, however, that the deliverable from the analysis
phase is both an analysis and a high-level initial design for the new system.
Design
The design phase decides how the system will operate in terms of the hardware, software,
and network infrastructure that will be in place; the user interface, forms, and reports that
will be used; and the specific programs, databases, and files that will be needed.
Although most of the strategic decisions about the system are made in the development of
the system concept during the analysis phase, the steps in the design phase determine
exactly how the system will operate. The design phase has four steps:
1. The design strategy must be determined. This clarifies whether the system will be
developed by the company’s own programmers, whether its development will be
outsourced to another firm (usually a consulting firm), or whether the company will buy
an existing software package.
2. This leads to the development of the basic architecture design for the system that
describes the hardware, software, and network infrastructure that will be used. In most
cases, the system will add to or change the infrastructure that already exists in the
organization. The interface design specifies how the users will move through the system
(e.g., by navigation methods such as menus and on-screen buttons) and the forms and
reports that the system will use.

3. The database and file specifications are developed. These define exactly what
data will be stored and where they will be stored.
4. The analyst team develops the program design, which defines the programs that need to be
written and exactly what each program will do. This collection of deliverables (architecture
design, interface design, database and file specifications, and program design) is the system
specification that is used
by the programming team for implementation. At the end of the design phase, the feasibility
analysis and project plan are reexamined and revised, and another decision is made by the
project sponsor and approval committee about whether to terminate the project or continue.

Implementation
The final phase in the SDLC is the implementation phase, during which the system is
actually built (or purchased, in the case of a packaged software design and installed). This
is the phase that usually gets the most attention, because for most systems it is the longest
and most expensive single part of the development process.
This phase has three steps:
1. System construction is the first step. The system is built and tested to ensure that it
performs as designed. Since the cost of fixing bugs can be immense, testing is one of the
most critical steps in implementation. Most organizations spend more time and attention
on testing than on writing the programs in the first place.
2. The system is installed. Installation is the process by which the old system is turned off
and the new one is turned on. There are several approaches that may be used to convert
from the old to the new system. One of the most important aspects of conversion is the
training plan, used to teach users how to use the new system and help manage the
changes caused by the new system.
3. The analyst team establishes a support plan for the system. This plan usually includes a
formal or informal post-implementation review, as well as a systematic way for
identifying major and minor changes needed for the system.
PROJECT IDENTIFICATION AND INITIATION
Where do project ideas come from? A project is identified when someone in the
organization identifies a business need to build a system. Examples of business needs
include supporting a new marketing campaign, reaching out to a new type of customer, or
improving interactions with suppliers. Sometimes, needs arise from some kind of “pain”
within the organization, such as a drop in market share, poor customer service levels,
unacceptable product defect rates, or increased competition. New business initiatives and
strategies may be created and a system to
support them is required, or a merger or acquisition may require systems to be integrated.
Business needs also can surface when the organization identifies unique and competitive
ways of using IT. Many organizations keep an eye on emerging technology, which is
technology that is still being developed and not yet viable for widespread business use.
For example, if companies stay abreast of technological advances such as cloud
computing, RFID (radio frequency identification), or Web 2.0, they can develop business
strategies that leverage the capabilities of these technologies and introduce them into the
marketplace as a first mover. Ideally, companies
can take advantage of this first mover position by making money and continuing to
innovate while competitors trail behind.
Today, many new information system projects grow out of business process management
(BPM) initiatives. BPM is a methodology used by organizations to continuously improve
end-to-end business processes. Business process management can be applied to internal
organizational processes and to processes spanning multiple business partners. By
studying and improving their underlying business processes, organizations can achieve
several important benefits, including:
■ enhanced process agility, giving the organization the ability to adapt more rapidly and
effectively to a changing business environment;
■ improved process alignment with industry “best practices”; and
■ increased process efficiencies as costs are identified and eliminated from process
workflows.
When a strong business need for an information system is recognized, often as a result of
BPM, a person (or group) who has an interest in the system’s success typically steps
forward. We call this person (or group) the project sponsor. Often, the project sponsor
develops the initial vision of the new system. The project sponsor works throughout the
SDLC to make sure that the project is moving in the right direction from the perspective
of the business and serves as the primary point of contact for the project team. Usually,
the sponsor of the project is from a business function
such as marketing, accounting, or finance; however, members of the IT area also can
sponsor or cosponsor a project. The business need drives the high-level business
requirements for the system.
Business requirements describe the reasons for developing the system and outline
the benefits it will provide the organization. These requirements need to be explained at a
high level so that the approval committee and, ultimately, the project team understand
what the business expects from the final product. Business requirements summarize the
features and capabilities the information system will have to include, such as the ability
to collect customer orders online or the ability for suppliers to receive inventory
information as orders are placed and sales are made.
The project sponsor has the insights needed to determine the business value that will be
gained from the system, in both tangible and intangible ways. Tangible
value can be quantified and measured easily (e.g., 2% reduction in operating costs).
An intangible value results from an intuitive belief that the system provides important,
but hard-to-measure, benefits to the organization (e.g., improved customer
service, a better competitive position).
Once the project sponsor identifies a project that meets an important business need and he
or she can identify the business requirements and business value of the system, it is time
to formally initiate the project. In most organizations, project initiation begins by
preparing a system request.
System Request
A system request is a document that describes the business reasons for building a system
and the value that the system is expected to provide. The project sponsor usually
completes this form as part of a formal system project selection process within the
organization. Most system requests include five elements: project sponsor, business need,
business requirements, business value, and special issues.
Element Description Example
Project Sponsor The person who initiates Several members of the
the project and who serves finance department
as the primary point of Vice president of
contact for the marketing
project on the business side IT manager
Steering committee
CIO
CEO
Business Need the business-related reason increase sales
for initiating the system Improve market share
Improve access to
information
Improve customer
service
Decrease product defects
Streamline supply
acquisition
processes
Business The business capabilities that the Provide onIine access to
Requirements system will provide information
Capture customer
demographic
information
Include product search
capabilities
Produce management
reports
Include online user support
Business Value The benefits that the 3% increase in sales
system will create for the 1% increase in market
organization share
Reduction in headcount
by 5*FTEs
$200,000 cost savings
from
decreased supply costs
$150,000 savings from
removal
of existing system
Special Issues or Issues that are relevant to Government-mandated deadline
Constraints the implementation of the for May 30
system that need to be System needed in time for the
known by the approval Christmas holiday season
committee Top-level security clearance
needed
by project team to work with
data