Ticket Solving Process at a Small IT dev Company

From Simulace.info
Revision as of 15:44, 19 January 2019 by Manj01 (talk | contribs) (A)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Information

• Project name: Ticket Solving Process at a Small IT dev Company

• Class: 4IT496 (WS 2018/2019)

• Author: Bc. Jan Mandík

• Model type: Discrete-event simulation

• Software used: SimProcess, trial version


Problem definition

There is a small IT company, which developed an IT Product (an email client) a long time ago. Today, customers or QA personnel report bugs, which are then analyzed by testers and given to developers to fix. After fixing the issue, the ticket is given back to testers to test the solution. The time required to fix the bug is extremely long, as there are not so many developers and the bugs are often difficult to fix. A single developer spend only three hours per day fixing the issues, as he spends most of the time developing new features of the program. The company management wonders how many full time ticket-solving only developers would be needed to fix the issues at the same pace as the issues are being created. As to the other parts of the ticket life cycle - testing and retesting takes neglible amount of time compared to the development time, it is however an essential part of the process.

Aggregated real data

The company uses a very simple setting of Jira ticketing software. It is possible to export data to CSV from Jira. In this export, there is a number of columns, most of which is useless. The columns I used are Created Date, Updated Date and Status. Status Column can have values ToDo, In Review, Done, In Progress. Out of these, only items with Done status were used, as only these have usable Updated Date. Updated Date present time at which a tester marked this issue as done. Created Date present a point in time in which the issue was created (after its analysis). Out of these points in time, it is possible to get numbers of created issues per day and difference between time it was created and the time it was marked as Done (in hours). The distribution of these values seems to be random, but I have Simprocess in-build ModelFit function to describe these distributions mathematically. The distribution of created issues per day seems to be Hyper Exponential Distribution and the distribution of hours in repair is Gamma Distribution. These are the expected distributions for this type of input, and simprocess ModelFit function was able to provide the best possible parametrs. The CSV file with has 345 usable lines. Thise are all the ticket that have been marked as solved in the company's Jira since the Jira system launch. These 345 are enough to provide a distribution that allows the model to resemble real life workflow. As to the analysis and retesting, these are not visible in the Jira. As I was the only employee responsible for these process, I have a good overview of how long it takes. Given the fact these are truly negligible, I have set the analysis to take one hour and and the retest to take half one hour.


Model

The model is very simple given the company small size and the low level of Jira implementation. The model consist of one Generate Stage, three wait stages, and one Dispose Stage. The stages are described below: Generate: Simulates the real life inflow of new tickets from customers. Based on 345 cases, the inflow is defined as Hex(0.203, 1.632, 0.75) issues per that, that is is 0.56 issues per day on average. Wait 1 (Analysis): Simulates the analysis need to give the ticket to developers. It is simplified to take Nor(0.7,0.2,1) hours, based on my experience in this job. One tester is needed as a resource for this stage. Wait 2 (Repair): Simulates the repair process itself, which constitutes for most of the time. It is based on the before-mentioned date from Jire and the distribution is created by Simprocess from this date. It takes Gam(1773.276, 0.597) hours - as you can see, this amount is truly neglible compared to Analysis and Retesting. Wait 3 (Retesting): Simulates the retesting necessary to marked the issue as done. It is a very quick process, it takes Nor(0.5,0.2,1) hours. Dispose: The issue is fixed and retested.


Entities

The only entity is defect, that is not prioritized.

Resources

There are two resources. Its properties are based on the real data seen in the company: Developer: Needed for Repair stage. Works only on working day from 10am do 6pm. Costs 750 CZK per hour and 25000 annually. Tester: Needed for Analysis and Retesting stages. Willing to work every day from 10am to 8pm because his utilization is low. Costs 250 CZK per hour and 25000 annually.

Processes

Optimal model

Code