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