Difference between revisions of "Xkraj119"

From Simulace.info
Jump to: navigation, search
Line 1: Line 1:
 
==Assignment==
 
==Assignment==
* Project name – Event Match-up Dynamics
+
* Project name – Providing SLA-backed support
 
* Author – Jan Kratochvíl
 
* Author – Jan Kratochvíl
* Software used – NetLogo 5
+
* Software used – Simprocess
* Simulation type – Multi-agent model
+
* Simulation type – Queues theory
== About the model ==
+
== Scenario ==
The target of the demonstration is to simulate the match-up process as happens in a closed, limited-time, in-person event, such as a concert or a birthday party.
+
A software firm recently developed a new facing custom solution for one of the major banking institutions. The solution is critical to the bank’s operations. Therefore the bank decided to pay for support from the solution developer and has signed a Service Level Assurance agreement. The agreement defines several levels of incidents:
=== The basic characteristics of the model are: ===
+
 
* Every population member has two basic preference types – physical attraction and mental compatibility
+
{| class="wikitable"
* Every population member has a specific sex assigned, as well as a sexual preference – heterosexual, homosexual, bisexual, asexual
+
|-
* The model is spatial. Population members interact with the nearest neighbors. After the interaction, they walk randomly until they find another actor.
+
! Incident Severity
* The length of interaction between population members (can be zero) is based on their mutual physical attraction
+
! Hotfix time (hours)
* After the interaction, both members score the other one. The score is a compound of physical attraction index and the mental compatibility index. The longer the interaction is, the more weight does the mental compatibility carries
+
! Resolution time (hours)
* The resulting score is a basis for decision about mating. Some members have no intention of mating, yet take part in interactions
+
! Penalty (per hour)
* The later it is in the game, the lower the score must be in order to be sufficient for mating
+
|-
=== Model configurability ===
+
| Standard
* Minimum score to match-up
+
| 16
* The pace with which does one’s standard lowers as the game reaches later stages
+
| 72
* Weight of physical attraction/mental compatibility in scoring model
+
| 100 EUR
* The initial spatial distribution of actors
+
|-
== Goal variables ==
+
| Severe
* Median compatibility score of matched-up actors
+
| 8
* Median number of turns for a match-up to happen
+
| 32
* Median number of interaction it takes to reach a match-up
+
| 400 EUR
* Percentage of actors able to find a match-up
+
|-
== Goals of the simulations are: ==
+
| Critical
* Does the initial spatial distribution of actors significantly alter the median compatibility score of matched-up actors
+
| 2
* What is the average of interactions needed to reach a match-up?
+
| 16
* Does altering the number of actors with no mating intention increase the percentage of actors able to find a match-up?
+
| 1000 EUR
* How aggressively do need the actors’ standards need to lower in order for vast majority of actors to find a match-up?
+
|}
 +
 
 +
* Hotfix – A fix to the problem that can be temporary and does not have to address the root issue. Can be deployed out-of-band directly by a developer, does not include testing
 +
* Resolution – Fixes a root cause of the problem, deployed as part of the daily build. Needs to go through a testing phase
 +
 
 +
The solution firm has the following resources types:
 +
{| class="wikitable"
 +
|-
 +
! Resource Type
 +
! Price per MD (Man-day)
 +
|-
 +
| Junior Developer
 +
| 280 EUR
 +
|-
 +
| Standard Developer
 +
| 300 EUR
 +
|-
 +
| Senior Developer
 +
| 350 EUR
 +
|}
 +
 
 +
* The number of resources deployed on support is fixed for a month, since the training of new resources for the project is expensive due to the project complexity
 +
* The cost of resources is paid regardless of the resource’s utilization rate (the company internally uses cost accounting methods)
 +
* Each resource type has a different level of efficiency when performing tasks (main task types are - development, testing). The exact coefficients will estimated as part of the task solution
 +
 
 +
== Goals ==
 +
 
 +
The banked asked the solution developer to price the SLA contract and provide a reasoning for the pricing.
 +
 
 +
The software firm decided to simulate a month-log support cycle to estimate the internal costs for upholding the support contract which it will use as a basis for pricing the SLA contract. The software firm will use data about incident frequency and severity obtained on a different project of a similar scope and client profile.
 +
 
 +
The goals of the software firm are to maximize profit and to minimize the resolution time for critical incident, since the firm knows, that a larger number of overdue critical fixes would cause the bank to be unsatisfied over the long term.
 +
 
 +
The goals can be summed up as follows:
 +
* Bank – minimize SLA contract price, prevent long incident hotfix and resolution times
 +
* Software firm – maximize revenue from SLA contract, prevent overstaffing and long critical resolution times
 +
 
  
 
[[User:Xkraj119|Jan Kratochvíl]] 18:17, 19 December 2014 (CET)~
 
[[User:Xkraj119|Jan Kratochvíl]] 18:17, 19 December 2014 (CET)~
  
I must confess I am usually quite sceptical to the assignments like this one for a couple of reasons. First, it is very hard to measure such soft parameters like "psysical attraction" and keep it in touch with reality. Second, I am not sure if a random walk is the best way how to simulate people searching for a partner. And finally, do the goals solve a real problem or they just follow an artificial reality of the simulation? [[User:Tomáš|Tomáš]] 00:26, 20 December 2014 (CET)
+
I must confess I am usually quite sceptical to the assignments like this one for a couple of reasons. First, it is very hard to measure such soft parameters like "psysical attraction" and keep it in touch with reality. Second, I am not sure if a random walk is the best way how to simulate people searching for a partner. And finally, do the goals solve a real problem or they just follow an artificial reality of the simulation? - [[User:Tomáš|Tomáš]] 00:26, 20 December 2014 (CET)
 +
 
 +
I agree with your objections. Therefore I've defined a different task, one which is more in my area of expertise :-). As for the resource types efficiency, I feel that I can estimate them well since I have similar data available to me. What do you think? - [[User:Xkraj119|Jan Kratochvíl]] 10:30, 22 December 2014 (CET)~

Revision as of 10:35, 22 December 2014

Assignment

  • Project name – Providing SLA-backed support
  • Author – Jan Kratochvíl
  • Software used – Simprocess
  • Simulation type – Queues theory

Scenario

A software firm recently developed a new facing custom solution for one of the major banking institutions. The solution is critical to the bank’s operations. Therefore the bank decided to pay for support from the solution developer and has signed a Service Level Assurance agreement. The agreement defines several levels of incidents:

Incident Severity Hotfix time (hours) Resolution time (hours) Penalty (per hour)
Standard 16 72 100 EUR
Severe 8 32 400 EUR
Critical 2 16 1000 EUR
  • Hotfix – A fix to the problem that can be temporary and does not have to address the root issue. Can be deployed out-of-band directly by a developer, does not include testing
  • Resolution – Fixes a root cause of the problem, deployed as part of the daily build. Needs to go through a testing phase

The solution firm has the following resources types:

Resource Type Price per MD (Man-day)
Junior Developer 280 EUR
Standard Developer 300 EUR
Senior Developer 350 EUR
  • The number of resources deployed on support is fixed for a month, since the training of new resources for the project is expensive due to the project complexity
  • The cost of resources is paid regardless of the resource’s utilization rate (the company internally uses cost accounting methods)
  • Each resource type has a different level of efficiency when performing tasks (main task types are - development, testing). The exact coefficients will estimated as part of the task solution

Goals

The banked asked the solution developer to price the SLA contract and provide a reasoning for the pricing.

The software firm decided to simulate a month-log support cycle to estimate the internal costs for upholding the support contract which it will use as a basis for pricing the SLA contract. The software firm will use data about incident frequency and severity obtained on a different project of a similar scope and client profile.

The goals of the software firm are to maximize profit and to minimize the resolution time for critical incident, since the firm knows, that a larger number of overdue critical fixes would cause the bank to be unsatisfied over the long term.

The goals can be summed up as follows:

  • Bank – minimize SLA contract price, prevent long incident hotfix and resolution times
  • Software firm – maximize revenue from SLA contract, prevent overstaffing and long critical resolution times


Jan Kratochvíl 18:17, 19 December 2014 (CET)~

I must confess I am usually quite sceptical to the assignments like this one for a couple of reasons. First, it is very hard to measure such soft parameters like "psysical attraction" and keep it in touch with reality. Second, I am not sure if a random walk is the best way how to simulate people searching for a partner. And finally, do the goals solve a real problem or they just follow an artificial reality of the simulation? - Tomáš 00:26, 20 December 2014 (CET)

I agree with your objections. Therefore I've defined a different task, one which is more in my area of expertise :-). As for the resource types efficiency, I feel that I can estimate them well since I have similar data available to me. What do you think? - Jan Kratochvíl 10:30, 22 December 2014 (CET)~