1 / 61

IS 421 Information Systems Analysis

IS 421 Information Systems Analysis. James Nowotarski 21 October 2002. Today’s Objectives. Finish coverage of data modeling Understand rules and elements of data flow diagrams Understand the process for creating data flow diagrams Create simple data flow diagrams. Course Map. Contents

sarcher
Télécharger la présentation

IS 421 Information Systems Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IS 421Information Systems Analysis James Nowotarski 21 October 2002

  2. Today’s Objectives • Finish coverage of data modeling • Understand rules and elements of data flow diagrams • Understand the process for creating data flow diagrams • Create simple data flow diagrams

  3. Course Map Contents 1. Introduction Planning Phase 2. Project Initiation 3. Project Management Analysis Phase 4. Systems Analysis 5. Gathering Information 6. Process Modeling 7. Data Modeling 1 2 3 4 5 6 7 8 9 10 11 Week Core Exam Review Assignments Quizzes Final

  4. Today’s agenda Topic Duration • Recap Data Modeling 30 minutes • Quiz 45 minutes *** Break 15 minutes • Process Modeling 90 minutes • Assignment 4 Intro 10 minutes

  5. Today’s agenda Topic Duration • Recap Data Modeling 30 minutes • Quiz 45 minutes *** Break 15 minutes • Process Modeling 90 minutes • Assignment 4 Intro 10 minutes

  6. Foreign Key Example • Customer(cust_id (PK), cust_name) • Order (ord_no (PK), cust_id (FK), ord_date) Customers (Parent) Orders (Child) cust_idcust_name 100 Slick Willy, Inc. 200 George_W, Co. 300 Gore, Ltd. … ord no cust_idord_date 2100 200 13-Sep-2000 2101 100 14-Nov-2000 2102 100 23-Dec-2000 2103 100 24-Dec-2000 … PK Cust_id FK A foreign key is a primary key of one entity that is duplicated in another entity to provide a common linkage between entities.

  7. Entity Types • Independent • Dependent • Intersection

  8. An independent entity exists without the help of another entity Common entities such as student, professors, customers, products The identifier is created by the entity’s own attributes Usually on the “1” side of a relationship a.k.a. fundamental entity (in Visual Analyst, e.g.) or strong entity Independent Entities

  9. Alternatively, a dependent entitycannot exist without the help of another entity Special entities such as emp_dependent (needs an employee to exist) The identifier is usually based on another entity’s attributes (emp_ssn & dep_ssn) Usually on the “M” side of a relationship a.k.a. attributive entity (in Visual Analyst, e.g.) or weak entity Dependent Entities

  10. An intersection entity exists based on the relationship between two entities. They have attributes that are peculiar to the relationship between those entity instances, not the individual entities themselves They are created to store information about two entities sharing an M:M relationship a.k.a. associative entities, gerunds Intersection entities

  11. Intersection Entity Example A student may take many classes. A class may have many students. Where are grades stored? Class Student Student Roster Class An instance in the student entity is related to _____ instances in the class entity. An instance in the class entity is related to _____ instances in the student entity.

  12. Adding Intersection Entities • Create an intersection entity (line item). • Move the “M’s” adjacent to the intersection entity. 3. The “1” side goes on the original entities.

  13. M:N to 1:Ms • Rule: The M always go to the intersection entity. Why?

  14. Creating An Entity-Relationship Diagram

  15. Steps in Building Data Models • Review existing data models • Define entities • Independent • Dependent, including Intersection entities • Define attributes and keys (primary, foreign) • Define relationships • Finalize ERD • Normalize (to be covered in IS 422) • Integrate data models as required • Verify completeness of the data model • Validate the data model • With users • With the enterprise’s data administrator

  16. Best practices rather than rigid rules Entities should have many instances (don’t include fixed items such as stationery headings) Avoid unnecessary attributes (outside the scope of your system) Apply correct cardinality and modality Labels reflect common business terms Assumptions should be clearly stated Design Guidelines

  17. Summary • The ERD is the most common technique for drawing data models. The building blocks of the ERD are: • Entities (nouns), describe people, places, or things • Attributes (nouns), capture information about the entity • Relationships (active verb sentences) associate data across entities; they have cardinality and modality

  18. Today’s agenda Topic Duration • Recap Data Modeling 30 minutes • Quiz 45 minutes *** Break 15 minutes • Process Modeling 90 minutes • Assignment 4 Intro 10 minutes

  19. Today’s agenda Topic Duration • Recap Data Modeling 30 minutes • Quiz 45 minutes *** Break 15 minutes • Process Modeling 90 minutes • Assignment 4 Intro 10 minutes

  20. Planning Analysis Design SDLC The systems development life cycle (SDLC) is a description of the phases of an information system Implementation

  21. Develop ProcessModel Prepare Proposal Develop Data Model Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Process Modeling in the Analysis Phase From Planning Phase: Develop Concept for To-Be System System request Feasibility analysis Workplan . . . To Design Phase: Deliverables: Analysis Plan Functional Requirements Quality Requirements Data Model Process Model System Proposal System Concept

  22. Key Definitions • A process model is a formal way of representing business processes • Illustrates processes/activities and how data moves among them • Data flow diagramming is a technique for creating a process model. • The primary output of data flow diagramming is a data flow diagram (DFD)

  23. Key Definitions • Logical process models describe processes without suggesting how they are conducted • Physical models include information about how the processes are implemented

  24. Data Flow Diagrams

  25. employee_data salary tax employee_data employee_ data salary tax salary GET_DATA CALC_TAX PRINT_CHECK CALC_SALARY Structure Chart PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax)

  26. Program Graph employee_data PRINT_ PAYCHECK salary CALC_ SALARY taxes employee_ data READ_ DATA CALC_ TAXES salary

  27. Program Graph Big idea: As a prelude to creating a design, represent the basic computational requirement for the system to be designed in more abstract terms, i.e., in terms of data flow employee_data PRINT_ PAYCHECK salary CALC_ SALARY taxes employee_ data READ_ DATA CALC_ TAXES salary

  28. DFD Elements

  29. Some Rules for External Entities • External people, organizations, systems and data stores • Reside outside the system, but interact with system • Either receive info from system or trigger system into motion • Examples: Customers, managers • Not clerks or other staff External Entities

  30. Some Rules for Data Stores • Internal to the system • Data at rest • Include in system if the system processes transform the data • Create, Update, Delete • Every data store on DFD should correspond to an entity on an ERD • Must have at least one input data flow (or else they never contain any data) • Usually have at least one output data flow D1 Data Stores

  31. Some Rules for Data Flows • Data in motion • From external entity (“source”) to system • From system to external entity (“sink”) • From internal symbol to internal symbol, but always either start or end at a process Data Flow

  32. Some Rules for Processes 0. • Always internal to system • Law of conservation of data: #1: Data stays at rest unless moved by a process. #2: Processes cannot consume or manufacture data • Must have at least 1 input data flow (to avoid miracles) • Must have at least 1 output data flow (to avoid black holes) • Should have sufficient inputs to create outputs (to avoid gray holes) Processes

  33. Processes • Logical process models omit any processes that do nothing more than move or route data, thus leaving the data unchanged. Valid processes include those that: • Perform computations (e.g., calculate grade point average) • Make decisions (e.g., determine availability of ordered products) • Sort, filter or otherwise summarize data (e.g., identify overdue invoices) • Organize data into useful information (e.g., generate a report or answer a question) • Trigger other processes (e.g., turn on the furnace or instruct a robot) • Use stored data (create, read, update or delete a record)

  34. Structured English Common Statements Example Action Statement Profits = Revenues - Expenses Generate Inventory - Report Add Product record to Product Data Store If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current-Sale to Customer’s Total-Sales Update Customer record in Customer Data Store For Statement FOR all Customers in Customer Data Store Generate a new line in the Customer-Report Add Customer’s Total-Sales to Report-Total Case Statement CASE If Income < 10,000: Marginal-tax-rate = 10% If Income < 20,000: Marginal-tax-rate = 20% If Income < 30,000: Marginal-tax-rate = 31% If Income < 40,000: Marginal-tax-rate = 35% ELSE Marginal-tax-rate = 38% ENDCASE

  35. Creating Data Flow Diagrams Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create Use cases/textual requirements descriptions 2. Create a Context diagram 3. Create DFD fragments for each use case/requirement 4. Create a Level 0 diagram from fragments 5. Decompose to Level 1,2,… 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

  36. Creating Use Cases

  37. Step 1. Use Cases • Ask who, what, where, when about tasks the system will perform • Major tasks: • Who does them? When? • What info is required to perform the task? • What output is generated? Where does the output go? • Remember: The process is iterative. • Remember: Use cases are for users’ benefit, not programmers.

  38. Step 1. Use Cases • Name: becomes a process name on the level 0 DFD • Description • Trigger: external or temporal • Major inputs: become data flows • Major outputs: become data flows • Major steps performed: become process names on the level 1 DFD • Information for steps

  39. Creating Data Flow Diagrams

  40. Steps in Building DFDs 2. Create the context diagram 3. Create DFD fragments for each use case 4. Organize DFD fragments into level 0 diagram 5. Decompose level 0 DFDs as needed 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

  41. Shows the context into which the business process fits Shows the overall business process as just one process Shows all the outside entities that receive information from or contribute information to the system Step 2. Context Diagram

  42. Draw the overall system as a process. Number the process 0. Label the process as the name of the system. Draw and label all external entities. No data stores, unless external. Draw data flows for all possible data coming from or going to external entities Bundle data flows as you deem necessary Step 2. Context Diagram

  43. Context Diagram Example

  44. Step 3. Create DFD Fragments • For each use case, create a DFD fragment. • One process (verb phrase) per fragment • Maintain organization’s viewpoint in naming processes • Layouts often place: • Process in the center • Inputs from the left • Outputs to the right • Add data stores beneath the processes

  45. DFD Fragment Example

  46. Integrate DFD fragments to a Level 0 DFD There will be one Level 0 diagram, Shows all the processes that comprise the overall system A decomposition of the process on the context diagram Shows how information moves from and to each process Step 4. Level 0 Diagram

  47. Level 0 Tips • Generally move from top to bottom, left to right • Minimize crossed lines • Iterate as needed • The DFD is often drawn many times before it is finished, even with very experienced systems analysts

  48. Some Data Flow Rules A process moves data from place to place in the system. On a data flow diagram, processes may move data between certain symbols (data stores, external entities, and other processes). However, data may not be moved without a process. To help you understand and appreciate this, fill in the empty cells in the following table. The cell entries should either be 1) An example of how data could be moved; 2) N/A to indicate this cannot be done. In this example, “customer information” may be moved from an external entity to a process (e.g., a customer gives their address and credit card information to a sales agent). The “N/A” suggests data cannot be moved from a data store directly to an external entity, which is true (you need a process in between them).

  49. Relationship Among DFD levels

  50. A major step on the use case is usually a process on the Level 1 DFD Level 1 DFD shows all the processes that comprise a single process on the level 0 diagram Inputs to step are input data flows to process Outputs to step are output data flows from process In general, # level 1 DFDs =# of processes on level 0 DFD Step 5. Level 1 Diagrams

More Related