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.