ELECTRONIC TRANSPARENCIES

ELECTRONIC TRANSPARENCIES D I S K 1

ELECTRONIC TRANSPARENCIES DISK 1 MODERN SYSTEMS ANALYSIS AND DESIGN Jeffrey A. Hoffer Joey F. George Joseph S. Valacich B THE BENJAMIN/CUMMINGS PUBLISHING COMPANY, INC. READING, MASSACHUSETTS MENLO PARK, CALIFORNIA NEW YORK DON MILLS, ONTARIO HARLOW, U.K. AMSTERDAM BONN PARIS MILAN MADRID SYDNEY SINGAPORE TOKYO SEOUL TAIPEI MEICO CITY SAN JUAN, PUERTO RICO

CONTENTS Disk 1 Part I Defining the Context for Systems Development Chapter 1 Figure 1-1 The Systems Development Environment Differences among data, data flow, and processing logic Figure 1-2a Figure 1-2b Figure 1-3 Figure 1-7 Traditional approach Database approach Three application systems at Pine Valley Furniture The prototyping methodology Chapter 2 Figure 2-2 A Systems Analysis and Design Project at Pine Valley Furniture System Service Request for Purchasing Fulfillment System Figure 2-4a Figure 2-4b Figure 2-6a Figure 2-6b Figure 2-6c Figure 2-8 Figure 2-10 Figure 2-12 Figure 2-13 Top-down view of Purchasing Fulfillment System: Context diagram Top-down view of Purchasing Fulfillment System: Data flow diagram Analysis phase review meeting excerpts: Entity-relationship (E-R) diagram Analysis phase review meeting excerpts: System benefits, costs, and risks Analysis phase review meeting excerpts: Financial justification Example dialogue tree Conversion and installation plan Example system flow chart Example program structure chart

Part II Preparing and Organizing for Systems Development Chapter 3 Figure 3-2 Figure 3-3 Figure 3-5 Figure 3-6 Figure 3-7 Figure 3-9 Succeeding as a Systems Analyst A general depiction of a system Special characteristics of interfaces Purposes of decomposition An example of system decomposition A fast food restaurant s customer order information system depicted in a data flow diagram Some guidelines for running effective meetings Figure 3-10 ACM Code of Ethics and Professional Conduct (Part 1) Figure 3-10 ACM Code of Ethics and Professional Conduct (Part 2) Chapter 4 Figure 4-2 Figure 4-4 Managing the Information Systems Project A project manager juggles numerous items during a project The project workbook for the Purchasing Fulfillment System project contains both hard copy and electronic documents Figure 4-5a Figure 4-5b Figure 4-7 Figure 4-8a Figure 4-8b Figure 4-11 Figure 4-13 Level of detail in a project plan at the start of the project Level of detail in a project plan in the middle of the project Tradeoffs between the quality of the program code versus the speed of programming Graphical diagrams for depicting project plans: Gantt chart Graphical diagrams for depicting project plans: PERT chart Estimated time calculations for the SPTS project Gantt chart for the SPTS project

Figure 4-14 Figure 4-15 Figure 4-16 Figure 4-20 PERT chart for the SPTS project PERT chart for the SPTS project showing estimated times for each activity and their earliest and latest expected completion time Activity slack time calculations for the SPTS project Viewing project information as a PERT chart in Microsoft Project for Windows Chapter 5 Automating Development through CASE Figure 5-2a Figure 5-2b Figure 5-3 Figure 5-5 Figure 5-6 Figure 5-12 Figure 5-13 Figure 5-14 Figure 5-16 A profile of CASE users: Years of IS experience A profile of CASE users: Number of IS projects Popular uses for CASE The growth of the worldwide CASE market The relationship between CASE tools and the systems development life cycle System development items stored in the CASE repository Common components of a comprehensive CASE repository Data dictionary definition of a repository item from Visible Systems Corporation s VAW CASE environment Impact of documentation quality on system maintenance Part III Chapter 6 Making the Business Case Identifying and Selecting Systems Development Projects Figure 6-2 Project selection decisions must consider numerous factors and can have numerous outcomes

Figure 6-3 Figure 6-7 Figure 6-9 Figure 6-10 Figure 6-11 Figure 6-12 Figure 6-13 Figure 6-14 Figure 6-17 Information systems development projects come from both top-down and bottom-up initiatives Information systems planning is a three-step process Information systems architecture framework Parallel activities of corporate strategic planning and information systems planning Information systems planning information (Pine Valley Furniture) Functional decomposition of information systems planning information (Pine Valley Furniture) Data Entity-to-Function matrix (Pine Valley Furniture) Information System-to-Objective matrix (Pine Valley Furniture) Systems development projects flow from the information systems plan Chapter 7 Figure 7-2 Figure 7-4 Figure 7-5 Figure 7-6 Figure 7-7 Figure 7-8 Figure 7-9 Initiating and Planning Systems Development Projects Statement of Work for the Customer Tracking System (Pine Valley Furniture) Tangible benefits for Customer Tracking System (Pine Valley Furniture) One-time costs for Customer Tracking System (Pine Valley Furniture) Recurring costs for Customer Tracking System (Pine Valley Furniture) Summary spreadsheet reflecting the present value calculations of all benefits and costs for the Customer Tracking System (Pine Valley Furniture) Break-even analysis for Customer Tracking System (Pine Valley Furniture) Effects of degree of project structure, project size, and familiarity with application area on project implementation risk

Figure 7-10 Figure 7-11 Outline of a Baseline Project Plan Statement of project scope (Pine Valley Furniture) Part IV Chapter 8 Analysis Determining System Requirements Figure 8-2a Figure 8-2b Figure 8-6 Typical interview guide Typical interview guide (continued) Illustration of the typical room layout for a JAD Chapter 9 Figure 9-2 Figure 9-4 Figure 9-5 Figure 9-6 Figure 9-7 Figure 9-8 Figure 9-9 Structuring System Requirements: Process Modeling Comparison of DeMarco and Yourdan and Gane & Sarson DFD symbol sets Context diagram of Hoosier Burger s food ordering system Level-0 DFD of Hoosier Burger s food ordering system Incorrect and correct ways to draw data flow diagrams Level-1 diagram showing the decomposition of Process 1.0 from the level-0 diagram for Hoosier Burger s food ordering system Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger s food ordering system Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger s food ordering system Figure 9-10 Figure 9-11 An unbalanced set of data flow diagrams: (a) Context diagram; (b) Level-0 diagram Example of data flow splitting: (a) Composite data flow; (b) Disaggregated data flows

Figure 9-12 Figure 9-13a Figure 9-13b Figure 9-15 Figure 9-16 Figure 9-17 Figure 9-18 List of activities involved in Bob Mellankamp s inventory control system for Hoosier Burger Hoosier Burger s current physical inventory control system: Context diagram Hoosier Burger s current physical inventory control system: Level-0 data flow diagram Level-0 data flow diagram for Hoosier Burger s current logical inventory control system Level-0 data flow diagram for Hoosier Burger s new logical inventory control system Hoosier Burger s hiring procedures: (a) Data flow diagram; (b) Analysis of completeness report from CASE tool VAW repository entry for a data flow Figure 9-19 Class registration system (for Problem and Exercise 6) Figure 9-20 DFD for Problem and Exercise 10 Figure 9-21 DFD for Problem and Exercise 11 Chapter 10 Structuring System Requirements: Logic Modeling Figure 10-2 Figure 10-3 Figure 10-4 Figure 10-5 Figure 10-6 Figure 10-7 Figure 10-8 Current logical DFD for Hoosier Burger s inventory control system Structured English representations of the four processes depicted in Figure 10-2 Complete decision table for payroll system example Reduced decision table for payroll system example Complete decision table for Hoosier Burger s inventory reordering Reduced decision table for Hoosier Burger s inventory reordering Generic decision tree

Figure 10-9 Figure 10-10 Figure 10-11 Figure 10-12 Figure 10-13 Decision tree representation of the decision logic in the decision tables in Figures 10-4 and 10-5, with only two choices per decision point Decision tree representation of the decision logic in the decision tables in Figures 10-4 and 10-5, with multiple choices per decision point State-transition diagram for a two-state coffee maker State-transition diagram for Hoosier Burger s food-ordering system State-transition table for Hoosier Burger s food-ordering system Chapter 11 Structuring System Requirements: Conceptual Data Modeling Figure 11-5 Figure 11-6 Figure 11-7a Figure 11-7b Figure 11-8 Figure 11-9 Figure 11-10 Figure 11-11 Figure 11-12 Figure 11-15 Figure 11-16 Entity-relationship notation Example relationships of different degrees Bill-of-materials unary relationship: Many-to-many Bill-of-materials unary relationship: Two instances Examples of cardinalities in relationships: (a) Mandatory cardinalities; (b) One optional, one mandatory cardinality; (c) Optional cardinalities Example associative entity SHIPMENT entity type (a gerund) Examples of business rules: (a) Simple banking relationship; (b) Typical domain definitions; (c) Typical triggering operation Typical conceptual data model elements in a project dictionary Preliminary E-R diagram for Hoosier Burger s inventory control system Final E-R diagram for Hoosier Burger s inventory control system Figure 11-17 E-R diagram for Problem and Exercise 8 Figure 11-18 E-R diagram for Problem and Exercise 11 Figure 11-19 E-R diagram for Problem and Exercise 16

Chapter 12 Selecting the Best Alternative Design Strategy Figure 12-4 Figure 12-5 Figure 12-6 Figure 12-9 Figure 12-11 The steps in Hoosier Burger s inventory control system Description of three alternative systems that could be developed for Hoosier Burger s inventory system Weighted approach for comparing the three alternative systems for Hoosier Burger s inventory system Hoosier Burger s revised cost-benefit analysis for its Inventory Control System Project Hoosier Burger s revised schedule for its Inventory Control System project

Figure 1-1 Differences among data, data flow, and processing logic Data Data Flow Name John Smith Joan Chen Wilma Alvarez Age 25 42 31 Party Democrat Republican Independent Validate Credit Card Sale Account number and transaction data Valid account number and transaction data Processing Logic Event::Hours-Worked = 0 Event Action:: If Hours-Worked > 40 then Pay = 40 * Pay-Rate + (Hours-Worked - 40) * (1.5 * Pay-Rate) Else Pay = Pay-Rate * Hours-Worked End if Prepare Statement Account number and transactions Statement Transactions

Figure 1-2a Traditional approach Payroll System Project Management System Tax Data Personnel Data Personnel Data Projects Data

Figure 1-2b Database approach Payroll System Project Management System Tax Data Personnel Data Projects Data

Figure 1-3 Three application systems at Pine Valley Furniture Orders Department Accounting Department Payroll Department Program A Program B Program C Program A Program B Program A Program B Order Filling System Invoicing System Payroll System Customer Master File Inventory Master File Back Order File Inventory Pricing File Customer Master File Employee Master File (Source: McFadden and Hoffer, 1994)

Figure 1-7 The prototyping methodology Identify Problem Initial Requirements Develop Prototype Convert to Operational System Working Prototype New Requirements If Prototype Inefficient Implement & Use Prototype Problems Next Version Revise & Enhance Prototype (Adapted from Naumann and Jenkins, 1982)

Figure 2-2 System Service Request for Purchasing Fulfillment System Pine Valley Furniture System Service Request REQUESTED BY DEPARTMENT LOCATION CONTACT TYPE OF REQUEST [ ] [ ] [ ] PROBLEM STATEMENT Juanita Lopez Purchasing, Manufacturing Support Headquarters, 1-322 Tel: 4-3267 FA: 4-3270 e-mail: jlopez URGENCY New System System Enhancement System Error Correction [ [ [ ] ] ] DATE November 1, 1994 Immediate Operations are impaired or opportunity lost Problems exist, but can be worked around Business losses can be tolerated until new system installed Sales growth at PVF has caused greater volume of work for the manufacturing support unit within Purchasing. Further, more concentration on customer service has reduced manufacturing lead times, which puts more pressure on purchasing activities. In addition, cost-cutting measures force Purchasing to be more aggressive in negotiating terms with vendors, improving delivery times, and lowering our investments in inventory. The current modest systems support for manufacturing purchasing is not responsive to these new business conditions. Data are not available, information cannot be summarized, supplier orders cannot be adequately tracked, and commodity buying is not well supported. PVF is spending too much on raw materials and not being responsive to manufacturing needs. SERVICE REQUEST I request a thorough analysis of our current operations with the intent to design and build a completely new information system. This system should handle all purchasing transactions, support display and reporting of critical purchasing data, and assist purchasing agents in commodity buying. IS LIAISON SPONSOR Chris Martin (Tel: 4-6204 FA: 4-6200 e-mail: cmartin) Sal Divario, Director, Purchasing TO BE COMPLETED BY SYSTEMS PRIORITY BOARD [ [ [ [ ] ] ] ] Request approved Assigned to Start date Recommend revision Suggest user development Reject for reason

Figure 2-4a Top-down view of Purchasing Fulfillment System: Context diagram Price & Terms Quotes Shipment Suppliers Production Schedules Production Capacities Material Availability 0 Purchasing Fulfillment System Request for Quotes Order Supplier Material Evaluation Material Specifications Production Schedulers Supplier Material Specifications Engineering

Figure 2-4b Top-down view of Purchasing Fulfillment System: Data flow diagram Production Schedulers Production Schedules 6.0 Order Materials Production Capacities Preferred Supplier 1.0 Forecast Material Needs 4.0 Select Preferred Supplier Material Forecasts Supplier Description Criteria 2.0 Plan Purchase Agreements Price & Term Quotes Supplier Material Evaluations Suppliers Engineering Order Suppliers Bill of Materials 5.0 Produce Bill of Materials Product Design 3.0 Develop Purchased Goods Specs Material Specifications

Figure 2-6a Analysis phase review meeting excerpts: Entity-relationship (E-R) diagram Legend Entity Sends Supplier 4 Supplies Relationships mandatory 1 mandatory many optional many Shipment Receives Item Produces Production Plan Bill of Materials Generates Product Builds Master Schedule

Figure 2-6b Analysis phase review meeting excerpts: System benefits, costs, and risks TANGIBLE ONE-TIME BENEFITS Write-off of obsolete inventory: $ 40,000 Reduction in number of suppliers: 14,000 $ 54,000 TANGIBLE RECURRING ANNUAL BENEFITS Lower inventory carrying costs: $ 23,000 Net materials cost savings: 37,500 Less manufacturing rework: 13,000 Less manufacturing down-time: 25,000 Absorb growth with no additional staff: 32,000 $130,500 TANGIBLE ONE-TIME COSTS System development: $138,000 Equipment: 45,000 Training: 5,000 Conversion and installation: 23,000 $211,000 TANGIBLE RECURRING ANNUAL COSTS Data center charges: $ 39,500 INTANGIBLES Foundation for electronic linkage with suppliers in future Improved purchasing and manufacturing staff morale Improved management reporting and decision making RISKS Possible negative supplier reaction to system changes Poor quality data in current systems may necessitate a costly data cleanup project Potential delays or problems from possible first use of the Sybase client/server database engine by PVF

Figure 2-6c Analysis phase review meeting excerpts: Financial justification 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 A B C D E F G H Pine Valley Furniture Economic Feasibility Analysis Purchasing Fulfillment System Project Year of Project Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTALS Net economic benefit Discount rate (12%) PV of benefits $54,000 1.0000 $54,000 $130,500 0.8929 $116,518 $130,500 0.7972 $104,034 $130,500 0.7118 $92,887 $130,500 0.6355 $82,935 $130,500 0.5674 $74,049 NPV of all BENEFITS One-time COSTS Recurring Costs Discount rate (12%) PV of Recurring Costs NPV of all COSTS Overall NPV $54,000 ($211,000 ) $0 1.0000 $0 ($211,000 ) $170,518 ($39,500 ) 0.8929 ($35,268 ) ($246,268 ) $274,552 ($39,500 ) 0.7972 ($31,489 ) ($277,757 ) $367,439 ($39,500 ) 0.7118 ($28,115 ) ($305,872 ) $450,374 ($39,500 ) 0.6355 ($25,103 ) ($330,975 ) $524,423 ($39,500 ) 0.5674 ($22,416 ) ($353,389 ) $524,423 ($353,389 ) $171,035 Overall ROI - (Overall NPV / NPV of all COSTS).048 Break-even Analysis Yearly NPV Cash Flow Overall NPV Cash Flow ($157,000 ) ($157,000) $81,250 ($75,750) $72,545 ($3,205) $64,772 $61,567 $57,832 $119,399 $51,636 $171,035 Project break-even occurs between years 2 and 3 Use first year of positive cash flow to calculate break-even fraction - ((64,772 / 61,567) / 64,772) =.05 Actual break-even occurred at 2.05 years (about 2 years and 1 month) Note: All dollar values have been rounded to the nearest dollar

Figure 2-8 Example dialogue tree 0 Login Screen System 1 Main Menu 0,System 1.1 Find Suppliers For Item 0,1 1.2 Find Items For Supplier 0,1 1.3 Find Suppliers For Item and Conditions 0,1 1.1.1 Supplier Display 1.3.1 Supplier Display 1,1.1 1.3,1

Figure 2-10 Conversion and installation plan ID Name Duration 1 Start System Conversion 0d 2 Unload current vendor data files 1d 3 Analyze vendor data for errors 2d 4 Clean vendor data files 2d 5 Begin Wood Materials Conversion 0d 6 Extract data for wood materials 1d 7 Clean data for wood materials 1d 8 Load data for wood materials 1d 9 Disable old programs for wood area 1d 10 Add new data for wood materials 1d 11 Run acceptance test for wood area 2d 12 Install new programs for wood area 1d 13 Monitor wood materials use 5d 14 Begin fastener conversion 0d 15 Extract data for fasteners 1d 16 Clean data for fasteners 1d 17 Load data for fasteners 1d 18 Disable old program for fasteners 1d 19 Add new data for fasteners 1d 20 Run acceptance test for fasteners 1d 21 Install new programs for fasteners 1d 22 Monitor fasteners use 3d 23 Terminate conversion 0d Purchasing Fulfillment System Conversion Schedule March 10 March 17 March 24 March 31 M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T Project: Purchasing System Conversion Date: March 15, 1996 Critical Noncritical Progress Milestone Summary Rolled Up

Figure 2-12 Example system flow chart Bill of Materials Production Schedule Legend Online Storage Items to Order Explode Processing Requirements Quotes Display Output Rejected Orders Select Vendor Vendors Printed Output Order Report Tentative Orders Order Confirmations Write Orders Purchase Orders

Figure 2-13 Example program structure chart P.O. Number P.O. Number Write Purchase Order P.O. Number Add New Purchase Order Change Existing Purchase Order Delete Pending Purchase Order Print Purchase Order Vendor Number Vendor Status Order Data Linenum Check for New Vendor Get Basic Purchase Order Data Get Product Data for Purchase Order Legend Module Product_No Product Status Order Quantity Delivery Date data couple Read Product Data for Purchase Get Quantity to Order Get Delivery Terms for Order control flag

Figure 3-2 A general depiction of a system Input Components Environment Boundary Interfaces Interrelationship Output

Figure 3-3 Special characteristics of interfaces INTERFACE FUNCTIONS Because an interface exists at the point where a system meets its environment, the interface has several special, important functions. An interface provides Security, protecting the system from undesirable elements that may want to infiltrate it Filtering unwanted data, both for elements leaving the system and entering it Coding and decoding incoming and outgoing messages Detecting and correcting errors in its interaction with the environment Buffering, providing a layer of slack between the system and its environment, so that the system and its environment can work on different cycles and at different speeds Summarizing raw data and transforming them into the level of detail and format needed throughout the system (for an input interface) or in the environment (for an output interface) Because interface functions are critical in communication between system components or a system and its environment, interfaces receive much attention in the design of information systems (see Chapters 13 and 14).

Figure 3-5 Purposes of decomposition DECOMPOSITION FUNCTIONS Decomposition aids a systems analyst and other systems development project team members by Breaking a system into smaller, more manageable and understandable subsystems Facilitating the focusing of attention on one area (subsystem) at a time without interference from other parts Allowing attention to concentrate on the part of the system pertinent to a particular audience, without confusing people with details irrelevant to their interests Permitting different parts of the system to be built at independent times and/or by different people

Figure 3-6 An example of system decomposition After Decomposition CD Player System CD Signal Reading Subsystem Signal Amplifying Subsystem Music CD Control settings Control settings Signal Control Subsystem Signal Conversion Subsystem Music

Figure 3-7 A fast food restaurant s customer order information system depicted in a data flow diagram Customer Customer Order Kitchen Order Kitchen Receipt 1.0 Process Customer Food Order 2.0 3.0 Formatted Goods Sold Data Update Goods Sold File Goods Sold Inventory Data Update Inventory File Formatted Inventory Data Goods Sold File Inventory File Daily Goods Sold Amount 4.0 Produce Management Reports Daily Inventory Depletion Amounts Management Reports Restaurant Manager

Figure 3-9 Some guidelines for running effective meetings Become comfortable with your role as facilitator by gaining confidence in your ability, being clear about your purpose, and finding a style that is right for you. At the beginning of the meeting, make sure the group understands what is expected of them and of you. Use physical movement to focus on yourself or on the group, depending on which is called for at the time. Reward group member participation with thanks and respect. Ask questions instead of making statements. Be willing to wait patiently for group members to answer the questions you ask them. Be a good listener. Keep the group focused. Encourage group members to feel ownership of the group s goals and of their attempts to reach those goals. (Adapted from Option Technologies, Inc. [1992])

Figure 3-10 ACM Code of Ethics and Professional Conduct (Part 1) Association for Computing Machinery Professional Code of Ethics Preamble These statements of intended conduct are expected of every member (voting members, associate members, and student members) of the Association for Computing Machinery (ACM). Section 1.0 consists of fundamental ethical considerations; section 2.0 includes additional considerations of professional conduct; statements in 3.0 pertain to individuals who have a leadership role; and section 4.0 deals with compliance. ACM shall prepare and maintain an additional document for interpreting and following this Code. (1.0) General Moral Imperatives (As an ACM member I will...) (1.1) Contribute to society and human well-being. (1.2) Avoid harm to others. (1.3) Be honest and trustworthy. (1.4) Be fair and take action not to discriminate. (1.5) Respect property rights (Honor copyrights and patents; give proper credit; not steal, damage, or copy without permission). (1.6) Respect the privacy of others. (1.7) Honor confidentiality. (2.0) Additional Professional Obligations (As an ACM computing professional I will...) (2.1) Strive to achieve the highest quality in the processes and products of my work. (2.2) Acquire and maintain professional competence. (2.3) Know and respect existing law pertaining to my professional work. (2.4) Encourage review by peers and all affected parties. (2.5) Give well-grounded evaluations of computer systems, their impacts, and possible risks. (2.6) Honor contracts, agreements, and acknowledged responsibilities. (2.7) Improve public understanding of computing and its consequences. Revision Draft No. 19 (9/19/91), used with permission

Figure 3-10 ACM Code of Ethics and Professional Conduct (Part 2) (3.0) Organizational Leadership Imperatives (As an organizational leader I will...) (3.1) Articulate social responsibilities of members of the organizational unit and encourage full participation in these responsibilities. (3.2) Shape information systems to enhance the quality of working life. (3.3) Articulate proper and authorized uses of organizational computer technology and enforce those policies. (3.4) Ensure participation of users and other affected parties in system design, development and implementation. (3.5) Support policies that protect the dignity of users and others affected by a computerized system. (3.6) Support opportunities for learning the principles and limitations of computer systems. (4.0) Compliance with Code (4.1) I will uphold and promote the principles of this Code. (4.2) If I observe an apparent violation of this Code, I will take appropriate action leading to a remedy. (4.3) I understand that violation of this Code is inconsistent with continued membership in the ACM. Revision Draft No. 19 (9/19/91), used with permission

Figure 4-2 A project manager juggles numerous items during a project Technological Change Customer and Management Expectations Documentation and Communication Systems Development Life Cycle The Art of Project Management Time and Resource Constraints Organizational Change and Complexity Methodologies and Tools Contractors and Vendors Managing People

Figure 4-4 The project workbook for the Purchasing Fulfillment System project contains both hard copy and electronic documents Pine Valley Furniture Information Systems Development Group Purchasing Fulfillment System 1 2 3 4 5 6 7 8 1. Project overview 2. Initiation plan and SSR 3. Project scope and risks 4. Management procedures 5. Data descriptions 6. Process descriptions 7. Team correspondence 8. Statement of work 9. Project schedule Online copies of data dictionary, diagrams, schedules, reports, etc. Manager: Chris Martin 9 PFS Project PFS Project PFS Data Project Dictionary Data Dictionary Data Diagrams Dictionary Diagrams Diagrams

Figure 4-5a Level of detail in a project plan at the start of the project Analysis Design Implementation General Planning level Part of project planned so far Detailed Start of project Time End of project Current stage of project

Figure 4-5b Level of detail in a project plan in the middle of the project Analysis Design Implementation General Planning level Part of project planned so far Detailed Start of project Time End of project Current stage of project

Figure 4-7 Tradeoffs between the quality of the program code versus the speed of programming High Quality of Work Adam Brenda Carl Low Short Time of Programming a Task Long (Adapted from Page-Jones, 1985)

Figure 4.8a Graphical diagrams for depicting project plans: Gantt chart ID Name 1 Requirements Collection 2 Screen Design 3 Report Design 4 Database Design 5 User Documentation 6 Programming 7 Testing 8 Installation Sales Promotion Tracking April 1996 May 1996 June 1996 July 1996 August 1996 September Date: 4/1/96 8:00am Critical Noncritical Progress Milestone Summary Rolled Up

Figure 4-8b Graphical diagrams for depicting project plans: PERT chart Sales Promotion Tracking User Documentation Installation Screen Design Database Design 5 5.5w 7/15/96 8/21/96 8 1w 9/9/96 9/13/96 Requirements Collection 2 6w 5/20/96 6/28/96 4 2w 7/1/96 7/12/96 Programming Testing 1 5w 4/15/96 5/17/96 6 5w 7/15/96 8/16/96 7 3w 8/19/96 9/6/96 Report Design 3 6w 5/20/96 6/28/96 Name Critical Milestone Subproject Date: 4/1/96 8:00am ID Scheduled Start Duration Scheduled Finish Noncritical Summary Marked

Figure 4-11 Estimated time calculations for the SPTS project TIME ESTIMATE (in weeks) EPECTED TIME (ET) o + 4r + p ACTIVITY o r p 6 1. Requirements Collection 1 5 9 5 2. Screen Design 5 6 7 6 3. Report Design 3 6 9 6 4. Database Construction 1 2 3 2 5. User Documentation 3 6 7 5.5 6. Programming 4 5 6 5 7. Testing 1 3 5 3 8. Installation 1 1 1 1

Figure 4-13 Gantt chart for the SPTS project ID Name 1 Requirements Collection 2 Screen Design 3 Report Design 4 Database Design 5 User Documentation 6 Programming 7 Testing 8 Installation Sales Promotion Tracking April 1996 May 1996 June 1996 July 1996 August 1996 September Date: 4/1/96 8:00am Critical Noncritical Progress Milestone Summary Rolled Up

Figure 4-14 PERT chart for the SPTS project Screen Design User Documentation Installation Requirements Collection 2 Database Construction 5 8 1 4 3 6 7 Report Design Programming Testing

Figure 4-15 PERT chart for the SPTS project showing estimated times for each activity and their earliest and latest expected completion time T E = 11 T L = 11 T E = 18.5 T L = 21 T E = 22 T L = 22 T E = 5 T L = 5 1 ET = 5 2 T E = 13 ET = 6 T L = 13 ET = 5.5 ET = 1 T E = 11 T L = 11 4 ET = 2 T E = 18 T L = 18 3 6 5 8 ET = 6 ET = 5 ET = 3 7 T E = 21 T L = 21 Critical path Non-critical path

Figure 4-16 Activity slack time calculations for the SPTS project SLACK ACTIVITY T E T L T L T E ON CRITICAL PATH 1 5 5 0 2 11 11 0 3 11 11 0 4 13 13 0 5 18.5 21 2.5 6 18 18 0 7 21 21 0 8 22 22 0

Figure 4-20 Viewing project information as a PERT chart in Microsoft Project for Windows

Figure 5-2a A profile of CASE users: Years of IS experience 11 to 15 29.6% 6 to 10 18.3% 1 to 5 2.8% More than 15 49.3% (Source: Jones and Arnett, 1992)

Figure 5-2b A profile of CASE users: Number of IS projects (Figures do not add up to 100% due to rounding.) 1 to 10 45.1% 11 to 20 29.6% 21 to 30 10% More than 30 15.5% (Source: Jones and Arnett, 1992)

Figure 5-3 Popular uses for CASE Data Dictionary 56.3 Project Management 56.3 Feature Documentation Prototyping Graphics 54.9 53.5 52.1 Code Generation 47.9 Cost/Benefit Analysis 40.8 0 10 20 30 40 50 60 Percentage of users who regularly use this feature (Source: Jones and Arnett, 1992)

Figure 5-5 The growth of the worldwide CASE market Analysis & Design 0.61 1.67 1992 1996 Code & Application 0.85 2.6 Tool Type Generators Integrated CASE 1.1 5 Editors, Compilers, Debuggers & Testing 1.8 4.5 Reverse Engineering 0.17 0.65 0 1 2 3 4 5 6 Market Size ($ Billion) (Source: Pfrenzinger, 1992)

Figure 5-6 The relationship between CASE tools and the systems development life cycle Project Identification & Selection Project Initiation & Planning Requirements Definition Analysis Requirements Structuring Alternative Generation & Selection Realm of upper CASE tools Logical Design Design Physical Design Implementation Coding Documentation Testing Training Installation Realm of lower CASE tools Maintenance

Figure 5-12 System development items stored in the CASE repository Diagrams Documentation Forms and Reports Project Information CASE Repository Analysis & Testing Results Source & Object Code Standard Libraries

Figure 5-13 Common components of a comprehensive CASE repository Application Development Environment Production Environment CASE Tools Application Programs Repository Data Dictionary Information Repository Business Information Application Portfolio

Figure 5-14 Data dictionary definition of a repository item from Visible Systems Corporation s VAW CASE environment

Figure 5-16 Impact of documentation quality on system maintenance 400 400 % Change in maintenance effort from norm 300 200 100 0 100 200 125 75 30 Norm 0 15 35 48 50 80 Poor Average High Documentation technical quality (Source: Hanna, 1992)

Figure 6-2 Project selection decisions must consider numerous factors and can have numerous outcomes Perceived and Real Needs Existing and Available Resources List of Potential and Ongoing Projects Project Selection Decision Decision Outcome Accept Project Reject Project Delay Project Refocus Project End-User Development Proof of Concept Current Organizational Environment Evaluation Criteria

Figure 6-3 Information systems development projects come from both top-down and bottom-up initiatives Sources of Potential Projects Project Identification and Selection Project Initiation and Planning Top Down Top Management Steering Committee Evaluate, Prioritize, and Schedule Projects Schedule of Projects 1.... 2.... 3.... Bottom Up User Departments Development Group

Figure 6-7 Information systems planning is a three-step process Step 1 Current Situation: listing of manual & automated processes listing of manual & automated data technology inventory human resources inventory Step 2 Future Situation: blueprints of manual & automated processes blueprints of manual & automated data technology blueprints human resources blueprints Schedule of Projects: Step 3 viend dkfjsk dkksl f kdkj dkj s ak df kdjfdd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Figure 6-9 Information systems architecture framework Data Process Network 1 Business Scope List of Entities Important to the Business List of Functions the Business Performs List of Locations in which the Business Operates 2 Business Model Business Entities and their Inter-relationships Function and Process Decomposition Communications Links between Business Locations 3 Information Systems Model Model of the Business Data and its Inter-relationships Flows between Application Processes Distribution Network 4 Technology Model Database Design Process Specifications Configuration Design 5 Technology Definition Database Schema and Subschema Definition Program Code and Control Blocks Configuration Definition 6 Information System Data and Information Application Programs System Configuration (Adapted from Zachman, 1987)

Figure 6-10 Parallel activities of corporate strategic planning and information systems planning Corporate Strategic Planning Current Enterprise Information Systems Planning Current Situation: listing of manual & automated processes listing of manual & automated data technology inventory human resources inventory Future Enterprise Future Situation: blueprints of manual & automated processes blueprints of manual & automated data technology blueprints human resources blueprints Strategic Plan Schedule of Projects: viend dkfjsk dkksl f kdkj dkj s ak df kdjfdd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Figure 6-11 Information systems planning information (Pine Valley Furniture) FUNCTIONS: DATA ENTITIES: INFORMATION SYSTEMS: business planning customer payroll processing product development product accounts payable marketing and sales vendor accounts receivable production operations raw material time card processing finance and accounting order inventory management human resources invoice equipment

Figure 6-12 Functional decomposition of information systems planning information (Pine Valley Furniture) Business functions Supporting functions Business Planning Market Analysis Sales Forecasting Product Development Concept Analysis Product Design Marketing and Sales Marketing Research Order Fulfillment Distribution Production Operations Production Scheduling Fabrication Assembly Finishing Finance and Accounting Capital Budgeting Accounts Receivable Accounts Payable Human Resources Recruiting Training

Figure 6-13 Data Entity-to-Function matrix (Pine Valley Furniture) Business Functions Data Entity Types Customer Product Vendor Raw Material Order Work Center Equipment Employees Invoice Work Order... Marketing and Sales Marketing Research Order Fulfillment Distribution Production Operations Production Scheduling Fabrication Assembly Finishing Finance and Accounting Capital Budgeting Accounts Receivable Accounts Payable Human Resources Recruiting Training... = data entity is used within business function

Figure 6-14 Information System-to-Objective matrix (Pine Valley Furniture) Information System Objective Profit Service Innovation Personnel Diversity Transaction Processing Order Tracking Order Processing Plant Scheduling Payroll Accounts Payable Accounts Receivable Cash Management... Management Information Systems Sales Management Sales Region Analysis Inventory Control Production Scheduling... F C F C C C F C F C F F C F C F F C F C = objective currently supported by existing systems F = objective is planned to be supported by future system F F F C F F C F C C C F F F F

Figure 6-17 Systems development projects flow from the information systems plan Information Systems Plan: I. Organizational Mission II. Informational Inventory III. Mission and Objectives of IS IV. Constraints V. Long-Term Plan VI. Short-Term Plan VII. Conclusions Project 1 Project 2 Project 3 Project 4 Project 5

Figure 7-2 Statement of Work for the Customer Tracking System (Pine Valley Furniture) Pine Valley Furniture Statement of Work Prepared: 9/20/95 Project Name: PVF Project Manager: Customer Tracking Systems Jim Woo Customer: Project Sponsor: Marketing Jackie Judson Project Start/End (projected): 10/1/95 2/1/96 PVF Development Staff Estimates (man-months): Programmers: Jr. Analysts: Sr. Analysts: Supervisors: Consultants: Librarian: TOTAL: 2.0 1.5 0.3 0.1 0.0 0.1 4.0 Project Description Goal Objective This project will implement a customer tracking system for the marketing department. The purpose of this system is to automate the to save employee time, reduce errors, have more timely information, Phases of Work minimize data entry errors provide more timely information The following tasks and deliverables reflect the current understanding of the project: In Analysis, In Design, In Implementation,

Figure 7-4 Tangible benefits for Customer Tracking System (Pine Valley Furniture) TANGIBLE BENEFITS WORKSHEET Customer Tracking System Project Year 1 through 5 A. Cost reduction or avoidance $ 4,500 B. Error reduction 2,500 C. Increased flexibility 7,500 D. Increased speed of activity 10,500 E. Improvement in management planning or control 25,000 F. Other 0 TOTAL tangible benefits $50,000

Figure 7-5 One-time costs for Customer Tracking System (Pine Valley Furniture) ONE-TIME COSTS WORKSHEET Customer Tracking System Project Year 0 A. Development costs $20,000 B. New hardware 15,000 C. New (purchased) software, if any 1. Packaged applications software 5,000 2. Other 0 D. User training 2,500 E. Site preparation 0 F. Other 0 TOTAL one-time cost $42,500

Figure 7-6 Recurring costs for Customer Tracking System (Pine Valley Furniture) RECURRING COSTS WORKSHEET Customer Tracking System Project Year 1 through 5 A. Application software maintenance $25,000 B. Incremental data storage required: 20 MB $50. 1,000 (estimated cost/mb = $50) C. Incremental communications (lines, messages,...) 2,000 D. New software or hardware leases 0 E. Supplies 500 F. Other 0 TOTAL recurring costs $28,500

Figure 7-7 Summary spreadsheet reflecting the present value calculations of all benefits and costs for the Customer Tracking System (Pine Valley Furniture) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 A B C D E F G H Pine Valley Furniture Economic Feasibility Analysis Customer Tracking System Project Year of Project Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTALS Net economic benefit Discount rate (12%) PV of benefits $0 1.0000 $0 $50,000 0.8929 $44,643 $50,000 0.7972 $39,860 $50,000 0.7118 $35,589 $50,000 0.6355 $31,776 $50,000 0.5674 $28,371 NPV of all BENEFITS One-time COSTS Recurring Costs Discount rate (12%) PV of Recurring Costs NPV of all COSTS Overall NPV $0 ($42,500 ) $0 1.0000 $0 ($42,500 ) $44,643 ($28,500 ) 0.8929 ($25,446 ) ($67,946 ) $84,503 ($28,500 ) 0.7972 ($22,720 ) ($90,666 ) $120,092 ($28,500 ) 0.7118 ($20,286 ) ($110,952 ) $151,867 ($28,500 ) 0.6355 ($18,112 ) ($129,064 ) $180,239 ($28,500 ) 0.5674 ($16,172 ) ($145,236 ) $180,239 ($145,236 ) $35,003 Overall ROI - (Overall NPV / NPV of all COSTS) 0.24 Break-even Analysis Yearly NPV Cash Flow Overall NPV Cash Flow ($42,500 ) ($42,500) $19,196 ($23,304) $17,140 ($6,164) $15,303 $9,139 $13,664 $22,803 $12,200 $35,003 Project break-even occurs between years 2 and 3 Use first year of positive cash flow to calculate break-even fraction - ((15303-9139) / 15303) =.403 Actual break-even occurred at 2.4 years Note: All dollar values have been rounded to the nearest dollar

Figure 7-8 Break-even analysis for Customer Tracking System (Pine Valley Furniture) 200 Dollars ($ thousands) 150 100 Project break-even point 50 Benefits Costs 0 0 1 2 3 4 5 Year

Figure 7-9 Effects of degree of project structure, project size, and familiarity with application area on project implementation risk High Familiarity with Technology or Application Area Low Familiarity with Technology or Application Area Large Project Small Project Large Project Small Project Low Structure (1) Low risk (very susceptible to mismanagement) (3) Very low risk (very susceptible to mismanagement) (5) Very high risk (7) High risk High Structure (2) Low risk (4) Very low risk (6) Medium risk (8) Medium-low risk (Adapted from: Cash et al., 1992)

Figure 7-10 Outline of a Baseline Project Plan 1.0 2.0 3.0 4.0 Introduction A. B. System Description A. B. Feasibility Assessment A. B. C. D. E. F. Management Issues A. B. C. D. BASELINE PROJECT PLAN REPORT Project Overview Provides an executive summary that specifies the project s scope, feasibility, justification, resource requirements, and schedules. Additionally, a brief statement of the problem, the environment in which the system is to be implemented, and constraints that affect the project are provided. Recommendation Provides a summary of important findings from the planning process and recommendations for subsequent activities. Alternatives Provides a brief presentation of alternative system configurations. System Description Provides a description of the selected configuration and a narrative of input information, tasks performed, and resultant information. Economic Analysis Provides an economic justification for the system using cost-benefit analysis. Technical Analysis Provides a discussion of relevant technical risk factors and an overall risk rating of the project. Operational Analysis Provides an analysis of how the proposed system solves business problems or takes advantage of business opportunities in addition to an assessment of how current day-to-day activities will be changed by the system. Legal and Contractual Analysis Provides a description of any legal or contractual risks related to the project (e.g., copyright or nondisclosure issues, data capture or transferring, and so on). Political Analysis Provides a description of how key stakeholders within the organization view the proposed system. Schedules, Timeline, and Resource Analysis Provides a description of potential timeframe and completion date scenarios using various resource allocation schemes. Team Configuration and Management Provides a description of the team member roles and reporting relationships. Communication Plan Provides a description of the communication procedures to be followed by management, team members, and the customer. Project Standards and Procedures Provides a description of how deliverables will be evaluated and accepted by the customer. Other Project-Specific Topics Provides a description of any other relevant issues related to the project uncovered during planning.

Figure 7-11 Statement of project scope (Pine Valley Furniture) Pine Valley Furniture Statement of Project Scope General Project Information Project Name: Sponsor: Project Manager: Problem/Opportunity Statement: Project Objectives: Project Description: Business Benefits: Project Deliverables: Estimated Project Duration: Customer Tracking System Jackie Judson, VP Marketing Jim Woo Sales growth has out-paced the marketing department s ability to accurately track and forecast customer buying trends. An improved method for performing this process must be found in order to reach company objectives. To enable the marketing department to accurately track and forecast customer buying patterns in order to better serve customers with the best mix of products. This will also enable PVF to identify the proper application of production and material resources. A new information system will be constructed that will collect all customer purchasing activity, support display and reporting of sales information, aggregate data and show trends in order to assist marketing personnel in understanding dynamic market conditions. The project will follow PVF s systems development life cycle. Improved understanding of customer buying patterns Improved utilizaton of marketing and sales personnel Improved utilization of production and materials Customer tracking system analysis and design Customer tracking system programs Customer tracking documentation Training procedures 5 months Prepared by: Jim Woo Date: September 18, 1995

Figure 8-2a Typical interview guide Interview Outline Interviewee: Name of person being interviewed Location/Medium: Office, conference room, or phone number Objectives: What data to collect On what to gain agreement What areas to explore Agenda: Introduction Background on Project Overview of Interview Topics To Be Covered Permission to Tape Record Topic 1 Questions Topic 2 Questions Summary of Major Points Questions from Interviewee Closing Interviewer: Name of person leading interview Appointment Date: Start Time: End Time: Reminders: Background/experience of interviewee Known opinions of interviewee Approximate Time: 1 minute 2 minutes 1 minute 5 minutes 7 minutes 2 minutes 5 minutes 1 minute General Observations: Interviewee seemed busy probably need to call in a few days for follow-up questions since he gave only short answers. PC was turned off probably not a regular PC user. Unresolved Issues, Topics not Covered: He needs to look up sales figures from 1992. He raised the issue of how to handle returned goods, but we did not have time to discuss.

Figure 8-2b Typical interview guide (continued) Interviewee: Date: Questions: When to ask question, if conditional Question number: 1 Have you used the current sales tracking system? If so, how often? If yes, go to Question 2 Question: 2 What do you like least about this system? Notes: Answer Yes, I ask for a report on my product line weekly Observations Answer Seemed anxious may be over- estimating usage frequency dollars Observations Sales are shown in units, not System can show sales in dollars, but user does not know this.

Figure 8-6 Illustration of the typical room layout for a JAD Scanner Order Processing Overview Agenda 1. Overview 2.... 3.... 4.... 5.... 6.... 7.... 8.... 9. Magnetic Board Flip Chart Open Issues Screen for Overheads Flip Chart Sheets Printer Overhead Projector Name Tents (Adapted from Wood and Silver, 1989)

Figure 9-2 Comparison of DeMarco and Yourdan and Gane & Sarson DFD symbol sets process data store source/sink data flow DeMarco & Yourdon symbols Gane & Sarson symbols

Figure 9-4 Context diagram of Hoosier Burger s food ordering system CUSTOMER KITCHEN Customer Order Receipt 0 Food Ordering System Food Order Management Reports RESTAURANT MANAGER

Figure 9-5 Level-0 DFD of Hoosier Burger s food ordering system CUSTOMER KITCHEN Customer Order Receipt 1.0 Receive and Transform Customer Food Order Food Order 2.0 Update Goods Sold File Goods Sold Inventory Data 3.0 Update Inventory File Formatted Goods Sold Data Formatted Inventory Data D2 Goods Sold File D1 Inventory File Daily Goods Sold Amounts 4.0 Produce Management Reports Daily Inventory Depletion Amounts Management Reports RESTAURANT MANAGER

Figure 9-6 Incorrect and correct ways to draw data flow diagrams Rule Incorrect Correct A. B. D. E. F. H. J. K. A B A A L. B A A A A B M. A A A C

Figure 9-7 Level-1 diagram showing the decomposition of Process 1.0 from the level-0 diagram for Hoosier Burger s food ordering system Customer Order Customer Order 1.1 Receive Customer Order Customer Order Customer Order Customer Order 1.3 Transform Order to Kitchen Format Food Order 1.5 Generate Inventory Decrements Inventory Data 1.2 1.4 Generate Customer Receipt Generate Goods Sold Increments Goods Sold Data Receipt

Figure 9-8 Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger s food ordering system Daily Inventory Depletion Amounts Daily Goods Sold Amounts 4.1 Access Goods Sold and Inventory Data Inventory Data Goods Sold Data 4.2 Aggregate Goods Sold and Inventory Data Aggregated Data 4.3 Prepare Management Reports Management Reports

Figure 9-9 Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger s food ordering system 4.3.1 4.3.2 Aggregated Data Format Management Reports Formatted Data Print Management Reports Management Reports

Figure 9-10 An unbalanced set of data flow diagrams (a) Context diagram 0 SOURCE A B SINK (b) Level-0 diagram 1.0 SOURCE ONE A Formatted A Formatted C 2.0 SOURCE TWO C B SINK

Figure 9-11 Example of data flow splitting (a) Composite data flow.0 Payment and Coupon Write Software (b) Disaggregated data flows.1 Payment.2 Coupon

Figure 9-12 List of activities involved in Bob Mellankamp s inventory control system for Hoosier Burger 1. Meet delivery trucks before opening restaurant. 2. Unload and store deliveries. 3. Log invoices and file in accordion file. 4. Manually add amounts received to stock logs. 5. After closing, print inventory report. 6. Count physical inventory amounts. 7. Compare inventory report totals to physical count totals. 8. Compare physical count totals to minimum order quantities; if the amount is less, make order; if not, do nothing. 9. Pay bills that are due and record them as paid.

Figure 9-13a Hoosier Burger s current physical inventory control system: Context diagram Invoice Usage Count SUPPLIER Payment 0 Inventory System INVENTORY REPORTS STOCK-ON-HAND Order On-hand Count

Figure 9-13b Hoosier Burger s current physical inventory control system: Level-0 data flow diagram SUPPLIER Payment 6.0 Bob Pays Bills Due Invoice Invoice Paid Invoice Data D2 1.0 Bob Logs Invoice INVOICE LOG SHEET Logged Invoice D1 Invoices ACCORDION FILE 2.0 Invoices Bob Logs Amounts Received Inventory Amounts 3.0 2.0 Bob Compares Physical Count to Report Count INVENTORY REPORTS Usage Count STOCK ON-HAND On-hand Count Orders Amounts Received 5.0 Bob Places New Orders Minimum Order Quantities Quantity On-hand D3 STOCK LOGS Amounts Used 4.0 2.0 Bob Records Inventory Amounts

Figure 9-15 Level-0 data flow diagram for Hoosier Burger s current logical inventory control system SUPPLIER Invoices Counts STOCK-ON-HAND 1.0 2.0 Update Inventory Added Update Inventory Used Payments Invoices Amounts Added D1 INVENTORY Amounts Used Orders 4.0 Generate Payments 3.0 Generate Orders Inventory Levels Minimum Order Quantities

Figure 9-16 Level-0 data flow diagram for Hoosier Burger s new logical inventory control system SUPPLIER Invoices Counts STOCK-ON-HAND 1.0 2.0 Update Inventory Added Update Inventory Used Payments Invoices Orders Amounts Added D1 INVENTORY Amounts Used 4.0 Generate Payments 3.0 Generate Orders Inventory Levels Minimum Order Quantities Inventory Levels Query 5.0 Query Inventory Levels Query Result Request MANAGER

Figure 9-17 Hoosier Burger s hiring procedures (a) Data flow diagram APPLICANT Application Notice to Applicant Request for Reference 1 Receive and Review Application Application Data to Schedule Interview REFERENCE 2 Interview Applicant Application D1 APPLICANT FILE Reference Data 3 Receive References & Prepare Summary Application Full Applicant Data 4 Decide If Hire (b) Analysis of completeness report from CASE tool DFD Analysis Errors [Project 'S330'] Error: Process labeled 'Interview Applicant' is an input only Process. Error: Process labeled 'Receive References & Prepare Summary' is an input only Process. Error: Process labeled 'Decide If Hire' is an output only Process.

Figure 9-18 VAW repository entry for a data flow Date: Time: 5/15/94 2:06 PM Project: S330 Single Entry Listing Data Flow Diagrams Page: 1 Request for Reference Description: Data Flow Alias: Composition: Notes: Location: A letter sent by Hoosier Burger to individuals or companies listed as references on employee applications. Reference Letter Applicant name Date of application Position applied for Qualifications sought This is a personal letter that Bob Mellankamp writes himself. A standard part of the letter is a requested date by which the reference is to be returned, and this date is two weeks from the date on which Bob s letter is sent. applicant (0) Source: Dest: Receive and Review Application (Process) REFERENCE (External Entity) Date Last Altered: 5/15/94 Date Created: 5/15/94

Figure 9-19 Class registration system (for Problem and Exercise 6) Context Diagram Student Class Schedule Course Request List of Courses 0 Class Registration System Possible Classes Department Scheduled Classes D1 Roster of Classes Level-O Diagram From Student Course Request 1 Receive Course Request 3 Check for Availability Class Schedule To student From Department List of Courses 2 Receive Course Lists Course Request Scheduled Classes D2 Class Roster Possible Classes

Figure 9-20 DFD for Problem and Exercise 10 DF2 1.0 E1 DF5 P2 DF1 DS1 DF6 DF3 DF4 2.0 E2 DF2 P1

Figure 9-21 DFD for Problem and Exercise 11 Level 0 DF6 DS2 E1 DF1 P1 DF2 P2 DF4 E2 DF3 DS1 DF5 DF3 P3 Level 1 DF6 DS2 DF1 P1.1 DF7 P1.2 DF9 P1.4 DF2 P1.3 DF8 Level 2 DF11 P1.4.2 DF12 DF9 DF8 P1.4.1 DF10 P1.4.3 DF2

Figure 10-2 Current logical DFD for Hoosier Burger s inventory control system SUPPLIER Invoices Counts STOCK-ON-HAND 1.0 2.0 Update Inventory Added Update Inventory Used Payments Invoices Amounts Added D1 INVENTORY Amounts Used Orders 4.0 Generate Payments 3.0 Generate Orders Inventory Levels Minimum Order Quantities

Figure 10-3 Structured English representations of the four processes depicted in Figure 10-2 Process 1.0: Update Inventory Added DO READ next Invoice-item-record FIND matching Inventory-record ADD Quantity-added from Invoice-item-record to Quantity-in-stock on Inventory-record UNTIL End-of-file Process 2.0: Update Inventory Used DO READ next Stock-item-record FIND matching Inventory-record SUBTRACT Quantity-used on Stock-item-record from Quantity-in-stock on Inventory-record UNTIL End-of-file Process 3.0: Generate Orders DO READ next Inventory-record BEGIN IF IF Quantity-in-stock is less than Minimum-order-quantity THEN GENERATE Order END IF UNTIL End-of-file Process 4.0: Generate Payments READ Today's-date DO SORT Invoice-records by Date READ next Invoice-record BEGIN IF IF Date is 30 days or greater than Today's-date THEN GENERATE Payments END IF UNTIL End-of-file

Figure 10-4 Complete decision table for payroll system example Condition Stubs Action Stubs Conditions/ Courses of Action Employee type Hours worked Pay base salary Calculate hourly wage Calculate overtime Produce Absence Report 1 S <40 2 H <40 3 S 40 Rules 4 H 40 5 S >40 6 H >40

Figure 10-5 Reduced decision table for payroll system example Conditions/ Courses of Action Employee type Hours worked Pay base salary Calculate hourly wage Calculate overtime Produce Absence Report 1 S 2 H <40 Rules 3 H 40 4 H >40

Figure 10-6 Complete decision table for Hoosier Burger s inventory reordering Conditions/ Courses of Action Type of item Time of week Season of year Standing daily order Standing weekend order Minimum order quantity Holiday reduction Summer reduction Type of item: P = perishable N = non-perishable 1 P D A 2 N D A 3 P W A 4 N W A Time of week: D = weekday W = weekend 5 P D S Rules 6 N D S 7 P W S 8 N W S 9 P D H 10 N D H 11 P W H 12 N W H Season of year: A = academic year S = summer H = holiday

Figure 10-7 Reduced decision table for Hoosier Burger s inventory reordering Conditions/ Courses of Action Type of item Time of week Season of year 1 P D A 2 P W A 3 P D S Rules 4 P W S 5 P D H 6 P W H 7 N Standing daily order Standing weekend order Minimum order quantity Holiday reduction Summer reduction

Figure 10-8 Generic decision tree Sunday Sleep two more hours Yes 2 Weekday Time to get up 1 Saturday Sleep one more hour No Legend: 1) Sun up? 2) What day is it? Go back to sleep

Figure 10-9 Decision tree representation of the decision logic in the decision tables in Figures 10-4 and 10-5, with only two choices per decision point 1 Yes Pay base salary No 2 Yes Pay hourly wage; Absence report Legend: No Yes 3 Pay hourly wage 1) Salaried? No 2) Hours worked < 40? 3) Hours worked = 40? Pay hourly wage; Pay overtime wage

Figure 10-10 Decision tree representation of the decision logic in the decision tables in Figures 10-4 and 10-5, with multiple choices per decision point 1 Salaried Pay base salary Hourly 2 < 40 = 40 Pay hourly wage; Absence report Legend: > 40 Pay hourly wage 1) Type of employee 2) Hours worked Pay hourly wage; Pay overtime wage

Figure 10-11 State-transition diagram for a two-state coffee maker C1: Switch button to on turn on light turn on burner draw water through systems until none remains 1. Idle 2. Making coffee turn off light turn off burner C2: Switch button to off

Figure 10-12 State-transition diagram for Hoosier Burger s food-ordering system R2: Clear pushed R1: Menu item button pushed R3: Void pushed 2. Opening Order 4. Voiding Order R2: Clear pushed R1: Menu item button pushed Accept menu item input R4: Total pushed R5: Unexpected button pushed Clear screen Display order voided message R5: Unexpected button pushed R3: Void pushed R5: Unexpected 1. Idle R2: Clear pushed 3. Error State button pushed 5. Closing Order Clear screen Wait for input R2: Clear pushed Display error message R7: Close 7. Recording Order cash drawer 6. Cash Drawer Open R6: Payment due pushed Total amount for menu items ordered Send order to kitchen Display amount due Display item totals next to item buttons Print receipt Send goods sold data Send inventory data Display amount of change due

Figure 10-13 State-transition table for Hoosier Burger s food-ordering system States R1: Menu item pushed R2: Clear pushed R3: Void pushed R4: Total pushed R5: Odd button pushed R6: Payment due pushed R7: Cash drawer closed 1. 2. 3. 4. 5. 6. 7. Idle Opening Order Error State Voiding Order Closing Order Cash Drawer Open Recording Order 2 2 event ignored event ignored event ignored event ignored event ignored event ignored 1 1 1 event ignored event ignored 1 event ignored 4 event ignored event ignored 4 event ignored event ignored event ignored 5 event ignored event ignored event ignored event ignored event ignored event ignored 3 3 event ignored 3 event ignored event ignored event ignored event ignored event ignored event ignored 6 event ignored event ignored can t happen can t happen can t happen can t happen can t happen 7 can t happen Note: In the R7 column, the event Close Cash Drawer can t happen because the cash drawer is already closed for all states except State 6, Cash Drawer Open.

Figure 11-5 Entity-relationship notation Basic symbols Entity Relationship Primary key Attribute Multivalued attribute Gerund (Associative entity) Relationship degree Unary Binary Ternary Relationship cardinality Mandatory 1 cardinality n Many (M) cardinality (1, 2,..., many) (n is a number for an upper limit, if one exists) Optional 0 or 1 cardinality Optional zero-many cardinality (0, 1, 2,..., many) n Class-subclass relationship Exclusive relationship IS-A (see Appendix C) (see Appendix C)

Figure 11-6 Example relationships of different degrees Unary relationship PERSON Is Married to EMPLOYEE Manages One-to-one One-to-many Binary relationship Ternary relationship EMPLOYEE Is Assigned PARKING PLACE PART One-to-one PRODUCT LINE Contains PRODUCT VENDOR Ships WAREHOUSE One-to-many QUANTITY STUDENT Registers for COURSE Many-to-many

Figure 11-7a Bill-of-materials unary relationship: Many-to-many ITEM Has Components QUANTITY

Figure 11-7b Bill-of-materials unary relationship: Two instances A B V (1) (1) Y (2) (2) Y (1) Z (1) U (3) V (2) U (3) V (2) V (1) W (2)

Figure 11-8 Examples of cardinalities in relationships (a) Mandatory cardinalities PATIENT Has PATIENT HISTORY (b) One optional, one mandatory cardinality EMPLOYEE Is Assigned to PROJECT (c) Optional cardinalities PERSON Is Married to

Figure 11-9 Example associative entity DATE COMPLETED EMPLOYEE COMPLETES COURSE

Figure 11-10 SHIPMENT entity type (a gerund) VENDOR Quotes Price PART QUANTITY PRICE VENDOR PART SHIPMENT NO. SHIPMENT QUANTITY WAREHOUSE

Figure 11-11 Examples of business rules (a) Simple banking relationship ACCT. NO. BALANCE AMOUNT DATE ACCOUNT Is for WITHDRAWAL TIME (b) Typical domain definitions Name: ACCT NO. Name: AMOUNT Meaning: Customer account number in bank Meaning: Dollar amount of transaction Data type: Character Data type: Numeric Format: nnn-nnnn Format: 2 decimal places Uniqueness: Must be unique Range: 0 10,000 Null support: Non-null Uniqueness: Nonunique Null support: Non-null (c) Typical triggering operation User rule: WITHDRAWAL AMOUNT may not exceed ACCOUNT BALANCE Event: Insert Entity Name: WITHDRAWAL Condition: WITHDRAWAL AMOUNT> ACCOUNT BALANCE Action: Reject the insert transaction

Figure 11-12 Typical conceptual data model elements in a project dictionary Entity (major category of data) Name A short and a long name that uniquely label the entity Description Explanation so that it is clear what objects are covered by this entity Alias Alternative names used for this entity (that is, synonyms) Primary key Name(s) of attribute(s) that form the unique identifier for each instance of this entity Attributes List of attributes associated with this entity and the number of instances of each and repetition attribute for each entity instance Abstraction Indication of any superclasses or subclasses or composition of entity types involving this entity Attribute (entity characteristic) Name A short and a long name that uniquely label the attribute Description Explanation of the attribute so that its meaning is clearly different from all other attributes Alias Alternative names used for this attribute (that is, synonyms) Domain The permitted values that this attribute may assume Computation If this is not raw data, the formula or method to calculate the attribute s value Aggregation Indication of any groupings of attributes involving this attribute (e.g., a month attribute as part of a date attribute) Relationship (association between entity instances) Name A short and a long name that uniquely label the relationship Description Explanation of the relationship so that its meaning is clearly different from all other relationships Degree Names of entities involved in the relationship Cardinality The potential number of instances of each entity involved in the relationship Insertion rules Business rules that control the inclusion of entity instances in this relationship Deletion rules Business rules that control the elimination of entity instances from this relationship

Figure 11-15 Preliminary E-R diagram for Hoosier Burger s inventory control system SALE INVOICE Sells Includes ITEM SALE Is Sold on Orders Is Received for INVOICE ITEM Is Included on Is Ordered on PRODUCT RECIPE INVENTORY ITEM Received on

Figure 11-16 Final E-R diagram for Hoosier Burger s inventory control system Receipt No. Sale Date Vendor No. Invoice No. Invoice Date Sells SALE Includes INVOICE Paid? Is Sold on Is Included on ITEM SALE Quantity Sold Quantity Added INVOICE ITEM Product No. Product Description Is Ordered on PRODUCT Orders Quantity Used RECIPE Is Received for INVENTORY ITEM Received on Item No. Item Description Quantity in Stock Minimum Order Quantity Type of Item

Figure 11-17 E-R diagram for Problem and Exercise 8 PROJ # EMPL # PROJECT Works on EMPLOYEE Includes SKILL TOOL Used on TASK Done at CITY TIME TASK ID

Figure 11-18 E-R diagram for Problem and Exercise 11 CUSTOMER Places ORDER Generates BACKORDER Includes PRODUCT Comprised of COMPONENT Supplied by VENDOR

Figure 11-19 E-R diagram for Problem and Exercise 16 AGENT # CONSIGNMENT # $ VALUE CONTAINER # DESTINATION SIZE AGENT Is Responsible for CONSIGNMENT May Contain CONTAINER Holds Transports VESSEL Goes on VOYAGE VESSEL ID COUNTRY OF REGISTRY VOYAGE ID TONNAGE

Figure 12-4 The steps in Hoosier Burger s inventory control system 1. Meet delivery trucks before opening restaurant 2. Unload and store deliveries 3. Log invoices and file in accordion file 4. Manually add amounts received to stock logs 5. After closing, print inventory report 6. Count physical inventory amounts 7. Compare inventory reports totals to physical count totals 8. Compare physical count totals to minimum order quantities; if the amount is less, make order; if not, do nothing 9. Pay bills that are due and record them as paid

Figure 12-5 Description of three alternative systems that could be developed for Hoosier Burger s inventory system CRITERIA ALTERNATIVE A ALTERNATIVE B ALTERNATIVE C Requirements 1. Easy real-time entry of new Yes Yes Yes shipment data 2. Automatic re-order decisions For some items For all items For all items 3. Real-time data on Not available Available for some Fully available inventory levels items only Constraints 1. Cost to develop $25,000 $50,000 $65,000 2. Cost of hardware $25,000 $50,000 $50,000 3. Time to operation Three months Six months Nine months 4. Ease of training One week of training Two weeks of training One week of training

Figure 12-6 Weighted approach for comparing the three alternative systems for Hoosier Burger s inventory system Criteria Requirements Real-time data entry Auto re-order Real-time data query Constraints Development costs Hardware costs Time to operation Ease of training Weight 18 18 14 50 20 15 10 5 50 Alternative A Rating Score 5 3 1 5 5 5 5 90 54 14 158 100 75 50 25 250 Alternative B Rating Score 5 5 3 4 4 4 3 90 90 42 222 80 60 40 15 195 Alternative C Rating Score 5 5 5 3 4 3 5 90 90 70 250 60 60 30 25 175 Total 100 408 417 425

Figure 12-9 Hoosier Burger s revised cost-benefit analysis for its Inventory Control System Project Hoosier Burger Economic Feasibility Analysis Inventory Control System Net economic benefit Discount rate (12%) PV of benefits NPV of all BENEFITS One-time COSTS Recurring Costs Discount rate (12%) PV of Recurring Costs NPV of all COSTS Overall NPV Overall ROI - (Overall NPV / NPV of all COSTS) Year of Product Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTALS $0 1 $0 $0 ($115,000 ) $0 1 $0 ($115,000 ) $39,000 0.8928571 $34,821 $34,821 ($2,000 ) 0.8928571 ($1,786 ) ($116,786 ) $39,000 0.7971939 $31,091 $65,912 ($2,000 ) 0.7971939 ($1,594 ) ($118,380 ) $39,000 0.7117802 $27,759 $93,671 ($2,000 ) 0.7117802 ($1,424 ) ($119,804 ) $39,000 0.6355181 $24,785 $118,457 ($2,000 ) 0.6355181 ($1,271 ) ($121,075 ) $39,000 0.5674269 $22,130 $140,586 ($2,000) 0.5674269 ($1,135) ($122,210) $140,586 ($122,210) $18,377 0.15

Figure 12-11 Hoosier Burger s revised schedule for its Inventory Control System project Design Intervals Testing 3 8 weeks 7 5 weeks 10/6/97 11/28/97 2/9/98 3/13/98 Logical design Interface design Physical database design Coding Documentation Conversion 1 6 weeks 2 8 weeks 4 5 weeks 6 10 weeks 8 2 weeks 10 2 weeks 6/30/97 8/8/97 8/11/97 10/3/97 12/1/97 2/6/98 3/16/98 3/27/98 Data conversion Training 5 4 weeks 9 1 week