IS Theories & Practices Systems Architecture & Infrastructure IS 655: Supplementary Note 1...

IS Theories & Practices

SystemsArchitecture & InfrastructureIS 655:

Supplementary Note 1

CSUN Information Systems

Modified Zachman FrameworkThe Product

2

3

Modified Zachman FrameworkThe Stakeholders

Modified Zachman FrameworkThe Product Components

4

5

Modified Zachman FrameworkThe Building Process

6

Modified Zachman Framework

7

Systems Development Process

Scope Definition Phase: What Business ProblemProblem Analysis Phase: What System Issues

(Info/Data, Processes, Communications/Interfaces)Requirement Analysis Phase: What User NeedsLogical Design: Conceptual Model – What to DoDecision Analysis Phase: What SolutionDesign Phase: Physical Model: How to DoConstruction Phase: Do ItImplementation Phase: Use It

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

13

System Improvement Objectives

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

15

SoundStage System Context

16

Soundstage Process Model

17

SoundStage Data Model

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

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