CHAPTER THREE

THE SYSTEMS DEVELOPMENT LIFE CYCLE

The systems development life cycle (SDLC) is the process of understanding how an
information system (IS) can support business needs, designing the system, building it,
and delivering it to users. Provides overall framework for managing systems
development process. The series of steps used to mark the phases of development for
an information system. Provides a comprehensive formal framework for designing and
developing systems for the effective and efficient processing of information.
In many ways, building an information system is similar to building a house. First, the
house (or the information system) starts with a basic idea. Second, this idea is
transformed into a simple drawing that is shown to the customer and refined (often
through several drawings, each improving on the other) until the customer agrees that
the picture depicts what he or she wants. Third, a set of blueprints is designed that
presents much more detailed information about the house (e.g., the type of water
faucets, where the telephone jacks will be placed). Finally, the house is built following
the blueprints and often with some changes and decisions made by the customer as
the house is erected.

The Generic System Development Model.

Figure 3.1 The generic system development model

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. In

1|Page
this phase the organization total information system need are identified, organized,
arranged and prioritized. It has two steps:
1. Project initiation in 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 that generated the request (called the project sponsor) to conduct a
feasibility analysis.
2. 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. Once the project is approved, it enters project
management. During project management, the project manager creates a work plan,
staffs the projects, and puts techniques in place to help the project team control and
direct the project through the entire SDLC. The primary output in the planning phase is
system request and 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. Develop analysis strategy- an analysis strategy is developed to guide the project

team’s efforts. Such a strategy usually includes an analysis of the current system
(called the as-is system) and its problems, and then ways to design a new system
(called the to-be system).

2. Requirements gathering-through interviews or questionnaires gather information

on what the system should do from as many sources as possible. 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
2|Page
 describes how the business will operate if the new system were developed. The set
of models typically includes models that represent the data and processes
necessary to support the underlying business process.

3. Develop system proposal-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)
that decide whether the project should continue to move forward. The primary
output from the analysis phase is the system proposal.

Design
The design phase decides how the system will operate, in terms of the hardware,
software, and network infrastructure; 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 were 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. Develop design strategy. This clarifies whether the system will be developed by the
company’s own programmers, whether it will be outsourced to another firm (usually
a consulting firm), or whether the company will buy an existing software package.

2. Develop architecture design. This describes the development of the basic

architecture design for the hardware, software, and network infrastructure that will
be used. In most cases, the system will add or change the infrastructure that already
exists in the organization. The interface design specifies how the users will move
through the system (e.g., navigation methods such as menus and on-screen
buttons) and the forms and reports that the system will use.
3. Develop database and file specifications. These define exactly what data will be
stored and where they will be stored.
4. Develop program design this 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 handed to 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. The primary
output from design phase is the system specification.

Implementation
The final phase in the SDLC is the implementation phase, during which the system is

3|Page
actually built (or purchased, in the case of a packaged software design). 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. The system is built and tested to ensure it performs as

designed. Since the cost of bugs can be immense, testing is one of the most critical
steps in the implementation. Most organizations spend more time and attention on
testing than on writing the programs in the first place.

2. System installation. Installation is the process by which the old system is turned off
and the new one is turned on. It may include a direct cutover approach (in which the
new system immediately replaces the old system), a parallel conversion approach
(in which both the old and new systems are operated for a month or two until it is
clear that there are no bugs in the new system), or a phased conversion strategy (in
which the new system is installed in one part of the organization as an initial trial
and then gradually installed in others). One of the most important aspects of
conversion is the development of a training plan to teach users how to use the new
system and help manage the changes caused by the new system.

3. Establish a support plan. 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. It includes maintenance, recovery,
enhancement and end user support. The primary output from the implementation
phase is installed system.

Systems Development Methodologies

A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of
steps and deliverables). A system development methodology refers to the framework
that is used to structure, plan, and control the process of developing an information
system. System development methodology is a standard process followed in an
organization to conduct all steps necessary to analyze, design, implement and maintain
information system. A wide variety of such frameworks have evolved over the years,
each with its own recognized strengths and weaknesses. In the following sections,
three major categories of systems development methodologies explained that have
evolved over time: Structured Design, Rapid Application Development (RAD), and Agile
Development.

Structured Design
The first category of systems development methodologies is called structured design.

4|Page
These methodologies became dominant in the 1980s, replacing the previous ad-hoc
and undisciplined approach. Structured design methodologies adopt a formal
step-by-step approach to the SDLC that moves logically from one phase to the next.
Structured design also introduced the use of formal modeling or diagramming
techniques to describe a system’s basic business processes and the data that support
them. Structured design includes waterfall development and parallel development.

Waterfall Development The original structured design methodology (that is still used
today) is waterfall development. With waterfall development-based methodologies, the
analysts and users proceed sequentially from one phase to the next. This methodology
is called waterfall development because it moves forward from phase to phase in the
same manner as a waterfall. Although it is possible to go backward in the SDLC (e.g.,
from design back to analysis), it is extremely difficult (imagine yourself as a salmon
trying to swim upstream in a waterfall).

The two key advantages of waterfall development-based methodologies are that

system requirements are identified long before programming begins and changes to the
requirements are minimized as the project proceeds. The two key disadvantages are
that the design must be completely specified before programming begins and a long
time elapses between the completion of the system proposal in the analysis phase and
the delivery of the system.

Fig. 3.2 waterfall development

Parallel Development The parallel development-based methodologies attempt to

5|Page
address the long time interval between the analysis phase and the delivery of the
system. Instead of doing the design and implementation in sequence, a general design
for the whole system is performed, and then the project is divided into a series of
distinct sub projects that can be designed and implemented in parallel. Once all
subprojects are complete, there is a final integration of the separate pieces, and the
system is delivered. The primary advantage of these methodologies is that the schedule
time required to deliver a system is shortened; thus, there is less chance of changes in
the business environment causing rework. The approach still suffers from problems
caused by lengthy deliverables. It also adds a new problem: sometimes the subprojects
are not completely independent; design decisions made in one subproject may affect
another, and the end of the project may involve significant integration challenges.

Fig. 3.3 parallel development methodology

Rapid Application Development (RAD)
The second system development methodology category is rapid application
development (RAD) based methodologies. These are a newer class of system
development methodologies that emerged in the 1990s in response to both structured
design methodology weaknesses. RAD based methodologies adjust the SDLC phases
to get some part of the system developed quickly and into the hands of the users. In

6|Page
this way, the users can better understand the system and suggest revisions that bring
the system close to what is needed.

Most RAD-based methodologies recommend that analysts use special techniques and
computer tools to speed up the analysis, design, and implementation phases, such as
CASE (computer-aided software engineering) tools JAD (joint application design)
sessions, fourth-generation/visual programming languages that simplify and speed up
programming, and code generators that automatically produce programs from design
specifications. One possible subtle problem with RAD-based methodologies, however,
is managing user expectations. As systems are developed more rapidly and users gain
a better understanding of information technology, user expectations may dramatically
increase and system requirements expand during the project. This was less of a
problem with structured design methodologies where the system requirements, once
determined, were allowed only minimal change. RAD includes phased development,
prototyping and throwaway prototyping

Phased Development The phased development-based methodologies break the overall

system into a series of versions that are developed sequentially. The analysis phase
identifies the overall system concept, and the project team, users, and system sponsor
then categorize the requirements into a series of versions. The most important and
fundamental requirements are bundled into the first version of the system. The analysis
phase then leads into design and implementation, but only with the set of requirements
identified for version 1

Plannin
g Analys
is

Analys
is Design

Implem
entatio
Analys n
is

Design
System
version
1
Analys Implem
is entatio
n

7|Page Design

System
Implem version
entatio 2
Figure 3.4 phased development methodology.

Once version 1 is implemented, work begins on version 2. Additional analysis is

performed on the basis of the previously identified requirements and combined with
new ideas and issues that arose from users’ experience with version 1. Version 2 then is
designed and implemented, and work immediately begins on the next version. This
process continues until the system is complete. Phased development-based
methodologies have the advantage of quickly getting a useful system into the hands of
the users. The major drawback to phased development is that users begin to work with
systems that are intentionally incomplete. It is critical to identify the most important and
useful features and include them in the first version while managing users’ expectations
along the way.

Prototyping The prototyping-based methodologies perform the analysis, design, and

implementation phases concurrently, and all three phases are performed repeatedly in a
cycle until the system is completed. The first prototype is usually the first part of the
system that the user will use. This is shown to the users and the project sponsor, who
provide reaction and comments. This feedback is used to reanalyze, redesign, and
reemployment a second prototype that provides a few more features. This process
continues in a cycle until the analysts, users, and sponsor agree that the prototype
provides enough functionality to be installed and used in the organization. After the
prototype (now called the “system”) is installed, refinement occurs until it is accepted
as the new system. The key advantage of a prototyping-based methodology is that it
very quickly provides a system for the users to interact with, even if it is not initially
ready for widespread organizational use.

8|Page
Fig.3.5 Prototyping

Throwaway Prototyping Throwaway prototyping-based methodologies are similar to the

prototyping-based methodologies in that they include the development of prototypes;
however, throwaway prototypes are done at a different point in the SDLC. The
throwaway prototyping-based methodologies have a relatively thorough analysis phase
that is used to gather information and to develop ideas for the system concept. Many of
the features suggested by the users may not be well understood, however, and there
may be challenging technical issues to be solved. Each of these issues is examined by
analyzing, designing, and building a design prototype.

A design prototype is not a working system; it is a product that represents a part of the
system that needs additional refinement, and it contains only enough detail to enable
users to understand the issues under consideration. Once the issues are resolved, the
project moves into design and implementation. At this point, the design prototypes are
thrown away, which is an important difference between this approach and prototyping,
in which the prototypes evolve into the final system.

9|Page
 Fig.3.6 Throwaway prototyping

Agile Development
A third category of systems development methodologies is still emerging today: Agile
Development. These programming-centric methodologies have few rules and practices,
all of which are fairly easy to follow. They focus on streamlining the SDLC by eliminating
much of the modeling and documentation overhead and the time spent on those tasks.
Instead, projects emphasize simple, iterative application development. Examples of
Agile Development methodologies include extreme programming etc. To illustrate an
agile development methodology, we describe extreme programming in the next section.
Typically, extreme programming is used in conjunction with object-oriented
programming languages.

Extreme Programming Extreme programming (XP) is founded on four core values:

communication, simplicity, feedback, and courage. These four values provide a
foundation XP developers use to create any system. First, the developers must provide
rapid feedback to the end users on a continuous basis. Second, XP requires developers
to follow the KISS (Keep It Simple, Stupid) principle. Third, developers must make
incremental changes to grow the system and they must embrace change, not merely
accept it. Fourth, developers must have a quality first mentality.

Selecting the Appropriate System Development Methodology

Since there are many methodologies, the first challenge faced by analysts is to select
which methodology to use. Choosing a methodology is not simple, because no one
methodology is always best (if it were, we’d simply use it everywhere!). One system
development methodology is not necessarily suitable for use by all projects. Each of the
available methodologies is best suited to specific kinds of projects, based on various
technical, organizational, project and team considerations.
Clarity of User Requirements- When the user requirements for what the system should
do are unclear, it is difficult to understand them by talking about them and explaining
them with written reports. Users normally need to interact with technology to really
understand what the new system can do and how to best apply it to their needs. The
RAD methodologies of prototyping and throwaway prototyping are usually more
appropriate when user requirements are unclear because they provide prototypes for
users to interact with early in the SDLC. Agile development may also be appropriate if
on-site user input is available.

Familiarity with Technology-When the system will use new technology with which the
analysts and programmers are not familiar, applying the new technology early in the

10 | P a g e
methodology will improve the chance of success. If the system is designed without
some familiarity with the base technology, risks increase because the tools may not be
capable of doing what is needed. Throwaway prototyping-based methodologies are
particularly appropriate for a lack of familiarity with technology because they explicitly
encourage the developers to create design prototypes for areas with high risks. Phased
development-based methodologies are good as well because they create opportunities
to investigate the technology in some depth before the design is complete. While one
might think prototyping based methodologies would also be appropriate, they are much
less so, because the early prototypes that are built usually only scratch the surface of
the new technology. Usually, it is only after several prototypes and several months that
the developers discover weaknesses or problems in the new technology.

System Complexity- Complex systems require careful and detailed analysis and design.
Throwaway prototyping based methodologies are particularly well suited to such
detailed analysis and design, but prototyping based methodologies are not. The
traditional structured design based methodologies can handle complex systems, but
without the ability to get the system or prototypes into users’ hands early on, some key
issues may be overlooked. Although the phased development based methodologies
enable users to interact with the system early in the process, we have observed that
project teams who follow these methodologies tend to devote less attention to the
analysis of the complete problem domain than they might if they were using other
methodologies.

System Reliability- System reliability is usually an important factor in system

development. After all, who wants an unreliable system? However, reliability is just one
factor among several. For some applications reliability is truly critical (e.g., medical
equipment, missile control systems), while for other applications it is merely important
(e.g., games, Internet video). Throwaway prototyping-based methodologies are most
appropriate when system reliability is a high priority, because they combine detailed
analysis and design phases with the ability for the project team to test many different
approaches through design prototypes before completing the design.
Prototyping-based methodologies are generally not a good choice when reliability is
critical because they lack the careful analysis and design phases that are essential for
dependable systems.

Short Time Schedules -Projects that have short time schedules are well suited for
RAD-based methodologies because those methodologies are designed to increase the
speed of development. Prototyping and phased development-based methodologies are
excellent choices when timelines are short because they best enable the project team
to adjust the functionality in the system on the basis of a specific delivery date. If the

11 | P a g e
 project schedule starts to slip, it can be readjusted by removing functionality from the
version or prototype under development. Waterfall based methodologies are the worst
choice when time is at a premium because they do not allow for easy schedule
changes.
Ability to develop system Waterfall Parallel Phased prototyping Throwaway
prototyping
With unclear user Poor Poor Good Excellent Excellent
requirement
With unfamiliar Poor Poor Good Poor Excellent
technology
Complex system Good Good Good Poor Excellent
Reliable Good Good Good Poor Excellent
With a short time Poor Good Excellent Excellent Good
schedule
Approaches to system development
There are two approaches to Information system development:
A. Process-oriented and

B. Data-oriented

A. Process-oriented approach
Traditionally, Systems Analysts designed an Information System based on what the
system was meant to do, such as billing or inventory control or, in our example,
producing results statements.
This meant that the focus was on outputs and processing logic – or, in other words, on
the flow, use and transformation of data. The data used as inputs were seen as
important also, but secondary to (not as important as) the application. Each system
would contain its own files and data storage areas (e.g. a payroll system and a system
for scheduling classes & who will teach them would each have their own sets of data
for teachers in the university) The data in each system would match the specifications
for that system only. Each system was considered (looked at) separately. The analysis
involved creating drawings/diagrams that show how the data moves around the system
and where it is stored in between flows.

B. Data-oriented approach
Over time, the approach changed to being a more data-oriented. This was a response to
the problems above. This approach tends to focus on how the data should be
represented / organized, independently of where and how data are used in the system.
- A data model is produced – this describes the data and relationships between
the data. Business rules define how the organization deals with the data.

12 | P a g e
 - With this approach, databases are designed around subjects – such as
customers, suppliers, parts (or, in our university example, teachers, students, and
courses). This lets us use the same databases for many different applications.
- This led to the modern approach that usually includes a database for storing data
and applications that deal with getting and retrieving the data from this one
central location.
The diagram in figure 3.7 below shows the essential difference between these two
approaches.
 Suppose that a university has an application for Registration of students and also
an application for scheduling classes. Each of these applications would use data
about the available Courses.
 Note how the Courses Data in this example is duplicated for the Process-oriented
approach – because the focus is on the two different systems.
 The Courses Data exists in only one database for the Data-oriented approach –
because the focus is on where & how the data is stored, and then the systems
are designed around this.

Process-oriented approach

Registration Class
System Scheduling
System

Student Data Courses Courses Teachers

Data Data Data

Data-oriented approach

Registration Class
System Scheduling
System

Student Data Courses Teachers

Data Data

Figure 3.7 - Process-oriented & Data-oriented approach - the relationships between applications and data

13 | P a g e
Key difference between the process-oriented and data-oriented approach to system
development
Characteristics Processed- oriented Data –oriented
approach approach
System focus What the system is Data that the system
supposed to do &when needs to operate
Data organization Data files designed for Data file designed for the
each individual enterprise
application
State of the data Much uncontrolled Limited, controlled
duplication duplication

Object-Oriented Analysis and Design (OOAD)

A more recent approach to system development that is becoming more and more
popular is object-oriented analysis and designed (OOAD) which is system development
approach and techniques based on object rather than process or data. Object-oriented
programming became popular 1990s with the increased use of Smalltalk, C++, and
other new object-oriented programming languages. The object oriented-approach
combines data and process in to single entities called object. Object usually
corresponds to the real things in an information system deals with such as supplier,
customer, contracts and rental agreements.

The goal of OOAD is to make system elements more reusable, thus improve the
productivity of system development and analysis. Another key idea behind
object-orientation is that inheritance. Objects are organized in to object classes-which
are groups of objects sharing structural and behavioral characteristics. Inheritance
allows the creation of new classes that share some of the characteristics of existing
classes. In general the primary task of object-oriented analysis is identifying objects,

14 | P a g e
defining their structure and behavior and defining their relationships. The
Object-oriented SDLC model is characterized by its attempt to model real-world entities
(such as company, account, and employee) into abstract computer software objects
and all the interactions that can take place between those objects. Repetition

Computer Aided Software Engineering (CASE)

Computer aided engineering (CASE) refers to automated software tools used by system
analyst to develop information system. These tools can be used to automate or support
activities throughout the system development process with the objective of increasing
productivity and improving the overall quality of the systems.

Components of computer aided software engineering (CASE)

Diagramming tools: that enables system process, data and control structure to be
represented graphically.
Computer display and report generation: that helps prototype how systems (look and fill
to users)
Analysis tools: that automatically checks for incomplete, inconsistent or incorrect
specifications, diagrams and reports.
Central repository: that enables the integrated storage of specification, diagram, reports
and project management project in formation.
Documentation generators: that helps to produce both user and technical
documentation in standard format.
Code generators: that enables the automatic generation of program and database
definition code directly from the design document, diagrams, forms and reports.

15 | P a g e