The System Development Life Cycle

SYSTEMS
DEVELOPMENT LIFE
CYCLE
The System Development Life Cycle
What are the phases of the system development cycle?
Phase 2. Analysis
 Conduct preliminary investigation
Phase 1. Planning  Perform detailed analysis activities:
 Review project requests
Phase 3. Design
Study current system  Acquire hardware
 Prioritize project Determine user requirements and software, if
requests necessary
Recommend solution
 Allocate resources  Develop details of
 Identify project system
development team

Phase 5. Support Phase 4. Implementation

 Conduct post-implementation  Develop programs, if necessary
system review  Install and test new system
 Identify errors and enhancements  Train users
 Monitor system performance  Convert to new system
Questions to be Answered
 Planning phase
 Why should we build this system?
 What value does it provide?
 How long will it take to build?
 Analysis phase
 Who will use it?
 What should the system do for us?
 Where & when will it be used?
 Design phase
 How should we build it?
SDLC: The Planning Phase
1. Project Initiation
 Develop/receive a system request
 Conduct a feasibility analysis
 Technical feasibility
 Economic feasibility
 Organizational feasibility
2. Project Management
 Develop the work plan
 Staff the project
 Monitor & control the project
SDLC: The Analysis Phase

1. Develop an analysis strategy

 Model the current system
 Formulate the new system
2. Gather the requirements
 Develop a system concept
 Create a business model to represent:
 Business data
 Business processes
3. Develop a system proposal
SDLC: The Design Phase

1. Develop a design strategy

2. Design architecture and interfaces
3. Develop databases and file specifications
4. Develop the program design to specify:
 What programs to write
 What each program will do
SDLC: The Implementation Phase

1. Construct the system

 Build it (write the programming code)
 Test it
2. Install system
 Train the users
3. Support the system (maintenance)
The System Development Life Cycle
What are guidelines for system development?

Arrange tasks into phases

Involve(groups of activities)
users (anyone for whom
system is being built)

Develop clearly defined standards (procedures

company expects employees to follow)
The System Development Life Cycle
Who participates
in the system
development life
cycle?
The System Development Life Cycle
What is a systems analyst?

Responsible for designing

and developing
information system

Liaison between users

and IT professionals
The Systems Analyst: Skills

 Agents of change
 Identify ways to improve the organization
 Motivate & train others
 Skills needed:
 Technical: must understand the technology
 Business: must know the business processes
 Analytical: must be able to solve problems
 Communications: technical & non-technical audiences
 Interpersonal: leadership & management
 Ethics: deal fairly and protect confidential information
The Systems Analyst: Roles
The System Development Life Cycle
What is the project team?

Formed to work on project from beginning to end

Consists of users, systems analyst, and other IT professionals

Project leader—one member of the team who

manages and controls project budget and schedule
The System Development Life Cycle
What is feasibility?
Operational
feasibility
Measure of
how suitable
system Four feasibility
development tests:
will be to the Schedule
company feasibility

Economic
feasibility
(also called Technical
cost/benefit feasibility
feasibility)
Feasibility Analysis

 Is this project feasible?

 What are the risks?
 Can these risks be overcome?
 Major components:
 Technical feasibility (Can we build it?)
 Economic feasibility (Should we build it?)
 Organizational feasibility (Will they use it?)
Technical Feasibility

 Identify risks in the following areas:

 The functional area: Are analysts familiar with this
portion of the business?
 The technology: Less familiarity generates more risk
 Project size: Large projects have more risk
 Compatibility: Difficult integration increases the risk
Economic Feasibility (Cost-Benefit Analysis)

 Identify the costs and the benefits

 Assign values to the costs and benefits
 Determine the cash flow
 Determine the value using one or more methods:
 Net present value (NPV)
 Return on investment (ROI)
 Break-even point
The System Development Life Cycle
What is documentation?

Collection and summarization

of data and information
Includes reports, diagrams,
programs, and other deliverables
The System Development Life Cycle
What are six data and information gathering techniques?
 Review documentation
 Observe
 Questionnaire
 Interview
 Joint-application
design (JAD) session
 Research
ACTIVITY FEASIBILITY STUDY DISCUSSION
REVIEW

Feasibility is the measure of how beneficial the

development of information system would be to an
organization. Feasibility analysis is a management-
oriented activity, by which alternative solutions are
obtained and a specific solution is recommended
for optimal performance.
Technical Feasibility: Whether the project can be done
with the available equipment, technology and personnel.
Technical feasibility analysis questions whether the
hardware, software, and other technologies needed for the
project to exist in the organization or it has to be acquired
or it needs to be developed?
 Example: If a project requires coding in a new
programming language and none of the personnel knows
the language, the organization must consider the feasibility
of training existing personnel or hiring consultants. If these
options prove too costly or take too long, the project may
not be technically feasible
Economic Feasibility: Economic feasibility study
analyzes the viability of a solution in terms of revenues
and investments. The questions that are asked are:
 Is the project viable, given the resource constraints?
 Are the benefits that accrue from the new system
worth the costs?
 What are the savings that result from the system,
including tangible and intangible ones?
 What are the development and operational costs?
Operational Feasibility: Operational feasibility looks at the
operability and acceptability of any solution. The questions
that are asked are:
 If the system is developed, will it be used?
 Are there any people oriented issues such as manpower
problems and labor objections?
 Is there any conflict with the organizational policies
 Are there any issues of social acceptability, legality and
adherence to government
 regulations?
Operational feasibility can be analyzed using the PIECES framework.
PIECES FRAMEWORK:
 Performance: Does the system provide adequate throughput and
response time
 Information: Does the system provide the end users with timely,
pertinent, usefully formatted information
 Economy: Does the system offer adequate service level and capacity
to justify costs
 Control: Does the system offer adequate controls to ensure integrity
and security of data
 Efficiency: Does the system optimize the use of all available
resources
 Services: Is the service reliable, desirable, flexible and expandable
The System Development Life Cycle
What are some reasons to create or modify an
information system?

To correct problem To improve

in existing system existing system

Outside group may Competition can

mandate change lead to change
Defining the Problem

 Whether using the classical SDLC or an object-

oriented approach, the analyst first defines the
problems and objectives of the system. These
form the foundation of determining what needs
to be accomplished by the system. Methods like
Six Sigma (refer to Chapter 16 for details) start
with a problem definition.
Defining the Problem
To Identify Problems To Identify Problems
 Check output against • Too many errors
performance criteria. • Work completed slowly
• Work done incorrectly
• Work done incompletely
• Work not done at all

 Observe behavior of • High absenteeism

employees. • High job dissatisfaction
• High job turnover
Defining the Problem
 Listen to external • Complaints
feedback from: • Suggestions for improvement
Vendors. Customers. • Loss of sales • Lower sales
Suppliers.
Case Analysis
The System Development Life Cycle
What is a request for system services?
 Formal request for
new or modified
information system
 Also called
project request
The System Development Life Cycle
What is the planning phase?
Begins when steering committee receives project request

Steering
committee—
decision-making
body for the
company

Function of committee:

Form project
Review and development
Prioritize Allocate
approve project team for each
project requests resources
requests approved
project
Analysis Phase
The System Development Life Cycle
What is the analysis phase?

Conduct preliminary Perform detailed

investigation, also analysis
called feasibility
study
The System Development Life Cycle
What is the preliminary investigation?
 Determine exact nature of problem or improvement
and whether it is worth pursuing
 Findings are presented in feasibility report, also known as a feasibility study
The System Development Life Cycle
What is detailed analysis?
1. Study how current system
works

2. Determine user’s wants, needs,

and requirements

3. Recommend solution

Sometimes called logical design

The System Development Life Cycle
What is the
system proposal? Assesses
feasibility
of each
alternative
solution

Presented to
Recommends
steering
the most
committee,
feasible
which decides
solution for
how system will
the project
be developed
The System Development Life Cycle
What are possible solutions? Horizontal market
software—meets
needs of many
companies
Buy packaged software—prewritten
software available for purchase
Vertical market
software—designed
for particular industry
Write own custom software—software
developed at user’s request

Outsource—have outside source

develop software
Systems Requirement Specification (SRS)

 System requirements specification document

specifies the information requirements to be
provided. SRS is obtained after excessive
discussions with the user. The narrative of
requirements by users can be too long and
imprecise and it needs conversion to precise
specifications. SRS does not specify the design
of the information system to be developed.
Systems Requirement Specification (SRS)
should…
 Be complete and unambiguous
 Specify operational and strategic information
requirements
 Attempt to eliminate future disputes between
users and Analyst
 Use Graphical aids understood by users
How to create a SRS document
 Step1: Analyze statement of requirements
 Step2: Identify physical entities.
 Step3: Identify documents which are received/sent by
each office
 Step4: Draw a physical document.

SRS can be specified using graphical tools also.

Graphical Specification Tools for SRS
a). Physical- Document flow diagram describes the
physical flow of document in a system.
It depicts various entities or offices and documents
generated/transmitted by these entities

b). Logical- Data Flow Diagram describes the functional

logic of a system. It depicts the flow data between various
processes.
Data Flow Diagrams
Structured Analysis

 Structured analysis is a method for modeling the

components of a system using graphical symbols.
Data Flow Diagrams (DFD) show the flow of data
into the system and between processes and data stores.
A data store is a repository for data and it can be
manual, digital or temporary. In preparing the model,
the analyst emphasizes what occurs, not how it is
accomplished. Thus the focus is on logical rather than
physical aspects of the system.
 Process modeling is a graphical representation of the
processes that capture, manipulate, store, and distribute
data between a system and its environment and among
system co
 Data-flow Diagram (DFD) is an example of process
modeling. DFD is a graphical system model that shows
all of the components of an information system in one
diagram: inputs, outputs, processes and data stores. It
illustrates movement of data between external entities
and the processes and data stores within a system.
Data Flow Diagram and Levels of Abstraction
 DFD may reflect the processing at either a higher level
(more general view of the system) or at a lower level
(a more detailed view of one process). These different
views of the system, higher level versus low level,
create levels of abstraction. DFD is a modeling
technique that breaks up the system into a hierarchical
set of increasingly more detailed models. Higher level
processes in a DFD can be decomposed into separate
lower level DFDs.
Context Diagram

 Context Diagram
Context Diagram is a data-flow diagram to represent the
scope of an organizational system. It shows the system
boundaries, external entities that interact with the system
and the major information flows between the entities and
the system. It summarizes all processing activities within
the system by a single process symbol. It describes highest
level view of a system. All external agents and all data
flows into and out of a system are shown in the diagram.
Features of Context Diagrams
 Shows system boundaries
 Represents the system scope within a single process
 Shows external agents that supply or receive data from
the system and that are outside the system scope but
not the data stores
 This highest level of DFD des not show any details of
what takes place within the system
Data Flow Diagrams

 A data flow diagram (DFD) shows how data moves

through an information system but does not show
program logic or processing steps
 A set of DFDs provides a logical model that shows
what the system does, not how it does it
Data Flow Diagrams

 DFD Symbols
 DFDs use four basic symbols that represent processes,
data flows, data stores, and entities
 Symbols are referenced by using all capital letters for the
symbol name
 Data Flow
 Data Flow depicts data that are in motion- moving as a
unit from one place to another in the system. It is
represented as an arrow. A data flow has only one
direction of flow between symbols. A fork means that
exactly the same data go from a common location to
two or more processes, data stores, or external entities-
sources or sinks. A data flow cannot go directly back
to the same process it leaves. A data flow to a data
store means update into database. A data flow from a
data store means retrieve or use. A data flow has a
noun phrase label.
Data Store
 It depicts data at rest and may represent data in a file folder,
computer-based file or a notebook. Data Store is represented as
a rectangle with the right vertical line missing or with two
horizontal parallel lines. Data store has a noun phrase label. The
label should include name of the store as well as the number.
Data can neither be moved from one store to another, nor from
an outside source to a data store. A “join” means that exactly
the same data come from any two or more processes, data stores
or sources/sinks to a common location.
Process
 A process depicts work or actions performed on data
so that they are transformed, stored, or distributed. It
defines rules- algorithms or procedures, for
transforming inputs into outputs. It is drawn as a circle
or rectangle with rounded corners. A process has a
verb phrase label, and includes process number as well
as name. No process can have only outputs (a miracle).
No process can have only inputs (black hole
External Entity (Source/Sink)
 It depicts the origin and/or destination of the data and
is represented as a square symbol. A source/sink has a
noun phrase label and represents a person or an
organization. An external entity is outside the
boundary of a system. It provides data outputs or
accepts data inputs Data cannot move directly from a
source to a sink. In some notation, it forms part of
DFD while in some it is not a part of a DFD
Guidelines for drawing DFDs

Completeness:
 DFD must include all components necessary for
system
 Each component must be fully described in the project
dictionary or Computer
 Aided Software Engineering (CASE) repository
Consistency:
 The extent to which information contained on one
level of a set of nested DFDs is also included on other
levels
Guidelines for drawing DFDs
Timing:
 Timeframe is not represented on DFDs
 Best way to draw a DFD is as though system is an ongoing
one> It is not restricted by a specific time frame.
Iterative Development:
 Analyst should expect to redraw DFD several times before
reaching the closest approximation to the system being modeled
Top down development:
 Start from context diagram and reach the lowest logical level of
decomposition the primitive DFD
Guidelines for drawing DFDs
 Meaningful names should be chosen for process, flows, data
stores and external entities
 Numbering does not imply sequencing of processes
 To avoid cluttering, data stores and data flows can be repeated
on a diagram
 Each process on a DFD must be formally defined and
numbered
 Each process can transform data but cannot create data
 Data Store can not create data. It can store previously created
data
Examples of correct combinations of data flow
and process symbols.
 Examples of incorrect combinations of data flow
and process symbols. APPLY INSURANCE
PREMIUM has no input and is called a
spontaneous generation process. CALCULATE
GROSS PAY has no outputs and is called a black
hole process. CALCULATE GRADE has an input
that is obviously unable to produce the output. This
process is called a gray hole.
Data Flow Diagrams

 DFD Symbols
 Data store symbol
 Represent data that the system stores because one or more
processes need to use the data at a later time
 Symbol is a flat rectangle that is open on the right side and
closed on the left side
 Is a plural name consisting of a noun and an adjective, if
needed.
Examples of correct uses of data store symbols in a data
flow diagram.
Examples of incorrect uses of data store symbols: two data
stores can-not be connected by a data flow without an
intervening process, and each data store should have an
outgoing and incoming data flow.
Examples of correct uses of external entities in a data flow diagram.
Examples of incorrect uses of external entities.
An external entity must be connected by a
data flow to a process, and not directly to a
data store or to another external entity.
Data Flow Diagrams

 DFD Symbols
 Entity Symbol
 Symbol is a rectangle, which may be shaded to make it look
three-dimensional
 Name of the entity appears inside the symbol
 Terminators (entities are data origins and final destinations)
 Source(entity that supply data to the system)
 Sink (entity that receives data from the system)
Rules for connecting processes, data
stores, and entities in a DFD.
Data Flow Diagrams
 Context Diagrams
 Top-level view of an information system that shows the
system’s boundaries and scope
 Do not show any data stores in a context diagram
because data stores are internal to the system
 Begin by reviewing the system requirements to identify
all external data sources and destinations
Data Flow Diagrams

 Context Diagrams
 Record the name of the entities and the name and
content of the data flows, and the direction of the data
flows
 What makes one system more complex than another is
the number of components, the number of levels, and
the degree of interaction among its processes, entities,
data stores, and data flows
Context diagram for an order
system
Group Work

Draw a Context Diagram of

SPUD Enrollment System
Data Flow Diagrams

 Conventions for DFDs

1. Each context diagram must fit on one
page
2. The process name in the context
diagram should be the name of the
information system
3. Use unique names within each set of
symbols
Data Flow Diagrams

 Conventions for DFDs

4. Do not cross lines
5. Use a unique reference number
for each process symbol
Data Flow Diagrams

 Diagram 0
 Zooms in on the context diagram and
shows major processes, data flows,
and data stores
 Must retain all the connections that
flow into and out of process 0
 Each process has a reference number
Data Flow Diagrams
 Diagram 0
 If same data flows in both directions, you can use a
double-headed arrow
 Diagram 0 represents exploded view of process 0
 Parent diagram
 Child diagram
 Functional primitive – a process that consist of a single
function that is not exploded further.
Diagram 0 DFD
for the order system.
Data Flow Diagrams

 Lower-Level Diagrams
 Created using leveling and balancing techniques
 Leveling
 Uses a series of increasingly detailed DFDs until all
functional primitives are identified
 Exploding, partitioning, or decomposing
Diagram 1 DFD shows
details of the FILL
ORDER process in
the order system.
Data Flow Diagrams

 Lower-Level Diagrams
 Balancing
 Ensures that the input and output data flows of the parent
DFD are maintained on the child DFD
 The order system diagram 0 is shown at the top of
the figure, and exploded diagram 3 DFD (for the
APPLY PAYMENT process) is shown at the
bottom. The two DFDs are balanced, because the
child diagram at the bottom has the same input and
output flows as the parent process 3 shown at the
top.
Data Flow Diagrams

 Strategies for Developing DFDs

 A set of DFDs is a graphical, top-down model
 With a bottom-up strategy, you first identify all
functional primitives, data stores, entities, and data
flows
 The main objective is to ensure that your model is
accurate and easy to understand
Data Flow Diagrams
 Strategies for Developing DFDs
 General rule of thumb is that a diagram should have
no more than nine process symbols
 To construct a logical model of a complex system, you
might use a combination of top-down and bottom-up
strategies
 The best approach depends on the information system
you are modeling
The System Development Life Cycle
What is the design phase?

Acquire hardware and software

Develop all details of new or

modified information system
The System Development Life Cycle
What is needed to acquire new hardware and software?
 Identify all hardware and software requirements of new or
modified system

Talk with other

Surf Web
systems analysts

Read print and online

Visit vendors’ stores trade journals,
newspapers, and
magazines
The System Development Life Cycle
What are three basic documents used to summarize
technical specifications?

Vendor quotes
Identifies Request for quotation (RFQ) price(s) for
product(s) listed
you want product(s)

Vendor selects Request for proposal (RFP)

product(s) that
meet(s) your
requirements and
then quotes Less formal method
price(s) that uses standard
form to request
information about
Request for information (RFI) product or service
The System Development Life Cycle
How do systems analysts test software products?
 References from vendor
 Talk to current users of product
 Product demonstrations
 Trial version of software
 Benchmark test measures performance
The System Development Life Cycle
What is a detailed design?

Detailed design specifications for components in proposed solution

Includes several activities

Database Input and Program

design output design design
The System Development Life Cycle
What is a mockup?
 Sample of input or output that contains actual data
The System Development Life Cycle
What is a prototype?

Working model of
proposed system

Beginning a prototype
too early may lead to
problems
The System Development Life Cycle
What is computer-aided software engineering (CASE)?
 Software tools designed to support activities of system
development cycle
The System Development Life Cycle
What is the implementation phase?
 Purpose is to construct, or build, new or modified
system and then deliver it to users
Convert to new system

Train users

Install and test new system

Develop programs
The System Development Life Cycle
What are the three types of tests performed by system
developers?

Unit Test Systems test

Verifies each Verifies all programs

individual program in application work
works by itself together

Integration Test

Verifies application
works with other
applications
The System Development Life Cycle
What is training?
 Showing users exactly
how they will use new
hardware and software
in system
The System Development Life Cycle
What is the support phase?
 Provides ongoing assistance after system is implemented
Conduct post-implementation system review—meeting to find out if
information system is performing according to expectations

Identify errors

Identify enhancements

Monitor system performance

 Phase 1
Planning Phase
Phase 1: Planning Phase

1.1 Determine if you need to develop or buy a system.

When deciding to develop a business system or
business software, ask these questions:
 What is the business problem or opportunity to be
addressed?
 If there is an existing system in place, where does it
fall short? What are its strengths?
 What benefits would a new business system bring and
what procedural improvements might occur?
Phase 1: Planning Phase

1.1 Determine if you need to develop or buy an

administrative system. When deciding to develop a
business system or business software, ask these
questions:
 Are there other systems in the business that may be
performing similar functions or processing similar
data?
 Is it possible to salvage parts of an old system?
 What are the critical success factors for the
department's business? How does the proposed system
relate to these factors?
Phase 1: Planning Phase

1.2 Identify the primary stakeholders in the proposed

system development:
 Who would be likely to fund a project?
 Who are the primary users?
 Who are the secondary users?
 Will University policy be affected by the proposed project?
 Who are the business experts who will define the business
rules?
 What departments and external entities will be impacted by the
proposed system?
 Who will provide final technical and operational approval for
implementation of the system?
Phase 1: Planning Phase

1.3 Define the scope of the system, including the

constraints of the system, and plan to refine this
definition as the project progresses:
 Business problem to be solved
 Business functions to be included
 Business functions that will not be included
 Opportunities for re-engineering
 Security requirements (logical and physical)
 Required time-frame to implementation
 Estimated resource requirements
Phase 1: Planning Phase

1.3 Define the scope of the system, including the

constraints of the system, and plan to refine this
definition as the project progresses:
 Estimated budget
 Risks (include obstacles to implementing a new system)
 Mitigating actions
 Cost/ benefit analysis
 Preliminary project plan with time estimates and resource
requirements
 Note: Assistance from selected central offices may be helpful in
fulfilling these planning requirements
Phase 1: Planning Phase

1.4 Secure a sponsor for the project. The sponsor will

be responsible for:
 Approving the scope of the system development
project
 Securing the requested budget
 Acting as a liaison to external staff/
departments
 Providing resources as required for success
 Defining the governance of the project
Phase 1: Planning Phase

1.5 Identify the project team. Members of the team and

their roles may include the following:
 Project manager to manage the core team
 Business experts to provide the business requirements and rules,
test the system as it is developed, and define training
requirements
 System architect to provide technical oversight
 Quality assurance coordinator to ensure quality throughout the
project
 Software developers to analyze, design, and build the system
 Others as appropriate (reference IS-10 section 1.4 - Roles and
Responsibilities)