Post on 18-Jan-2018
description
Span of Control
CEO
VPFinance
Finance Dept.
VP Marketing
Marketing Dept.
VPAcctg
Acctg Dept.
CEO
VPIS
Plant Operations
VPMfg.
Excess Span of Control
VPFinance
Finance Dept.
VPAcctg
Marketing Dept.
VPMarketing
Acctg Dept.
ISDirector
Plant Operations
VPMfg.
CFO CIO COO
ISDept.
Hierarchical Span of Control
Module Fan-Out1.0
PayrollProgram
1.4Calculate
Deductions
1.0Payroll Program
1.2.1Calculate Gross Pay
1.4Update Payroll
Record
1.5CalculateNet Pay
1.6Generate Paycheck
1.7Update Payroll
Record
1.3Calculate Gross Pay
1.2Edit Payroll Record
1.1
Get Payroll Record
1.2.2Calculate
Taxes
1.2.3Calculate
Deductions
1.2.4CalculateNet Pay
1.4.1Print
Payroll Report
1.4.2Append
Payroll File
1.1.1Edit Payroll Record
1.3GeneratePaycheck
1.2Calculate
Employee Pay
1.1Get Payroll
Record
High Fan-Out
Low Fan-Out
DFD vs. Hierarchical Structure Diagram
READINPUTDATA
1.0EDIT
INPUTDATA
2.0PROCESS
DATA
3.0FORMATOUTPUT
4.0DISPLAYOUTPUT
5.0
INPUT STREAM OUTPUT STREAMCENTRAL TRANSFORM
(a)
(b)
THE
SYSTEM
GENERATEOUTPUT
PROCESSDATA
GETINPUTDATA
DISPLAYOUTPUT
FORMATOUTPUT
EDITINPUTDATA
READINPUTDATA
RAW DATA EDIT FLAG
INPUT OUTPUT
OUTPUT
FORMATTED OUTPUT
FORMATTED OUTPUTRAW DATA
INPUT OUTPUT
INPUT STREAM OUTPUT STREAM
Conversion to HSD
1.0PROCESS
A
2.0PROCESS
B
3.0PROCESS
C
1.0PROCESS
A
2.0PROCESS
B
3.0PROCESS
C
4.0PROCESS
D
SOURCE
B DATA STORE
A DATA STORE
B DATA STORE
C DATA STORE
A DATA STORE
C DATA STORE
(a)
(b)
SINK
SOURCE
SINK
Adding Data Access and Maintenance Processes to DFD
1.0
PROCESS
1.0READDATA
2.0
PROCESS
4.0DELETE
DATA
5.0UPDATE
DATA
SOURCE
B DATA STORE
A DATA STORE
B DATA STORE
C DATA STORE
A DATA STORE
C DATA STORE
(a)
(b)
SOURCE
D DATA STORE
New Data
Deleted Data
Updated Data
3.0ADD
NEW DATA
DC DATA STORE
Afferent, Transform and Efferent Processes
1.0
PROCESS
MAIN CONTROL
3.0
PROCESS
2.0
PROCESS
4.0
PROCESS
5.0
PROCESS
6.0
PROCESS
7.0
PROCESS
9.0
PROCESS
8.0
PROCESS
10.0
PROCESS
Afferent EfferentTransform
AFFERENT TRANSFORM EFFERENT
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0
First Draft Structure Diagram
1.0
PROCESSCLIENTORDER
1.1
INPUTCLIENTDATA
1.2
PROCESSORDER
RECORD
1.3
PRODUCE
WHSE.REQUEST
1.4
SENDCLIENT
CONFIRM
Level 0
Level 1
(a)
(b)
afferent transform efferent
PROCESSCLIENTORDER
INPUTCLIENTDATA
PROCESS ORDER RECORD
PRODUCEWHSE.REQUEST
SEND CLIENT CONFIRM
Client data
Orderdetail
OrderdetailClient
data
Orderheader
Order detail
Shippinginfo
Client data
Detailed Structure Diagram
Clientdata
CREATE SHIPPING LABEL
CREATE PICK LIST
PROCESS ORDERED ITEM
GET ORDERDATA
CREATECLIENT
RECORD
GETCLIENTDATA
CREATEITEM
DETAIL
GET PRODUCT RECORD
CHECK IN-STOCK
LEVEL
PROCESSCLIENTORDER
INPUTCLIENTDATA
PROCESS ORDER RECORD
PRODUCEWHSE.
REQUEST
SEND CLIENT
CONFIRM
Client data
Orderdetail
Orderdetail
Clientdata
Orderheader
Order detail
Shippinginfo
Client data
Clientdata
Orderdetail
Product ID
Orderdetail
Clientdata
Product ID
Valid flagProduct
detail
Productdetail
Transaction Analysis Approach
1.0
PROCESS
THESYSTEM
2.0
PROCESS
3.0
PROCESS
4.0
PROCESS
5.0
PROCESS6.0
PROCESS
Transaction Center
GET B TRANSACTION CENTER
(MAKE B INTO G)
OUTPUT G
GET A PROCESS1.0
PROCESS 2.0
PROCESS 3.0
PROCESS 4.0
PROCESS6.0
PUT H
PROCESS 5.0
A B
C
D
E
F
G H
A A BD
B CC
E
GB
D
F
GE
F
HHG
GB
System Design GuidelinesDesign Guideline Explanation
Factor
The system should be factored, or decomposed, into small modules which conform to both the size and cohesion guidelines of good design.
Span of Control No parent module should be given control over more than 5 to 7 child, or subordinate, modules.
Coupling The extent to which modules are dependent on each other should be minimized such that the amount of communication between dependent modules is also minimized. Ideally, module communication should occur only via passed data elements and informational flags.
Size A reasonable size for a single module is considered to be between 50 and 100 lines of executable code.
Cohesion The instructions contained within a module should pertain only to that function. This suggests that a well-factored module should be describable in a few simple words with no “and” or “or” in the module name.
Shared Use
Wherever possible, a child module should be called by multiple parent modules.