1. Span of Control CEO VP Finance Finance Dept. VP Marketing Marketing Dept. VP Acctg Acctg Dept. CEO VP IS Plant Operations VP Mfg. Excess Span of Control VP Finance Finance Dept. VP Acctg Marketing Dept. VP Marketing Acctg Dept. IS Director Plant Operations VP Mfg. CFO CIO COO IS Dept. Hierarchical Span of Control

2. Module Fan-Out 1.0 Payroll Program 1.4 Calculate Deductions 1.0 Payroll Program 1.2.1 Calculate Gross Pay 1.4 Update Payroll Record 1.5 Calculate Net Pay 1.6 Generate Paycheck 1.7 Update Payroll Record 1.3 Calculate Gross Pay 1.2 Edit Payroll Record 1.1 Get Payroll Record 1.2.2 Calculate Taxes 1.2.3 Calculate Deductions 1.2.4 Calculate Net Pay 1.4.1 Print Payroll Report 1.4.2 Append Payroll File 1.1.1 Edit Payroll Record 1.3 Generate Paycheck 1.2 Calculate Employee Pay 1.1 Get Payroll Record High Fan-Out Low Fan-Out

3. DFD vs. Hierarchical Structure Diagram READ INPUT DATA 1.0 EDIT INPUT DATA 2.0 PROCESS DATA 3.0 FORMAT OUTPUT 4.0 DISPLAY OUTPUT 5.0 INPUT STREAM OUTPUT STREAM CENTRAL TRANSFORM (a) (b) THE SYSTEM GENERATE OUTPUT PROCESS DATA GET INPUT DATA DISPLAY OUTPUT FORMAT OUTPUT EDIT INPUT DATA READ INPUT DATA RAW DATA EDIT FLAG INPUT OUTPUT OUTPUT FORMATTED OUTPUT FORMATTED OUTPUT RAW DATA INPUT OUTPUT INPUT STREAM OUTPUT STREAM

4. Conversion to HSD 1.0 PROCESS A 2.0 PROCESS B 3.0 PROCESS C 1.0 PROCESS A 2.0 PROCESS B 3.0 PROCESS C 4.0 PROCESS 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

5. Adding Data Access and Maintenance Processes to DFD 1.0 PROCESS 1.0 READ DATA 2.0 PROCESS 4.0 DELETE DATA 5.0 UPDATE 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.0 ADD NEW DATA DC DATA STORE

6. 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 Efferent Transform AFFERENT TRANSFORM EFFERENT 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0

7. First Draft Structure Diagram 1.0 PROCESS CLIENT ORDER 1.1 INPUT CLIENT DATA 1.2 PROCESS ORDER RECORD 1.3 PRODUCE WHSE. REQUEST 1.4 SEND CLIENT CONFIRM Level 0 Level 1 (a) (b) afferent transform efferent PROCESS CLIENT ORDER INPUT CLIENT DATA PROCESS ORDER RECORD PRODUCE WHSE. REQUEST SEND CLIENT CONFIRM Client data Order detail Order detail Client data Order header Order detail Shipping info Client data

8. Detailed Structure Diagram Client data CREATE SHIPPING LABEL CREATE PICK LIST PROCESS ORDERED ITEM GET ORDER DATA CREATE CLIENT RECORD GET CLIENT DATA CREATE ITEM DETAIL GET PRODUCT RECORD CHECK IN-STOCK LEVEL PROCESS CLIENT ORDER INPUT CLIENT DATA PROCESS ORDER RECORD PRODUCE WHSE. REQUEST SEND CLIENT CONFIRM Client data Order detail Order detail Client data Order header Order detail Shipping info Client data Client data Order detail Product ID Order detail Client data Product ID Valid flag Product detail Product detail

9. Transaction Analysis Approach 1.0 PROCESS THE SYSTEM 2.0 PROCESS 3.0 PROCESS 4.0 PROCESS 5.0 PROCESS 6.0 PROCESS Transaction Center GET B TRANSACTION CENTER (MAKE B INTO G) OUTPUT G GET A PROCESS 1.0 PROCESS 2.0 PROCESS 3.0 PROCESS 4.0 PROCESS 6.0 PUT H PROCESS 5.0 A B C D E F G H A A B D B C C E G B D F G E F H H G G B

10. System Design Guidelines Design 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.