Simulace.info - User contributions [en]

Software Support Lifecycle

2015-01-24T14:15:34Z

Xkraj119: /* Result */

== Problem Recap ==
A software firm was contracted to develop a new customer-facing solution for a major banking institution. As part of the negotiation process, an SLA needs to be reached. The banking institution provided required issue resolution times and asked the software firm to appropriately price the contract while provide reasoning for the contract pricing.

The software firm decided to create a simulation of a typical month of the support cycle as a basis for approximate the resources needed to provide the support.

== Approach ==
The model consists of various severity incidents, represented as entities, and various development resources, represented as resources in SIMPROCESS. The model aims to represent a reasonably simplified version of the real development process.

The model needs to represent developer shifts, “emergency holding” (where developer does not work, but is available to start solving incidents in a reasonable amount of time) and overtime billing.

== Model Structure ==
=== Entities ===
==== Incidents ====
There are several severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
The SLA terms of different incidents can be found [http://www.simulace.info/index.php/Xkraj119 here].
{| class="wikitable"
|-
! Incident Type
! Severity (lower is less severe)
! Probability of Occurrence (per hour)
|-
| Standard
| 1
| Nor(0.4, 0.25, 1)
|-
| Severe
| 2
| Nor(0.2, 0.25, 1)
|-
| Critical
| 3
| Nor(0.075, 0.25, 1)
|}

It is important to note, that higher severity incidents can preempt lower severity incidents, which is desirable as higher severity incidents have more strict SLA terms.

While the normal distribution is sometimes considered problematic when using it to generate entities, due to the fact that a lot of real distributions are not symmetrical and instead are “right-leaning”, I believe that the normal distribution is sufficient for this scenario. An alternative shape that seem to be a bit more realistic was a beta distribution, but seeing the relatively small impact on the results, I chose a normal distribution, since it is far more accessible and requires less expertise to understand.

==== Technical Entities ====
Another type of entity in the system is a Release Trigger. The Release Trigger is responsible for triggering an automated software build every 24 hours.

=== Resources (Developers) ===
Developers are grouped into three tiers – standard, junior and senior. Each developer tier has different pricing (here) and might not be able to participate in all parts of the process. The developers get paid a fixed wage, regardless of their utilization. The developers work in the 8x5 mode. This is however problematic when dealing with high-severity incidents, which have strict SLA terms.

Therefore, a new tier has been added – “Developer – Standard – Overtime”. The role of this tier is to hold “emergency” in non-working hours of the day (17:00 – 9:00 on work days + whole weekends). Holding emergency means, that the developer is ready to immediately start resolving critical bugs from his home office. For this, the developer is compensated in the following way: The developer gets paid 10% of his standard hourly wage for every hour he holds emergency, regardless of the number of incidents (fixed cost). Apart from that, the developer gets paid for every hour he spends resolving incidents in the emergency hours (variable cost).

=== Support Process ===
The incident resolution process is as follows:

[[File:SoftwareSupport-Process.jpg]]

Things to note about the process:
* Standard severity incidents are not eligible for hotfixing
* Since junior developers do not have full knowledge of the system, they are excluded from the hotfix development and incident resolution activities
* Hotfix development is a high-risk activity (deployed directly to production without proper testing), standard developers need to pair up when developing the hotfix
* Critical incidents are released “out-of-band”, meaning they do not wait for the next release and are released individually

== Simulation Result & Analysis ==
The conflicting goals of the task are obvious. On the one side, we wish to minimize the time of incident resolution. Unless we consider rearchitecting the support process, this is done mainly by deploying additional resources. On the other side, we wish to minimize the amount of deployed resources to optimize support costs and create room for margin generation.

The model shows, that a good compromise between these two goals can be reached with the following resource deployment:

{| class="wikitable"
|-
! Resource Type
! Number of Resources
|-
| Junior Developer
| 1
|-
| Senior Developer
| 2
|-
| Standard Developer
| 4
|-
| Standard Developer - Overtime
| 2
|}

The rest of this chapter will aim at providing supporting evidence for this conclusion. I will refer to the above configuration as 1-2-4-2 configuration

=== Utilization and Depreciating Returns on Additional Resources ===
The utilization of the above configuration is as follows:

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 49.93
|-
| Senior Developer
| 65.35
|-
| Standard Developer
| 79.1
|-
| Standard Developer - Overtime
| 83.09
|}

Granted, the utilization above might seem low. Consider the case when we remove one Senior Developer from the team. Than the utilization will be as follows (1-1-4-2):

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 87.77
|-
| Senior Developer
| 94.92
|-
| Standard Developer
| 95.7
|-
| Standard Developer - Overtime
| 96.45
|}

This looks much better. It is however important to realize, that while near 100% utilization is good for product development teams, for support teams the situation looks different. There, utilization near 100% means very little headroom for situations where more than expected incident occur. To illustrate this, let’s compare average incident resolution times between 1-2-4-2 and 1-1-4-2

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 13.76
| 36.01
|-
| Severe
| 36.23
| 94
|-
| Standard
| 63.72
| 159
|}

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 11.11
| 21.36
|-
| Severe
| 28.51
| 81
|-
| Standard
| 36.64
| 122
|}

As we can see, the difference in resolution times is stark, especially when considering the average resolution time of standard-severity incident, which almost doubled. As we can see, utilization nearing 100% percent can actually considered bad, as it lowers the ability of support teams to appropriately absorb additional incidents.

From the other side, when we add additional resources to the 1-2-4-2 scenario, we see only small decreases in resolution times. Therefore, the 1-2-4-2 seems to be a good compromise from the utilization/resolution time standpoint.

=== Minimizing Resolution & Hotfix Delivery Time Spikes ===
An important characteristic that deserves extra attention are individual resolution and hotfix times. So far, we have been mostly concerned with averages, but when running an SLA-bound support team, it is important to consider the fix times for individual incident, with utmost focus on minimizing the number of “spikes” in critical incidents, as those have severe impact on customers.

In the following histograms, we see the individual hotfix and resolution times (in hours) categorized by incident severity for the 1-2-4-2 configuration.

[[File:HotfixHistogram.png]]

[[File:ResolutionHistogram.png]]

As we can see, the results are encouraging. The times for critical incidents are very consistent with no spikes at all. While we can see occasional spikes for lower-priority incidents, eliminating those would require deploying multiple additional resources which does not seem to be worth the cost.

There is however one thing that we need to address at this point. While a reasonable amount of incidents that exceeds the SLA terms is standard, the hotfix times for critical incidents are consistently higher than in the bank-proposed SLA terms. This is not caused by “waiting for resources”, but by structural inability to deliver such fix times by the current process. This can be seen from that the fact, that while the average resolution of a critical incident is 11.11 hours, this figure composes of 7.98 hours of processing and only 3.13 hours of waiting. This facts need to be communicated to the bank and an attempt to raise the fix time of critical incidents to a more acceptable level (e.g. 6 hours) needs to be made.

=== Preventing Incident Accumulation ===
The last important metric we will consider is the chronological development of average hotfix and resolution times. While these times do not need to be absolutely stable over time (with the exception of critical incidents, where there is very little room for error), there should not be a tendency of higher values in time, as that would indicate that the system is getting backed up and might collapse at some point in the future. Let’s see the results for the 1-2-4-2 configuration.

[[File:HotfixTrace.png]]

[[File:ResolutionTrace.png]]

While one cannot call the results stable, the spikes always seem to return to an acceptable value making the system stable over longer periods of time.

== SLA Contract Pricing ==
The total cost of upholding the SLA contract, excluding SLA violation-related penalties is 78432 EUR per month. The cost breaks down as follows:

[[File:ResourceCosts.png]]

On top of that, we must calculate a risk margin to cover the SLA violation penalties.

As part of the simulation, it became clear that the SLA hotfix and response times and penalties need to be recalibrated in several ways
* Some of the times are simply unrealistic due to the current support process
* The bank provided the hours in the 8x5 mode (“business hours”), while the developer operates exclusively in the 24x7 mode
* To prevent double penalty billing for incident, when the hotfix time exceeds the allowed resolution time, only the resolution time penalty will be billed from now on
* The resolution time penalties will be dropped by ¾ and differentiated from hotfix time penalties

The updated proposed SLA times are:
{| class="wikitable"
|-
! Incident Type
! Hotfix time (hours)
! Resolution time (hours)
! Hotfix penalty (per hour)
! Resolution penalty (per hour)
|-
| Critical
| 8
| 24
| 1000 EUR
| 250 EUR
|-
| Severe
| 24
| 72
| 400 EUR
| 100 EUR
|-
| Standard
| -
| 168
| 100 EUR
| 100 EUR
|}

For these times, '''the estimated monthly penalty is 62750 EUR. Source data can be found here - [[File:Appreciation.xlsx]] With a 20% risk margin, that makes the absolute risk margin 75300 EUR'''.

That brings the '''total contract price to 153 732 EUR per month'''.

== Source Code ==
The source code can be found here - [[File:SoftwareSupportLifecycleModel.zip]]

Software Support Lifecycle

2015-01-24T14:14:52Z

Xkraj119:

== Problem Recap ==
A software firm was contracted to develop a new customer-facing solution for a major banking institution. As part of the negotiation process, an SLA needs to be reached. The banking institution provided required issue resolution times and asked the software firm to appropriately price the contract while provide reasoning for the contract pricing.

The software firm decided to create a simulation of a typical month of the support cycle as a basis for approximate the resources needed to provide the support.

== Approach ==
The model consists of various severity incidents, represented as entities, and various development resources, represented as resources in SIMPROCESS. The model aims to represent a reasonably simplified version of the real development process.

The model needs to represent developer shifts, “emergency holding” (where developer does not work, but is available to start solving incidents in a reasonable amount of time) and overtime billing.

== Model Structure ==
=== Entities ===
==== Incidents ====
There are several severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
The SLA terms of different incidents can be found [http://www.simulace.info/index.php/Xkraj119 here].
{| class="wikitable"
|-
! Incident Type
! Severity (lower is less severe)
! Probability of Occurrence (per hour)
|-
| Standard
| 1
| Nor(0.4, 0.25, 1)
|-
| Severe
| 2
| Nor(0.2, 0.25, 1)
|-
| Critical
| 3
| Nor(0.075, 0.25, 1)
|}

It is important to note, that higher severity incidents can preempt lower severity incidents, which is desirable as higher severity incidents have more strict SLA terms.

While the normal distribution is sometimes considered problematic when using it to generate entities, due to the fact that a lot of real distributions are not symmetrical and instead are “right-leaning”, I believe that the normal distribution is sufficient for this scenario. An alternative shape that seem to be a bit more realistic was a beta distribution, but seeing the relatively small impact on the results, I chose a normal distribution, since it is far more accessible and requires less expertise to understand.

==== Technical Entities ====
Another type of entity in the system is a Release Trigger. The Release Trigger is responsible for triggering an automated software build every 24 hours.

=== Resources (Developers) ===
Developers are grouped into three tiers – standard, junior and senior. Each developer tier has different pricing (here) and might not be able to participate in all parts of the process. The developers get paid a fixed wage, regardless of their utilization. The developers work in the 8x5 mode. This is however problematic when dealing with high-severity incidents, which have strict SLA terms.

Therefore, a new tier has been added – “Developer – Standard – Overtime”. The role of this tier is to hold “emergency” in non-working hours of the day (17:00 – 9:00 on work days + whole weekends). Holding emergency means, that the developer is ready to immediately start resolving critical bugs from his home office. For this, the developer is compensated in the following way: The developer gets paid 10% of his standard hourly wage for every hour he holds emergency, regardless of the number of incidents (fixed cost). Apart from that, the developer gets paid for every hour he spends resolving incidents in the emergency hours (variable cost).

=== Support Process ===
The incident resolution process is as follows:

[[File:SoftwareSupport-Process.jpg]]

Things to note about the process:
* Standard severity incidents are not eligible for hotfixing
* Since junior developers do not have full knowledge of the system, they are excluded from the hotfix development and incident resolution activities
* Hotfix development is a high-risk activity (deployed directly to production without proper testing), standard developers need to pair up when developing the hotfix
* Critical incidents are released “out-of-band”, meaning they do not wait for the next release and are released individually

== Result ==
The conflicting goals of the task are obvious. On the one side, we wish to minimize the time of incident resolution. Unless we consider rearchitecting the support process, this is done mainly by deploying additional resources. On the other side, we wish to minimize the amount of deployed resources to optimize support costs and create room for margin generation.

The model shows, that a good compromise between these two goals can be reached with the following resource deployment:

{| class="wikitable"
|-
! Resource Type
! Number of Resources
|-
| Junior Developer
| 1
|-
| Senior Developer
| 2
|-
| Standard Developer
| 4
|-
| Standard Developer - Overtime
| 2
|}

The rest of this chapter will aim at providing supporting evidence for this conclusion. I will refer to the above configuration as 1-2-4-2 configuration

=== Utilization and Depreciating Returns on Additional Resources ===
The utilization of the above configuration is as follows:

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 49.93
|-
| Senior Developer
| 65.35
|-
| Standard Developer
| 79.1
|-
| Standard Developer - Overtime
| 83.09
|}

Granted, the utilization above might seem low. Consider the case when we remove one Senior Developer from the team. Than the utilization will be as follows (1-1-4-2):

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 87.77
|-
| Senior Developer
| 94.92
|-
| Standard Developer
| 95.7
|-
| Standard Developer - Overtime
| 96.45
|}

This looks much better. It is however important to realize, that while near 100% utilization is good for product development teams, for support teams the situation looks different. There, utilization near 100% means very little headroom for situations where more than expected incident occur. To illustrate this, let’s compare average incident resolution times between 1-2-4-2 and 1-1-4-2

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 13.76
| 36.01
|-
| Severe
| 36.23
| 94
|-
| Standard
| 63.72
| 159
|}

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 11.11
| 21.36
|-
| Severe
| 28.51
| 81
|-
| Standard
| 36.64
| 122
|}

As we can see, the difference in resolution times is stark, especially when considering the average resolution time of standard-severity incident, which almost doubled. As we can see, utilization nearing 100% percent can actually considered bad, as it lowers the ability of support teams to appropriately absorb additional incidents.

From the other side, when we add additional resources to the 1-2-4-2 scenario, we see only small decreases in resolution times. Therefore, the 1-2-4-2 seems to be a good compromise from the utilization/resolution time standpoint.

=== Minimizing Resolution & Hotfix Delivery Time Spikes ===
An important characteristic that deserves extra attention are individual resolution and hotfix times. So far, we have been mostly concerned with averages, but when running an SLA-bound support team, it is important to consider the fix times for individual incident, with utmost focus on minimizing the number of “spikes” in critical incidents, as those have severe impact on customers.

In the following histograms, we see the individual hotfix and resolution times (in hours) categorized by incident severity for the 1-2-4-2 configuration.

[[File:HotfixHistogram.png]]

[[File:ResolutionHistogram.png]]

As we can see, the results are encouraging. The times for critical incidents are very consistent with no spikes at all. While we can see occasional spikes for lower-priority incidents, eliminating those would require deploying multiple additional resources which does not seem to be worth the cost.

There is however one thing that we need to address at this point. While a reasonable amount of incidents that exceeds the SLA terms is standard, the hotfix times for critical incidents are consistently higher than in the bank-proposed SLA terms. This is not caused by “waiting for resources”, but by structural inability to deliver such fix times by the current process. This can be seen from that the fact, that while the average resolution of a critical incident is 11.11 hours, this figure composes of 7.98 hours of processing and only 3.13 hours of waiting. This facts need to be communicated to the bank and an attempt to raise the fix time of critical incidents to a more acceptable level (e.g. 6 hours) needs to be made.

=== Preventing Incident Accumulation ===
The last important metric we will consider is the chronological development of average hotfix and resolution times. While these times do not need to be absolutely stable over time (with the exception of critical incidents, where there is very little room for error), there should not be a tendency of higher values in time, as that would indicate that the system is getting backed up and might collapse at some point in the future. Let’s see the results for the 1-2-4-2 configuration.

[[File:HotfixTrace.png]]

[[File:ResolutionTrace.png]]

While one cannot call the results stable, the spikes always seem to return to an acceptable value making the system stable over longer periods of time.

== SLA Contract Pricing ==
The total cost of upholding the SLA contract, excluding SLA violation-related penalties is 78432 EUR per month. The cost breaks down as follows:

[[File:ResourceCosts.png]]

On top of that, we must calculate a risk margin to cover the SLA violation penalties.

As part of the simulation, it became clear that the SLA hotfix and response times and penalties need to be recalibrated in several ways
* Some of the times are simply unrealistic due to the current support process
* The bank provided the hours in the 8x5 mode (“business hours”), while the developer operates exclusively in the 24x7 mode
* To prevent double penalty billing for incident, when the hotfix time exceeds the allowed resolution time, only the resolution time penalty will be billed from now on
* The resolution time penalties will be dropped by ¾ and differentiated from hotfix time penalties

The updated proposed SLA times are:
{| class="wikitable"
|-
! Incident Type
! Hotfix time (hours)
! Resolution time (hours)
! Hotfix penalty (per hour)
! Resolution penalty (per hour)
|-
| Critical
| 8
| 24
| 1000 EUR
| 250 EUR
|-
| Severe
| 24
| 72
| 400 EUR
| 100 EUR
|-
| Standard
| -
| 168
| 100 EUR
| 100 EUR
|}

For these times, '''the estimated monthly penalty is 62750 EUR. Source data can be found here - [[File:Appreciation.xlsx]] With a 20% risk margin, that makes the absolute risk margin 75300 EUR'''.

That brings the '''total contract price to 153 732 EUR per month'''.

== Source Code ==
The source code can be found here - [[File:SoftwareSupportLifecycleModel.zip]]

File:SoftwareSupportLifecycleModel.zip

2015-01-24T14:14:21Z

Xkraj119:

File:Appreciation.xlsx

2015-01-24T14:11:12Z

Xkraj119: uploaded a new version of "File:Appreciation.xlsx"

Software Support Lifecycle

2015-01-24T14:10:38Z

Xkraj119: /* SLA Contract Pricing */

== Problem Recap ==
A software firm was contracted to develop a new customer-facing solution for a major banking institution. As part of the negotiation process, an SLA needs to be reached. The banking institution provided required issue resolution times and asked the software firm to appropriately price the contract while provide reasoning for the contract pricing.

The software firm decided to create a simulation of a typical month of the support cycle as a basis for approximate the resources needed to provide the support.

== Approach ==
The model consists of various severity incidents, represented as entities, and various development resources, represented as resources in SIMPROCESS. The model aims to represent a reasonably simplified version of the real development process.

The model needs to represent developer shifts, “emergency holding” (where developer does not work, but is available to start solving incidents in a reasonable amount of time) and overtime billing.

== Model Structure ==
=== Entities ===
==== Incidents ====
There are several severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
The SLA terms of different incidents can be found [http://www.simulace.info/index.php/Xkraj119 here].
{| class="wikitable"
|-
! Incident Type
! Severity (lower is less severe)
! Probability of Occurrence (per hour)
|-
| Standard
| 1
| Nor(0.4, 0.25, 1)
|-
| Severe
| 2
| Nor(0.2, 0.25, 1)
|-
| Critical
| 3
| Nor(0.075, 0.25, 1)
|}

It is important to note, that higher severity incidents can preempt lower severity incidents, which is desirable as higher severity incidents have more strict SLA terms.

While the normal distribution is sometimes considered problematic when using it to generate entities, due to the fact that a lot of real distributions are not symmetrical and instead are “right-leaning”, I believe that the normal distribution is sufficient for this scenario. An alternative shape that seem to be a bit more realistic was a beta distribution, but seeing the relatively small impact on the results, I chose a normal distribution, since it is far more accessible and requires less expertise to understand.

==== Technical Entities ====
Another type of entity in the system is a Release Trigger. The Release Trigger is responsible for triggering an automated software build every 24 hours.

=== Resources (Developers) ===
Developers are grouped into three tiers – standard, junior and senior. Each developer tier has different pricing (here) and might not be able to participate in all parts of the process. The developers get paid a fixed wage, regardless of their utilization. The developers work in the 8x5 mode. This is however problematic when dealing with high-severity incidents, which have strict SLA terms.

Therefore, a new tier has been added – “Developer – Standard – Overtime”. The role of this tier is to hold “emergency” in non-working hours of the day (17:00 – 9:00 on work days + whole weekends). Holding emergency means, that the developer is ready to immediately start resolving critical bugs from his home office. For this, the developer is compensated in the following way: The developer gets paid 10% of his standard hourly wage for every hour he holds emergency, regardless of the number of incidents (fixed cost). Apart from that, the developer gets paid for every hour he spends resolving incidents in the emergency hours (variable cost).

=== Support Process ===
The incident resolution process is as follows:

[[File:SoftwareSupport-Process.jpg]]

Things to note about the process:
* Standard severity incidents are not eligible for hotfixing
* Since junior developers do not have full knowledge of the system, they are excluded from the hotfix development and incident resolution activities
* Hotfix development is a high-risk activity (deployed directly to production without proper testing), standard developers need to pair up when developing the hotfix
* Critical incidents are released “out-of-band”, meaning they do not wait for the next release and are released individually

== Result ==
The conflicting goals of the task are obvious. On the one side, we wish to minimize the time of incident resolution. Unless we consider rearchitecting the support process, this is done mainly by deploying additional resources. On the other side, we wish to minimize the amount of deployed resources to optimize support costs and create room for margin generation.

The model shows, that a good compromise between these two goals can be reached with the following resource deployment:

{| class="wikitable"
|-
! Resource Type
! Number of Resources
|-
| Junior Developer
| 1
|-
| Senior Developer
| 2
|-
| Standard Developer
| 4
|-
| Standard Developer - Overtime
| 2
|}

The rest of this chapter will aim at providing supporting evidence for this conclusion. I will refer to the above configuration as 1-2-4-2 configuration

=== Utilization and Depreciating Returns on Additional Resources ===
The utilization of the above configuration is as follows:

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 49.93
|-
| Senior Developer
| 65.35
|-
| Standard Developer
| 79.1
|-
| Standard Developer - Overtime
| 83.09
|}

Granted, the utilization above might seem low. Consider the case when we remove one Senior Developer from the team. Than the utilization will be as follows (1-1-4-2):

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 87.77
|-
| Senior Developer
| 94.92
|-
| Standard Developer
| 95.7
|-
| Standard Developer - Overtime
| 96.45
|}

This looks much better. It is however important to realize, that while near 100% utilization is good for product development teams, for support teams the situation looks different. There, utilization near 100% means very little headroom for situations where more than expected incident occur. To illustrate this, let’s compare average incident resolution times between 1-2-4-2 and 1-1-4-2

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 13.76
| 36.01
|-
| Severe
| 36.23
| 94
|-
| Standard
| 63.72
| 159
|}

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 11.11
| 21.36
|-
| Severe
| 28.51
| 81
|-
| Standard
| 36.64
| 122
|}

As we can see, the difference in resolution times is stark, especially when considering the average resolution time of standard-severity incident, which almost doubled. As we can see, utilization nearing 100% percent can actually considered bad, as it lowers the ability of support teams to appropriately absorb additional incidents.

From the other side, when we add additional resources to the 1-2-4-2 scenario, we see only small decreases in resolution times. Therefore, the 1-2-4-2 seems to be a good compromise from the utilization/resolution time standpoint.

=== Minimizing Resolution & Hotfix Delivery Time Spikes ===
An important characteristic that deserves extra attention are individual resolution and hotfix times. So far, we have been mostly concerned with averages, but when running an SLA-bound support team, it is important to consider the fix times for individual incident, with utmost focus on minimizing the number of “spikes” in critical incidents, as those have severe impact on customers.

In the following histograms, we see the individual hotfix and resolution times (in hours) categorized by incident severity for the 1-2-4-2 configuration.

[[File:HotfixHistogram.png]]

[[File:ResolutionHistogram.png]]

As we can see, the results are encouraging. The times for critical incidents are very consistent with no spikes at all. While we can see occasional spikes for lower-priority incidents, eliminating those would require deploying multiple additional resources which does not seem to be worth the cost.

There is however one thing that we need to address at this point. While a reasonable amount of incidents that exceeds the SLA terms is standard, the hotfix times for critical incidents are consistently higher than in the bank-proposed SLA terms. This is not caused by “waiting for resources”, but by structural inability to deliver such fix times by the current process. This can be seen from that the fact, that while the average resolution of a critical incident is 11.11 hours, this figure composes of 7.98 hours of processing and only 3.13 hours of waiting. This facts need to be communicated to the bank and an attempt to raise the fix time of critical incidents to a more acceptable level (e.g. 6 hours) needs to be made.

=== Preventing Incident Accumulation ===
The last important metric we will consider is the chronological development of average hotfix and resolution times. While these times do not need to be absolutely stable over time (with the exception of critical incidents, where there is very little room for error), there should not be a tendency of higher values in time, as that would indicate that the system is getting backed up and might collapse at some point in the future. Let’s see the results for the 1-2-4-2 configuration.

[[File:HotfixTrace.png]]

[[File:ResolutionTrace.png]]

While one cannot call the results stable, the spikes always seem to return to an acceptable value making the system stable over longer periods of time.

== SLA Contract Pricing ==
The total cost of upholding the SLA contract, excluding SLA violation-related penalties is 78432 EUR per month. The cost breaks down as follows:

[[File:ResourceCosts.png]]

On top of that, we must calculate a risk margin to cover the SLA violation penalties.

As part of the simulation, it became clear that the SLA hotfix and response times and penalties need to be recalibrated in several ways
* Some of the times are simply unrealistic due to the current support process
* The bank provided the hours in the 8x5 mode (“business hours”), while the developer operates exclusively in the 24x7 mode
* To prevent double penalty billing for incident, when the hotfix time exceeds the allowed resolution time, only the resolution time penalty will be billed from now on
* The resolution time penalties will be dropped by ¾ and differentiated from hotfix time penalties

The updated proposed SLA times are:
{| class="wikitable"
|-
! Incident Type
! Hotfix time (hours)
! Resolution time (hours)
! Hotfix penalty (per hour)
! Resolution penalty (per hour)
|-
| Critical
| 8
| 24
| 1000 EUR
| 250 EUR
|-
| Severe
| 24
| 72
| 400 EUR
| 100 EUR
|-
| Standard
| -
| 168
| 100 EUR
| 100 EUR
|}

For these times, '''the estimated monthly penalty is 62750 EUR. Source data can be found here - [[File:Appreciation.xlsx]] With a 20% risk margin, that makes the absolute risk margin 75300 EUR'''.

That brings the '''total contract price to 153 732 EUR per month'''.

File:Appreciation.xlsx

2015-01-24T14:08:52Z

Xkraj119:

Software Support Lifecycle

2015-01-24T14:08:04Z

Xkraj119:

== Problem Recap ==
A software firm was contracted to develop a new customer-facing solution for a major banking institution. As part of the negotiation process, an SLA needs to be reached. The banking institution provided required issue resolution times and asked the software firm to appropriately price the contract while provide reasoning for the contract pricing.

The software firm decided to create a simulation of a typical month of the support cycle as a basis for approximate the resources needed to provide the support.

== Approach ==
The model consists of various severity incidents, represented as entities, and various development resources, represented as resources in SIMPROCESS. The model aims to represent a reasonably simplified version of the real development process.

The model needs to represent developer shifts, “emergency holding” (where developer does not work, but is available to start solving incidents in a reasonable amount of time) and overtime billing.

== Model Structure ==
=== Entities ===
==== Incidents ====
There are several severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
The SLA terms of different incidents can be found [http://www.simulace.info/index.php/Xkraj119 here].
{| class="wikitable"
|-
! Incident Type
! Severity (lower is less severe)
! Probability of Occurrence (per hour)
|-
| Standard
| 1
| Nor(0.4, 0.25, 1)
|-
| Severe
| 2
| Nor(0.2, 0.25, 1)
|-
| Critical
| 3
| Nor(0.075, 0.25, 1)
|}

It is important to note, that higher severity incidents can preempt lower severity incidents, which is desirable as higher severity incidents have more strict SLA terms.

While the normal distribution is sometimes considered problematic when using it to generate entities, due to the fact that a lot of real distributions are not symmetrical and instead are “right-leaning”, I believe that the normal distribution is sufficient for this scenario. An alternative shape that seem to be a bit more realistic was a beta distribution, but seeing the relatively small impact on the results, I chose a normal distribution, since it is far more accessible and requires less expertise to understand.

==== Technical Entities ====
Another type of entity in the system is a Release Trigger. The Release Trigger is responsible for triggering an automated software build every 24 hours.

=== Resources (Developers) ===
Developers are grouped into three tiers – standard, junior and senior. Each developer tier has different pricing (here) and might not be able to participate in all parts of the process. The developers get paid a fixed wage, regardless of their utilization. The developers work in the 8x5 mode. This is however problematic when dealing with high-severity incidents, which have strict SLA terms.

Therefore, a new tier has been added – “Developer – Standard – Overtime”. The role of this tier is to hold “emergency” in non-working hours of the day (17:00 – 9:00 on work days + whole weekends). Holding emergency means, that the developer is ready to immediately start resolving critical bugs from his home office. For this, the developer is compensated in the following way: The developer gets paid 10% of his standard hourly wage for every hour he holds emergency, regardless of the number of incidents (fixed cost). Apart from that, the developer gets paid for every hour he spends resolving incidents in the emergency hours (variable cost).

=== Support Process ===
The incident resolution process is as follows:

[[File:SoftwareSupport-Process.jpg]]

Things to note about the process:
* Standard severity incidents are not eligible for hotfixing
* Since junior developers do not have full knowledge of the system, they are excluded from the hotfix development and incident resolution activities
* Hotfix development is a high-risk activity (deployed directly to production without proper testing), standard developers need to pair up when developing the hotfix
* Critical incidents are released “out-of-band”, meaning they do not wait for the next release and are released individually

== Result ==
The conflicting goals of the task are obvious. On the one side, we wish to minimize the time of incident resolution. Unless we consider rearchitecting the support process, this is done mainly by deploying additional resources. On the other side, we wish to minimize the amount of deployed resources to optimize support costs and create room for margin generation.

The model shows, that a good compromise between these two goals can be reached with the following resource deployment:

{| class="wikitable"
|-
! Resource Type
! Number of Resources
|-
| Junior Developer
| 1
|-
| Senior Developer
| 2
|-
| Standard Developer
| 4
|-
| Standard Developer - Overtime
| 2
|}

The rest of this chapter will aim at providing supporting evidence for this conclusion. I will refer to the above configuration as 1-2-4-2 configuration

=== Utilization and Depreciating Returns on Additional Resources ===
The utilization of the above configuration is as follows:

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 49.93
|-
| Senior Developer
| 65.35
|-
| Standard Developer
| 79.1
|-
| Standard Developer - Overtime
| 83.09
|}

Granted, the utilization above might seem low. Consider the case when we remove one Senior Developer from the team. Than the utilization will be as follows (1-1-4-2):

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 87.77
|-
| Senior Developer
| 94.92
|-
| Standard Developer
| 95.7
|-
| Standard Developer - Overtime
| 96.45
|}

This looks much better. It is however important to realize, that while near 100% utilization is good for product development teams, for support teams the situation looks different. There, utilization near 100% means very little headroom for situations where more than expected incident occur. To illustrate this, let’s compare average incident resolution times between 1-2-4-2 and 1-1-4-2

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 13.76
| 36.01
|-
| Severe
| 36.23
| 94
|-
| Standard
| 63.72
| 159
|}

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 11.11
| 21.36
|-
| Severe
| 28.51
| 81
|-
| Standard
| 36.64
| 122
|}

As we can see, the difference in resolution times is stark, especially when considering the average resolution time of standard-severity incident, which almost doubled. As we can see, utilization nearing 100% percent can actually considered bad, as it lowers the ability of support teams to appropriately absorb additional incidents.

From the other side, when we add additional resources to the 1-2-4-2 scenario, we see only small decreases in resolution times. Therefore, the 1-2-4-2 seems to be a good compromise from the utilization/resolution time standpoint.

=== Minimizing Resolution & Hotfix Delivery Time Spikes ===
An important characteristic that deserves extra attention are individual resolution and hotfix times. So far, we have been mostly concerned with averages, but when running an SLA-bound support team, it is important to consider the fix times for individual incident, with utmost focus on minimizing the number of “spikes” in critical incidents, as those have severe impact on customers.

In the following histograms, we see the individual hotfix and resolution times (in hours) categorized by incident severity for the 1-2-4-2 configuration.

[[File:HotfixHistogram.png]]

[[File:ResolutionHistogram.png]]

As we can see, the results are encouraging. The times for critical incidents are very consistent with no spikes at all. While we can see occasional spikes for lower-priority incidents, eliminating those would require deploying multiple additional resources which does not seem to be worth the cost.

There is however one thing that we need to address at this point. While a reasonable amount of incidents that exceeds the SLA terms is standard, the hotfix times for critical incidents are consistently higher than in the bank-proposed SLA terms. This is not caused by “waiting for resources”, but by structural inability to deliver such fix times by the current process. This can be seen from that the fact, that while the average resolution of a critical incident is 11.11 hours, this figure composes of 7.98 hours of processing and only 3.13 hours of waiting. This facts need to be communicated to the bank and an attempt to raise the fix time of critical incidents to a more acceptable level (e.g. 6 hours) needs to be made.

=== Preventing Incident Accumulation ===
The last important metric we will consider is the chronological development of average hotfix and resolution times. While these times do not need to be absolutely stable over time (with the exception of critical incidents, where there is very little room for error), there should not be a tendency of higher values in time, as that would indicate that the system is getting backed up and might collapse at some point in the future. Let’s see the results for the 1-2-4-2 configuration.

[[File:HotfixTrace.png]]

[[File:ResolutionTrace.png]]

While one cannot call the results stable, the spikes always seem to return to an acceptable value making the system stable over longer periods of time.

== SLA Contract Pricing ==
The total cost of upholding the SLA contract, excluding SLA violation-related penalties is 78432 EUR per month. The cost breaks down as follows:

[[File:ResourceCosts.png]]

On top of that, we must calculate a risk margin to cover the SLA violation penalties.

As part of the simulation, it became clear that the SLA hotfix and response times and penalties need to be recalibrated in several ways
* Some of the times are simply unrealistic due to the current support process
* The bank provided the hours in the 8x5 mode (“business hours”), while the developer operates exclusively in the 24x7 mode
* To prevent double penalty billing for incident, when the hotfix time exceeds the allowed resolution time, only the resolution time penalty will be billed from now on
* The resolution time penalties will be dropped by ¾ and differentiated from hotfix time penalties

The updated proposed SLA times are:
{| class="wikitable"
|-
! Incident Type
! Hotfix time (hours)
! Resolution time (hours)
! Hotfix penalty (per hour)
! Resolution penalty (per hour)
|-
| Critical
| 8
| 24
| 1000 EUR
| 250 EUR
|-
| Severe
| 24
| 72
| 400 EUR
| 100 EUR
|-
| Standard
| -
| 168
| 100 EUR
| 100 EUR
|}

For these times, '''the estimated monthly penalty is 62750 EUR. With a 20% risk margin, that makes the absolute risk margin 75300 EUR'''.

That brings the '''total contract price to 153 732 EUR per month'''.

File:ResourceCosts.png

2015-01-24T14:05:01Z

Xkraj119:

Software Support Lifecycle

2015-01-24T14:04:05Z

Xkraj119: /* Result */

== Problem Recap ==
A software firm was contracted to develop a new customer-facing solution for a major banking institution. As part of the negotiation process, an SLA needs to be reached. The banking institution provided required issue resolution times and asked the software firm to appropriately price the contract while provide reasoning for the contract pricing.

The software firm decided to create a simulation of a typical month of the support cycle as a basis for approximate the resources needed to provide the support.

== Approach ==
The model consists of various severity incidents, represented as entities, and various development resources, represented as resources in SIMPROCESS. The model aims to represent a reasonably simplified version of the real development process.

The model needs to represent developer shifts, “emergency holding” (where developer does not work, but is available to start solving incidents in a reasonable amount of time) and overtime billing.

== Model Structure ==
=== Entities ===
==== Incidents ====
There are several severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
The SLA terms of different incidents can be found [http://www.simulace.info/index.php/Xkraj119 here].
{| class="wikitable"
|-
! Incident Type
! Severity (lower is less severe)
! Probability of Occurrence (per hour)
|-
| Standard
| 1
| Nor(0.4, 0.25, 1)
|-
| Severe
| 2
| Nor(0.2, 0.25, 1)
|-
| Critical
| 3
| Nor(0.075, 0.25, 1)
|}

It is important to note, that higher severity incidents can preempt lower severity incidents, which is desirable as higher severity incidents have more strict SLA terms.

While the normal distribution is sometimes considered problematic when using it to generate entities, due to the fact that a lot of real distributions are not symmetrical and instead are “right-leaning”, I believe that the normal distribution is sufficient for this scenario. An alternative shape that seem to be a bit more realistic was a beta distribution, but seeing the relatively small impact on the results, I chose a normal distribution, since it is far more accessible and requires less expertise to understand.

==== Technical Entities ====
Another type of entity in the system is a Release Trigger. The Release Trigger is responsible for triggering an automated software build every 24 hours.

=== Resources (Developers) ===
Developers are grouped into three tiers – standard, junior and senior. Each developer tier has different pricing (here) and might not be able to participate in all parts of the process. The developers get paid a fixed wage, regardless of their utilization. The developers work in the 8x5 mode. This is however problematic when dealing with high-severity incidents, which have strict SLA terms.

Therefore, a new tier has been added – “Developer – Standard – Overtime”. The role of this tier is to hold “emergency” in non-working hours of the day (17:00 – 9:00 on work days + whole weekends). Holding emergency means, that the developer is ready to immediately start resolving critical bugs from his home office. For this, the developer is compensated in the following way: The developer gets paid 10% of his standard hourly wage for every hour he holds emergency, regardless of the number of incidents (fixed cost). Apart from that, the developer gets paid for every hour he spends resolving incidents in the emergency hours (variable cost).

=== Support Process ===
The incident resolution process is as follows:

[[File:SoftwareSupport-Process.jpg]]

Things to note about the process:
* Standard severity incidents are not eligible for hotfixing
* Since junior developers do not have full knowledge of the system, they are excluded from the hotfix development and incident resolution activities
* Hotfix development is a high-risk activity (deployed directly to production without proper testing), standard developers need to pair up when developing the hotfix
* Critical incidents are released “out-of-band”, meaning they do not wait for the next release and are released individually

== Result ==
The conflicting goals of the task are obvious. On the one side, we wish to minimize the time of incident resolution. Unless we consider rearchitecting the support process, this is done mainly by deploying additional resources. On the other side, we wish to minimize the amount of deployed resources to optimize support costs and create room for margin generation.

The model shows, that a good compromise between these two goals can be reached with the following resource deployment:

{| class="wikitable"
|-
! Resource Type
! Number of Resources
|-
| Junior Developer
| 1
|-
| Senior Developer
| 2
|-
| Standard Developer
| 4
|-
| Standard Developer - Overtime
| 2
|}

The rest of this chapter will aim at providing supporting evidence for this conclusion. I will refer to the above configuration as 1-2-4-2 configuration

=== Utilization and Depreciating Returns on Additional Resources ===
The utilization of the above configuration is as follows:

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 49.93
|-
| Senior Developer
| 65.35
|-
| Standard Developer
| 79.1
|-
| Standard Developer - Overtime
| 83.09
|}

Granted, the utilization above might seem low. Consider the case when we remove one Senior Developer from the team. Than the utilization will be as follows (1-1-4-2):

{| class="wikitable"
|-
! Resource Type
! Utilization (%)
|-
| Junior Developer
| 87.77
|-
| Senior Developer
| 94.92
|-
| Standard Developer
| 95.7
|-
| Standard Developer - Overtime
| 96.45
|}

This looks much better. It is however important to realize, that while near 100% utilization is good for product development teams, for support teams the situation looks different. There, utilization near 100% means very little headroom for situations where more than expected incident occur. To illustrate this, let’s compare average incident resolution times between 1-2-4-2 and 1-1-4-2

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 13.76
| 36.01
|-
| Severe
| 36.23
| 94
|-
| Standard
| 63.72
| 159
|}

{| class="wikitable"
|-
! Incident Type
! Average Resolution Time (hours)
! Maximum Resolution Time (hours)
|-
| Critical
| 11.11
| 21.36
|-
| Severe
| 28.51
| 81
|-
| Standard
| 36.64
| 122
|}

As we can see, the difference in resolution times is stark, especially when considering the average resolution time of standard-severity incident, which almost doubled. As we can see, utilization nearing 100% percent can actually considered bad, as it lowers the ability of support teams to appropriately absorb additional incidents.

From the other side, when we add additional resources to the 1-2-4-2 scenario, we see only small decreases in resolution times. Therefore, the 1-2-4-2 seems to be a good compromise from the utilization/resolution time standpoint.

=== Minimizing Resolution & Hotfix Delivery Time Spikes ===
An important characteristic that deserves extra attention are individual resolution and hotfix times. So far, we have been mostly concerned with averages, but when running an SLA-bound support team, it is important to consider the fix times for individual incident, with utmost focus on minimizing the number of “spikes” in critical incidents, as those have severe impact on customers.

In the following histograms, we see the individual hotfix and resolution times (in hours) categorized by incident severity for the 1-2-4-2 configuration.

[[File:HotfixHistogram.png]]

[[File:ResolutionHistogram.png]]

As we can see, the results are encouraging. The times for critical incidents are very consistent with no spikes at all. While we can see occasional spikes for lower-priority incidents, eliminating those would require deploying multiple additional resources which does not seem to be worth the cost.

There is however one thing that we need to address at this point. While a reasonable amount of incidents that exceeds the SLA terms is standard, the hotfix times for critical incidents are consistently higher than in the bank-proposed SLA terms. This is not caused by “waiting for resources”, but by structural inability to deliver such fix times by the current process. This can be seen from that the fact, that while the average resolution of a critical incident is 11.11 hours, this figure composes of 7.98 hours of processing and only 3.13 hours of waiting. This facts need to be communicated to the bank and an attempt to raise the fix time of critical incidents to a more acceptable level (e.g. 6 hours) needs to be made.

=== Preventing Incident Accumulation ===
The last important metric we will consider is the chronological development of average hotfix and resolution times. While these times do not need to be absolutely stable over time (with the exception of critical incidents, where there is very little room for error), there should not be a tendency of higher values in time, as that would indicate that the system is getting backed up and might collapse at some point in the future. Let’s see the results for the 1-2-4-2 configuration.

[[File:HotfixTrace.png]]

[[File:ResolutionTrace.png]]

While one cannot call the results stable, the spikes always seem to return to an acceptable value making the system stable over longer periods of time.

File:ResolutionTrace.png

2015-01-24T14:03:53Z

Xkraj119:

File:HotfixTrace.png

2015-01-24T14:03:29Z

Xkraj119:

File:ResolutionHistogram.png

2015-01-24T14:02:24Z

Xkraj119:

File:HotfixHistogram.png

2015-01-24T14:01:46Z

Xkraj119:

Software Support Lifecycle

2015-01-24T14:00:11Z

Xkraj119: /* Utilization and Depreciating Returns on Additional Resources */

Software Support Lifecycle

2015-01-24T13:57:17Z

Xkraj119: /* Result */

Software Support Lifecycle

2015-01-24T13:51:11Z

Xkraj119:

File:SoftwareSupport-Process.jpg

2015-01-24T13:49:15Z

Xkraj119:

Software Support Lifecycle

2015-01-24T13:48:20Z

Xkraj119: V1

WS 2014/2015

2015-01-24T13:42:29Z

Xkraj119:

Semestral papers from winter term 2014/2015. Please, put here links to the pages with your paper. First you need to have your [[Assignments WS 2014/2015|assignment approved]].

==Simulations==

--[[User:Zhua00|Andriy Zhubryd]] 14:24, 15 January 2015 (CET) [[E-Sim Optimal Equipment Selection]]

--[[User:Xgubk00|Xgubk00]] 12:24, 17 January 2015 (CET) [[Flood evacuation]]

-- [[User:Xzasj00|Xzasj00]] 00:07, 18 January 2015 (CET) [[Formula 1 teams economic situation]]

-- [[User:Qnovm21|Qnovm21]] 10:33, 18 January 2015 (CET) [[Simulation of the surgery staff in a hospital]]

-- [[User:Xzigm03|Xzigm03]] 23:40, 18 January 2015 (CET) [[Poker probabilities and variance simulation]]

-- [[User:Xkraj119|Xkraj119]] 14:41, 24 January 2015 (CET) [[Software Support Lifecycle]]

==Papers==

--[[User:Xgubk00|Xgubk00]] 12:24, 17 January 2015 (CET) [[Game theory]]

--[[User:Qnovm21|Qnovm21]] 16:40, 21 January 2015 (CET) [[Casual loop diagram]]

--[[User:Xkraj119|Xkraj119]] 10:32, 24 January 2015 (CET) [https://en.wikipedia.org/wiki/Growth_and_underinvestment Growth and Underinvestment Archetype]

WS 2014/2015

2015-01-24T09:34:22Z

Xkraj119: Adds link to my paper on Wikipedia

Semestral papers from winter term 2014/2015. Please, put here links to the pages with your paper. First you need to have your [[Assignments WS 2014/2015|assignment approved]].

==Simulations==

--[[User:Zhua00|Andriy Zhubryd]] 14:24, 15 January 2015 (CET) [[E-Sim Optimal Equipment Selection]]

--[[User:Xgubk00|Xgubk00]] 12:24, 17 January 2015 (CET) [[Flood evacuation]]

-- [[User:Xzasj00|Xzasj00]] 00:07, 18 January 2015 (CET) [[Formula 1 teams economic situation]]

-- [[User:Qnovm21|Qnovm21]] 10:33, 18 January 2015 (CET) [[Simulation of the surgery staff in a hospital]]

-- [[User:Xzigm03|Xzigm03]] 23:40, 18 January 2015 (CET) [[Poker probabilities and variance simulation]]

==Papers==

--[[User:Xgubk00|Xgubk00]] 12:24, 17 January 2015 (CET) [[Game theory]]

--[[User:Qnovm21|Qnovm21]] 16:40, 21 January 2015 (CET) [[Casual loop diagram]]

--[[User:Xkraj119|Xkraj119]] 10:32, 24 January 2015 (CET) [https://en.wikipedia.org/wiki/Growth_and_underinvestment Growth and Underinvestment Archetype]

Xkraj119

2014-12-22T09:35:24Z

Xkraj119:

==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:

{| class="wikitable"
|-
! 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:
{| 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)~

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)~

Xkraj119

2014-12-19T17:17:26Z

Xkraj119:

==Assignment==
* Project name – Event Match-up Dynamics
* Author – Jan Kratochvíl
* Software used – NetLogo 5
* Simulation type – Multi-agent model
== About the model ==
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.
=== The basic characteristics of the model are: ===
* Every population member has two basic preference types – physical attraction and mental compatibility
* 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.
* The length of interaction between population members (can be zero) is based on their mutual physical attraction
* 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
* The resulting score is a basis for decision about mating. Some members have no intention of mating, yet take part in interactions
* The later it is in the game, the lower the score must be in order to be sufficient for mating
=== Model configurability ===
* Minimum score to match-up
* The pace with which does one’s standard lowers as the game reaches later stages
* Weight of physical attraction/mental compatibility in scoring model
* The initial spatial distribution of actors
== Goal variables ==
* Median compatibility score of matched-up actors
* Median number of turns for a match-up to happen
* Median number of interaction it takes to reach a match-up
* Percentage of actors able to find a match-up
== Goals of the simulations are: ==
* Does the initial spatial distribution of actors significantly alter the median compatibility score of matched-up actors
* What is the average of interactions needed to reach a match-up?
* Does altering the number of actors with no mating intention increase the percentage of actors able to find a match-up?
* How aggressively do need the actors’ standards need to lower in order for vast majority of actors to find a match-up?

[[User:Xkraj119|Jan Kratochvíl]] 18:17, 19 December 2014 (CET)

Xkraj119

2014-12-19T17:16:27Z

Xkraj119:

Xkraj119

2014-12-19T16:23:38Z

Xkraj119: Created page with "TBD"

TBD

Assignments WS 2014/2015

2014-12-19T16:23:24Z

Xkraj119:

{{DISPLAYTITLE:Assignments WS 2014/2015}}

{{Ambox
| text = <div>
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.
</div>
}}

{{Ambox
| text = <div>
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment/en|How to deal with the simulation assignment]].
</div>
}}

{{Ambox
| type = content
| text = <div>
In order to avoid possible confusion, please, check if you have added '''approved''' in bold somewhere in our comment under your submission. If there is no '''approved''', it means the assignment was not approved yet.
</div>
}}

== Assignments ==
[[xcesj04 ]]
<div>[[qnovm21 ]]</div>
[[xpalj24]]

[[xzasj00]]

[[zhua00]]

[[rock00]]

[[kado00]]

[[xgubk00]]

[[xkraj119]]

Assignments WS 2014/2015

2014-12-19T16:23:11Z

Xkraj119: