The Systems Development Life Cycle (SDLC).

Introduction

 Lecture objectives

At the end of this lecture, the student should be able to:

Reasons for System’s  Investigations and change

When a new or upgraded system is introduced into an organisation, it is usually intended to

support the work already carried out by the organisation. Although the new system may differ
substantially from the existing system, the information being handled, and the main functions of
the system, will remain relatively unchanged. An analysis of the existing system, therefore,
provides a firm basis for the design of the new system.

Other reasons for performing a system investigation include:

 Determining the scope of the project, by evaluating the complexity of the problem and
the effort required to complete it. This information can assist with planning the project
and allocating the necessary resources to it.
 Increasing user confidence by reassuring the users that the analyst fully understands the
nature of the problem and the business operations that the system must carry out.

Some of the aspects that will be investigated include:

 Operations and data - an understanding of the current operations and data will make it
easier to understand the requirements of the new system
 Existing problems - determining what the problems are with the new system ensures that
they will not be replicated in the new system
 System boundaries - determine which business areas are within the scope of the project,
to ensure that effort is not wasted on areas that lie outside the scope of the project, and to
ensure that all relevant areas are included. The system boundaries should be explicitly
stated and agreed with all those concerned.

Note that an investigation of the existing system does not constrain the project team to simply re-
hash the features of the current system. A fresh approach to meeting the system objectives is
taken, and may lead to a complete restructuring of both the business processes and data, in a new
system that is nothing like the old one.

 
 

Impetus for system Change

The idea for change originates in the environment or from within the firm. Environment-based
ideas originate from customers, vendors, government sources, and the like. For example:

 new unemployment compensation regulations may make it necessary to change the

structures.
 Customer complaints about the delivery of orders may prompt an investigation of the
delivery schedule,
 the experience of truck drivers, or the volume of orders to be delivered. When
investigated, each of these ideas may lead to a problem definition as a first step in the
system life cycle process.

Ideas for change may also come from within the organization- top management,

the user   or even the analyst. As an organization changes its operations or faces advances in

computer technology, someone within the organization may feel the need to update

existing applications or improve procedures. Here are some examples:

• An organization  may acquire another organization.

• A local bank may branch into the suburbs.

• A department spending 80 percent of its budget in one month.

• Two departments are doing essentially the same work, and each department head insists the
other department should be eliminated.

• A request for a new form discloses the use of bootleg (unauthorized) forms.

 Serious problems in operations,

 a high rate of labor turnover,
 labor intensive activities and
 high reject rates of finished goods, also prompt top management to initiatean
investigation. Other examples are:

• A report reaches a senior director and they suspect the figures.

• The company comptroller reads an Internal Revenue Service (IRS) audit report and starts
thinking.

• An executive read about decision support systems for sales forecasting and it
gives him an idea.

Many of these ideas lead to further studies by management request, often funneled downward
and carried out by lower management.

User- originated ideas also prompt initial investigations. For example, a bank’s

head teller has been noticing long customer lines in the lobby. She wants to know

whether they are due to the computers slow response to inquires, the new teller’s limited

training or just a sudden increase in bank business. To what extent and how quickly a

user- originated idea is converted to a feasibility study depends on several factors such as:

• The risks and potential returns.

• Management’s bias toward the user.

• Financial costs, and the funds, available for system work.

• Priorities of other projects in the firm.

• The persuasive ability of the user.

All these factors are crucial for a prompt response to a user request for change. A

systems analyst  act as a convenient resource for ideas. The role and status of the analyst as a
professional add credibility to the suggestions made. With these considerations, an investigation
may be initiated.

Figure below  shows a complete system development life cycle. The sections following discuss
each of the steps involved in the systems development life cycle.
 Deliverables of the SDLC
Approved Feasibility Ab o r t P r o je c t
Preliminary
Investigation Study Go t o n e xt p h a s e
Problem Go t o P r e vio u s p h a s e
System
Analysis Specifications

System
Design Design Specifications

System Coded and

Development Tested System
Begin building System System converted
new system Implementation Users trained
System
Maintenance
Operational System
Documentation completed

Step 1. The Investigation or Idea Stage

There are certain steps through which systems development process should follow. These start
with the investigation stage and others follow as shown in the figure. The first step in the systems
development process is the systems investigation stage.  This step may involve consideration of
proposals generated by stakeholders of the system in the information systems planning process. 

In the stakeholders’ meetings, departmental managers and the board initiate the need for the new
system. The reasons for the change or new system are generated by parties mentioned in the
sections above.

Departmental managers brief systems analyst on departmental needs, identify key processes,
documents and key workers. During these meetings, the systems analyst establishes a rapport
that enables them to get support of user staff during the investigations and developments. With
the user staff, an agreement is arrived at on how the analysing of the current system is to be
carried out.

Users assist manager and systems analyst in providing information about current systems
including documentation used and the processes undertaken. Identification of particular
individual needs of the new system is done.

The investigation stage also includes the preliminary study of the proposed system.

The three steps of the systems investigation stage involve:

 Determining whether a business problem or opportunity exists.

 Defining Problems and Opportunities:

To solve a problem or pursue an opportunity requires a thorough understanding of the situation

at hand.  This requires separating problems from symptoms, determining objectives and
constraints, and, more important, viewing the problem or opportunity in a systems context.
Problem: - is a basic condition that is causing undesirable results.

Opportunity: - is a basic condition that presents the potential for desirable results.

Symptoms: - are merely signals of an underlying cause or problem.

Ideally, to solve a problem, it is necessary to conduct a feasibility study to determine whether a

new or improved information system is a feasible solution. Next, it is important to develop a
project management plan and obtain management approval.

Consultations between senior management, departmental managers and technical experts such as
the systems analyst define a new proposal. It is also called the investigation stage. This is then
used to provide guidelines for a feasibility study that will enable a decision to be made about
further development. The need for a new system is raised.

Step  2. The  Feasibility Study stage

Definition 1: Feasibility is defined as the practical extent to which a project can be performed
successfully.

Definition 2: A feasibility study is a preliminary study which investigates the information needs
of prospective users and determine the resource requirements, cost, benefits, and feasibility of a
proposed project. Consider a case of developing a software to perform a certain function.

 To evaluate feasibility, a feasibility study is performed, which determines whether the solution
considered to accomplish the requirements is practical and workable in the software.  Every
legitimate solution will have some advantages or benefits, and some disadvantages or costs. 
These advantages and disadvantages are identified when each alternative solution is evaluated. 
This process is typically called cost/benefit analysis.

Information such as resource availability, cost estimation for software development, benefits of
the software to the organization after it is developed and cost to be incurred on its maintenance
are considered during the feasibility study.  The objective of the feasibility study is to establish
the reasons for developing the software(where the project is about developing a software)  that is
acceptable to users, adaptable to change and conformable to established standards. It will  ensure
clear objectives are determined before development takes place, administrative and procedural
processes are considered, costs are identified (therefore can be controlled) and a clear plan of
development is defined.

The objective of the feasibility study is to establish the reasons for developing the software that
is acceptable to users, adaptable to change and conformable to established standards. It will
ensure clear objectives are determined before development takes place, administrative and
procedural processes are considered, costs are identified (therefore can be controlled) and a clear
plan of development is defined.

There are five areas in which to do a feasiblilty study to ascertain suitability of a project:

 Technical feasibility
 Economical feasilbility
 Social feasibility
 Operational feasibility
 Legal feasibility

Technical feasibility

For a project to be technically feasible, there should be the technology to help achieve the
objectives of the project. If the technology is not available or no trained personnel to handle the
project, then it should be abundoned. The proposed solution should be achievable using the
existing or propossed hardware and software. Some creteria that the hardware and software
should meet include:

 Processing a given volume of transactions at a given time

 Storage of files- should be able to store a given size of files
 Speed- must be able to meet a predetermined response time.
 It Should be able to support a given number of users at a time.

Economic feasibility

On economic feasibility, a cost-benefit analysis should be carried out.If any benefits are to be
realized from the propossed system, the costs incurred in developing it be less than the benefits.

 Costs

Probable costs normally incurred in developing a new system in clude:

Capital costs – costs incurred in the purchase of hardware and software to be used in the system.

Maintenance cost (sometimes refered to as revenue costs) – Cost in supporting and maintaining
the new system
One-off costs- costs incurred in training the staff on the use of the propossed system.

 Benefits:

 Benefits expected from the propossed system include:

 Speed of processing- less time to process transactions, customers are served faster
 Savings in staff costs- this reduces operation costs as smaller workforce is required to
produce the same output.
 Improvement on products’ quality- This translates to high quality products, higher
demand for the products and hence more revenue for the organization.

Social Feasibility study

Cultural and social feasibility studies involve evaluating the compatibility of cultural and social
practices, beliefs and status affected by the proposed project. It should motivate the staff and
should also be compatible with social structures in the organization. It should give job
satisfaction and not create industrial unrest in the organization.

Operational Feasibility Study

Operational feasibility is a measure of how well a proposed system solves the problems, and
takes advantage of the opportunities identified during scope definition and how it satisfies the
requirements identified in the requirements analysis phase of system development. Operational
feasibility is mainly concerned with issues like whether the system will be used if it is developed
and implemented. Whether there will be resistance from users that will affect the possible
application benefits. The essential questions that help in testing the operational feasibility of a
system are following.

Does management support the project?

Are the users not happy with current business practices? Will it reduce the time (operation)
considerably? If yes, then they will welcome the change and the new system.

Have the users been involved in the planning and development of the project? Early involvement
reduces the probability of resistance towards the new system. Will the proposed system really
benefit the organization? Does the overall response increase? Will accessibility of information be
lost? Will the system affect the customers in considerable way?  The users should be able to use
or operate it without any new training. The new system should have as many similarities as
possible with the old system. This will make the users to easily adapt the system.

Legal feasibility

It includes study concerning contracts, liability, violations, and legal other traps frequently
unknown to the technical staff. Usually the proposed system should meet the legal requirements
of the country where the organization is domiciled. It should not for example be a system that
would interfere with others in the neighbourhood or in the country.

For a feasibility study to be carried out, terms of refernce are spelled out.

Terms of Reference - Identifies the people involved including the leader, time-scales,

budgets, area under investigation, clear boundaries of the investigation. It will identify the

required outcomes such as the cost-benefits expected, comparison with the existing system,

alternative solutions and a recommendation for progression. A report will be produced for

Discussion at high level.

Report – The report will identify the title, the members of the team, dates of the investigation,

a review of the existing system with its defects. It will list the reason why the study was

undertaken and a proposed solution with alternatives, some of which could be scaled down

version or partial solutions. It will identify costs and benefits of the new system, time-scales

for implementation and should recommend a particular solution.

Board Decisions – The board or deciding panel can make any one of many different

decisions as a result of reading the report, discussing it at a meeting and questioning the

system analyst on any matter that would affect the new proposal. Possible decisions (ranging

from the ones with least effect on the company to complete acceptance) are:

a) Reject the report outright and continue with the old system

b) Improve the old systems without needing a re-write

c) Postpone the decision until a later date

d) Call for further information or a more detailed report – perhaps a new study

e) Implement only part of the proposal

f) Implement one of the alternative solutions

g) Implement one of the solutions but in a different way than proposed

h) Accept the main proposal and authorise the project to begin

Step 3. Investigation – This is a more detailed investigation of the existing system and will
involve working in the user departments to find out how the current system operates in practice.

The systems analyst will already have found out the main processes within the department and
may need to approach the manager for more information and who should be approached to
provide it. Seniority and experience may decide this. The information the analyst will require
will include:

a) Precise definition of each process

b) Who performs this process

c) What it involves

d) What data is collected

e) How it is collected

f) What data is stored

g) What documentation/forms are used

h) Where the data then is moved to

Methodology

Possible ways to obtain information could be:

a) Questionnaires - Can capture from many (possibly remote) sites, from more people

and can be used as a starting point for interviews. The aim is to find out about general

processes, documents used, document movements, volumes of data, filing systems

could be identified at an early stage in the investigation.

However, questionnaires by their nature may need to be standardised for different

areas within the business and are only likely to give an outline for further investigation.

Returns could be low unless there is managerial pressure, questions may not be given

full attention and may represent what should be performed rather than what actually

happens. There could be a feeling by staff of outside interference. A previous explanatory

meeting with all staff could have eliminated some of the problems. There could be discrepancies
between answers from different staff that should be highlighted and investigated at later
interviews.

b) Interview – This gives direct contact with actual users. It could be one-to-one or in a

small group of staff who perform similar functions. Not everyone can be interviewed

because it is time-consuming so key people are chosen. Direct contact with users can

improve the developer-user relationship. Actual problems experienced by users can be

addressed. Staff are told why they have been picked. Terms of the interview are agreed on first.
A place and time convenient for the user(s) is chosen. Users are asked to bring typical
documentation/forms used. A friendly atmosphere is generated with the correct level of language
used – not too technical. Direct questions, one at a time and agree answers before moving on.
Points raised from questionnaires are raised. The analyst can give some indication of how the
new system might work. Questions are invited. A summary is agreed at the end which might be
confirmed in writing later.

Analyst will ask about procedures, forms, data, where data comes from and where it is

then passed, files used, volumes and frequencies. After the interview, the analyst

updates charts (DFDs etc). Progress is reported to manager.

c) Documentation analysis

 Forms, documents (invoices etc) are studied. Where possible, these are replicated in the new
system to enhance familiarity. Filing systems, ledgers and procedure manuals, where available,
are collected.

d) Systems Observation

This could be watching the people performing their task. Watching what happens at every step is
important.  
After doing the feasibility study we are able to determine:

 The systems requirements- Requirements analysis

 How the system works and what needs to be done
 Systems specifications can be drawn

Step 4: System Specifications (System analysis)

Systems analysis is the dissection of a system into its component pieces for purposes of studying
how those component pieces interact and work.

User Interface, Data, and Process Design

The systems design concept focuses on three major products or deliverables that should result
from the design stage.  These are: User Interface, Data, and Process Design

 System design consists of three activities:

1.  User Interface Design

2.  Data Design

3.  Process Design

User Interface Design: 

User interface design focuses on supporting the interactions between end users and their
computer-based applications.   Designers concentrate on:

 The design of attractive and efficient forms of user input and output, such as easy-to-use
Internet or intranet web pages.
 Designing methods of converting human-readable documents to machine-readable inputs,
such as optical scanning of business forms.

Design tips to keep in mind are:

Keep it simple

Keep it clean

Organize logically
User interface design is frequently a prototyping process, where working models or prototypes of
user interface methods are designed and modified with feedback from end users.  User interface
design produces detailed specifications for information products such as:

 Display screens
  Interactive user/computer dialogues
  Audio responses
 Forms
  Documents
  Reports.

Data Design

The data design activity focuses on the design of the structure of databases and files to be used
by a proposed information system.  Data design frequently produces a data dictionary, which
catalogues detailed descriptions of the:

 Attributes or characteristics of the entities (objects, people, places, events) about which
the proposed information system needs to maintain information.
 Relationships these entities have to each other.
 Specific data elements (databases, files, records, etc.) that need to be maintained for each
entity tracked by the information system
 Integrity rules that govern how each data element is specified and used in the information
system.

Process Design

The process design activity focuses on the design of software resources, that is, computer
programs and of procedures needed by the proposed information system.  It concentrates on
developing detailed specifications for the program modules that will have to be purchased as
software packages or developed by custom programming.  Process design produces:

1.         Detailed program specifications and procedures needed to meet the user interface and
data design specifications that are developed.

2.         Produces specifications that meet the functional control and performance requirements
developed in the analysis stage.

  

 
 

Step 5. Systems Design

System analysis describes what a system should do to meet the information needs of users.  The
design also specifies how the system will accomplish this objective.  Systems design consists of
design activities, which produce systems specifications satisfying the functional requirements
developed in the systems analysis stage.  These specifications are used as the basis for:

 Software development( if any software is to be used)

  Hardware acquisition
 Building (or can be refered to as developing and prototyping)
 System testing
 Other activities of the implementation stage.

The analyst in this design stage designs all aspects of the system from the data collected. This
involves:

a) Process design – system flowcharts, data flow diagrams, decision tables

b) Data structures

c) File design including access method and file organisation to be used. Each data item

will be defined by name and size, type and use recorded.

d) Input method determination/forms for data capture

e) Validation to be applied to input data

f) Output design – screen and print layouts

g) Modularization – the analyst identifies how the logical design will break down into

smaller modules/programs
h) Security of data (and privacy) to be built in

i) Plan for testing and setting target dates. Method of conversion from old to the new

system

j) Training identified

Step 6. System Development

Prototyping:

Prototyping is the rapid development and testing of working models, or prototypes, of new
applications in an interactive process involving both systems analysts and end users.  Prototyping
makes the development process faster and easier for systems analysts  especially for projects
where end user requirements are hard to define.   Thus, prototyping is sometimes called rapid
application design (RAD).  Prototyping has also opened up the application development process
to end users because it simplifies and accelerates systems design.  These developments are
changing the roles of end users and information systems specialists in systems development.

Prototyping can be used for both large and small applications.  Typically, large systems still
require using the traditional systems development approach, but parts of such systems can
frequently be prototyped. Prototyping combines steps of the traditional systems development
cycle, and allows the rapid development and testing of a working model.  The model is then
repeatedly refined until it is acceptable to an end user.

Once a proposed information system has been designed, it is taken to the next step;
implementation.

Step 7. System Implementation

  The systems implementation stage involves:

1.         Hardware and software acquisition

2.         Software development

3.         Testing of programs and procedures

4.         Development of documentation

5.         Installation activities

6.         Education and training of end users and specialists who will operate the new system.
7.         Converting from the use of the present system to the operation of a new or improved
system.

Converting to a new system may involve:

Parallel System - Operating both a new system and an old system at the same time for a trial
period.

Pilot System - Operate a pilot system on a trial basis at one location.

Phasing - Phasing in the new system one application or location at a time.

Plunge (Cutover) - Converting immediately to the new system.

Step 8. Maintenance of the System

The systems analyst undertakes to ensure training from initial outlines of the new system to
specific training on using it.

IT Technical staff or the line staffs are lined up for the installation and testing of the new
equipment or system.

Development programmers are given an initial briefing about the whole new system and one-to-
one briefing about individuals own designated tasks. The Systems analyst is updated on progress
and any problems.  The arragements are made on assistance with testing of the new
system.Training of users and documentation of the new system  are provided.

Maintenance Programmer(s) are assisted in becoming familiar with all programs including one
not written by the development programmer. Performance of  changes as required is taken as a
priority.

Systems maintenance is the final stage of the systems development cycle.  It  involves the
monitoring, evaluating, and modifying of a system to make desirable or necessary
improvements. This may include:

1.         Post implementation review process to ensure that the new system meets the objectives
established for it.

2.         Error detected in the development or use of the system are corrected.

3.         Later modifications to a system may also become necessary due to changes within the
business or the business environment.

The Computer-Aided Systems Engineering –

The traditional systems development life cycle process has often been too inflexible, time-
consuming, and expensive for many organizations to utilize.  To overcome some of the shortfalls
of the SDLC, Computer-Aided Systems Engineering (CASE) process has emerged.  CASE
involves using software packages called CASE tools, to perform many of the activities of the
systems development life cycle.

CASE software packages are available to help do:

1.         Business planning

2.         Project management

3.         User interface design

4.         Database design

5.         Software development.

Using CASE Tools:

Some of the capabilities of CASE tools can be found in the application development capabilities
of end user software such as electronic spreadsheet and database management packages.  CASE
tools also help to automate the use of graphics tools such as flowcharts and data flow diagram. 

CASE packages provide tools for the front end of the systems development life cycle (planning,
analysis, and design) as well as the back end (implementation and maintenance).   Many
packages now include a system repository component that expands the role of the data dictionary
as a catalogue of data definitions.  A system repository provides systems analysts with computer-
aided data descriptions and other cataloguing facilities, beginning with their systems planning
and systems analysis activities, and continuing through the design, implementation, and
maintenance of the system.  Thus, the repository has become a database for all the details of a
system generated with other systems development tools. 

Integrated CASE tools are also available that can assist all of the stages of the systems
development.  Some CASE tools support joint application design (JAD), where a group of
systems analysts, programmers, and end users can jointly and interactively design new
applications.  Finally, if the development of new systems can be called forward engineering,
some CASE tools support backward engineering.  That is, they allow systems analysts to inspect
the logic of a program code for old applications and convert it automatically into more efficient
programs that significantly improve system effectiveness.

End User Development

In end-user development, IS professionals play a consulting role while you do your own
application development.  Sometimes a staff of user consultants may be available to help you and
other end users with your application development efforts.  For instance, a user services group or
information centre may provide assistance for both mainframe and microcomputer applications
development. 

Doing End User Development:

In end user development, you and other end users can develop new or improved ways to perform
your jobs without the direct involvement of IS professionals.  The application development
capabilities built into a variety of end user software packages have made it easier for many users
to develop their own computer-based solutions. 

End user development should focus on the fundamental activities of an information system: 
input, processing, output, storage, and control.

Summary

Steps involved and products produced in the traditional information systems development cycle:

1.  Systems investigation - Product:  Feasibility Study

2.  Systems analysis - Product:  Functional Requirements

3.  Systems design - Product:  Systems Specifications

4.  Systems implementation - Product:  Operational System

5.  Systems maintenance - Product:  Improved System