Análisis del Microambiente

All designed algorithms are translated into Java-code in order to test the performance of the algorithms. Testing on customer specific data is undesired during the experimental phase as it focusses on a customer specific situation and so the output is customer specific. Therefore, randomly generated input data is used within the computational experiment. The Java-code generates a number of resources with a random location and random assigned qualifications (i.e., skills). Also the set of events is randomly generated and those are assigned a duration, a location, a timeframe (i.e., morning or afternoon), a release and due date, a number of required resources (i.e., 1 or 2) and required skills. The computational experiment gives an indication of the performance of the different algorithms. Locations are used to generate the need for preparation times, as it results in travel distances (or travel times).

In order to create valid and credible experiments Law (2006) indicate the collection of information and data, and the construction of an assumption document as important steps. In relation to the computational experiment data collection is an issue, as any collection is customer specific and therefore the results are not per definition general applicable. For that matter the experimental parameters are based on assumptions (i.e., the parameters and related probability distributions are assumed). For example, the expected duration is assumed to be between 0.5 hour and 2 hours with a normal distribution.

The assumptions made on variables and parameters are based on several data collections from different companies. The number of experiments performed in order to create credible results is set at 50. With this number of runs the influence of outliers due to randomness in the created data is levelled off. In

order to come to this number, several tests are done. Test includes a different number of randomly generated data collections and analyses of the results. A comparison of the average results of the experiment with 5 instances and the experiment with 10 instances is quite large (i.e., over 10 percent). This implies that the performance of those instances is not constant. In order to perform a credible experiment, the results must be more stable and therefore we enlarged the instance size. The difference between experiments with 20 instances and those with 50 instances is small (i.e., lower than 2.5 percent). This percentage does not change when comparing experiments with 50 and 75 instances. As the experiment with 50 instances performs stable, the experiment is performed with this number of instances. The results of the experiment provide insight in the (average) performance of the different algorithms. In order to compare the performance of these algorithm, the following measures are set:

- Total number of events placed - Time related issues:

o Percentage of time working on events

o Percentage of time preparing for events; travel times are used for expressing preparation times. An assumption is made for average speed (i.e., 47km/h). The distance in the algorithms is based on Manhattan-distances.

o Percentage of time waiting

o Percentage of time utilized (total time of working, preparing and waiting) - Sum of static priority value of placed events

- CPU time of the algorithm

The following restrictions are set on scheduling:

- The overall utilization degree is set at 75 percent. This implies that 25 percent of the total resource capacity is reserved to perform currently unknown events. As long as the overall utilization rate is below 75 percent, a new event is added to the schedule. In addition, the time required for return trips are not considered calculating the utilization rate.

- No event can (partly) be scheduled after 5 PM (i.e., overtime is not allowed). This implies that all events must be finished before 5 PM, including return trips.

In order to compare the performance of an algorithm, the results can ideally be compared to the optimal situation. Therefore, a brute force algorithm is created. The brute force algorithm checks all scheduling options given a specific instance and results in the optimal schedule. The running time of the brute force algorithm is very poor, and so it can only be used to test the performance of small instances. The running time of the brute force algorithm takes approximately 3 minutes to solve an instance containing 2 resources and 10 events. The results of the brute force algorithm are compared to the results of the other algorithms. This comparison provides insight in the performance of the designed algorithms, and it indicates the (different) decisions made a certain (critical) points.

As we are dealing with multiple factors, there is no clear definition of an optimal schedule. The optimal schedule is here defined as the schedule for which the sum of the priority values of scheduled events is

- 65 -

what event to schedule as the average added value per time unit increase the popularity of event. Events of the same type (and so the same priority value) can have a different duration. While using the brute force algorithm the short duration event is more favourable than the other as there is more time left to schedule another event. The duration of an event ideally does not influence the priority of an event, but still the goal is to schedule the events that have the highest priority. Within the priority value both the type of event and the urgency are defined. Based on those characteristics the scheduling engine is able to make decisions on what events must be in the schedule. The optimal schedule is therefore defined as the schedule for which the sum of priority value of the scheduled events is maximized.