Vous êtes sur la page 1sur 47

The System Environment

What is a SYSTEM?
A composite of equipment, skills, techniques, and information capable of performing and/or supporting an operational role in attaining specified management objectives. Includes related facilities, equipment, material, service personnel, and information required for its information to degree that it can be considered a selfsufficient unit in its intended operational and/or support environment.

Terminal FILE

Computer Processing Unit

Computer System

Theoretical View of System


Theoretical approaches to systems have introduced 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 system environment. Subsystems Part of systems function.

A GOOD system will be made up of highly independent subsystems with minimal flows between them. Minimizing flows minimizes, in turn complexity and simplifies the system.

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.

Typical Information Systems


Human Resource System One important subsystem in most organizations is the personnel system which keeps personal details about people organization. Typical Information included is data about employees date of birth, addresses, marital status and medical histories. Personnel system also keep information on employment histories, VL and SL records, position held and any special assignments. Records of skills, qualifications and special courses attended by employees are also stored in personal system.

Customer or Client System The goal of this system is to provide service to the clients. There is a lot of variety but all follow a similar pattern. They usually begin with the client approaching the organization with a specific request. The request is recorded and check to see if requested service can be provided. If it can, arrangements are made within organizations to provide the service. This may involve arranging of some goods to be delivered or payments to be made to the clients. Usually the client system follows up a requests to ensure that the service is carried out and to answer any customer queries about the service.

Inventory Control System The primary goal of inventory control system is to ensure that all necessary parts are available at all times. However, this does not mean that as many items as possible should be stored in the warehouse. Stored items do not cost money and do not generate any returns while stored. Thus an inventory system must maintain the minimum possible number of items in store while ensuring that needed items are always available. A distinction can be made between two kinds of inventory. One is an inventory of parts purchased by the organization for its internal use or to produce other products, while the other is an inventory of parts produced or purchased by the organization for sale to its customer.

Accounting System The 3 major subsystems of accounting are: Accounts Receivable - subsystem includes invoicing, credit checking, recording payments and sales, general analysis and reporting. Accounts Payable - subsystem that is the reverse of Accounts Receivable General Accounts Subsystem produces reports about the organizations assets and its resources.

Marketing System Marketing system publicize 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.

Systems Design (definition)


The complete plan for producing an operational system, which includes problem description, algorithm, development, flowcharting, coding, program debugging and documentation.

Linear Cycle
Systems Analysis HLAD Feasibility Study

Problem Definition

Systems Design
Detail Design

Development System Implementation Post Implementation Review

Implementation Maintenance Working System

Stage Design
Feasibility Study Define stages

Problem Definition

Feasibility Study

Systems Analysis

System Design

System Implementation

Stage 1

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 system is 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 the next part to be developed. This part is being developed and the process continues.

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 with computers or in novel applications where there is no previous experience. Instead it is more appropriate to develop the system a little bit at a time, learning about system capabilities as one goes along.

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 clear how the system work. Decision support systems have a further degree of uncertainty because it is not clear whether a computer can be used at all to solve problem.

Evolutionary Design Method


User Suggestion

Inception

Initial Grouping

Pilot system developed in conjunction with user

Design/ Program/ Test

Mutual Progress

Conversion

Transfer of ownership (usually a gradual activity) Through out the design Process.

Conversion

Operation of final product

Maturity

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 the feasibility of a new system and then virtually thrown away. The new system is then built from scratch.

Advantage of Protyping
More clearly identify system objectives More clearly identify critical problems More clearly identify logical solutions

Prototyping in Systems Development


System Problem Evaluate Feasibility Implementation Prototyping

Detailed Designed

No Yes Identify Critical Logical Operation

Evaluate Alternative Physical Implementation

Linear Prototype Development Cycle

Suggest Alternative Logical Solutions

Implementing Evolution Design and Prototyping


Evolutionary design and prototyping call for special development methods. These life cycles require experimentation and continual change to develop systems. We do not want a situation where every change requires us to throw away what has been done so far and start again, so we require development techniques that allow us to make changes or add new components without an ordinate amount of programming. The alternative cycles become very attractive if this can be done.

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

Benefits of Information Systems Architecture


Provides a basis for strategic planning of IS Provides a basis for communicating with top management and a context for budget decisions concerning IS Provides a unifying concept for the various stakeholders in information systems. Communicates the overall direction for information technology and a context for decisions in this area Helps achieve information integration when systems are distributed (increasing important in a global economy) Provides a basis for evaluating technology options (for example, downsizing and distributed processing)

ISA Framework Components


Data Process
The What of the information system The How of the information system The Where of the information system Who performs processes and are the source and receiver of data and information. When processes are performed Why: For events and rules that govern processing

Network

People

Events and Points in time

Reasons

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)

Data Flow Diagrams


DFD symbols
External entities (sources and sinks) Data Stores Data Flows Processes

Types of diagrams Step by step approach Rules

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

Some Rules for Data Stores


Internal to the system Data at rest Include in system if the system processes transform the data
Store, Add, Delete, Update

Every data store on DFD should correspond to an entity on an ERD Data stores can come in many forms:
Hanging file folders Computer-based files Notebooks

Some Rules for Data Flows


Data in motion, moving from one place to another in the system
From external entity (source) to system From system to external entity (sink) From internal symbol to internal symbol, but always either start or end at a process
Data Flow

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)

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 the furnace or instruct a robot) Use stored data (create, read, update or delete a record)

Processes

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 systems major processes, data flows and data stores at a high level of detail

Figure A Context diagram of Hoosier Burgers Food ordering system

Figure B Level-0 DFD of Hoosier Burgers food ordering system

Creating Data Flow Diagrams


Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create a preliminary Context Diagram 2. Identify Use Cases, i.e. the ways in which users most commonly 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.

Data Flow Diagramming Rules


General Specific rules to
Symbols Context Diagram Level 0 and lower decompositions Balancing across levels

DFD RulesGeneral
Basic rules that apply to all DFDs
Inputs to a process are always different than outputs Objects always have a unique name
In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram

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 directly from 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

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 exactly the same data goes from a common location to two or more processes, data stores or sources/sinks

DFD RulesSymbols (cont)


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

any two or more different processes, data stores or sources/sinks to a common location A data flow cannot go directly back to the same process 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

DFD RulesContext Diagram


One process, numbered 0. Sources and sinks (external entities) as squares Main data flows depicted No internal data stores are shown
They are inside the system External data stores are shown as external entities

Decomposition of DFDs
Functional decomposition
Act of going from one single system to many component processes This is a repetitive procedure allowing us to provide more and more detail as necessary The lowest level is called a primitive DFD

Level-N Diagrams
A DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram

DFD RulesBalancing DFDs


When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level 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

DFD RulesBalancing DFDs


Example (Continued)
Notice Figure B. We have the same inputs and outputs No new inputs or outputs have been introduced We can say that the context diagram and level-0 DFD are balanced

Figure C An unbalanced set of data flow diagramswhy? (a) Context diagram (b) Level-0 diagram

DFD RulesBalancing DFDs


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

Vous aimerez peut-être aussi