SADM 6/ed - CASE STUDY 1 CRS - Milestone 6: Process ModelingPage: 6-1

MILESTONE 6 – PROCESS MODELING

Synopsis

P

rocess modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and/or the logic, policies, and procedures to be implemented by a system’s processes. In this milestone we focus on using and constructing data flow diagrams (DFDs) and decomposition diagrams to perform process modeling.

Data flow diagrams are tools that depict the flow of data through a system and the work or processing performed by that system. A decomposition diagram is a DFD planning tool that shows the top-down functional decomposition and structure of a system.

During this milestone you will first construct a context diagram to establish project scope and boundaries. Secondly, you will draw an event decomposition diagram to partition the system into logical subsystems and/or functions. Thirdly, you will draw event diagrams to model individual processes. Finally you will construct a system data flow diagram that shows the big picture of the system, and a primitive data flow diagram for a single event process.

Objectives

After completing this milestone, you should be able to:

Construct a context diagram to illustrate a system’s interfaces with its environment.

Identify external and temporal business events for a system.

Logically group events to create an event decomposition diagram.

Create event diagrams.

Merge event diagrams into a system data flow diagram.

Draw appropriate primitive data flow diagrams.

Prerequisites

  1. Process modeling - Chapter 9
  2. Optional: Solutions for Milestone 3-5

Assignment

As a systems analyst or knowledgeable end-user, you must learn how to draw decomposition and data flow diagrams to model business process requirements. The preliminary investigation and problem analysis phases of the methodology have been completed and you understand the current system’s strengths, weaknesses, limitations, problems, opportunities, and constraints. You have already built the data model (Milestones 4 and 5) to document business data requirements for the new system. You now need to build the corresponding process models.

Activities

  1. Draw a Context Diagram using the accompanying narrative.
  2. Given the accompanying use-case (event/response) matrix, draw the Event Decomposition Diagram.
  3. Given your decomposition diagram from above and the use-case matrix, draw Event Diagramsfor “Generate month invoices” and “enter service equipments” events. Use your data model from milestones 3 and 4 as an attribute reference. Also, state any assumptions you make.
  4. (Optional) Merge your event diagrams from #3 above into a System Diagram.
  5. For all transaction processes described in the accompanying narratives, draw the Primitive Data Flow Diagram.

Please email the deliverables to the TA and the instructor

References:

Completed Solutions from Prior Milestones

Context Diagram Narrative

Exhibit 6.1

Completed Use-Case (or Event-Response) List

Exhibit 6.2

Primitive Diagram Narrative(s)

Exhibit 6.3

Deliverables:

Context Diagram:Due: __/__/__

Time:______

Decomposition Diagram:Due: __/__/__

Time:______

Event Diagrams:Due: __/__/__

Time:______

System Diagram:Due: __/__/__

Time:______

Primitive Diagram(s):Due: __/__/__

Time:______

ADVANCED OPTION

Exhibit 6.2 is a partial Use-Case list. Add all maintenance Use-Cases necessary to match the system narrative in Exhibit 6.1 and to maintain the data structure established in previous milestones. Then draw the Event Decomposition Diagrams and the System Diagram based on the complete list.

Use-cases:Due: __/__/__

Time:______

Activity diagrams and state models:Due: __/__/__

Time:______

Milestone’s Point Value:______

Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 6ed

by J. L. Whitten, L. D. Bentley, & K. C. DittmanCopyright Irwin/McGraw-Hill 2004

SADM 6/ed - CASE STUDY 1 CRS - Milestone 6: Process ModelingPage: 6-1

Exhibit 6.1

Use the following narrative to construct the Context Diagram for the Customer Response System

The purpose of the Customer Response System is to provide a central repository of all information related to servicing clients. This includes service requests, the work done on service requests, other time-and-billing records, and a complete list of each piece of equipment and all the components installed on that equipment that is services by Coastline Systems Consulting.

Users, including clients, technicians, and Coastline management, will submit service requests to the system whenever they have a problem. Users will also be able to check on the status of service requests at any time. In response to a submitted service request, the system will automatically assign each request to a technician and send an e-mail to the technician. As they respond to and fix problems, technicians will enter service information. If they replace parts or entire machines, they will also enter new equipment and component change information. To help technicians do their jobs, they will be able to view reports of the service and component installation history of any machine.

In addition, technicians will use the system to record other kinds of time-and-billing including work done on new projects and other reimbursable expenses. Coastline management will be able to use this information to do generate monthly invoices to clients.

Coastline management will be able to view various management reports such as service requests and responses for any period of time and the work history. Coastline management will also be able to view key statistics and trends such as average response time.

Exhibit 6.2

Below is a Use-Case list for the major processes of the system. To keep the assignment simple, most “maintenance” events, such as adding new technicians or component types and edit/delete options have been ignored.

Actor(s) / Event (or Use-Case) / Trigger / Responses
Client
Technician
Management / Enter Service Request / Upon request / Create new Service Request in database
Send e-mail to appropriate Technician
Client
Technician
Management / Check Unresolved Requests / Upon request / Display request information on screen
Client
Technician / Resolve Service Request / When problem is solved / Update request information to mark as resolved
Technician / Enter Work Record / Tech performs work / Create new Work Record in database
Technician / Enter Misc Charge / Tech purchases something reimbursable for a client / Create new OtherCharge in database
Management / Enter New Client / Upon request / Create a new Client in database
Management / Make Service Statistic Inquiry / Upon request / Generate statistics report
Technician / Enter Component Information / New component is installed / Create new Equipment Component in database
Technician / Enter New Equip / New equipment is sold to client / Create new Equipment in database
Time / Generate Monthly Invoices / End of month / Invoices printed and ready to be sent to clients
Exhibit 6.3

Use the following narrative to construct the Primitive Diagram for the Enter Component Information event.

The user will select the Enter Component option from the user interface. The technician will be asked to identify the client. Depending on implementation, the client selection may need to be checked for validity. If it is not valid, send an error response to the user. The system will then display a list of equipment installed for that client. The user will select the appropriate piece of equipment where the component was installed. The system will then provide a screen requesting the user to select the type of component. The user will also enter the quantity, serial number, and installation date. The installation date will default to the current system date. The new component information will then be recorded in the data store and a confirmation message will be given to the user.

Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 6ed

by J. L. Whitten, L. D. Bentley, & K. C. DittmanCopyright Irwin/McGraw-Hill 2004