Lecture 2
Systems Development Process
http://www.csun.edu/~dn58412/IS531/IS531_SP16.html
Learning Objectives
1. Systems Development Life Cycle vs.
Systems Development Process
2. Zachman Framework and Stakehoders’
Perspectives in Systems Development
3. Classic Phases in Systems Development
Process
IS 531 : Lecture 2
2
Systems Development
Life Cycle (SDLC)
• Systems Development Life Cycle (SDLC) :the
factoring of the lifetime of an information system
into two stages, (1) systems development and (2)
systems operation and maintenance.
• Systems Development Process :a standardized
methodology defines a set of activities, methods,
best practices, deliverables, and tools for system
developers and project managers to develop and
continuously improve information systems and
software.
IS 531 : Lecture 2
3
Systems Development
Life Cycle (SDLC)
• Systems development
life cycle (SDLC) – The
overall process for
developing
information systems
from planning and
analysis through
implementation and
maintenance
IS 531 : Lecture 2
4
Systems Development
Life Cycle (SDLC)
IS 531 : Lecture 2
5
Where Do Systems Development
Projects Come From?
• Problem – an actual undesirable situation that
prevents the organization from fully achieving its
purpose, goals, and/or objectives.
• Opportunity – a chance to improve the
organization even in the absence of an identified
problem (using PIECES framework).
• Directive - a new requirement that is imposed by
management, government, or some external
influence/parties.
IS 531 : Lecture 2
6
PIECES Framework for Systems
Improvement
P
the need to improve performance
I
the need to improve information (and data)
E
the need to improve economics, control costs, or
increase profits
C
the need to improve control or security
E
the need to improve efficiency of people and
processes
S
the need to improve service to customers, suppliers,
partners, employees, etc.
IS 531 : Lecture 2
7
Where Do Systems Development
Projects Come From?
• Planned Projects
– An information systems strategy plan has examined
the business as a whole to identify those system
development projects that will return the greatest
strategic (long-term) value to the business
– A business process redesign has thoroughly
analyzed a series of business processes to eliminate
redundancy and bureaucracy and to improve
efficiency and value added. Now it is time to
design/redesign the supporting information system
for those redesigned business processes.
IS 531 : Lecture 2
8
Where Do Systems Development
Projects Come From?
• Unplanned projects
– Triggered by a specific problem, opportunity, or
directive that occurs in the course of doing business.
– Steering committee – an administrative body of
system owners and information technology
executives that prioritizes and approves candidate
system development projects.
– Backlog – a repository of project proposals that
cannot be funded or staffed because they are a
lower priority than those that have been approved
for system development.
IS 531 : Lecture 2
9
Problem-Solving
• What “problems” to solve: (Project Definition)
– True problem situations, either real or anticipated,
that require corrective action
– Opportunities to improve a situation despite the
absence of complaints
– Directives to change a situation regardless of
whether anyone has complained about the current
situation
IS 531 : Lecture 2
10
Problem-Solving …
• Why: (Project Justification)
– Effective: Do right thing
– Efficient: Do thing right
– Competitive: Do thing differently
IS 531 : Lecture 2
11
Zachman Framework
IS 531 : Lecture 2
12
Perspectives on
an Information System
IS 531 : Lecture 2
13
System Stakeholders
•
•
•
•
•
System owners
System users
System analysts
System designer
System builder
IS 531 : Lecture 2
14
System Owners
• System owners – an information system’s
sponsors and executives advocate, usually
responsible for funding the project of
developing, operating, and maintaining the
information system. They define the SCOPE of
a system: what business problem to be solved
– They view the system in term of cost/benefit to
solve a business problem
IS 531 : Lecture 2
15
System Users
• System users – use or are affected by an
information system on a regular basis –
capturing, validating, entering, responding to,
storing, and exchanging data and information.
They define the REQUIREMENTS of the
system.
– Internal users
– External users
IS 531 : Lecture 2
16
System Designers
• System designers translate system users’
business requirements and constraints into
technical solution: computer databases,
inputs, outputs, networks, and software
meeting the system users’ requirements. Their
activities relate to the DESIGN of a system
IS 531 : Lecture 2
17
System Builders
• System builders constructs information
systems based on the design specifications
from the system designers. Their activities
relate to building the COMPONENTS of the
system.
IS 531 : Lecture 2
18
Systems Analysts
• Systems analysts study the problems and
needs of an organization to determine how
people, data, processes, and information
technology can best accomplish improvements
for the business. They are FACILITATORS of the
system development project.
• A programmer-analyst
• A business analyst / consultant
IS 531 : Lecture 2
19
HIS Professional Involvement
in Systems Development
• User
• Analyst
• Purchaser
• Implementer
• Consultant
• Internal Auditor
• External Auditor
IS 531 : Lecture 2
20
Focuses for
Information Systems
• KNOWLEDGE (Data) — the raw material
used to create useful information.
• PROCESSES — the activities (including
management) that carry out the mission of
the business.
• COMMUNICATION (Interfaces) — how the
system interfaces with its users and other
information systems.
IS 531 : Lecture 2
21
KNOWLEDGE Focus
• System owners’ view
– Interested not in raw data but in information that
adds new business knowledge and information
that help managers make intelligent decisions.
– Data entities and business rules.
IS 531 : Lecture 2
22
KNOWLEDGE Focus . . .
• System users’ view
– Something recorded on forms, stored in file
cabinets, recorded in books and binders,
organized into spreadsheets, or stored in
computer files and databases.
– Focus on the business issues as they pertain to
the data.
– Data requirement – a representation of users’
data in terms of entities, attributes, relationships,
and rules independent of data technology.
IS 531 : Lecture 2
23
KNOWLEDGE Focus . . .
• System designers’ view
– Data structures, database schemas, fields,
indexes, and constraints of particular database
management system (DBMS).
• System builders’ view
– Coding
– DBMS or other data technologies
IS 531 : Lecture 2
24
PROCESS Focus
• System owners’ view
– concerned with high-level process
– Business function – a group of related processes that
support the business. Functions can be decomposed into
other sub-functions, activities, tasks.
– A cross-functional information system – a system that
supports relevant business processes from several
functions within organizational boundaries.
IS 531 : Lecture 2
25
PROCESS Focus . . .
• System users’ view
– concerned with work that must be performed to provide
the appropriate responses to business events.
– Business processes – activities that respond to business
events.
– Process requirements – a user’s expectation of the
processing requirements for a business process and its
information systems.
– Policy – a set of rules that govern a business process.
– Procedure – a step-by-step set of instructions and logic
for accomplishing a business process.
– Work flow – the flow of transactions through business
processes to ensure appropriate checks and approvals
are implemented.IS 531 : Lecture 2
26
PROCESS Focus . . .
• System designers’ view
– Concerned with which processes to automate
and how to automate them
– Constrained by limitations of application
development technologies being used
– Software specifications – the technical design of
business processes to be automated or
supported by computer programs (off-shelf, inhouse) to be written by system builders.
IS 531 : Lecture 2
27
PROCESS Focus . . .
• System builders’ view
– Concerned with programming logic that
implements automated processes
– Application program – a language-based,
machine-readable representation of what a
software process is supposed to do, or how a
software process is supposed to accomplish its
task.
– Prototyping – a technique for quickly building a
functioning, but incomplete model of the
information system using rapid application
development tools.
IS 531 : Lecture 2
28
COMMUNICATION Focus
• System owners’ view
– Concerned with communications scope of an
information system.
• Who (which business units, employees, customers,
and partners) must interact with the system?
• Where are these business units, employees,
customers, and partners located?
• What other information systems will the system
have to interface with?
• System users’ view
– Concerned with the information system’s inputs and
outputs (Interface Requirements).
IS 531 : Lecture 2
29
COMMUNICATION Focus . . .
• System designers’ view
– Concerned with the technical design of both the
user and the system-to-system communication
interfaces.
– Interface specifications – technical designs that
document how system users are to interact with a
system and how a system interacts with other
systems.
– User dialogue – a specification of how the user
moves from window to window or page to page,
interacting with the application programs to
perform useful work.
IS 531 : Lecture 2
30
COMMUNICATION Focus . . .
• System builders’ view
– Concerned with the construction, installation,
testing and implementation of user and systemto-system interface solutions.
– Middleware – utility software that allows
application software and systems software that
utilize differing technologies to interoperate.
IS 531 : Lecture 2
31
Systems Development Objectives
• To ensure the information system satisfies an
organization’s informational and operational
needs (product-oriented objective).
• To develop/acquire an information system in
an efficient and effective manner (processoriented objective).
IS 531 : Lecture 2
32
Characteristics of a Systems
Development Methodology
• Divide project into identifiable processes, each
having a starting and ending point.
• Produce deliverables to monitor process.
• Require signoffs.
• Test system before implementation.
• Conduct training.
• Use program change controls.
• Conduct post-implementation review.
IS 531 : Lecture 2
33
Classic Systems
Development Process
IS 531 : Lecture 2
34
Systems Development
Process Phases
•
•
•
•
•
•
•
•
Scope Definition Phase
Problem Analysis Phase
Requirement Analysis Phase
Logical Design
Decision Analysis Phase
Design Phase
Construction Phase
Implementation Phase
IS 531 : Lecture 2
35
1. Scope Definition
• Purpose: define perceived problems, opportunities,
and directives ; assess the risk of project; establish scope,
preliminary requirements and constraints, participants,
budget and schedule (preliminary study)
• Issues: Is the project worthwhile? (using PIECES
framework) Define the scope of project
• Deliverable: Project charter/plan
•Feasibility check: Cancel project / Approve to continue
/ Reduce or expanse the scope with budget and schedule
modification
IS 531 : Lecture 2
36
2. Problem Analysis
• Purpose: to study and analyze the existing system
from the users’ perspectives as they see Data,
Processes, and Interfaces
• Issue: Cost/benefits of building new system to solve
these problems
• Deliverable: system improvement objectives
(business criteria to evaluate the new system)
• Feasibility check: Cancel project / Approve to
continue / Reduce or expanse the scope with budget
and schedule modification
IS 531 : Lecture 2
37
3. Requirement Analysis
• Purpose: discover users’ needs or expectations out of
the new system in terms of Data, Processes, and
Interfaces
• Issue: Specify requirements for the new system
(WHAT TO BE DONE) without prematurely expressing
technical details (HOW)
• Errors and omissions in requirement analysis result in
user dissatisfaction of final system and costly
modifications
• Deliverable: business requirements statement
IS 531 : Lecture 2
38
4. Logical Design
• Purpose: translating business user requirements
into a system model that depicts only WHAT TO DO
without specifying any possible technical design or
implementation of those requirements (conceptual
design).
• Issue: using graphical model of a system to
represent user requirements in terms of Data,
Processes and Interfaces, and to facilitate improved
communication between system stakeholders.
IS 531 : Lecture 2
39
5. Decision Analysis
• Purpose: identify all candidate solutions, analyze the
feasibility of each candidate, recommend a candidate
system as the target solution
• Issue: Feasibility analysis in terms of technical,
operational, economic, schedule (TOES), and risk
•Deliverable: approved system proposal
•Feasibility check: Cancel project / Approve system
proposal with budget and schedule modification /
Reduce the scope of proposed solution with budget
and schedule modification
IS 531 : Lecture 2
40
6. Physical Design
• Purpose: to transform business requirements into
technical design specifications for construction
• Issue: HOW technology will be used to build the
system in terms of Data, Processes, and Interfaces
• Design by Specifications vs. Design by Prototyping
• Deliverable: System design specifications (blueprints)
•Feasibility check: Continue/ Reduce or expanse the
scope with budget and schedule modification
IS 531 : Lecture 2
41
7. Construction Phase
• Purpose: to build and test a system that fulfill
business requirements and design specs; implement
interfaces between new and existing systems
• Issue: Construct database, application programs,
user/system interfaces, implement purchased or
leased software
• Deliverable: proposed system within budget and
schedule
IS 531 : Lecture 2
42
8. Implementation Phase
• Purpose: deliver the production system into
operation
• Issue: Train users, write manuals, load files,
populate database, final test
• Conversion plan: parallel systems, switch point
• Deliverable: system up and running
IS 531 : Lecture 2
43
Operation and Support
• Ongoing system support would be provided until
the system becomes obsolete and is replaced by a
new one
• Issues: technical support for user, fixing bugs,
recovering plan, adapt to emerging requirements
• When a system has reached entropy, new project
for new system should be initiated
IS 531 : Lecture 2
44
Summary:
Systems Development Process
• Scope Definition Phase: What Business Problem
• Problem Analysis Phase: What System Issues (Info/Data,
Processes, Communications/Interfaces)
• Requirement Analysis Phase: What User Needs
• Logical Design: (Conceptual Model) – What to Do
• Decision Analysis Phase: What Solution
• Design Phase: (Physical Model) - How IT Can Do
• Construction Phase: Do It
• Implementation Phase: Use It
IS 531 : Lecture 2
45
Systems Development as
Problem Solving
IS 531 : Lecture 2
46
Feasibility Analysis
• Technical feasibility is a measure of the practicality of a
specific technical solution and the availability of technical
resources and expertise.
• Operational feasibility is a measure of how well the
solution will work in the organization. It is also a measure
of how people feel about the system/project.
• Economic feasibility is a measure of the costeffectiveness of a project or solution.
• Schedule feasibility is a measure of how reasonable the
project timetable is.
• Risk feasibility – What is the probability of a successful
implementation using the technology and approach?
(Risk Management)
IS 531 : Lecture 2
47
Costs and Benefits
• Direct costs (benefits): directly attributable to
the system or the system change.
– Direct costs include equipment purchased,
personnel salaries, site preparation, and materials
and supplies.
– Direct benefits include items such as reduced
personnel and hardware costs, and improved data
reliability.
IS 531 : Lecture 2
48
Costs and Benefits . . .
• Indirect costs (benefits): not directly
attributable to the system or the system
change.
– Indirect costs are those associate with overhead
expenses, such as personnel fringe benefits and
utilities.
– Indirect benefits are most difficult to quantify.
Ex: an indirect benefit is increased revenue
resulting from improved customer support
IS 531 : Lecture 2
49
Costs and Benefits ...
• Tangible costs (benefits): can be reasonably
quantified.
– Costs include software purchases and insurance
– Benefits include reduced equipment costs and
increased revenue.
• Intangible cost (benefit): cannot be reasonably
quantified.
– Costs include productivity loss caused by low
employee morale.
– Benefits may accrue from improved information.
IS 531 : Lecture 2
50
Costs and Benefits ...
• Nonrecurring costs, such as those for systems
development, are incurred only once to get
the system operational (development costs).
• Recurring costs, such as those for equipment
rental, occur throughout all or most of the
system’s life (operational costs).
IS 531 : Lecture 2
51
Economic Feasibility
• Payback Analysis
– Payback analysis is to determine if and when an
investment will pay for itself.
– Payback period is the period of time that will
lapse before accrued benefits overtake accrued
and continuing costs.
• Net Present Value
– a dollar today is worth more than a dollar one
year from now
– Discount rate : a percentage that the business
earns on investing money in other projects or
investments: opportunity cost
IS 531 : Lecture 2
52
Economic Feasibility …
• Return-on-Investment (ROI) Analysis
– Lifetime ROI =(estimated lifetime benefits –
estimated lifetime costs) / estimated lifetime
costs
– Annual ROI = lifetime ROI / lifetime of the
system
IS 531 : Lecture 2
53
Scheduling Strategies
• Forward Scheduling – a project
scheduling approach that establishes a
project start date and then schedules
forward from that date.
• Reverse Scheduling – a project scheduling
strategy that establishes a project
deadline and then schedules backward
from that date.
IS 531 : Lecture 2
54
Project Initiation
5-3-2001
N/A
5-3-2001
N/A
PERT Chart
Task
Scheduled Scheduled
Start
Finish
Actual
Actual Start
Finish
Preliminary Investigation
5-3-2001
5-12-2001
5-3-2001
5-11-2001
Problem Analysis
Task
intertask
dependency
Scheduled Scheduled
Start
Finish
Actual
Actual Start
Finish
Legend
Requirements Analysis
Decision Analysis
5-12-2001
6-12-2001
5-28-2001
7-15-2001
6-13-2001
7-30-2001
5-12-2001
6-14-2001
5-30-2001
7-18-2001
6-13-2001
8-3-2001
Design
Construction
7-3-2001
9-25-2001
7-19-2001
11-13-2001
7-5-2001
10-9-2001
7-20-2001
In Progress
Implementation
IS 531 : Lecture 2
9-10-2001
12-14-2001
TBD
TBD
55
Critical Path
TASKD
Duration
Tue 2/20/01 7 days
Tue 2/20/01 0 days
TASKA
TASKB
TASKC
Mon 2/5/01 3 days
Wed 2/7/01 2 days
Fri 2/9/01
Mon 2/5/01 0 days
Wed 2/7/01 0 days
Fri 2/9/01
TASKE
TASKI
2 days
Mon 2/19/016 days
Tue 2/27/01 5 days
0 days
Tue 2/20/01 1 day
Tue 2/27/01 0 days
TASKF
TASKG
Wed 2/14/013 days
Fri 2/16/01 2 days
Fri 2/16/01 2 days
Tue 2/20/01 2 days
Slack Time
TASKH
Thu 2/15/01 1 day
Tue 2/20/01 3 days
IS 531 : Lecture 2
56
Gantt Chart
ID
Task Name
2001
May
1
Preliminary investigation
2
Problem analysis
3
Requirements analysis
4
Decision analysis
5
Design
6
Construction
7
Implementation
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Today
Complete Task
Legend
Incomplete Task
IS 531 : Lecture 2
57
In-Sourcing Vs. Outsourcing
• In-sourcing (Build) –Uses professional
expertise within an organization to develop
and maintain its information technology
systems
• Outsourcing (Buy) – Obtains services from
a software developer
IS 531 : Lecture 2
58
Tasks for “Build” Option
• Design the Application Architecture
– Defines technologies to be used and used to build
• Design the System Databases
– Database schema
• Design the System Interface
– User Interfaces: Input, output, and dialogue
specifications
• Package Design Specifications
– Specifications for programmers
IS 531 : Lecture 2
59
Tasks for “Buy” Option
•
•
•
•
Research Technical Criteria and Options
Solicit Proposals/Quotes from Vendors
Validate Vendor Claims and Performances
Evaluate and Rank Vendor Proposals: Gap Analysis
on the differences between proposed and desired
features. Also Cost/Benefit Analysis.
• Contract “Winning” Vendor and Debrief “Losing”
Vendors
IS 531 : Lecture 2
60
Systems Acceptance Test
• Systems Acceptance Test – a test performed
on the final system wherein users conduct a
verification, validation, and audit test.
– Uses real data over an extended time period
– Extensive test that addresses: verification testing,
validation testing, and audit testing.
•Verification Testing runs the system in a simulated
environment using simulated data.
– Checks for errors and omissions regarding end-use and
design specifications
IS 531 : Lecture 2
61
Systems Acceptance Test …
• Validation testing runs the system in a live
environment using real data.
– Testing:
• Systems performance (throughput and response time)
• Peak workload performance
• Human engineering
• Methods and procedures
• Backup and recovery
• Audit testing certifies that the system is free of errors
and is ready to be placed into operation.
IS 531 : Lecture 2
62
Tasks in Implementation Phase
•
•
•
•
•
Conduct System Test
Prepare Conversion Plan
Install Databases
Train Users
Convert to New System
IS 531 : Lecture 2
63
System Conversion
IS 531 : Lecture 2
64
Installation/Conversion
Approaches
Abrupt
Cutover
R
i
s
k
Location
Conversion
Staged
Conversion
Parallel
Conversion
Cost
IS 531 : Lecture 2
65
Post-Implementation Review
• Post-implementation review: examination of
a working information system, conducted
soon after that system’s implementation, to
determine if:
– user’s requirements have been satisfied
– development effort was efficient and conducted in
accordance with the organization’s systems
development standards.
IS 531 : Lecture 2
66
Post Implementation Review…
• Determine if the user is satisfied with the new
system.
• Identify how well the system’s achieved
performance corresponds to the performance
requirements, recommending improvements
if necessary.
• Evaluate the quality of the new system’s
documentation, training programs, and data
conversions.
IS 531 : Lecture 2
67
Post Implementation Review…
• Ascertain that the organization’s project
management framework and SDLC were followed
during development.
• Recommend improvements to the systems
development/acquisition standards manual if
necessary.
• Improve the cost/effectiveness analysis process by
reviewing cost projections and benefit estimations
and determining the degree to which these were
achieved.
IS 531 : Lecture 2
68
System Support Activities
• Program Maintenance corrects “bugs” or errors
that slipped through the system development
process.
• System Recovery is the restoration of the system
and data after a system failure.
• Technical Support is any assistance provided to
users in response to inexperience or unanticipated
situations.
• System Enhancement is the improvement of the
system to handle new business problems, new
technical problems, or new technology
requirements.
IS 531 : Lecture 2
69
System Maintenance
Objectives
• To make predictable changes to existing programs to
correct errors.
• To preserve those aspects of the programs that were
correct, and to avoid “ripple effects” of changes that
may adversely affect the correctly functioning
aspects.
• To avoid, as much as possible, the degradation of
system performance.
• To complete the task as quickly as possible without
sacrificing quality and reliability of the system.
IS 531 : Lecture 2
70
System Obsolescence
• All systems degrade over time (entropy)
• At some point, not cost-effective to support
and maintain
• Leads to a new systems development project
• New cycle of SDLC
IS 531 : Lecture 2
71
Typical Contents of
a Systems Proposal
IS 531 : Lecture 2
72
Measures of Project Success
• The resulting information system is
acceptable to the user.
• The system was delivered “on time.”
• The system was delivered “within budget.”
• The system development process had a
minimal impact on ongoing organizational
operations.
IS 531 : Lecture 2
73