isad chapter 1

7/29/2019 Isad Chapter 1

1/47

The System Environment

What is a SYSTEM? A composite of equipment, skills, techniques, and

information capable of performing and/or supportingan operational role in attaining specified management

objectives. Includes related facilities, equipment, material,

service personnel, and information required for itsinformation to degree that it can be considered a self-sufficient unit in its intended operational and/orsupport environment.


2/47

FILE

Computer Processing Unit

Terminal

Computer System


3/47

Theoretical View of System

Theoretical approaches to systems haveintroduced many generalized principles.

Goal Setting Defines what exactly the system

wants to do.System Boundary Concerned with system

structure and behavior.

Environment Anything outside the systemenvironment.

Subsystems Part of systems function.


4/47

A GOOD system willbe made up ofhighly independentsubsystems withminimal flows

between them.

Minimizing flowsminimizes, in turncomplexity and simplifies

the system.


5/47

Why is Systems Analysis

Necessary? To set-up the right procedures to ensure

that all organizations personnel have all

the data needed for their work. Systems Analysis provides understanding

of the existing system before system

design commences.


6/47

Typical Information Systems

Human Resource System One importantsubsystem in most organizations is thepersonnel system which keeps personal detailsabout people organization. Typical Information

included is data about employees date of birth,addresses, marital status and medical histories.Personnel system also keep information onemployment histories, VL and SL records,position held and any special assignments.Records of skills, qualifications and specialcourses attended by employees are also storedin personal system.


7/47

Customer or Client System The goal of thissystem is to provide service to the clients. Thereis a lot of variety but all follow a similar pattern.They usually begin with the client approachingthe organization with a specific request. Therequest is recorded and check to see ifrequested service can be provided. If it can,

arrangements are made within organizations toprovide the service. This may involve arrangingof some goods to be delivered or payments tobe made to the clients. Usually the client systemfollows up a requests to ensure that the service

is carried out and to answer any customerqueries about the service.


8/47

Inventory Control System The primary goal ofinventory control system is to ensure that allnecessary parts are available at all times.

However, this does not mean that as many itemsas possible should be stored in the warehouse.Stored items do not cost money and do notgenerate any returns while stored. Thus aninventory system must maintain the minimum

possible number of items in store while ensuringthat needed items are always available. Adistinction can be made between two kinds ofinventory. One is an inventory of partspurchased by the organization for its internal useor to produce other products, while the other isan inventory of parts produced or purchased bythe organization for sale to its customer.


9/47

Accounting System The 3 major subsystems

of accounting are:Accounts Receivable - subsystem includes

invoicing, credit checking, recording paymentsand sales, general analysis and reporting.

Accounts Payable - subsystem that is thereverse of Accounts Receivable

General Accounts Subsystem producesreports about the organizations assets and its

resources.


10/47

Marketing System Marketing systempublicize the organization to its external

environment. This involves many

things, such as preparing information

about the services and disseminating it

to potential customers. Such activity

may include advertising, mailouts or

simply visiting the customer.


11/47

Systems Design

(definition) The complete plan for producing

an operational system, which

includes problem description,algorithm, development,

flowcharting, coding, program

debugging and documentation.


12/47

Linear Cycle ProblemDefinition

Feasibility

StudySystems

Analysis

Systems Design

HLAD

Detail

Design

Development

Implementation

Maintenance

Post ImplementationReview

System Implementation

Working System


13/47

Stage DesignFeasibility

Study

Define

stages

Problem

Definition

Feasibility

Study

Systems

Analysis

System Implementation

System Design

Stage 1


14/47

Alternative Life Cycles

Evolutionary Design does not assume that we

can subdivide the problem into distinct and

loosely-coupled phases and design the system

in one pass through these phases. The systemis developed gradually. We developed a system

part and learn more about the problem from the

operation of that part. With the knowledge

gained from this operation we can define thenext part to be developed. This part is being

developed and the process continues.


15/47

Imprecise Systems

Imprecise systems occur when it is not

possible to start with a set of precise

system requirements. This often occurs in

the organizations that are just starting withcomputers or in novel applications where

there is no previous experience. Instead it

is more appropriate to develop the systema little bit at a time, learning about system

capabilities as one goes along.


16/47

Decision Support Systems

The problem here differs from that found in

imprecise systems, where it is clear that

the system will eventually do what is

expected to it, even though it is not clearhow the system work. Decision support

systems have a further degree of

uncertainty because it is not clear whethera computer can be used at all to solve

problem.


17/47

Evolutionary Design Method

User

Suggestion

Pilot system

developed

in conjunction

with user

Design/

Program/ Test

Transfer of ownership (usually

a gradual activity)

Through out the design

Process.

Conversion

Operation of

final product

Inception

Initial Grouping

Mutual Progress

Conversion

Maturity


18/47

Prototypes

Prototyping differs from evolutionary

design in one significant way. A prototype

is often considered to be a model of a

proposed system. It is built to illustrate thefeasibility of a new system and then

virtually thrown away. The new system is

then built from scratch.


19/47

Advantage of Protyping

More clearly identify system objectives

More clearly identify critical problems

More clearly identify logical solutions


20/47

Prototyping in Systems

DevelopmentSystem

Problem

Evaluate

Feasibility

Prototyping

No

Yes

Identify

Critical

Logical

Operation

Suggest

Alternative

Logical

Solutions

Evaluate

Alternative

Physical

Implementation

Detailed

Designed

Implementation

Linear Prototype

Development Cycle


21/47

Implementing Evolution Design and

Prototyping

Evolutionary design and prototyping call forspecial development methods. These life cyclesrequire experimentation and continual change todevelop systems. We do not want a situationwhere every change requires us to throw awaywhat has been done so far and start again, sowe require development techniques that allowus to make changes or add new components

without an ordinate amount of programming.The alternative cycles become very attractive ifthis can be done.


22/47

Information Systems Architecture

An ISA is a conceptual blueprint or plan

that expresses the desired future structure

for information systems in an organization

It provides a context within which

managers throughout the organization can

make consistent decisions concerning

their information systems


23/47

Benefits of Information Systems

Architecture

Provides a basis for strategic planning of IS Provides a basis for communicating with topmanagement and a context for budgetdecisions concerning IS

Provides a unifying concept for the various

stakeholders in information systems. Communicates the overall direction for

information technology and a context fordecisions in this area

Helps achieve information integration when

systems are distributed (increasing importantin a global economy) Provides a basis for evaluating technology

options (for example, downsizing anddistributed processing)


24/47

ISA Framework Components

Data The What of the information system

Process The How of the information system

Network

The Where of the information system People

Who performs processes and are the source and receiver ofdata and information.

Events and Points in time When processes are performed

Reasons Why: For events and rules that govern processing


25/47

Six roles or perspectives of the Data,

Process and Network components

Business scope (Owner)

Business model (Architect)

Information systems model (Designer) Technology model (Builder)

Technology definition (Contractor)

Information system (User)


26/47

Data Flow Diagrams

DFD symbols

External entities (sources and sinks)

Data Stores

Data Flows

Processes

Types of diagrams

Step by step approach

Rules


27/47

Some Rules for External

Entities External people, systems and data

stores

Reside outside the system, but

interact with system

Either a) receive info from system,

b) trigger system into motion, or c)

provide new information to system

e.g. Customers, managers

Not clerks or other staff who simply

move data

External

Entities


28/47

Some Rules for Data Stores

Internal to the system

Data at rest

Include in system if the systemprocesses transform the data

Store, Add, Delete, Update

Every data store on DFD shouldcorrespond to an entity on an ERD

Data stores can come in many

forms: Hanging file folders Computer-based files

Notebooks


29/47

Some Rules for Data Flows

Data in motion, moving from

one place to another in the

system

From external entity (source) tosystem

From system to external entity

(sink)

From internal symbol to internalsymbol, but always either start

or end at a process

Data Flow


30/47

Some Rules for Processes

Always internal to system

Law of conservation of data:

#1: Data stays at rest unless

moved by a process.

#2: Processes cannot consume or create data Must have at least 1 input data flow (to avoid miracles)

Must have at least 1 output data flow (to avoid black holes) Should have sufficient inputs to create outputs (to avoid

gray holes)


31/47

Processes Logical process models omit any processes that do

nothing more than move or route data, thus leaving the

data unchanged. Valid processes include those that:

Perform computations (e.g., calculate grade point

average)

Make decisions (determine availability of ordered

products)

Sort, filter or otherwise summarize data (identify

overdue invoices)

Organize data into useful information (e.g., generate

a report or answer a question)

Trigger other processes (e.g., turn on thefurnace orinstruct a robot)

Use stored data (create, read, update or delete a

record)


32/47

Types of Diagrams

Context Diagram

A data flow diagram (DFD) of the scope of an

organizational system that shows the system

boundaries, external entities that interact with the

system and the major information flows between the

entities and the system

Level-O Diagram

A data flow diagram (DFD) that represents a systemsmajor processes, data flows and data stores at a high

level of detail


33/47

Figure A

Context diagram of Hoosier Burgers Food ordering

system


34/47

Figure B

Level-0 DFD of Hoosier Burgers food ordering system


35/47

Creating Data Flow Diagrams

Creating DFDs is a highly iterative process of gradualrefinement.

General steps:

1. Create a preliminary Context Diagram

2. Identify Use Cases, i.e. the ways in which users mostcommonly use the system

3. Create DFD fragments for each use case

4. Create a Level 0 diagram from fragments

5. Decompose to Level 1,2,6. Go to step 1 and revise as necessary

7. Validate DFDs with users.


36/47

Data Flow Diagramming Rules

General

Specific rules to

Symbols

Context Diagram

Level 0 and lower decompositions

Balancing across levels


37/47

DFD RulesGeneral

Basic rules that apply to all DFDs

Inputs to a process are always different than

outputs

Objects always have a unique nameIn order to keep the diagram uncluttered, you can

repeat data stores and sources/sinks on a diagram


38/47

DFD RulesSymbols

Process

No process can have

only outputs (a

miracle)

No process can have

only inputs (black

hole)

A process has a verb

phrase label

Data Store

Data cannot be moved

directly from one store to

another

Data cannot move directlyfrom an outside source to a

data store

Data cannot move directly

from a data store to a data

sink Data store has a noun

phrase label


39/47

DFD RulesSymbols (cont)

Source/Sink

Data cannot move

directly from a source

to a sink

A source/sink has a

noun phrase label

Data Flow

A data flow has only one

direction of flow between

symbols

A fork means that exactlythe same data goes from a

common location to two or

more processes, data

stores or sources/sinks


40/47

DFD RulesSymbols (cont)

Data Flow (Continued) A join means that exactly the same data comes from

any two or more different processes, data stores orsources/sinks to a common location

A data flow cannot go directly back to the sameprocess it leaves

A data flow to a data store means update

A data flow from a data store means retrieve or use

A data flow has a noun phrase label


41/47

DFD RulesContext Diagram

One process, numbered 0.

Sources and sinks (external entities) assquares

Main data flows depicted No internal data stores are shown

They are inside the system

External data stores are shown as externalentities


42/47

Decomposition of DFDs

Functional decomposition

Act of going from one single system to many

component processes

This is a repetitive procedure allowing us to providemore and more detail as necessary

The lowest level is called a primitive DFD

Level-N Diagrams

A DFD that is the result ofn nested decompositions ofa series of subprocesses from a process on a level-0

diagram


43/47

DFD RulesBalancing DFDs

When decomposing a DFD, you must conserveinputs to and outputs from a process at the nextlevel of decomposition. This is called balancing.

Example: Hoosier Burgers In Figure B, notice that there is one input to the

system, the customer order

Three outputs: Customer receipt

Food order Management reports


44/47


Example (Continued)

Notice Figure B. We have the same inputs

and outputs

No new inputs or outputs have beenintroduced

We can say that the context diagram and

level-0 DFD are balanced


45/47

Figure C

An unbalanced set of data flow diagramswhy?

(a) Context diagram (b) Level-0 diagram


46/47


An unbalanced example, Figure C

In context diagram, we have one input to the

system, A and one output, B

Level-0 diagram has one additional data flow,C

These DFDs are not balanced


47/47

isad chapter 1

Documents