Topic II

Systems Development Life Cycle

Def: A framework that describes the

activities performed at each stage of a
software development project.
 Current Generic SDLC
Systems Requirements Systems
Investigation Determination Analysis

Systems
Systems Testing Systems Design
Development

Systems
Systems
Implementation
Maintenance
and evaluation
 Systems Investigation
Some authors omit it, it is an important phase
without which an information system will not
have a basis and it determines the success of the
project.

The deliverable at this phase is the feasibility

report containing the problem definition and
summarized objectives. Management must make
a decision on whether to proceed with the
proposed system
 Feasibility Reports
Technical feasibility - whether the technology exists to
implement the proposed system.
Economic feasibility – cost-benefit analysis.
Legal feasibility – e.g., will the system contravene the
Information Privacy Act?
Operational/Behavioural feasibility - concerned with
whether the current work practices and procedures are
adequate to support the new system, the social factors –
impact on employees.
Time/Schedule Feasibility – Whether the project will be
implemented in time
 Requirements Determination
The deliverable at this phase is the System
Requirements Specification (SRS) document
Types of requirements
User Requirement: what users want of the system. eg easy to
use, flexible etc
Functional Requirement: the core operations e.g. process
payroll, benefits administration, recruitment and selection etc.
Non functional Requirements: how well the system should
operate e.g. security, operational efficiency, speed, scalability etc
System Requirements (Physical): Software and Hardware
requirements etc.
 Systems Analysis
Studies the system operation by studying data flows
or process flows with the view of improving it using
e.g. Entity Relation Diagram (ERD), Entity Life
History (ELH), Data Flow Diagram (DFD)
{storage, information flow, processes, and entities
all represented diagrammatically} to chart the input,
output & processes of the business functions in a
structured graphical form. A data dictionary is
developed (lists all the data items & specifications).
 System Design
Accomplishes the logical (What the system must do)
and physical (how to work) design of the HRIS.
During system design, the analyst/designer emphasizes
the graphical user interface (GUIs), Input/output
design, back end databases and system architecture in
form of a prototype. Analyst should emphasize on User
Interface, designing files/databases that will store much
of the data needed by decision maker and controls and
backup procedures to protect the system and data.
 Systems Development
The design is built physically. Programmers write
codes/programs the system will use to execute its
functional requirements. The system design is put
into its physical shape ready to be used
(implemented).

Testing and documentation can be done

concurrently e.g. procedure manuals, online help
etc. documentation tells users how to use software
and what to do if software problems occur.
 Testing
Why testing?
• To see its compatibility with user requirements and how it
effectively addresses the identified problems.
• To identify bugs in the software.
Tests normally carried out:
Unit Test; to test each module, this is normally done by the
programmer and the system analyst.
Integrating Testing ; to test how well modules operate when
linked as a single unit
System test; this tests the whole system to see how well it
meets business requirements.
 Systems Implementation and
Evaluation
• The developed system is put into operation. It involves
training users (on job or off job) to handle the system by
vendors.
• The system analyst must also plan for the smooth
conversion of the new system from the old system.
Conversion involves converting files from old format,
building databases, installing equipment and bringing
the new system into production.
• Its at this phase that the users take over the system for
use and evaluate its performance, the analyst signs off.
 Strategies/Schemes for conversion
Direct change over/Cold Turkey: The old
system is dropped and the new system is put into
use. Successful after extensive testing and some
delays are acceptable.
Advantage : Users adapt quickly to the new
system and costs are minimized.
The limitations: many errors could be made,
long delays, and lack of comparisons with old
system etc.
 Strategies/Schemes for conversion…
Parallel conversion: running the old system and
the new system at the same time (in parallel) till
new system is proven successful, most commonly
used.
Advantages: Easy comparing of output, errors
checking, security to users.
Limitations: costly, need for employees to double
their work efforts since they interact with both
system, also employees will tend to stick to the old
system which they are used to.
 Strategies/Schemes for conversion…

Gradual/phased conversion: combine the best

features of the 1st 2 methods without all the risks.
The volume of transactions handled by the new
system is gradually increased as the new system is
ushered in.
Advantage: detecting and recovering errors.
Limitations: takes too long to get the new system
in place. The approach is also not compatible with
small uncomplicated systems.
 Strategies/Schemes for conversion…
Modular prototype/pilot conversion: This uses
the building of modular operational prototype to
change from old to new systems in a gradual
manner. As each model is modified and
accepted, it is put into use.
Advantage: the models are well tested and users
will be familiar with each model as it becomes
operational.
Limitation: it is not often feasible.
 Strategies/Schemes for conversion…
Distributed conversion: many
installations of the same system are
contemplated. One entire conversion is
done (with any of the four approaches
discussed above) at the same site. When the
conversion is successfully completed, other
conversion are done for other sites. This
operates in cases where an organization is
large and has several sites.
Illustration
 System Maintenance
After the system is installed, is must be
maintained i.e. keeping it up to date by
upgrading software, hardware etc. The system
should be maintained to reflect business
requirements but when the system becomes
obsolete, the IS life cycle is repeated.

It is important to document each stage for

usage, future reference and troubleshooting
 Criteria for selecting a Methodology
Clarity of User requirements: when user
requirements are not clear, prototyping, DSDM, XP
and RAD are appropriate.
Familiarity with technology: when the developers are
not familiar with the technology that they need to
develop a system, a lot of risks are involved, therefore
methodologies such as Spiral model are preferred.
System complexity: some systems are more complex
to develop, therefore choice should be of indepth
analysis – XP, Spiral etc
 Criteria…
System Reliability: Some systems e.g. for medical
equipment, missile control systems etc need a high
degree of reliability, comprehensive testing should be
done during the cycle, e.g. in XP and V-Model
Short time schedules: systems that have a short
time scope for development need methodologies like
RAD, DSDM, XP and prototyping. Waterfall method
is the most time consuming.
 Criteria…
Schedule visibility: some systems need constant
checking to determine whether its on schedule. There
is need to measure pace of development; XP is the
most appropriate.
Need for end user involvement: systems that
require high participation of end users would dictate
on the methodology to use. The best to use would be
JAD, XP, RAD