IS Theories

1
IS Theories Practices
CSUN Information Systems

• Systems
• Architecture
• Infrastructure

IS 655 Supplementary Note 1
2
Modified Zachman Framework The Product
3
Modified Zachman Framework The Stakeholders
4
Modified Zachman Framework The Product Components
5
Modified Zachman Framework The Building Process
6
Modified Zachman Framework
7
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

8
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

9
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.

10
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

11
Problem Statement
12
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

13
System Improvement Objectives
14
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)

15
SoundStage System Context
16
Soundstage Process Model
17
SoundStage Data Model
18
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

19
Candidate Systems Matrix
20
Candidate Systems Matrix
21
Feasibility Matrix
22
Costs for Proposed Systems Solution
23
Net Present Value Analysis
24
Payback Analysis
25
Project Scheduling
26
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)

27
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

28
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

29
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