Transcript Document 7300692

CSUN Information Systems
IS Theories & Practices
IS 655:
Supplementary
Note 1
Systems
Architecture
& Infrastructure
Modified Zachman Framework
The Product
2
Modified Zachman Framework
The Stakeholders
3
Modified Zachman Framework
The Product Components
4
Modified Zachman Framework
The Building Process
5
Modified Zachman Framework
6
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 to Do
 Construction Phase: Do It
 Implementation Phase: Use It
7
1. Scope Definition
• Purpose: define perceived problems, opportunities,
and directives (POD); 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
8
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.
9
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
10
Problem Statement
11
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
12
System Improvement
Objectives
13
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.
•Caution: Analysis paralysis – excessive system
modeling dramatically slows progress toward
implementation of the intended system solution.
•Deliverable: Logical Systems Models (DFD, ERD
etc)
14
SoundStage System Context
15
Soundstage Process Model
16
SoundStage Data Model
17
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
Candidate Systems Matrix
19
Candidate Systems Matrix…
20
Feasibility Matrix
21
Costs for Proposed
Systems Solution
22
Net Present Value Analysis
23
Payback Analysis
24
Project Scheduling
25
Decision Analysis
 Candidate solutions evaluated in terms of TOES and Risks:
– Technical feasibility – Is the solution technically practical? Does
our staff have the technical expertise to design and build this
solution?
– Operational feasibility – Will the solution fulfill the users’
requirements? To what degree? How will the solution change the
users’ work environment? How do users feel about such a solution?
– Economic feasibility – Is the solution cost-effective?
– Schedule feasibility – Can the solution be designed and
implemented within an acceptable time?
– Risk feasibility – What is the probability of a successful
implementation using the technology and approach? (Risk
Management)
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
27
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
28
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
29