Reference no: EM132484321 , Length: 1000 words

Business Analysis

Section A Workflow Modelling and Implementation using YAWL or SAS Studio

Section 1: Process Modelling (Using YAWL Editor)

First, download the software from YAWL Sourceforge page. The green button should allow you to download the whole package at one go.

Unzip the file into a directory.

• Under the installation root directory, you will find the user manual document (in pdf)
• Under 'bin' directory, you should see all the control command that you can use to start/stop YAWL engine and the editor.

Start the YAWL engine (found under 'bin'). Try running Control Centre to test that the engine is running.

Now, start the YAWL Editor (found under 'bin'). Under Specification menu, choose 'New Specification'. You should see an empty YAWL specification with a start and end places filled in.

• Activity register: an account manager receives a booking request from a customer and registers the details.
• Depending on the booking request type, one or more of booking tasks (flight, hotel or car) is carried out by a booking agent.
• After bookings are done, the account manager process the payment

Step 1: Implement control flow aspect

Create a control flow aspect of the model. Put in the tasks and task routing options in place as shown in the above figure (Note the OR split (inclusive OR, i.e., one or more options) and OR join in the figure). A quick look at this video will show you the basic use of the editor. It is recommended that you create tasks first (i.e., squares) and then create links and task routing.

Step 2: Implement data flow aspect

(from YAWL user manual page 27, section 3.3 and page 32, section 3.4.2) Add task decompositions to each task and data flow specification.

Before we add this information to the model, we need to understand the task composition and variables in YAWL. Note that a net here refers to a YAWL model specification (often referred to as YAWL net).

First, we need to specify how information passes from YAWL to its Sectionicipants (e.g. workers and external applications) and how the data comes back into YAWL once they are finished. This is done by attaching a decomposition to each task. Every atomic task that requires work to be performed needs to have a decomposition. A decomposition may be described as a contract between the task and its environment, describing the data that will be assigned and updated when the task is performed.

Second, we need to specify data flow, i.e., what data will be passed about during the execution of an instance of this specification. Specifically, we need to describe what data Sectionicipants will need in each work item, and what data they must return to the Engine once the work item is complete. We also need to have a way of moving data about in the running workflow, including how we can use that data to automatically choose between flows in a running workflow. For this, each task decomposition has a number of parameters (or variables) defined for them, describing what data must be supplied to a running net or task instance, and what data that net or task instance will eventually deliver. Each parameter has a name it may be referenced by, a type dictating valid values it may store, a designation indicating how that data may be used, and a scope defining the visibility of the parameter.

Step 4: Implement resource aspect

(from page 31, section 3.4.1 User Manual). To define an organisational model (i.e., roles and workers) you need to log into the YAWL Resource Service (for now, we will use the generic username admin and password YAWL). Assuming you used one of the automatic installers, this is simply a matter of starting the engine (choose Start Engine from the options shown for the YAWL program) followed by access the Resource Service in a Web Browser (choose YAWL Control Centre from the options shown for the YAWL program). When you have logged in you can create new roles by choosing the Org Data from the menubar, and new Sectionicipants by choosing Users form from the menubar. Once we have defined all the required roles and Sectionicipants, we can specify resourcing requirements for tasks. Go back in the Editor, right click with your mouse on a task and choose 'Manage Resourcing'.

Step 5: Executing the workflow specification

Now, you have defined all aspects of the workflow. Now the engine can 'run' the instances from the information given in the specification. Try logging in as the different users you have created in the resources Section, and see how the system works.

*Section B

Design process architectures for ANY ONE of the following two cases.

Case 1: A Process Architecture for a University

Design a process architecture as follows:
Q1. identify the case types that should appear in the process architecture

Q2. identify the functions that should appear in the process architecture

Q3. draw a case/function matrix

Q4. identify the processes in the case function matrix, split up processes if and only if one of the guidelines applies (see Appendix), clearly indicate which guideline you applied and where.

Case 2: A Process Architecture for a Consultancy Firm

Design a process architecture as follows:
Q1. identify the case types that should appear in the process architecture

Q2. identify the functions that should appear in the process architecture

Q3. draw a case/function matrix

Q4. identify the processes in the case function matrix, split up processes if and only if one of the guidelines applies (see Appendix), clearly indicate which guideline you applied and where.

*Note: Need only Section B

Attachment:- Workflow Modelling.rar