9 Process Modeling

Total Page:16

File Type:pdf, Size:1020Kb

9 Process Modeling 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.
Recommended publications
  • Chapter 1: Introduction
    Just Enough Structured Analysis Chapter 1: Introduction “The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.” — John Galsworthy Over the River, 1933 www.yourdon.com ©2006 Ed Yourdon - rev. 051406 In this chapter, you will learn: 1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis. Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time. 1.1 Why is systems analysis interesting? Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978), [systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.
    [Show full text]
  • Assignments and Hints Pearson Livelessons
    Assignments and Hints Pearson LiveLessons • This downloadable file contains Assignments and Hints, which are referenced to the appropriate sub-lesson number. • The purpose of an Assignment is to ask you some questions and set you exercises to help you explore and reinforce the subjects covered by a particular sub-lesson. • The purpose of Hints is to remind you of some techniques that are particularly useful in considering how to apply the ideas covered by a particular sub-lesson. • This material also contains a glossary of terms used in the video course. • The Requirements Knowledge Model is reproduced in full. • The table of contents for the Volere Requirements Specification Template is also reproduced. • We should also mention our book, Mastering the Requirements Process – Getting Requirements Right, 3rd edition, published by Addison Wesley. • You can read articles about requirements at www.volere.co.uk • We have a discussion forum at the Volere Requirements LinkedIn grouphttp://goo.gl/NHGwT 1.1 Assignment: Establish your requirements process Consider the following questions and mentally answer them. These are here to reinforce the sub-lesson about requirements processes. 1. What is a requirements process? 2. Why do you need a requirements process? 3. Why do requirements processes vary from project to project? 2.1 Assignment: Lay the foundations 1. What are the three elements that you want to get into balance? 2. What is the difference between the scope of the work and the scope of the product? 3. How will you identify the appropriate stakeholders for the work you need to study? 4. How do you know if you have a well-defined goal? 5.
    [Show full text]
  • Software Engineering
    INDEX LESSON 1: INTRODUCTION TO SOFTWARE ENGINEERING LESSON 2: SOFTWARE METRICS LESSON 3: SOFTWARE LIFE CYCLE MODELS LESSON 4: SOFTWARE PROJECT PLANNING LESSON 5: SOFTWARE REQUIREMENT ANALYSIS & SPECIFICATION LESSON 6: SOFTWARE DESIGN - I LESSON 7: SOFTWARE DESIGN - II LESSON 8: CODING LESSON 9: SOFTWARE TESTING - I LESSON 10: SOFTWARE TESTING - II LESSON 11: SOFTWARE RELIABILITY Introduction to Software Engineering Page 1 of 348 Lesson No. : 1 Writer: Dr. Rakesh Kumar Introduction to Software Engineering Vetter: Sh. Naresh Mann 1.0 Objectives The objective of this lesson is to make the students acquainted with the introductory concepts of software engineering. To make them familiar with the problem of software crisis this has ultimately resulted into the development of software engineering. After studying this lesson, the students will: 1. Understand what is software crisis? 2. What are software engineering and its importance? 3. What are the quality factors of software? 1.1 Introduction In order to develop a software product, user needs and constraints must be determined and explicitly stated; the product must be designed to accommodate implementers, users and maintainers; the source code must be carefully implemented and thoroughly tested; and supporting documents must be prepared. Software maintenance tasks include analysis of change request, redesign and modification of the source code, thorough testing of the modified code, updating of documents to reflect the changes and the distribution of modified work products to the appropriate user. The need for systematic approaches to development and maintenance of software products became apparent in the 1960s. Many software developed at that time were subject to cost Introduction to Software Engineering Page 2 of 348 overruns, schedule slippage, lack of reliability, inefficiency, and lack of user acceptance.
    [Show full text]
  • An Event-Based Methodology to Generate Class Diagrams and Its Empirical Evaluation
    Journal of Computer Science 6 (11): 1301-1325, 2010 ISSN 1549-3636 © 2010 Science Publications An Event-Based Methodology to Generate Class Diagrams and its Empirical Evaluation 1Sandeep K. Singh, 2Sangeeta Sabharwal and 1J.P. Gupta 1Department of Computer Science and Engineering and Information Technology, JIIT A-10 Sector 62, Noida, India 2Division of Information Technology, NSIT Sector, 3, Dwarka, New Delhi, India Abstract: Problem statement: Event-based systems have importance in many application domains ranging from real time monitoring systems in production, logistics, medical devices and networking to complex event processing in finance and security. The increasing popularity of Event-based systems has opened new challenging issues for them. One such issue is to carry out requirements analysis of event-based systems and build conceptual models. Currently, Object Oriented Analysis (OOA) using Unified Modeling Language (UML) is the most popular requirement analysis approach for which several OOA tools and techniques have been proposed. But none of the techniques and tools to the best of our knowledge, have focused on event-based requirements analysis, rather all are behavior-based approaches. Approach: This study described a requirement analysis approach specifically for event based systems. The proposed approach started from events occurring in the system and derives an importable class diagram specification in XML Metadata Interchange (XMI) format for Argo UML tool. Requirements of the problem domain are captured as events in restricted natural language using the proposed Event Templates in order to reduce the ambiguity. Results: Rules were designed to extract a domain model specification (analysis-level class diagram) from Event Templates.
    [Show full text]
  • The Relationship Between Systems Development Methodologies and Information Technology Project Success MS Nkone 12570850
    The relationship between systems development methodologies and Information Technology project success MS Nkone 12570850 Dissertation submitted in fulfilment of the requirements for the degree Magister Scientiae in Computer Science at the Potchefstroom Campus of the North-West University Supervisor: Prof HM Huisman May 2013 i Abstract The purpose of this study was to investigate the relationship between systems development methodologies (SDMs) and the success of Information Technology (IT) projects. The study also seeks to find other critical success factors (CSFs) that influence IT projects success. What initiated this study, with reference to the literature review, is the apparent general view that IT project deliveries are still late, over budget, and unpredictable (Chow & Cao, 2008:961; The Standish Group, 2004). To some extent, the entire project fails before delivering an application. Hence this causes the need to investigate the employment of SDMs and their belief that SDMs improve quality in the development of IT projects and permit more flexible deployment to IT projects (Idea Group Publishing, 2006:13; Dyba et al., 2005:447; Mihailescu & Mihailescu, 2009:1). However, SDMs are still less popularly used (Siau & Tan, 2005:3132; Masrek I., 2008:137). The study provides insight into the relationship between SDMs and the IT projects. A survey using a questionnaire was carried out to obtain the data. The study employed a positivist paradigm and used a quantitative approach. A total of 132 questionnaires were returned from systems developers, IT project managers and team leaders from system development companies. It was found that there is a relationship between systems development methodologies (SDMs) and IT project success.
    [Show full text]
  • Significances and Impact of Use Cases- a Product Perspective V
    ISSN 2277-2685 IJESR/Sept. 2016/ Vol-6/Issue-9/202-208 Mallikarjun Reddy et. al., / International Journal of Engineering & Science Research SIGNIFICANCES AND IMPACT OF USE CASES- A PRODUCT PERSPECTIVE V. Indarni1, Mallikarjun Reddy*2, D.Swaroopa3 1Professor & Head. Dept of CSE,vmtw, Hyderabad, India. 2Assistant Professor, Dept of CSE,vmtw, Hyderabad, India. 3Assistant Professor. Dept of CSE,vmtw, Hyderabad, India. ABSTRACT In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in Systems Modeling Language (SysML) or as contractual statements. Use Case driven development is a key characteristic of process models and frameworks like Unified Process(UP), Rational Unified Process (RUP), Oracle Unified Method (OUM), etc. With its iterative and evolutionary nature, use case is also a good fit for agile development. Here in this paper we present the significance and impact of Use Cases of on software project management. Since Use Cases are the inception of the project management. Primary, at the product level Use Cases are helpful in formalizing the acceptance of product from client. The development company/project manager shall exhibit the functionality of the system using Use Cases, wherein the client will have complete knowledge of the product and will be in a position to go for agreement of the product.
    [Show full text]
  • Dr. Rakesh Kumar Introduction to Software Engineering Vetter: Dr
    Lesson No. I Writer: Dr. Rakesh Kumar Introduction to Software Engineering Vetter: Dr. Naresh Mann 1.0 Objectives The objective of this lesson is to make the students acquainted with the introductory concepts of software engineering. To make them familiar with the problem of software crisis this has ultimately resulted into the development of software engineering. After studying this lesson, the students will: 1. Understand what is software crisis? 2. What are software engineering and its importance? 3. What are the quality factors of software? 1.1 Introduction In order to develop a software product, user needs and constraints must be determined and explicitly stated; the product must be designed to accommodate implementers, users and maintainers; the source code must be carefully implemented and thoroughly tested; and supporting documents must be prepared. Software maintenance tasks include analysis of change request, redesign and modification of the source code, thorough testing of the modified code, updating of documents to reflect the changes and the distribution of modified work products to the appropriate user. The need for systematic approaches to development and maintenance of software products became 1 apparent in the 1960s. Many software developed at that time were subject to cost overruns, schedule slippage, lack of reliability, inefficiency, and lack of user acceptance. As computer systems become larger and complex, it became apparent that the demand for computer software was growing faster than our ability to produce and
    [Show full text]