CHAPTER THREE: SYSTEM DEVELOPMENT LIFE CYCLE

(SDLC)
SDLC can be defined as the step-by-step process that many organizations follow during system
analysis and design, which is problem solving procedure for examining an existing information
system and improving it or the development of new ones. And it help us to understanding how an
information system (IS) can support business needs, designing the system, building it, and
delivering it to users. The number of phases or steps may vary from one company to another, and
even the name of the process may differ but its purpose is to reduce the risks of developing system.
The basic idea of SDLC is that information system has a life cycle similar to that of any living
organism, and it involves a sequence of activities to be performed in the cycle. A life cycle
methodology is a formalized description of a project picture for the development of an IS.

2.1. The traditional system development life cycle

The development of information system is a multipart process; usually involving many people
within a variety of special skills. The process is traditionally broken down into stages or phases
that deliver several intermediate outputs on the way to the final system. These stages together are
known as the System Development Life Cycle (SDLC).

In the traditional approach to systems development, ‘traditional’ tends to mean unstructured and
somewhat non-specific, and most traditional approaches are based on variations of the waterfall
model. Although the overall picture will probably be familiar, the actual methods of developing
the systems are almost as numerous as the projects themselves. In a typical traditional approach,
three of the stages are as follows:

 Analyze requirements: - In this stage the analyst considers the current system and
investigates any problems associated with it. The users are also interviewed to obtain their
views of the problems and to get their ideas for improvements. Other sources of
information about the system and the new requirements would also be investigated at this
time. The output from this stage would probably be no more than a set of notes put together
by the analyst.
 Specify requirements: - In this stage the analyst considers the information that has been
accumulated, and produces a requirements document. This is likely to be a mix of business
requirements, functional and non-functional requirements and an overview of the proposed
hardware and software. Elements of the physical specification in terms of screens and
printed output reports might also be included.
 Produce high-level design: - The designer would consider the requirements document
and, on that basis, produce a high-level design for the system setting out the database

1|Page
 design, the input and output specifications, the menu structure and the overall program
design and breakdown.

2.2. The generic system development model

In the generic system development model, professional organizations usually follow one of the
two basic models: The waterfall model or the spiral model.

2.2.1. Waterfall model

In the waterfall model, which was originally published in 1970 by Royce? In this model, system
development is broken down into a number of sequential sections or stages represented by boxes,
with each stage being completed before work starts on the following one. The outputs from one
stage are used as inputs to the next. Nowadays, the waterfall model is generally taken to mean any
sequential model divided into consecutive stages and having the attributes of the original model.
The identification and naming of the stages are not fixed, and can be modified to suit particular
project characteristics.

The model has a number of good points. Apart from the sequencing of activities, it addresses
elements of quality management through verification and validation, and configuration
management by base lining products at the end of the stage. It does not have explicit means for
exercising management control on a project, however, and planning, control and risk management
are not covered. Nevertheless, the stage-by-stage nature of the waterfall model and the completion
of products for the end of each stage lend themselves well to project management planning and
control techniques and assist in the process of change control. Many projects still use versions of
the waterfall model, generally with some of the shortcomings of the original one addressed, and
the model is used as the basis for many structured methods. Waterfall models work best when the
level of reworking of products is kept to a minimum and the products remain unchanged after
completion of their ‘stage’. In situations where the requirements are well understood and the
business area in general is not likely to undergo significant business change, the waterfall model
works well. In situations where the business requirements are not well understood and where the
system is likely to undergo radical change, a different approach from that suggested by the
waterfall model may be more appropriate.

This is illustrated by the flow from one stage to the next. The development flows down a number
of successive stages are typically:

 Preliminary investigation (Project Definition)

2|Page
  Implementation
 Maintenance

Phase 1: Preliminary Investigation (Project Definition)

Preliminary investigation also sometimes known as problem definition tries to answer questions
such as: Why do we need a new or improved system? What do we want to accomplish? This stage
determines whether the organization has a problem, proposes alternative solutions, comparing
costs and benefits and finally, submit a preliminary plan to top management with
recommendations. This stage determines the needs of the proposed users of the system, produces
a broad outlines of the system that identifies the activities to be performed, the technology to be
used, and the expected cost of the system. In other words, the preliminary stage defines the
objectives of the system, specifies its scope and develops a working project plan. Problem
definition is the first step in the systems development life cycle because it makes little sense to try
to solve a problem you do not understand.

Phase 2: Systems Analysis

After a clear problem definition, the analysis phase begins. The objective of this phase is to
determine exactly what must be done to solve the problem. It involves gathering data, analyzing
the data, and writing a report. In gathering data, there are a handful tools that systems analysts
use, most of them not terribly technical. They include written documents, interview, questionnaires
and observation. Once the data is gathered, you need to come to grip with it and analyze it. Many
analytical tools, or modeling tools, are available, which enable a systems analyst to present
graphic, or pictorial, representations of a system. Once you have completed the analysis, you need
to document this phase so that it can be reported to top managers of the firm. This report to
management should have three parts, that is it should explain how existing system works, explain
the problems with the existing system and describe the requirements for the new system and make
recommendations on what to do next. Analysis ends with a detailed set of requirements
specifications that clearly define what the system must do.

Phase 3: Design the system

Given the approved system proposal from the decision analysis phase, you can finally design the
target system. The purpose of the design phase is to transform the business requirements statement
from the analysis phase into design specification for construction. In other words, the design phase
addresses how technology will be used in the new system. Design requires soliciting ideas and
options from users, vendors, and IT specialists. It also requires adherence to internal technical
design standards that ensure completeness, usability, reliability, performance, and quality. Once
analysis is completed, the analyst knows what must be done to solve the problem. However, the
objective of design phase is to determine how the problem will be solved. Thus, analysis is

3|Page
concerned with doing the right thing, but design is concerned with doing the things right. During
design the analyst’s focus shifts from the logical to the physical. The processes are converted to
manual procedures or computer programs. Data elements are grouped to form physical data
structures, screens, reports, files, and databases.

The design of an IS is the overall plan or model for the system. It consists of all of the specifications
that give the system its form and structure. The design of an IS can be broken down in to:

 Conceptual (logical) design,

Phase 4: Systems Development

After the design specifications, the next activity is creating or constructing and testing system
components for that design to build the functional system. The purposes of the construction phase
are:

1. To build and test a system that fulfills business requirements and design specifications,
2. To implement the interfaces between the new system and the existing systems because
there is always an existing system, regardless of whether it currently uses a computer. So,
the new system must be integrated with other IS,
3. Installation of new hardware and software, and
4. Preparation of end-user documentation and training of users.

One important aspect of systems development is conducting tests of both individual system
components as well as the overall system. Once tested, a system is ready for implementation.

The systems test programmers are derived from the requirements specification. Thus, a well-
designed test plan ensures that the system meets the user’s needs.

Phase 5: Implementation

New systems represent a departure from the way an organization is currently doing its operation.
Therefore, the analyst must provide for a smooth transition from the old system to the new system
and help users cope with normal start-up problems. At this stage the system is released to the end
users and the analyst’s formal responsibility ends, although additional end-user training may be
necessary.

To provide a smooth transition to the new system, a convention plan should be prepared. This plan
may call for an abrupt switch where the old system is terminated and replaced by the new 30

4|Page
system on a specific date. Alternatively, the old and new systems may run in parallel until the new
system has been deemed acceptable to replace the old system.

The implementation phase also involves training individuals that will use the final system and
developing documentation to aid system users. This stage involves system activities like
acquisition, software development, training, testing, documentation and conversion.

Phase 6: Maintaining the system

Even with the conversion accomplished and the users trained, the system won’t just run itself.
There is a sixth and never ending phase in which the system implemented must be evaluated and
monitored to ensure that it is successful. Maintenance is not only to keep the system functioning
at the objective of an acceptable level but also updating and upgrading the system to keep pace
with new products, services, customers, government regulations and other requirements.

For example, using Figure, the product design products are completed and accepted before being
used as inputs to the work of the next stage, development, and so on.

Preliminary
investigation
(Project
Definition)

Analysis

Design

Development

Implementation

Maintenance

2.2.2. Spiral model

The Spiral model of systems development proposed by Barry Boehm, has become popular for
iterative system development. The spiral model follows the same breakdown into stages, but takes

5|Page
an incremental approach to systems development. Typically, a system is divided into smaller sub-
sets for development and delivery. This provides functionality to end-users at regular intervals,
rather than at the end of waterfall development. It is also common in iterative development for
highly-skilled developers to model systems with stakeholders, the design and implements them,
rather than assign the stages to different departments or groups. Effective use of spiral approach
to system development can deliver systems quickly and ensure user involvement, especially when
prototypes are part of the development approach.

In contrast to the waterfall approach, the spiral model introduces an evolutionary or iterative
approach to systems development. The waterfall model concentrates on a stage-by-stage process,
with the end products from one stage being finalized before the next stage is begun. This works
reasonably well where the requirements of the system are well understood by the users and the
environment is stable. There are often occasions where the requirements are not well formed or
understood by the users, where it is difficult to specify the requirements, or where it is difficult to
determine how a proposed solution will perform in practice. In this situation, an evolutionary
approach may be appropriate. This involves carrying out the same activities over a number of
cycles in order to clarify the requirements, issues and solutions, and in effect amounts to repeating
the development life cycle several times.

At the centre, the requirements will be poorly understood, and they will be successively refined
with each rotation around the spiral. The total cost of the project will increase as the length of the
spiral increases. The model is divided into four quadrants:

 The top-left quadrant is where the objectives are determined and the alternatives and
constraints identified.
 The top-right quadrant is where the alternatives are evaluated and the various risks are
identified and resolved.
 The bottom-right quadrant is where the development takes place. This in effect covers
the same area as the more conventional waterfall model.
 The bottom-left quadrant is where the next phase or iteration is planned.

The Boehm spiral introduces the important concepts of objective setting, risk management and
planning into the overall cycle. These are all very desirable from a project management point of
view as they apply explicitly to factors that may affect the timely delivery of the system within its
defined constraints.

6|Page
 2.2.3. Problems of system Development Life Cycle

Tasks in system analysis and design require use of standard and prescribed process. If IS
development projects follow no prescribed process, we will have a situation of anarchy or chaos.
And as result each developer uses his/her own tools and methods which makes communication
between team members very difficult. The success or failure of the project depends on the skill
and experience of the project team but if there is no standard process, it may become over budget
and behind schedule.

SDLC suffers from some problems. Some of the major ones are:

 Projects are not integrated: - SDLC usually promotes a narrow project orientation that
leads to fragmentation of effort and uncoordinated systems.
 Slow delivery: - SDLC is a step-by-step process where the whole cycle must be completed
before anything can be delivered. There are no intermediate products other than
specifications and documents.
 Low user involvement: - After the analysis has be conducted to identify the requirements
of the user and users sign of on the project, the rest activity is left to the analyst and other

7|Page
 technical staffs. The users have no connection with the project until it is signed on and
released to the users, which may take a long time. This leads to misunderstandings between
system users and developers about what is to be delivered.
 Systems are Inflexible: - Since activities are performed step by step, any change at one
point affects the whole process. As a result changes will be expensive and infrequent.

2.2.4. Advantages of Using SDLC

Though using SDLC has the above mentioned limitations, using SDLC methodology has several
advantages. The major ones are:

 The method acts as a memory aid: - The environment in which we are living demands
individuals and organization to be effective and efficient otherwise the effect of minor
mistake is very damaging. Therefore, following the SDLC helps analysts to minimize the
risk that key elements or details will be overlooked.
 It enhances communication: - One important feature of SDLC is a consistent set of
documentation standards. Thus, if everyone follows the same approach, then the members
of analysts, design or programming team will find it relatively easy to understand each
other. Even, it will be easy for staffs that join the team after the project has begun.
 Facilitate management control: - The methodology by definition, consist of a set of steps
and well-defined exit criteria, which serves as a milestones or checkpoints and developing
a schedule and a budget.
 It involves problem-solving tools: - Another mark of a good SDLC methodology is that
the tools are compatible, with the output from one step serving as a foundation for
subsequent steps.
 It helps to detect significant errors early: - The cost of a system accelerates as work
progress. If an error is detected early, only the work performed to that point is lost.

On the contrary, if the error is not detected until just before the system is finished, the efforts of
analysts, programmers and other technical professionals might be wasted.

2.2.5. Systems Development Methodologies

A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and
deliverables). There are many different systems development methodologies and each one is
unique because of its emphasis on processes versus data and the order and focus it places on each
SDLC phase. Some methodologies are formal standards used by government agencies, while
others have been developed by consulting firms to sell to clients. Many organizations have their
own internal methodologies that have been refined over the years, and they explain exactly how
each phase of the SDLC is to be performed in that company.

8|Page
All system development methodologies lead to a representation of the system concept in terms of
processes and data; however, they vary in terms of whether the methodology places primary
emphasis on business processes or on the data that supports the business. The open-ended
rectangles in the diagram represent data storage containers; the rounded rectangles represent
activities performed; and the arrows represent activity inputs and outputs.

Process-centered methodologies: - focus first on defining the activities associated with the
system, i.e., the processes. Process-centered methodologies utilize process models as the core of
the system concept. Analysts concentrate initially on representing the system concept as a set of
processes with information flowing into and out of the processes.

Data-centered methodologies: - focus first on defining the contents of the data storage containers
and how the contents are organized. Data-centered methodologies utilize data models as the core
of the system concept. For example, analysts concentrate initially on identifying the data that must
be available to produce.

2.3. Systems development approaches

When organizations develop their new information system or modify the existing information
system, they have to follow the following basic approaches. These approaches are not mutually
exclusive and firms generally employ certain aspects of each approach.

1. Ad hoc Approach: This approach is directed towards solving particular problem or the potential
for integrating applications. In this approach, the analyst does not deal with the overall information
requirements of the firm, instead it pinpoint only the trouble sports. The major advantage of ad
hoc approach is that it is important in certain emergencies and in organizations undergoing rapid
changes. However, this approach is not without a limitation. It is inconsistent with the concept of
planning an information system. Moreover, it could result in redundant and inefficient subsystems
and database that cannot be integrated or linked each other.

2. Data Modeling Approach: Data modeling attempts to develop a common data base model. The
data base should contain all the necessary information to support the operation of the firm, but it
should redundancy. Of course, the approach does not require that all data be stored in one unit, but
physical data base can be stored in several places, but it should be planned to integrate the data
bases. The emphasis of this approach is on establishing linkages within the data base that allows
common up data, common retrieval and common manipulation.

3. Bottom-up approach: Bottom-up approach focuses on the basic transaction processing

9|Page
becomes more complex, it integrates the standalone TPS and to deal with DSS and ESS. It is a
dominating system development strategy because the system development can be made in a logical
revolutionary or step-by-step manner.

4. Top-down approach: This approach attempts to align information system with business
strategies and to involve top management in the information development process. It focuses on
strategies of the firm, data and information and activities necessary to implement the strategy of
an organization. This approach is not a step-by- step process. Top management have its strategy
to develop IS by analyzing the whole company problem unlike bottom-up approach which is a
step-by-step process.

The philosophy underlying the information system development in a certain organization could be
either of the above or a combination of them. Regardless of the underlying philosophy the actual
analysis and design of an information system could be undertaken in either of the following two
ways: Prototype approach or systems development life cycle.

10 | P a g e