Home Assignment - Detailed Conditions
Submit homework through e-mail to: Ábel Hegedüs
Requirements against the system to be modeled
Your task is to create a (business) process model of an IT system, subject to the following constraints:
- at least 10 elementary actions / steps (these will be the tasks of the process model)
preferably 3 independent resource types (more than 3 is also acceptable), that process instances will compete for
- the usage of the various resource types should fall within the same order of magnitude
nontrivial control flow, specifically
- at least one branch point (decision), simulated probabilistically
- at least one occurrence of either fork-join parallelism or a loop (formed by feeding back a decision to an earlier merge)
the system must be at least partially in an IT context
- at least one, preferably all of the resources must be IT-related
- if only partially IT-related, every phase of the home assignment should involve the IT-based parts
To be submitted: a one-page-long textual specification declaring the following aspects of the system:
- textual description of the system (approx. 2 paragraphs)
- the identity of the business item / token (the subject that experiences the process)
- elementary tasks and resources
- what kind of measurements will be carired out, and how
- whatkind of sensitivity will be analysed
The specification should be sufficient to recreate the entire process model (barring numerical constants). If the specification is vague or does not meet the required constraints, the grading of the latter part of the submission may be denied. Therefore it is recommended to ask for advice before you start buiding the model, if you suspect weak points in your specification.
Requirements against the model
The model should be easily comprehensible. To support this goal, take time to arrange the graphical elements of the diagrams in a suitable way.
All numerical parameters have to be set in the model:
- Resource allocation and usage time for individual tasks
- Initial (scarce) resource pool
- Decision probabilities
- Resource cost per time unit (this is used for reliability modeling, not yet required at the first submission)
These values should also be listed in a short documentation accompanying the model. It is recommended to compile these lists using the report generation features of the modeling tool. The documentation should also contain images depicting the various parts of the workflow.
At the point of submission, the model should be ready for simulation. This should be checked by running a brief test simulation.
IBM WebSphere Business Modeler V6.2 is provided and recommended as a modeling tool.
Deadline: 2011-10-30 23:59:59
A single ZIP archive containing the project report document alongside the (potentially revised) model. The report should consist of the (potentially revised) specification, the description and image of the business process with the lists of numerical parameters, and most importantly the description of measurements carried out, including results and conclusions.
Workload calibration. In order to obtain relevant measurement results, the workload should be chosen so that the system can be considered in steady state during the course of simulation runs. In other words, the initial filling up and final draining of the pipeline should not significantly impact the measurement results, and the behavior of the system per time should not be influenced by the length of the simulation. Additionally, the deviation in results that is inherent to probabilistic systems should also be mitigated by averaging over a large number of process instances. Finally, case should be taken that process instances are started with sufficient frequency so that they overlap and compete for resources. It is recommended to verify a given workload by examinig whether resource utilization is impacted by a significant increase in the number of process instances to be started or their arrival frequency.
Global performance limit. The throughput / roundtrip time of the system is to be measured without resource limits (i.e. with infinite resource pools), to obtain an upper limit on the real performace of the system.
Identifying and eliminating bottlenecks. The goal is to eliminate bottlenecks and measure the effect on system performance. Bottleneck resource types can be identified by their very high utilization, and the scarcity of the resource can be mitigated by increasing the resource pool of the given type (or decreasing, in case of superflous resources). This process is to be iterated until the utilization of each resource type falls between 40-60%.
Reliability analysis. The goal is to measure the (average, minimal, maximal) probability of a process instance finishing without technical failures, based on failure rates assigned to resource types. The recommended solution is to substitute the product of reliability probabilities of tasks executed in sequence with the sum of the logarithms of these probabilities. This way the modeling tool can use failure rates as a time-proportional resource usage cost to find out the (logarithm of the) process-level reliability. Failure rates can be derived from MTTF values. For more details, see the attached handout.
Sensitivity analysis. The goal is to measure how system performance is affected by varying the value of a numerical parameter (resource allocation time, decision probability). By running simulations and measurements at a wide range of values for the parameter, the analysis should find the degree at which system performance depends on the chosen parameter.
Deadline: 2010-12-04 23:59:59
Oral "defense" after Phase 2