9 Process Modeling Overview Chapter 9 is a “technique” chapter that teaches the still important skill of proc- ess modeling. The focus is on drawing logical data flow diagrams. After teach- ing system and process modeling concepts to introduce DFD constructs, the chapter presents a contemporary approach to structured analysis based upon event partitioning. Chapter to Course Sequencing Students are encouraged to read Chapter 5 to provide perspective for logical system modeling. Adopters wishing to focus on object-oriented analysis tech- niques may want to skip this chapter in favor of Chapter 10. However, DFDs will not go away overnight. This is especially true given that DFDs have enjoyed something of a renaissance in new forms directed to business process redesign. For the time being, we recommend that this chapter be at least surveyed prior to introducing our object-oriented analysis coverage. Given non-object-oriented analysis, there has always been disagreement con- cerning the sequencing of the modeling chapters. Classical structured analysis always sequenced process modeling before data modeling. Information engi- neering and modern structured analysis reversed that trend—data models were drawn first and their existence drove process modeling. Although we prefer the latter more contemporary approach, the chapters were designed to be covered in either sequence at the instructor’s preference. What’s Different Here and Why? This chapter did not necessitate many content changes from the sixth edi- tion, but significant changes were made in the order in which that content is presented. The following changes have been made to this chapter in the sev- enth edition: 1. As with all chapters, we have streamlined the SoundStage episode into a quick narrative introduction to the concepts presented the chapter. 2. Several topics were rearranged in the chapter for better flow. This was based on actual field experience in teaching the concepts to students. • We begin with an introduction to process modeling. 9-2 Chapter Nine • We next discuss system concepts for processing modeling, which quickly introduces the external agent, data stores, and processes. Processes are saved to last so that we can move into process concepts, such as decomposition, functions, events, etc. without students for- getting the overall relationship of processes to agents and data stores. • Data flow concepts are discussed next, which finishes laying the groundwork for drawing DFDs. • We next discuss the process of logical process modeling, including strategic systems planning, process modeling for BPR, and process modeling for systems analysis. We lay out the sets of the various sys- tems analysis DFDs: context, decomposition, event-response list and event handlers, event diagram, system diagram, primitive diagrams. We also discuss fact-finding for process modeling and the role of CASE. • Next we walk through the process of constructing process models. • Now that the students have seen a completed DFD and know what it can tell them and what it cannot, then they are ready to learn about specifying process logic with structured English or decision tables. • The last topic, as in earlier editions, is synchronizing process models with data models and locations. Lesson Planning Notes for Slides The following instructor notes, keyed to slide images from the PowerPoint re- pository, are intended to help instructors integrate the slides into their individ- ual lesson plans for this chapter. Slide 1 This repository of slides is intended to support the named chapter. The slide repository should be Chapter 9 used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Process Modeling Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector. Each slide includes instructor notes. To view those notes in PowerPoint, click-left on the View Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor slide appearance after initial mouse click notes. in slide show mode The instructor notes are also available in hard- copy as the Instructor Guide to Accompany Sys- tems Analysis and Design Methods, 6/ed. Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved. Process Modeling 9-3 Slide 2 Chapter 9 objectives. Objectives • Define systems modeling and differentiate logical and physical models. • Define process modeling and explain its benefits. • Recognize and understand basic concepts and constructs of a process model. • Read and interpret a data flow diagram. • Explain when to construct process models and where to store them. • Construct a context diagram to illustrate a system’s interfaces with its environment. • Identify use cases, external and temporal business events. • Perform event partitioning and organize events in a functional decomposition diagram. • Draw event diagrams and merge them into a system diagram. • Draw primitive data flow diagrams and describe the elementary data flows in terms of data structures and procedural logic. • Document the distribution of processes to locations. • Synchronize data and process models using a CRUD matrix. Slide 3 Teaching Notes This slide shows the how this chapter's content fits with the building blocks framework used throughout the textbook. The emphasis of this chapter is upon PROCESSES. It also reflects the fact that process modeling may be performed during certain analysis phases and involves not only systems analysts…but owners and users. 9-3 Slide 4 Teaching Notes Models: Logical and Physical In some books, the term logical is called a con- ceptual or essential. The term essential comes Model – a pictorial representation of reality. from the notion that the model represents the Just as a picture is worth a thousand words, most “essence” of the system. models are pictorial representations of reality. For database-oriented instructors, the term logi- cal in the world of systems analysis is NOT Logical model –a Physical model –a equivalent to the term logical in the world of data- nontechnical pictorial technical pictorial base. In the database world, a “logical schema” is representation that depicts representation that depicts what a system is or does. what a system is or does and already constrained by the choice of a database Synonyms or essential how the system is technology, which runs contrary to the systems model, conceptual model, implemented. Synonyms are and business model. implementation model and analysis expectation that a logical model is tech- technical model. nology-independent. 9-4 In some books, the term physical is called imple- mentation or technical. Emphasize that there are nearly always multiple technical solutions for any given set of business requirements. In most projects, there is one logi- cal model that represents the mandatory and desirable business requirements, regardless of how those requirements might be implemented. On the other hand, given that one logical model, there are multiple candidate physical models that could represent alternative, technical implemen- tations that could fulfill the business requirements (although analysts rarely draw more than one or two of those physical models). Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved. 9-4 Chapter Nine Slide 5 No additional notes Why Logical System Models • Logical models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented. • Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results. • Logical models allow us to communicate with end-users in nontechnical or less technical languages. 9-5 Slide 6 Teaching Notes Process Modeling and DFDs Many, if not most students have drawn or seen process models in the form of program flow- Process modeling – a technique used to organize and charts. document a system’s processes. • Flow of data through processes Unfortunately, flowcharts are control-flow process • Logic models as opposed to data flow process models. • Policies This can cause some students trouble because • Procedures they want to illustrate structured flow of control Data flow diagram (DFD) – a process model used to (nonparallel processing) in their early DFDs. depict the flow of data through a system and the work or Most introductory information systems books at processing performed by the system. Synonyms are bubble chart, transformation graph, and process model. least introduce, with one or two examples, DFDs. • The DFD has also become a popular tool for business process redesign. 9-6 Slide 7 Teaching Notes Simple Data Flow Diagram We have found it useful to walk through this first DFD. Don’t be alarmed if students take excep- tion to some of the oversimplification of the illus- trated problem—it can actually contribute to the learning experience. 9-7 Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved. Process Modeling 9-5 Slide 8 Differences Between DFDs No additional notes and Flowcharts • Processes on DFDs can operate in parallel (at- the-same-time) • Processes on flowcharts execute one at a time • DFDs show the flow of data through a system • Flowcharts show the flow of control (sequence and transfer of control) • Processes on a DFD can have dramatically different timing (daily, weekly, on demand) • Processes on flowcharts are part of a single program with consistent timing 9-8 Slide 9 Teaching Notes External Agents It is very important to emphasize the external agents on DFDs are not the same as entities on External agent – an outside person, unit, ERDs (from Chapter 7)—especially if the instruc- system, or organization that interacts with a system. Also called an external entity. tor prefers the more traditional term “external • External agents define the “boundary” or entity.” scope of a system being modeled.