Transcript section I Introduction

Review 1
Chapters 1 - 4
Systems definition example
System: An interrelated set of components, with an identifiable
boundary, working together for some purpose
General System Depiction
Environment: Everything external to a system that interacts with the system.
General System Depiction
Boundary: The line that marks the inside and outside of a system and that sets
off the system from its environment.
General System Depiction
Components: An irreducible part or aggregation of parts that make up a
system, also called a subsystem..
General System Depiction
Interrelationship: Dependence of one subsystem on one or more
subsystems.
General System Depiction
Input: Whatever a system takes from its environment in order to fulfill its purpose.
General System Depiction
Output: Whatever a system returns to its environment in order to fulfill its
purpose.
General System Depiction
Interfaces: Point of contact where a system meets its environment or where
subsystems meet each other.
Information Systems Defined
• An information system is a well-coordinated collection of
resources that gather and transform data into information
products and services that help the enterprise perform its
designed functions
• An information system hierarchy associates different
classifications of information systems with different
audiences
10
Information System Hierarchy
11
The Systems Development Life Cycle
The systems development life
cycle (SDLC) consists of five
major phases:
•
•
•
•
•
Analysis
Design
Development
Implementation
Maintenance
12
The Circular SDLC
13
Information System Components
There are six major information system
components:
•
•
•
•
•
•
People
Procedures
Software
Hardware
Networks
Data
Reference Figure 1-7: Information System Components
14
The Role of the Analyst
• An agent of change
• A problem-solving strategist
• A group facilitator
• Four Sets of Analytical Skills
–
–
–
–
Systems Thinking
Organizational Knowledge
Problem Identification
Problem Analyzing and Solving
15
Basic Information-Processing
Requirements
Information must be:
• Relevant
• Accurate
• Timely
• Usable
• Affordable
• Adaptable
• Accessible
Reference Figure 2-1: Basic Information Processing Requirements
16
Figure 2-2: Symptom, Problem, Solution
Summary (1/3)
Basic Requirement
Symptom
Problem
Solution
Relevancy
The system is not used
User needs have changed
Involve the user in the
redesign process
Accuracy
Reports are incomplete or
erroneous
The data input procedures
are confusing or too
demanding
Simplify data capture
through source document
redesign or the use of input
automation
Timeliness
Response time to user
requests for information is
increasing
Input and/or output
demands exceed the
capabilities of the system
Automate input, upgrade
the output and disk storage
devices and/or processor
speed
17
Figure 2-2: Symptom, Problem, Solution
Summary (2/3)
Basic Requirement
Symptom
Problem
Solution
Usability
Users are confused
about how to use the
system
Outputs are
inappropriately designed
or they are poorly
documented
Redesign the outputs
and/or improve the
documentation, then
retrain the users
Affordability
System costs are
increasing more than
user productivity
One or more of the
system elements are
mismatched
Evaluate the system
mismatches to see if they
can be minimized or
commence a new SDLC
18
Figure 2-2: Symptom, Problem, Solution
Summary (3/3)
Basic Requirement
Symptom
Problem
Solution
Adaptability
Users have abandoned
some parts of the system
The system is
approaching functional
obsolescence
Upgrade to a more
powerful computer
platform to allow for
software upgrades
Accessibility
Users must alter work
patterns to retrieve
information
The information delivery
system does not match
work patterns
Redesign the distribution
and retrieval system to
include online and ondemand access
19
Feasibility Analysis
Given the project objectives, cost constraints, and
delivery date, is there a practical solution to the problem?
•
Build strategies
– Develop your own programs
– Customize horizontal software
•
Buy strategies
– Purchase vertical software
– Purchase a turnkey system
20
Feasibility Analysis
Vertical Software
Advantages:
• Available immediately
• Verifiable track record
• Generally tailored to the enterprise
• Fixed price
Disadvantages:
• Difficult to modify
• Must rely on long-distance assistance
• May not address all the user’s problems
• May include features the user doesn’t need
Reference Figure 2-6: Advantages and Disadvantages of Vertical Software
21
Feasibility Analysis
The project contract consists of:
1.
2.
3.
4.
Problem Summary
Scope
Constraints
Objectives
Reference Figure 2-7: The Initial Project Contract
22
Process Modeling
• Graphically represent the processes that capture, manipulate, store
and distribute data between a system and its environment and
among system components
• Data flow diagrams (DFD)
– Graphically illustrate movement of data between external entities and
the processes and data stores within a system
• Modeling a system’s process
– Utilize information gathered during requirements determination
– Structure of the data is also modeled in addition to the processes
Process Modeling
• Deliverables and Outcomes
– Set of coherent, interrelated data flow diagrams
– Context data flow diagram (DFD)
• Scope of system
– DFDs of current system
• Enables analysts to understand current system
– DFDs of new logical system
• Technology independent
• Show data flows, structure and functional requirements of new system
– Project dictionary and CASE repository
Symbol Standards
•
Activity or function – verb
•
Collection of data – noun
•
External entity – noun
•
Logical “collection” of
information in motion - noun
Context DFD - Food Ordering System
Level 0 DFD
Level 0 Diagram
• ‘Decomposition’ of Context Diagram
• Represents the major functions of a system
• Answers question – “What does the system
fundamentally do”?
• Highest level of detail
• Each process is numbered ‘n’ or ‘n.0’
• May show data stores
Continuing the Functional
Decomposition
Continue the Functional
Decomposition
• Further ‘Decompose’ each process:
– Level 1 to Level 2
– Level 2 to Level 3 etc
• Decompose Level 0 Process 1.0, number Level 1
Processes as 1.1, 1.2, 1.3, 1.4 etc.
• Decompose Level 1 Process 1.1, number Level 2
Processes as 1.1.1, 1.1.2, 1.1.3, 1.1.4 etc.
• No fixed number of processes at each level
• Goal is to make the diagram readable and
meaningful
Data Flow Diagramming
Mechanics
• Data Flow
– Depicts data that are in motion and moving as a unit from one place to
another in the system.
– Drawn as an arrow
– Select a meaningful name to represent the data
• Data Store
– Depicts data at rest
– May represent data in
• File folder
• Computer-based file
• Notebook
– The name of the store as well as the number are recorded in between
lines
Data Flow Diagramming
Mechanics
• Process
– Depicts work or action performed on data so that they are
transformed, stored or distributed
– Number of process as well as name are recorded
• Source/Sink
–
–
–
–
–
Depicts the origin and/or destination of the data
Sometimes referred to as an external entity
Drawn as a square symbol
Name states what the external agent is
Because they are external, many characteristics are not of interest
to us
Data Flow Diagramming
Definitions
• 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 system’s major processes,
data flows and data stores at a high level of detail
Decomposition of DFDs
• Functional decomposition
– Act of going from one single system to many component processes
– Repetitive procedure
– 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
Four Different Types of DFDS
• Current Physical
– Process label includes an identification of the technology (people or
systems) used to process the data
– Data flows and data stores are labeled with the actual name of the
physical media on which data flow or in which data are stored
• New Physical
– Represents the physical implementation of the new system
Four Different Types of DFDS
• Current Logical
– Physical aspects of system are removed as much as possible
– Current system is reduced to data and processes that transform them
• New Logical
– Includes additional functions
– Obsolete functions are removed
– Inefficient data flows are reorganized
Guidelines for Drawing DFDs
• Completeness
– DFD must include all components necessary for system
– Each component must be fully described in the project dictionary
or CASE repository
• Consistency
– The extent to which information contained on one level of a set
of nested DFDs is also included on other levels
Guidelines for Drawing DFDs
• Timing
– Time is not represented well on DFDs
– Best to draw DFDs as if the system has never started and will
never stop.
• Iterative Development
– Analyst should expect to redraw diagram several times before
reaching the closest approximation to the system being modeled
Guidelines for Drawing DFDs
• Primitive DFDs
– Lowest logical level of decomposition
– Decision has to be made when to stop decomposition
Guidelines for Drawing DFDs
• Rules for stopping decomposition
– When each process has been reduced to a single decision, calculation
or database operation
– When each data store represents data about a single entity
– When the system user does not care to see any more detail
Guidelines for Drawing DFDs
• Rules for stopping decomposition (continued)
– When every data flow does not need to be split further to show that data
are handled in various ways
– When you believe that you have shown each business form or
transaction, on-line display and report as a single data flow
– When you believe that there is a separate process for each choice on all
lowest-level menu options
Using DFDs as Analysis Tools
• Gap Analysis
– The process of discovering discrepancies between two or more
sets of data flow diagrams or discrepancies within a single DFD
• Inefficiencies in a system can often be identified through
DFDs
Data Fundamentals
Data Definition and Structure:
•
Data is defined by three attributes: name, size, and type
–
–
–
•
Data names provide unique and descriptive labels
Data size determines the amount of space required to store the data
Data type specifies how the computer stores the data and restricts how the
data can be used
Data elements are organized into structures
–
–
a record is a collection of related data elements or fields
a data file is a collection of related records
File Processing Fundamentals
Data File Types:
•
One way to classify files is to consider how file content
correlates to events or activities within the enterprise
– A master files is a collection of data that represents an
identifiable person or thing
– A transaction file is a collection of data that represents a
particular event or activity of the enterprise
File Processing Fundamentals
Database Structure:
•
A relational database is a collection of data files that are tied
together by common fields
•
The records in each data file are distinguished from one
another by key fields
•
A key field may contain a unique value, known as a primary
key value.
Entity Relationship Diagrams
•
•
•
•
The entity-relationship diagram (ERD) presents the data
model
The data stores of the DFD become the entities of the ERD
Entities are related to one another when they share a
common field
Cardinality is the term used to describe the nature of the
entity relationship, which may be:
– one-to-one
– one-to-many
– many-to-many
Three Normal Forms
Formal database design theory outlines a process that ensures
file efficiency, referred to as normalcy.
•First normal (1NF) eliminates repeating groups
•Second normal form (2NF) requires every field to be dependent
on or determined by the key field
•Third normal form (3NF) requires that all of the dependencies be
contained within the file