Post on 08-Sep-2014
description
transcript
kipram 1
BAB IIIDATA MODELING dan
ANALYSIS
kipram 2
Performing Requirements Determination
Gather information on what system should do from many sources� Users� Reports
� Forms� Procedures
A. Determining System Requirements
kipram 3
Performing Requirements Determination
Characteristics for gathering requirements� Impertinence
� Question everything
� Impartiality� Find the best organizational solution
� Relaxation of constraints� Attention to detail� Reframing
� View the organization in new ways
kipram 4
Deliverables and OutcomesTypes of deliverables:� Information collected from users� Existing documents and files� Computer-based information� Understanding of organizational components
� Business objective� Information needs� Rules of data processing� Key events
kipram 5
Traditional Methods for Determining Requirements
Interviewing and Listening� Gather facts, opinions and speculations� Observe body language and emotions� Guidelines
� Plan� Checklist� Appointment
� Be neutral� Listen� Seek a diverse view
kipram 6
Traditional Methods for Determining Requirements
Interviewing (Continued)� Interview Questions
� Open-Ended� No pre-specified answers
� Close-Ended� Respondent is asked to choose from a set of specified
responses
� Additional Guidelines� Do not phrase questions in ways that imply a wrong or
right answer� Listen very carefully to what is being said� Type up notes within 48 hours� Do not set expectations about the new system
kipram 7
Traditional Methods for Determining Requirements
Administering Questionnaires� More cost-effective than interviews� Choosing respondents
� Should be representative of all users� Types of samples
� Convenient� Random sample� Purposeful sample� Stratified sample
kipram 8
Traditional Methods for Determining Requirements
Questionnaires� Design
� Mostly closed-ended questions� Can be administered over the phone or in
person
� Vs. Interviews� Interviews cost more but yield more information� Questionnaires are more cost-effective� See table 7-4 for a complete comparison
kipram 9
Traditional Methods for Determining Requirements
Interviewing Groups� Advantages
� More effective use of time� Enables people to hear opinions of others and to agree
or disagree
� Disadvantages� Difficulty in scheduling
� Nominal Group Technique� Facilitated process to support idea generation by groups� Individuals work alone to generate ideas which are
pooled under guidance of a trained facilitator
kipram 10
Traditional Methods for Determining Requirements
Directly Observing Users� Serves as a good method to supplement
interviews� Often difficult to obtain unbiased data
� People often work differently when being observed
kipram 11
Analyzing Procedures and Other Documents
Types of information to be discovered:� Problems with existing system� Opportunity to meet new need� Organizational direction� Names of key individuals� Values of organization� Special information processing circumstances� Reasons for current system design� Rules for processing data
kipram 12
Analyzing Procedures and Other Documents
Four types of useful documents� Written work procedures
� Describes how a job is performed� Includes data and information used and created in the
process of performing the job or task
� Business form� Explicitly indicate data flow in or out of a system
� Report � Enables the analyst to work backwards from the report to
the data that generated it
� Description of current information system
kipram 13
Modern Methods for Determining Requirements
Joint Application Design (JAD)� Brings together key users, managers and systems
analysts� Purpose: collect system requirements
simultaneously from key people� Conducted off-site
Prototyping� Repetitive process� Rudimentary version of system is built� Replaces or augments SDLC� Goal: to develop concrete specifications for
ultimate system
kipram 14
Joint Application Design (JAD)Participants� Session Leader� Users� Managers� Sponsor� Systems Analysts� Scribe� IS Staff
kipram 15
Joint Application Design (JAD)End Result� Documentation detailing existing system
� Features of proposed system
CASE Tools During JAD� Upper CASE tools are used � Enables analysts to enter system models directly into CASE
during the JAD session� Screen designs and prototyping can be done during JAD
and shown to users
Supporting JAD with GSS� Group support systems (GSS) can be used to enable more
participation by group members in JAD� Members type their answers into the computer� All members of the group see what other members have
been typing
kipram 16
Prototyping
Quickly converts requirements to working version of systemOnce the user sees requirements converted to system, will ask for modifications or will generate additional requestsMost useful when:� User requests are not clear� Few users are involved in the system� Designs are complex and require concrete form� History of communication problems between
analysts and users� Tools are readily available to build prototype
kipram 17
Prototyping
Drawbacks� Tendency to avoid formal documentation� Difficult to adapt to more general user
audience
� Sharing data with other systems is often not considered
� Systems Development Life Cycle (SDLC) checks are often bypassed
kipram 18
Business Process Reengineering (BPR)Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services
Goals� Reorganize complete flow of data in major sections of an
organization� Eliminate unnecessary steps� Combine steps� Become more responsive to future change
7.187.18
Identification of processes to reengineer� Key business processes
� Set of activities designed to produce specific output for a particular customer or market
� Focused on customers and outcome� Same techniques are used as were used for requirements
determination
kipram 19
Business Process Reengineering (BPR)
Identify specific activities that can be improved through BPRDisruptive technologies� Technologies that enable the breaking of
long-held business rules that inhibit organizations from making radical business changes
�
kipram 20
B. Structuring System Requirements:1. Process Modeling
kipram 21
Process ModelingGraphically 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
Deliverables and Outcomes� Set of coherent, interrelated data flow diagrams
kipram 22
Process Modeling
Deliverables and outcomes (continued)� 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 systemProject dictionary and CASE repository
kipram 23
Data Flow Diagramming Mechanics
Four symbols are used� See Figure 8-2� Two different standard sets can be used
� DeMarco and Yourdan� Gane and Sarson
kipram 24
Figure 8-2Comparison of DeMarco & Yourdan and Gane &
Sarson DFD symbol sets
kipram 25
Data Flow Diagramming MechanicsData 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
kipram 26
Data Flow Diagramming MechanicsProcess� Depicts work or action performed on data so that they are
transformed, stored or distributed� Number of process as well as name are recorded
8.268.26
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
kipram 27
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
kipram 28
Developing DFDs: An Example
Hoosier Burger’s automated food ordering systemContext Diagram (Figure 8-4) contains no data storesNext step is to expand the context diagram to show the breakdown of processes (Figure 8-5)
kipram 29
Figure 8-4Context diagram of Hoosier Burger’s
food ordering system
kipram 30
Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system
kipram 31
Data Flow Diagramming Rules
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
kipram 32
Data Flow Diagramming RulesProcess� 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
kipram 33
Data Flow Diagramming RulesSource/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
kipram 34
Data Flow Diagramming RulesData Flow (Continued)L. 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
M. A data flow cannot go directly back to the same process it leaves
N. A data flow to a data store means updateO. A data flow from a data store means retrieve or
useP. A data flow has a noun phrase label
kipram 35
Decomposition of DFDsFunctional 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
kipram 36
Balancing DFDsWhen decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decompositionThis is called balancingExample: Hoosier Burgers� In Figure 8-4, notice that there is one input to the
system, the customer order� Three outputs:
� Customer receipt� Food order� Management reports
kipram 37
Balancing DFDs
Example (Continued)� Notice Figure 8-5. 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
kipram 38
Balancing DFDs
An unbalanced example� Figure 8-10� 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
kipram 39
Figure 8-10An unbalanced set of data flow diagrams
(a) Context diagram(b) Level-0 diagram
kipram 40
Balancing DFDs
We can split a data flow into separate data flows on a lower level diagram (see Figure 8-11)Balancing leads to four additional advanced rules (See Table 8-3)
kipram 41
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
kipram 42
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
New Physical� Represents the physical implementation of the
new system
kipram 43
Guidelines for Drawing DFDsCompleteness� 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
kipram 44
Guidelines for Drawing DFDsTiming� 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
Primitive DFDs� Lowest logical level of decomposition� Decision has to be made when to stop
decomposition
kipram 45
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
kipram 46
Guidelines for Drawing DFDsRules 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
kipram 47
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
kipram 48
Using DFDs in Business Process Reengineering
Example: IBM Credit� See Figure 8-20 – before reengineering� Credit approval process required six days
before BPR� Figure 8-21 depicts DFD after
reengineering� IBM was able to process 100 times the
number of transactions in the same amount of time
kipram 49
Oracle’s Process Modeler and Functional Hierarchy Diagrams
Process Modeler� Unique to Oracle� Similar to DFDS but outputs and methods differ in
several ways.� Table 8-4 illustrates differences
Functional Hierarchy Diagrams� Picture of various tasks performed in a business
and how they are related� Tasks are broken down into their various parts� Does not include data flows
kipram 50
Simple Data Flow Diagram
Data flow
Process
External agent
(entity)
Data store (internal entity)
kipram 51
Process Decomposition
kipram 52
Decomposition Diagrams
kipram 53
Illegal Data Flows
Practice data flow conservation –only data needed should move
kipram 54
SummaryData flow diagrams (DFD)� Symbols� Rules for creating� Decomposition� Balancing
Four different kinds of DFDs� Current Physical� Current Logical� New Logical� New Physical
kipram 55
Summary
DFDs for AnalysisDFDs for Business Process Reengineering (BPR)Oracle’s Process ModelerFunctional Hierarchy Diagrams
8.558.55
kipram 56
2. Logic Modeling
kipram 57
Logic Modeling
Data flow diagrams do not show the logic inside the processesLogic modeling involves representing internal structure and functionality of processes depicted on a DFDLogic modeling can also be used to show when processes on a DFD occur
kipram 58
Logic Modeling
Deliverables and Outcomes� Structured English� Decision Tables
� Decision Trees� State-transition diagrams
� Sequence diagrams� Activity diagrams
kipram 59
Modeling Logic with Structured English
Modified form of English used to specify the logic of information processesUses a subset of English� Action verbs� Noun phrases
� No adjectives or adverbs
No specific standards
kipram 60
Modeling Logic with Structured English
Similar to programming language� If conditions� Case statements
Figure 9-3 shows Structured English representation for Hoosier Burger
kipram 61
Modeling Logic withDecision Tables
A matrix representation of the logic of a decisionSpecifies the possible conditions and the resulting actionsBest used for complicated decision logic
Consists of three parts� Condition stubs
� Lists condition relevant to decision� Action stubs
� Actions that result from a given set of conditions� Rules
� Specify which actions are to be followed for a given set of conditions
kipram 62
Modeling Logic withDecision Tables
Indifferent Condition� Condition whose value does not affect which
action is taken for two or more rules
Standard procedure for creating decision tables� Name the condition and values each condition can
assume� Name all possible actions that can occur� List all rules� Define the actions for each rule� Simplify the table
kipram 63
Figure 9-4Complete decision table for payroll system example
kipram 64
Modeling Logic with Decision Trees
A graphical representation of a decision situationDecision situation points are connected together by arcs and terminate in ovalsTwo main components� Decision points represented by nodes� Actions represented by ovals
kipram 65
Modeling Logic with Decision Trees
Read from left to rightEach node corresponds to a numbered choice on a legendAll possible actions are listed on the far right
kipram 66
Figure 9-9Decision tree representation of the decision logic in the decision tables in Figures 9-4 and 9-5, with only two choices per decision
point
kipram 67
Deciding Among Structured English, Decision Tables and Decision Trees
BestBestThird BestChecking Consistency and Completeness
BestThird BestBestTransforming Conditions and Actions into Sequence
BestThird BestSecond BestDetermining Conditions and Actions
Decision Trees
Decision Tables
Structured English
Criteria
kipram 68
Summary
Several methods of logic modeling� Structured English
� Primarily communication technique for analysts and users
� Decision Tables� Conditions are listed in condition stubs� Possible actions are listed in action stubs� Rules link conditions with actions
kipram 69
Summary
Decision Tables� Lists all possible rules
Decision Trees� Conditions are portrayed by decision points
� Values are represented by paths between decision points and ovals that contain actions
kipram 70
Summary
Comparison of Structured English, Decision Tables and Decision Trees� Most studies show that decision trees are
best for many criteria� There is no best technique
� Analyst must be proficient in all three
kipram 71
C. Conceptual Data Modeling
kipram 72
Learning Objectives�Define key data modeling terms
� Entity type� Attribute� Multivalued attribute� Relationship� Degree� Cardinality� Business Rule� Associative entity� Trigger� Supertype� Subtype
kipram 73
Conceptual Data Modeling
Representation of organizational dataPurpose is to show rules about the meaning and interrelationships among dataEntity-Relationship (E-R) diagrams are commonly used to show how data are organizedMain goal of conceptual data modeling is to create accurate E-R diagramsMethods such as interviewing, questionnaires and JAD are used to collect informationConsistency must be maintained between process flow, decision logic and data modeling descriptions
kipram 74
Process of Conceptual Data Modeling
First step is to develop a data model for the system being replacedNext, a new conceptual data model is built that includes all the requirements of the new systemIn the design stage, the conceptual data model is translated into a physical designProject repository links all design and data modeling steps performed during SDLC
kipram 75
Deliverables and Outcome
Primary deliverable is the entity-relationship diagramThere may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling� Covers just data needed in the project’s
application� E-R diagram for system being replaced� An E-R diagram for the whole database from
which the new application’s data are extracted� An E-R diagram for the whole database from
which data for the application system being replaced is drawn
kipram 76
Figure 10-3Sample conceptual data model diagram
kipram 77
Deliverables and OutcomeSecond deliverable is a set of entries about data objects to be stored in repository or project dictionary� Repository links data, process and logic models of
an information system� Data elements that are included in the DFD must
appear in the data model and visa versa� Each data store in a process model must relate to
business objects represented in the data model
kipram 78
Gathering Information for Conceptual Data Modeling
Two perspectives� Top-down
� Data model is derived from an intimate understanding of the business
� Bottom-up� Data model is derived by reviewing
specifications and business documents
kipram 79
Introduction to Entity-Relationship (E-R) Modeling
Notation uses three main constructs� Data entities� Relationships
� Attributes
Entity-Relationship (E-R) Diagram� A detailed, logical representation of the
entities, associations and data elements for an organization or business
kipram 80
Entity-Relationship (E-R) ModelingKey TermsEntity
� A person, place, object, event or concept in the user environment about which the organization wishes to maintain data
� Represented by a rectangle in E-R diagrams
Entity Type� A collection of entities that share common
properties or characteristics
Attribute� A named property or characteristic of an entity that
is of interest to an organization
kipram 81
Entity-Relationship (E-R) ModelingKey TermsCandidate keys and identifiers
� Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type
� Candidate key� Attribute (or combination of attributes) that
uniquely identifies each instance of an entity type
kipram 82
Entity-Relationship (E-R) ModelingKey Terms
Identifier� A candidate key that has been selected as the
unique identifying characteristic for an entity type� Selection rules for an identifier
1. Choose a candidate key that will not change its value2. Choose a candidate key that will never be null3. Avoid using intelligent keys4. Consider substituting single value surrogate keys for
large composite keys
kipram 83
Entity-Relationship (E-R) ModelingKey Terms
Multivalued Attribute� An attribute that may take on more than
one value for each entity instance
� Represented on E-R Diagram in two ways:� double-lined ellipse� weak entity
kipram 84
Entity-Relationship (E-R) ModelingKey TermsRelationship
� An association between the instances of one or more entity types that is of interest to the organization
� Association indicates that an event has occurred or that there is a natural link between entity types
� Relationships are always labeled with verb phrases
kipram 85
Conceptual Data Modeling and the E-R Diagram
Goal� Capture as much of the meaning of the data as
possible
Result� A better design that is easier to maintain
kipram 86
Degree of Relationship
Degree� Number of entity types that participate in a
relationship
Three cases� Unary
� A relationship between two instances of one entity type
� Binary� A relationship between the instances of two entity types
� Ternary� A simultaneous relationship among the instances of
three entity types� Not the same as three binary relationships
10.8610.86
kipram 87
Figure 10-6Example relationships of different degrees
kipram 88
Cardinality
The number of instances of entity B that can be associated with each instance of entity AMinimum Cardinality� The minimum number of instances of entity B that
may be associated with each instance of entity A
Maximum Cardinality� The maximum number of instances of entity B that
may be associated with each instance of entity A
kipram 89
Naming and Defining Relationships
Relationship name is a verb phraseAvoid vague names
Guidelines for defining relationships� Definition explains what action is being taken and
why it is important� Give examples to clarify the action� Optional participation should be explained� Explain reasons for any explicit maximum
cardinality
10.8910.89
kipram 90
Naming and Defining Relationships
Guidelines for defining relationships� Explain any restrictions on participation in
the relationship� Explain extent of the history that is kept in
the relationship� Explain whether an entity instance involved
in a relationship instance can transfer participation to another relationship instance
kipram 91
Associative Entity
An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances
10.9110.91
kipram 92
DomainsThe set of all data types and ranges of values that an attribute can assumeSeveral advantages
1. Verify that the values for an attribute are valid
2. Ensure that various data manipulation operations are logical
3. Help conserve effort in describing attribute characteristics
kipram 93
Triggering Operations
An assertion or rule that governs the validity of data manipulation operations such as insert, update and deleteIncludes the following components:� User rule
� Statement of the business rule to be enforced by the trigger
� Event� Data manipulation operation that initiates the operation
� Entity Name� Name of entity being accessed or modified
� Condition� Condition that causes the operation to be triggered
� Action� Action taken when the operation is triggered
kipram 94
Triggering Operations
Responsibility for data integrity lies within scope of database management system, not individual applications
kipram 95
The Role of CASE in Conceptual Data
CASE tools provide two important functions:� Maintain E-R diagrams as a visual
depiction of structured data requirements� Link objects on E-R diagrams to
corresponding descriptions in a repository
kipram 96
SummaryProcess of conceptual data modeling� Deliverables� Gathering information
Entity-Relationship Modeling� Entities� Attributes� Candidate keys and identifiers� Multivalued attributes
Degree of relationship
kipram 97
Summary
CardinalityNaming and defining relationshipsAssociative entitiesDomainsTriggering OperationsRole of CASE