Department of Computer Science Dissertation in

City University of Hong Kong

Department of Computer Science

Dissertation

Rostering System for aircraft service industry

Lam Chi Wo

50447402

2004-2005

Supervisor: Dr. Andy Chun

Master of Science in

Computing

Lam Chi Wo MSC 50447402

TABLE OF CONTENT

1.

INTRODUCTION............................................................................................................................... 5

1.1.

B ACKGROUND .............................................................................................................................. 5

1.1.1.

Aircraft Services industry ....................................................................................................... 5

1.1.2.

Needs for better scheduling .................................................................................................... 6

1.1.3.

Rostering in Aircraft Services Industry................................................................................... 7

2.

PROJECT AIM & OBJECTIVES .................................................................................................... 8

3.

PROBLEM DESCRIPTION.............................................................................................................. 9

3.1.1.

Problem analysis .................................................................................................................... 9

3.1.1.1.

Labour Demand.................................................................................................................... 10

3.1.1.2.

Engineer Supply.................................................................................................................... 10

3.1.1.3.

Constrains............................................................................................................................. 11

3.1.1.4.

Roster.................................................................................................................................... 12

3.1.2.

Evaluation criteria................................................................................................................ 12

4.

LITERATURE REVIEW................................................................................................................. 14

4.1.

R ESEARCH ON R OSTERING ......................................................................................................... 14

4.2.

A PPROACHES AND ALGORITHMS ................................................................................................ 16

5.

ALGORITHM DESIGN................................................................................................................... 18

5.1.

T HE PROBLEM ............................................................................................................................ 18

5.2.

A

LGORITHM OBJECTIVES

............................................................................................................ 19

5.3.

P ROBLEM SOLVING APPROACH ................................................................................................... 19

5.4.

R OW FORMING ........................................................................................................................... 20

5.4.1.

Constrains in row forming.................................................................................................... 20

5.4.2.

Preparing possible row combinations .................................................................................. 21

5.5.

R OSTER FORMING ....................................................................................................................... 25

5.5.1.

Constrains in roster forming ................................................................................................ 25

5.5.2.

Demand................................................................................................................................. 26

5.5.3.

Sampling strategy ................................................................................................................. 27

5.5.4.

Linear Forward Search ........................................................................................................ 27

5.5.4.1.

Solution naming.................................................................................................................... 28

5.5.5.

Multi-directions Search ........................................................................................................ 32

5.5.6.

Genetic Algorithm................................................................................................................. 32

5.6.

E VALUATION .............................................................................................................................. 35

5.6.1.

Shift distribution ................................................................................................................... 35

5.6.2.

The fitness function ............................................................................................................... 36

5.6.3.

Case base.............................................................................................................................. 37

5.6.4.

Problem signature ................................................................................................................ 37


5.7.

T HE OVERALL ALGORITHM ......................................................................................................... 39

6.

SYSTEM ANALYSIS ....................................................................................................................... 40

6.1.

B ASIC SYSTEM REQUIREMENT .................................................................................................... 40

6.2.

F UNCTIONAL SPECIFICATION ...................................................................................................... 40

6.3.

U SE C ASES ANALYSIS ................................................................................................................ 43

6.4.

U SE CASE SCENARIO .................................................................................................................. 45

6.5.

C ONCEPTUAL C LASS DIAGRAM .................................................................................................. 46

7.

SYSTEM DESIGN............................................................................................................................ 47

7.1.

D ESIGN C LASS D IAGRAM ........................................................................................................... 47

7.1.1.

Presentation Layer ............................................................................................................... 47

7.1.2.

Domain Layer ....................................................................................................................... 47

7.2.

S EQUENCE D IAGRAM ................................................................................................................. 48

D ATABASE D ESIGN ................................................................................................................................... 50

7.2.1.

ER diagram........................................................................................................................... 50

7.2.2.

Table listing .......................................................................................................................... 51

7.2.3.

Table Details ........................................................................................................................ 51

7.3.

I NTERFACE DESIGN ..................................................................................................................... 54

8.

SYSTEM IMPLEMENTATION ..................................................................................................... 60

8.1.

P ROGRAMMING LANGUAGE ........................................................................................................ 60

8.2.

D ATABASE S YSTEM ................................................................................................................... 62

8.2.1.

System Architecture .............................................................................................................. 63

8.3.

S YSTEM T ESTING ....................................................................................................................... 63

8.4.

S YSTEM E VALUATION ................................................................................................................ 65

8.4.1.

Performance Evaluation....................................................................................................... 65

8.4.2.

The Gene Hunter .................................................................................................................. 65

8.4.3.

Simple GA model .................................................................................................................. 65

8.4.4.

Evaluation Scenario ............................................................................................................. 67

8.4.5.

Result .................................................................................................................................... 69

8.4.5.1.

RosterBuilder Vs GeneHunter .............................................................................................. 69

8.4.5.2.

Result Analysis...................................................................................................................... 70

8.4.5.3.

Observations from the results ............................................................................................... 71

8.4.6.

Sampling Strategies in RosterBuilder................................................................................... 72

8.4.7.

Results................................................................................................................................... 72

8.4.8.

Observations from the results ............................................................................................... 73

9.

CONCLUSION ................................................................................................................................. 75

9.1.

A CHIEVEMENTS ......................................................................................................................... 75

9.2.

F URTHER DEVELOPMENT ............................................................................................................ 76


REFERENCES ........................................................................................................................................... 78

10.

APPENDIX ................................................................................................................................... 80

10.1.

P ROJECT S CHEDULE ................................................................................................................... 80

10.2.

A TTACHMENT CD CONTENT ...................................................................................................... 80

10.3.

S YSTEM REQUIREMENTS ............................................................................................................ 80

10.4.

I NSTALLATION G UIDE ................................................................................................................ 81


1. Introduction

1.1. Background

1.1.1. Aircraft Services industry

Aircraft Services, in a broader sense, is referring all services providing to the aircraft that is landed and parked in the airport. These include cabin cleaning, ground services (drainage, power supply, push back service) and maintenance service. Aircraft maintenance services include periodic inspection (the A, B, C, D checks) and lines maintenance which maintains aircrafts that are actively in service.

Since the operation mode of periodic inspection and line maintenance are totally different, in this study, we will focus on the line maintenance section of aircraft services industry. As the operation mode of cabin cleaning and ground service sections is just a simpler version of line maintenance section, we assume that the result of the study on line maintenance case can be applied to other sections without difficulties.

In Hong Kong, there are 3 government approved Aircraft

Services Companies operating in the Hong Kong Chak Lap Kok

International airport.


1.1.2. Needs for better scheduling

Unlike other ground transportation industry that having their own depot for the maintenance and servicing of their rolling stock, it is a norm for airline operator to contract out the maintenance and servicing of their aircraft to aircraft servicing company. This, of course, due to the extremely heavy cost burden of airlines to operate maintenance facilities in all airports they will reach. And this also provides the opportunities for the aircraft services company to survive.

Aircraft services companies operating in an international airport, like

Hong Kong Chak Lap Kok International airport, will serve aircrafts coming from different airlines and country. To comply with the strict aviation requirement of different authorizations and customers, the maintenance engineers of the aircraft services companies have to possess different licenses and approvals according to the requirement of the regulations set by the aviation authority and airline customers.

The diversification of license requirements of the aircraft being served makes the manpower cost to be one of the major operation cost of

Aircraft Services company.

To increase the profit margin, the company wants to hire as few engineers as possible. However, to maintain the services level, the company has to maintain enough number of engineers having different license and skill sets that can fulfil the requirements from airlines customers. In view of such, the better utilization of the manpower becomes one of the key factors for the company to succeed. It has been seen in the literature that a good personnel schedule can reduce the number of labour needed significantly. Thus a better way of scheduling engineer is needed and is vital to the company.


1.1.3. Rostering in Aircraft Services Industry

Rostering, which is the preparation of roster for available staff, in aircraft services industry is known to be a complex and difficult task.

The complexity of the problem is a result of constrains set by the government regulations, airworthiness requirements, airlines (customer) requirements, international standard, company policy, flight schedule and the human factors.

Since there is not much rostering software specially designed for aircraft services industry, there are two common ways of preparing roster in aircraft services industry. The first one is to prepare the roster manually. The responsible staff prepares the roster using general office-use software like spreadsheet and text editor. The staff prepares the roster by his/her experience and knowledge. The computer software is only used to help counting and printing of the roster. The quality of the roster is solely depends on the experience and knowledge of the responsible staff. Since the resulting rosters are normally stored in the computers in a document or spreadsheet format, the summary information can be provided is limited. And, obviously, the process of making roster manually is fairly slow.

Another way commonly used is to adopt the personnel scheduling software developed for other similar industry, like airlines.

However, as the operation model of airlines crews is different from that of aircraft maintenance industry, a lot of customizations and/or modifications are needed before the system can be adopted successfully.


2. Project Aim & Objectives

This project aims to research an Artificial Intelligence methodology suitable for solving rostering problem in aircraft service industry. Design and develop a prototype system for testing the methodology.

The objective of the project is to study and analyze the requirement and characteristic of rostering problem in aircraft service industry. Research and review the Artificial Intelligence methodology used in rostering problem. Design and Program a prototype system.

Evaluate the performance of the methodology using the prototype system.


3. Problem description

3.1.1. Problem analysis

In this study, we are going to build a rostering system for aircraft maintenance industry. The output of the system is a monthly roster showing the work shift of all maintenance engineers for the next month. The block diagram of the proposed system is show as Figure 1.

Figure 1: Block diagram of Rostering System

The information of demand and available supply are fed into the system as input. Using the defined methodology, a roster is generated subject to constrain imposed. The details of each block will be described in following section.


Labour demand is a set of numbers showing how many engineers of which type is needed in which work shift for which day.

Work shift is a list of predefined working period. From another point of view, work shift is a grouping of working hours in a day. The whole working periods are grouped into a number of shifts. In our case, we assume there are 3 shifts pre-defined:

Shift Code Shift Description Start time End Time

N

Shift 23:30

Night Shift 23:00 08:00

(next day) hours.

The labour demand is listed in terms of work shift, instead of

Engineer supply is a list of engineer that can be assigned to fill the labour demand. Each engineer has his/her own list of skill-set, that is the licenses or approval that he/she is bearing. When assigning engineer to fill the labour demand, the skill-set of the engineer must match the skill set requirement of the labour demand. In our case, we assume engineer skill set is classified by its grade.


3.1.1.3. Constrains

Constrains here refers to everything that restricts, guide and limit the assignment of supply to the demand. Specifically, constrains are the rules, regulations, policies, criteria or preferences that the resulting roster has to meet. Constrains are the main factors that makes rostering so difficult.

There are many types of constrains in rostering, and the constrains for different industries, departments, or even seasons are different. Constrains can be categorises into two types – the hard constrain and soft constrain. Hard constrains are the rules or regulation that must be follow and it cannot be violated in any case. For example, there is a rule set by the authority that engineers performing aircraft maintenance must have enough rest. So, the roster must ensure that there is no more than 7 consecutive working days for every engineer, there must be a rest day after 7 consecutive working days.

In contrast, soft constrains are the guideline or normal practice that nice to have. For example, the company policy stated that night shift should be evenly distributed. That is every engineer should have equal chance of assigning night shift. And the number of days between two night shift weeks should be maximised. Since this is just a soft constrain, it can be released in the case that the supply is not enough to fill up the demand.

Typical hard constrain in aircraft maintenance includes:

1.

At least 12 hours rest time between every consecutive shifts

2.

At least 1 rest day after 7 consecutive working days.

3.

Continuous working time should not exceed 10 hours

Typical soft constrain in aircraft maintenance includes:


1.

Night shifts are evenly distributed, days between night shift periods should be maximised.

2.

There should be fixed pattern of day off, or the length of working period should be fixed.

There is another type of constrains that we called

“Background” constrain. Background constrains is the “background” information that will affect the preparation of current roster. One of the examples is the roster of pervious month. Since the first day of the current roster is the consecutive days of the last day of the previous roster. Hence, previous roster must also be considered.

3.1.1.4. Roster

Roster in the output stream of the system should be a table showing the assignment of the supply to the demand. However, as the resulting roster is read by human being. The table is not grouped by demand; it is grouped by supply, i.e. name of the engineer, with the demand filled. (see the table below)

Jan 1 Jan 2 Jan 3 ……

Engineer A D D Off

…….

3.1.2. Evaluation criteria

Since there may be more than one feasible roster in the solution domain, and we want to choose the best one among, we need some means to know the quality of a roster. We must define some measures


to weight different rosters that may be generated. In our case, a penalty system will be used to mark the roster generated.

The marking scheme is a measure of the violation of constrains.

So it is the summation of penalties for each type of constrains:

Demand penalty

Hard Constrain penalty

Penalty will be given if any of the demand cannot be filled.

Penalty will be given if any of the hard constrain is violated

Soft Constrain penalty Penalty will be given if any of the soft constrain is violated

Background Constrain penalty Penalty will be given if any of the background constrain is violated

Obviously, the weight of the 4 penalties types would be different. For example, the penalty for hard constrain will be much higher than that of soft constrain. So the resulting solution will be biased to those only having soft constrain violation. Roster solutions will be compared by the corresponding total penalty calculated.


4. Literature Review

Reviewing the literature about rostering, it has been an active research subject since 1950’s. ERNST et al [6] have done an extensive review on the researches that have been done to try solving the problem. ERNST summarised and categorised the paper that have been published concerning rostering by their proposed approach and the types of problem that going to solve.

Table 1: Categorisation of papers by solution method. [6]

Table 2: Categorisation of papers by application [6]

Based on the result presented by ERNST, there are only a few papers focused on the rostering of Aircraft Maintenance Industry.

Dijkstra et al [10] presented the problem of planning a multi-skilled workforce of engineers required to carry out aircraft maintenance. In


this paper, the planning of aircraft maintenance personnel is solved using a Lagrangean relaxation approach and a constructive heuristic which can obtain an approximate solution quickly. Alfares [9] presented a case study describing the generation of a weekly roster for aircraft maintenance staff of Saudi Aramco. Simple IP models are used to determine the minimum number of staff required and the optimal assignment of days off and shifts.

Besides the studies focused on Aircraft Maintenance Industry, there are some studies focused on similar industries that are worth noted. Usher [4] presented a preliminary review of scheduling problems in airlines. KOHL et al [5] has discussed in details the solution method employed in a commercial crew rostering system for airlines.

The number of studies being done in so many different approaches and application areas hint that there is no “one-fits-all” solution available. Certain degree of adoption and customization is needed for different situations and applications.


Within the around 70 references reviewed, ERNST identified

28 different methods have been used to solve rostering problem in different areas. Among those 28 identified methods, we can see that there are two main streams of approaches that most researchers are working on. They are the mathematical programming and Heuristic approach.

Mathematical programming method, including its special cases and variation, like linear programming, integer linear programming, and many network flow problems, models the rostering as an optimization problem and seek to minimise or maximise an objective subject to a set of constraints by mathematic methods. Recent publications using mathematical programming like Azmat et al [7], and

Eitzen et al [8] that used Integer programming. The strength of mathematical programming methods is that they can give out solution in comparative shorter time and in most of the case, the optimum solution can be found if it exists. However, as constrains of roster have to be transformed into mathematical form before the problem can be solved by the optimizer, it is less flexible to cope with the situation that constrains of the problem will be changed frequently. Furthermore, the number of constrains can be “considered” is limited by the capability of the mathematical solver being used.

Heuristic approach has been used extensively in research to tackle difficult combinatorial problems for a long time. And another term, “meta- heuristic” was defined to describe the heuristic methods that are based on local search improvement and applying complex techniques to explore and guide neighbourhood searches. Examples of meta-heuristics include simulated annealing, tabu search, evolutionary algorithms, genetic algorithms, iterated randomised construction,

GRASP, ant colony optimization and problem space search methods.


Heuristic approach can due with complex problem with many and frequently changing constrains. Instead of taking the problem as a mathematical optimization problem, heuristic approach treats the problem as a searching problem. They search for good answer in the solution space. Ideally, the optimum answer can be found if the whole solution space has been searched. However, as the size of the solution space grows rapidly with the input of the problem, the solution space is simply too large and it is too costly to visit all solutions in order to find the optimum solution. So, different techniques are applied to reduce the time and storage cost of finding the solution. The ?? is to change the target to local optimum instead of optimum. That means the solution obtained may not be the best one, it is only a feasible one with certain quality. Since these algorithms having shorter calculation time are comparatively easier to implement and the sub-optimum solution obtained is already good enough in most of the case, they are preferred in real and practical rostering situation.


5. Algorithm Design

In this paper, rostering problem is treated as a searching problem. The input of the problem is the dimension forming the roster. These include the number of shift, number staff, number of days, number of demand, the rules/constrains has to be complied and the evaluation criteria which judge the good/bad of a roster. The space being searched is the combinations of different days, shifts and staff.

As shown in the figure above, a roster is a table formed by rows and columns. Row in the roster form represents the shifts assigned to one staff.

Column in the roster form represents the shifts assigned for one day. Roster generation actually is the task of filling the blanks on the rostering form with a predefined shift code. There is always a short list of shift codes defining what can be put into the blank.

In general, there is a list of possible shift S with m elements

S

=

{

S

1

, S

2

,......

S m

}

, m

≥

1 and a roster can be viewed as a collection of n rows, where n =number of staff,

RT i

=

{

R

1

, R

2

,......

R n

}

, n

≥

1


roster. and each row i has d elements where d = number of days

R i

=

{ r i 1

, r i 2

......

r id

} , d

≥

1 where

∈

S

Thus, with different combination of the elements r ij

, there are C r possible rows for row r

C

= d r m and with different combinations of rows R i

, there are C

RT

possible

C

RT

=

C r n =

( ) n

, C

RT

≥

1 ----------------------------------(1)

Therefore, the problem is to search for a solution roster RT sol

RT

=

{

RT

1

, RT

2

,......

RT

C

RT

}

∈

RT

So, the objective of the desire algorithm is:

“To find a feasible solution which complies with all constrains

(at least all hard constrain) and, if possible, fulfil all demands without excess in reasonable time.”

5.3. Problem solving approach

It is obvious from equation (1) that the search space to be searched will grow rapidly if either number of staff, shift or day is increased. So, it is not practical or realistic to tackle the problem directly. One of the ways to reduce the size or complexity of problem being solved is to divide it into several sub-problems and tackle them individually.

As discussed in previous section, a roster is formed by a combination of rows, and each row is formed by a combination of cells.

We also know that the cell combination, which forming the row, is limited by horizontal constrains; while the row combination, which forming the roster, is limited by vertical constrains. So, our approach is to divide the rostering problem into the problem of row forming and


roster forming. The block diagram below shows the flow of the approach.

5.4.1. Constrains in row forming

Constrains affecting row forming is the shift pattern that is not allowed or to be blocked. These patterns are defined by user and can be used to account for the minimum working time requirement.

Shift

Code

Shift Description Start time End time

D Day 16:30

Shift 23:30

N Night 08:00

For example, if we have 3 shifts as shown in the table above, and there is a constrains that, for every two consecutive shift assignments, there must be at least 12 hours between the end time of the former shift and the start time of the later shift. So, for the shifts listed below, the shift pattern shown below must be blocked.

Shift pattern Time between

ND Overlap


It is obvious that any solution containing these shift patterns are not “legal” solution and can be discarded. So, these patterns will be used to reduce the number of possible cell combinations.

Another typical horizontal constrain is the number of consecutive working days and night shifts. According to the labour regulation from the government, there must be one holiday within 7 consecutive working days. In other words, the maximum number of consecutive working day is 6. And following the policy of the company, there should not be more than 3 consecutive night shifts for each engineer.

So any rows containing over 6 consecutive working days and over 3 consecutive night shifts will be ignored.

5.4.2. Preparing possible row combinations

Jan 1 Jan 2

Engineer A D

Î

D?

Î

A?

Î

N?

Î

O?

Jan 3

Î

D?

Î

A?

Î

N?

Î

O?

Î

D?

Î

A?

Î

N?

Î

O?

Î

D?

Î

A?

Î

N?

Î

O?

Î

D?

Î

A?

Î

N?

Î

O?

Jan 4

…


The figure above shows the process of filling a row of roster. Say, if a “D” is filled in the 1 st

cell, when filling the 2 nd

cell, there are 4 possible choices (Assume there are four shifts defined), for each choice in the 2 nd

cell, there are another 4 choices for the 3 rd

row, and so on.

However, if we consider the shift constrains, an “A” shift can not be followed by a “D” shift, and “N” shift cannot be followed by “D” or “A” shift. So, the possible combination will be reduced, and the table will become:

Jan 1

Engineer A D

Jan 2

Î

D?

Î

Î

Î

A?

N?

O?

Jan 3

Î

D?

Î A?

Î N?

Î O?

Î

A?

Î

N?

Î

O?

Î

N?

Î

O?

Î

D?

Î

A?

Î

N?

Î

O?

Jan 4

…

So, our task in this stage is to find out all possible cell combinations which can form a “legal” row. It is obvious that this can be solved by tree-search using backtracking method.


We define a n level tree that represents a single row in a roster having n-1 day. Each node in the tree represents a possible shift assignment. Each level represents one column in the row. The tree below shows a 3 level tree representing a row for 3 days.

Backtracking method is applied in tree building process, so that any path having “illegal” pattern, having too many consecutive work or night shift is marked as “dead-end” (nodes with red cross) , and no more path will be grown from that node.

After building the tree, all possible rows can be obtained by a depth first search. Since all paths with “illegal” pattern are ignored and killed from the tree, all rows obtained in the depth first search comply with horizontal constrains. In other words, the search space of the roster is reduced with only legal rows.

The tree below is a sample tree of a 3 days row. The number of possible path is reduced to 41 from a total of 64 according to the shiftconstrains.


If, for demonstration purpose, we set the maximum number of consecutive working days and maximum number of consecutive night shift to 2 and 1 respectively, the number of possible rows will be further reduced to 29.

The same constrains are applied on different number of days to see the effect on reducing the number of possible row and the result is shown as below: day without constrain applied

No. of possible row with constrains applied

% of reduction

2 16 13

3 64 29

4 256 85

9 262144 13228 95%

10 1048576 36420 96.5%


5.5.1. Constrains in roster forming

Now we have a list of possible rows for each staff. To form the roster, we need to combine the rows picked from each staff.

Staff A

Staff B

Staff C

Staff D

Î

DDD ?

Î

DDA ?

Î DDN ?

Î DDO ?

…….

Î

DDD ?

Î DDA ?

Î

DDN ?

Î DDO ?

…….

Î

DDD ?

Î DDA ?

Î DDN ?

Î DDO ?

…….

Î

DDD ?

Î

DDA ?

Î DDN ?

Î DDO ?

…….


5.5.2. Demand

The criteria for picking the rows to form the roster is that the combination of rows have to comply with vertical constrains defined for the roster. As discussed in previous section, one of the main vertical constrains is the demand of the day. Below is a table of demand.

Shift Day 1 Day 2 Day 3 ….

….

Demand specified how many staff required for a shift. That means, for any column of a roster, the number of staff assigned to specific shift must be equal or greater than the number demanded in the demand table. In the other way round, we don’t want to have overassignment of staff, i.e. the number of staffs assigned to a shift is more than the number required. So, we always want to have a roster that can meet the demand with minimum over-assignment. As we assume that the number of staff required in the demand definition is the minimum, any roster that cannot meet demand will be considered as “illegal” and will be filtered.


5.5.3. Sampling strategy

Although the number of possible row for each staff is reduced in the row forming stage, the number of possible roster formed by combining those possible rows is still very huge. That means a lot of time and cost have to be spent to search for a good solution. In order to get a balance between the time spent and solution quality, we relax the condition that we can accept sub-optimum solution. Adopting the idea of randomness and continuous improvement from Genetic Algorithm, instead of checking every possible solution to look for the true optimum, we pick samples randomly from the solution space, and choose the best one in the sample set to be the solution.

Since the sampling strategy will affect the quality of the solution and the performance of the system, three sampling strategies are used. They are namely, “Linear Forward Search”, “Multi-direction

Search” and “Genetic Algorithm”

5.5.4. Linear Forward Search

Assuming we have K solutions in the solution space and k is very large. The simplest method to pick samples from the solution space is using a random number generator to generate a random number from 1 to K.

However, this method arise a problem of repeatability and evenness. If we draw J random numbers, where J

≤

K , from the space 1 to K, the J numbers drawn may not be unique and evenly distributed over the space. If there are repeated numbers in the numbers drawn, it will be a waste of processing time as we might evaluate the same sample more than one time, and it will reduce the chance of picking the optimum solution. And if the numbers drawn are not evenly distributed, the final solution will be biased the chance of getting the optimum will also be reduced. To overcome the


problems, Linear Forward search picks samples in one direction with a random step size. The steps of Linear Forward search is shown as below:

1.

Sort the solutions linearly to certain order.

2.

Set the sample index j

0

=

0

3.

Define a maximum step size T, 0

<

T

≤

K and generate a random number r, 0

< r

≤

T

4.

Pick sample at j n

= j n

−

1

+ r

5.

Repeat step 3 and 4 until j n

≥

K

This method provides assurance on the uniqueness and evenness of samples. It also provides flexibility that we can control the sample size by the step size T. Step size T can be interpreted as “one sample will be picked per T solutions”. The figure below demonstrates how the samples are picked using the customized sampling method.

To use Linear forward search and for the convenient of storing and describing the solution, we need to name the solutions in number and sort them in certain order. As the solutions we are now working on in this stage is a combination of row of each staff and there is no explicit ordering among the solutions, we have to define a way to name and order the solutions. The table below shows an example of the possible solution.


Staff A

Staff B

1. DDD

2. DDA

3. DDN

4. DDO

1. DDD

2. DDA

3. DDN

Staff C 1. DDD

2. DDA

3. DDN

4. DDO

For we have 3 staffs and the number of possible row is 4, 3 and 4 respectively, there are 48 possible solutions for the roster. They are listed in the table below:

7

8

9

10

11

12

13

14

2

3

4

5

6

Sol.

# A B C

1

15

16

17

Sol.

# A B C

3 1 1

3 1 2

3 1 3

3 1 4

3 2 1

3 2 2

3 2 3

3 2 4

3 3 1

3 3 2

3 3 3

3 3 4

4 1 1

4 1 2

4 1 3

4 1 4

4 2 1


18

19

20

21

22

23

24

4 2 2

4 2 3

4 2 4

4 3 1

4 3 2

4 3 3

4 3 4

Obviously, the simplest method is to make a table like the one above which list out all possible solutions and give every one a solution number. However, this will consume huge among of memory if the number of possible solution is very large. So, a naming method that does not require explicit listing is needed. Examining the solution listed in the table carefully, we found that there is one way to name the solution without listing them explicitly. The solutions in the table above are listed in a convention that the right-most column is increased first. The 2 nd

right-most column will be increased until the right-most column reaches its max. In general, except the right-most column, every column will be increased until the column in its right side reached maximum. Using this listing convention, all solutions are already implicitly numbered. Given any number within the solution space, the corresponding number in each column can be retrieved using the following algorithm.

Let, M M >0

j be the solution number, 0

≤ j

<

M

C ij

be the corresponding number in column i for solution j

Tmax i

be the corresponding maximum number for column i

Function gd(i) = gd(i-1) x Tmaxi, for i>1 ;

= Tmaxi ,

= 1 ,

for i=1 ; a a mod b = the remainder of b if ( j mod gd(i) > 0 )


then

C ij

=

⎡

⎢ j mod gd ( i gd

−

1 )

( i )

⎤

⎥ else

C ij

=

T max i

For demonstration purpose, we take one solution number arbitrarily from the solution table above.

For j =33, M =48, Tmax

1

=4, Tmax

2

=3, Tmax

3

=4 gd ( 0 )

=

1 gd ( 3 )

=

12

×

4

=

48 gd T i

, gd ( 2 )

=

4

×

3

=

12 ,

Q j mod gd ( 1 )

=

33 mod 4

=

1 >0

∴

C

1 , 33

=

⎡

⎢⎢

1

1

⎤

⎥⎥

=

1

Q j mod gd ( 2 )

=

33 mod 12

=

9 >0

∴

C

2 , 33

=

⎡

⎢⎢

9

4

⎤

⎥⎥

=

3

Q j mod gd ( 3 )

=

33 mod 48

=

33 >0

∴

C

3 , 33

=

⎡

33

⎢⎢

12

⎤

⎥⎥

=

3

So, the corresponding column values for solution 33 is {3,3,1} which matches the value in the table.


5.5.5. Multi-directions Search

There is one obvious draw back in the Linear Forward search. If the solutions are gathered near the end of the list, it will need a very long time to obtain the solution because, by design, it has to start searching from the first solution in the list. For such occasion, a Multi-directions search may shorten the searching time.

Instead of listing the solutions (combinations of rows) linearly, Multidirections search pick samples randomly by randomly choosing row for each staff and combine them to form the solution.

Staff A Rand(1, A max

)?

Staff B Rand(1, B max

)?

Staff C Rand(1, C max

)?

Staff D Rand(1, D max

)?

=>

Staff A

Staff B

Staff C

Staff D

1

3

4

2

Using such method, every sample picked is independent and does not affect the next sample to be picked. Thus the sampling point is

“jumping” in the solution space. This may improve the performance of discovering solutions that gathered in the one part of the solution space.

5.5.6. Genetic Algorithm

Although Multi-directions method may shorten the time for discovering solution, there may be the chance that the time is increased. It is because Multi-directions search is work on a totally random basis. There is no guidance on which direction to go. If we are lucky, we can find solution in the first iteration. But if we are not lucky, there will be no solutions found even it iterated for millions of times. So, we want a method which can provides randomness with certain degree of direction.

Genetic algorithm simulates the nature’s evolution process.

Individual in the nature produce offspring by mating with another


individual. The chromosome of the produced offspring is created by

“crossovering” the chromosome of its parents. That means some genes of the offspring are obtained from one of its parents and the other genes are obtained from another parent. This is why, in the nature, offspring are usually having some similarity but not equal to their parents. And if the chromosome of the offspring makes itself able to survive in the world, the offspring will be able to mate with another individual to produce another offspring. This process keeps good genes alive in the world. However, if offspring has some bad genes, the offspring will not be able to survive and hence without chance to produce offspring. This will destroy the bad genes.

By continue the process many times, the quality of chromosome will be keep improving and only individuals having good chromosome will be left in this world. Genetic algorithm applies this idea into problem solving. By defining the genes with problem variables, continuously producing offspring by mating individual solution, and kill those bad solution, after certain generations, all individual left will be good answer to the problem.

To use Genetic Algorithm in our problem, we define the gene as below:

Gene 1

Gene 2

Gene 3

Row selection for staff A

Row selection for staff B

Row selection for staff C

…… ……

The length of the chromosome is defined as the number of staff in the roster. Each gene in the chromosome represents a row selection for the corresponding staff. So, each chromosome is representing one combination of rows, or we can say it is representing one roster.


With the Gene definition decided, we have to define some parameters for the problem.

Parameter Explanation

Population Size The number of individuals created for 50 each iteration

Cross over rate The chance that the chromosome will be cross-over with another individual in

0.9 a generation. These probabilities range from 0 to 1.

Generation Gap The fraction of individuals that do not 0.98 go into the next generation. It is specified as a fraction from 0.0 to 1.0

The steps of the operation are listed as below:

1.

Create a generation randomly

2.

Evaluate and sort the individuals by demand fulfilment

3.

Good individuals are left for producing offspring.

4.

Form a new generation by combining the offspring produced and the individual left in last generation.

5.

Repeat step 2 until iteration criteria fails.

Analyzing the Genetic Algorithms, it is a random approach as the populations are generated randomly. However, as part of the population is generated by crossovering good solutions, the search using GA is not totally random. It searches over the solution space randomly and at the same time looking around the space near the good solution found.


5.6. Evaluation

After obtaining a list of “legal” roster that complies with the demand requirement, we have to choose the best one to be our final answer. To evaluate the “good” or “bad” of a roster, the soft constrain is used.

5.6.1. Shift distribution

Within the space of “legal” roster solutions that met the demand constrains, there exist some solutions that the distributions of shifts are not even. Below is one of the examples.

Day 1 Day 2 Day 3 ….

Staff Off Off Off

Demand 1 1 1 for D

It is obvious that the roster above is not a good one, although it can meet the requirements of demand. The shifts are unevenly distributed as staff A has to work consecutively for 3 days, while staff

B no needs to work in this 3 days. Therefore, we have to consider the shift distribution when looking for good roster solution. Beside the distribution of off day, the distribution of special shift has to be considered too. Night shift is one of special shift that we have to consider.


5.6.2. The fitness function

Since the vertical constrains in our case is quantitative, a fitness function will be used to judge or evaluate the resulting roster. In our case, there are three vertical constraints to meet:

1.

Demand constrain (Meet demand with minimum over-assignment)

2.

Off day distribution

3.

Night shift distribution

So we use three indexes to cater for the three constrains. They are

Demand fulfilment DF = Total number of shift that the number of staff assigned is not equal to the number of staff required.

Off day deviation OD = Summation of standard deviation of the count of off day for each staff

Night shift deviation ND = Summation of standard deviation of the count of night shift for each staff

In order to reflect the importance of these three indexes, weight factors are assigned as below:

Index Weight

Demand Fulfilment, DF 2

Off day deviation, OD

Night shift deviation, ND

1

3

So, the fitness function is defined as below, and it will be used to judge whether a roster solution is good or not.

F fitness

=

3

×

ND

+

2

×

DF

+

OD ----------------------------------------(2)


5.6.3. Case base

As randomised approach is used, there may be the case that if we run the algorithm for 3 times, the qualities of the “best rosters” being found in 3 runs are not the same, and may even decreasing. This is due to the randomized sampling method. The samples picked for evaluation in each time are not the same, so the “best” solution in the first run, may not be the best one in another run. To overcome this repeatability problem, the idea of case base is adopted. For every run, the solution number of the best solution will be stored into the database with a signature of the problem. For any future run, the database will be queried to see if there is any record saved having the same problem signature. If yes, that solution will be retrieved, and it will be compared with the best solution found in the sampled solutions to obtain the best among them. If the best solution in the sampled set is better than the retrieved one, the database record will be updated with this better solution number. Using such case base comparison, the quality of the “best” solution can be retained in different runs, and it ensures the quality of the result will only be the same or improving, if we repeat the procedure again and again.

5.6.4. Problem signature

Like other case base problem, one of the important issues is the definition of problem signature. How do we know the problem we currently dealing with is the same as the one stored in database? To define the signature of the problem, we have to get balance between the size and the amount of information stored in the signature. Since the signature will be used as the key for searching, it should be kept small and simple to facilitate efficiency searching.


Recalling the analysis of the problem in previous section, the total number of possible solution is

( ) n d m , where m is the number of shift, d is number of day, and n is the number of staff. So, if these numbers of two problems are the same, that two problems will have the same number of total possible solutions. And that is the upper bound of the size of the search space. However, as we apply backtracking in the row forming stage to reduce the search space, the actual total number of possible solution is not only affected by these three numbers. Constrains will also affect the problem size. However, it would be too complex and lengthy to store all constrains in the problem ID. In order to get a balance between space and accuracy, the outcome of constrains is being used. In the row forming stage, the shift constrains are used to filter out the solution having illegal shift patterns and this operation reduced the number of possible rows for each staff.

We then make an assumption that, if two problems A and B, having the same number of shift, staff and day, and the number of filtered solutions for all staffs of problem A is the same as the number of filtered solutions for all staff of problem B, we assume that there are high chances that both problem A and B are using the same set of constrain.

Thus, we define the problem ID as follow:

ProblemID= [Number of days]

+ [Number of Shift]

+ [Number of possible rows per staff]


5.7. The overall algorithm

The following flow chart summarized the proposed algorithm.


6. System Analysis

6.1. Basic system requirement

•

Implement the designed algorithm for rostering

•

Generate roster for any number of days

• staff information editing

•

Shift setting editing

•

Shift constrains editing

•

Demand setting editing

•

Store setting and roster data in database

•

With users login level to restrict changing of staff and shift information, as well as the user login information

1.

The system software contains an integrated user interface.

2.

It is divided into 6 parts, namely “User Management”, “Staff settings”, “Shift settings”, “Demand settings”, “Fitness Function” and “Rostering”.

2.1

User management

•

Manage user levels and module accessibility

•

Add a new user with suitable access right depend on their job nature and grade seniority.

•

Edit user information (username, password and user right)

•

Remove existing user who left the company.

•

This module can only be accessed by Super User

•

2.2

Staff settings

•

Maintain (insert/update/delete) staff and update corresponding information.


2.3

Shift setting

•

Maintain (insert/update/delete) shift and update corresponding information

•

Maintain (insert/update/delete) shift constrains. Allow user to define shift pattern block.

2.4

Demand setting

•

Allow user to select any number of days

•

Load demands within selected day range from database

•

Update demand value

•

Save updated demand into the database

2.5

Fitness setting

•

View and update the weight factor of the fitness function

2.6

Rostering

1.

Allow user to select any number of days for rostering

2.

Generate roster of the date selected by user

3.

Allow user to change the maximum step size

4.

Save the generated roster into the database


3.

User’s Authority Right

Authority Right

Insert user

Update user

Delete user

Insert staff

Delete staff

Insert shift

Delete shift

Add shift pattern block

Delete shift pattern block

5 Fitness function

View weight factor

Update weight factor

6 Rostering

Generate roster

Save roster

Super user General user

4.

Assumptions

•

The system software is using within a local area network where database server can be accessed through the network

•

The program is used by single user simultaneously

•

User has to login with ID and password before using any functions

•


6.3. Use Cases analysis

Super user

«inherits»

General user

RosterBuilder

Edit system user

Edit staff information

Edit Shift setting

Edit fitness fucntion

Edit demand setting

Generate roster

Login System



Name : Login System

Input : Login Name, Login Password

Output: No

Participant: General user, Super user

Goal: Start application and set the accessibility of function modules according to user type if the login name and password is valid.

Pre-condition: User account valid

Name : Edit Demand Setting

Input : Start date, End date, Day demand

Output: No


Goal: Update the demand stored in database for the day specified by start date and end date

Pre-condition: Start date and end date valid (i.e. end date behind start date), day demand is integer.

Name : Edit Staff information

Input : Staff ID, staff name and staff Type

Output: No

Participant: Super user

Goal: Update staff records stored in database

Pre-condition: Staff ID is unique

Name : Edit Shift setting

Input : Shift code, Shift name, shift type, shift constrains

Output: No


Goal: Update shifts records stored in database. Update shift constrains stored in database

Pre-condition: Shift code is unique, shift code in shift constrain is valid.

Name : Edit Fitness function

Input : Weight factors for the terms in the fitness function

Output: No


Goal: Update the weight factor records stored in database

Pre-condition: weight factor records exist in database

Name : Generate roster

Input : Start date, end date, sampling strategy, settings for corresponding strategy

Output: No


Goal: Generate roster of the date specified by start and end date. Save the generated roster into database.


Pre-condition: Shift, Staff, Demand setting already entered and stored in database.

Name : Edit system user

Input : login name, login password, user type.

Output: No


Goal: Update user records stored in database.

Pre-condition: login name is unique, password is not blank.

6.5. Conceptual Class diagram

ShiftManager

-acnwork

-acoff

-acwork

DemandManager

-startDate

-endDate

-dayDemand

UserManager uses

RosterManager Rules

1 *

1 create

*

Roster

1 has

*

RosterRow

-totalNumOfRow

1 creates

*

Tree

-rootNode

-treeSize

StaffManager

1

Manages

*

Staff

-staffID

1 has

*

TreeNode

-childNodeList

-nodeLabel

-nodeLevel

-parentNode


7. System Design

7.1. Design Class Diagram

7.1.1. Presentation Layer

RosterBuilder:: LoginForm

-exitButton_Click_1()

+getUserType()

-loginButton_Click_1()

+LoginForm()

RosterBuilder:: StartUpForm

-buttonDemand_Click()

-buttonRoster_Click()

-buttonRules_Click()

-buttonShift_Click()

-buttonStaff_Click()

-buttonUser_Click()

-setButtons()

+StartupForm()

RosterBuilder:: StaffForm

+StaffForm()

+buttonBack_Click()

+laodStaffGrid()

+staffForm_Load()

RosterBuilder:: UserForm

+buttonAdd_Click()

+buttonBack_Click()

+buttonRemove_Click()

+loadUserGrid()

+UserForm()

+UserForm_Load()

RosterBuilder:: RosterForm

+generateRoster()

+RosterForm()

+setStatusBar()

+showRoster()

+buttonBack_Click()

+buttonGenerate_Click()

+fromDatePicker_ValueChanged()

+RosterForm_Load()

+toDatePicker_ValueChanged()

RosterBuilder:: MethodSetupForm

-buttonGo_Click()

-checkBox1_CheckedChanged()



-checkBoxConditions()

-comboBox1_SelectedIndexChanged()

+MethodSetupForm()

RosterBuilder:: DemandForm

-buttonBack_Click()

-buttonGet_Click()

-buttonSave_Click()

+DemandForm()

RosterBuilder:: ShiftForm

-AddConstrainButton_click()

-backButton_Click_1()

-buttonConstrainSave_Click()

-loadShiftGrid()

#MoveDnButton_Click()

+ShiftForm()

+ShiftFromLoad()

RosterBuilder:: FitnessForm

+buttonBack_Click()

+buttonSave_Click()

+FitnessForm()

-FitnessForm_Load_1()

7.1.2. Domain Layer

RosterBuilder:: ShiftManager

+code2Shift()

+getACNWrok()

+getACOff()

+getACWork()

+getNightShfits()

+getNumOfWorkShift()

+getOffShift()

+getShiftconstrains()

+getShiftList()

+getShiftTable()

+loadDbData()

+ShiftManager()

RosterBuilder:: StaffManager

+getNumOfStaff()

+getStaff()

+getStaffList()

+getStaffTable()

+loadStaffData()

+StaffManager()

«utility»

RosterBuilder:: DBConnector

+cloaseDB()

+connectDBAdaptor()

+connectDBNonQuery()

+connectDBNonQuerySP()

+connectDBQuerySP()

+connectDBReader()

-openConnection()

RosterBuilder:: Staff

+getConsecutiveNight()

+getConsecutiveOff()

+getConsecutiveWork()

+getLastShiftCode()

+getMaxNumOfSol()

+getRosterRow()

+getStaffID()

+setRosterRow()

+Staff()

RosterBuilder:: UserManager

+checkLogin()

+getUserTable()

-loadDBData()

+refreshUserTable()

+updateUserData()

+UserManager()

RosterBuilder:: DemandManager

+DemandManager()

+getDayDamand()

+saveDayDemand()

RosterBuilder:: Rules

+buildCheck()

+checkConsecutiveNight()

+checkConsecutiveOff()

+checkConsecutiveWork()

+checkDemand()

+checkNightShfits()

+checkOffShifts()

+checkShiftsOrder()

+code2Shifts()

+evaluate()

+getDivider()

+getNumOfDay()

+getShifts()

+getTotalNumOfSolution()

+id2Sol()

+Rules()

+scoreOkSolution()

+sol2Id()

RosterBuilder:: RosterManager

-buildTree()

+getStaff()

+RosterManager()

-scoreOkSolution()

-searchMethod1()

-searchMethod2()

-searchMethod3()

+startGeneration()

RosterBuilder:: GAEngine

+crossOver()

+GAEngine()

-makeChromosome()

+makePopulation()

RosterBuilder::

+std()

Statistic

RosterBuilder:: Roster

+getNumOfDay()

+getOverallScore()

+getRosterList()

+getSolID()

+Roster()

+setDayDemand()

+setNightSTD()

+setOffSTD()

+vector2Roster()

RosterBuilder:: RosterRow

+getTotalRowNumber()

+getTreeListItem()

+RosterRow()

RosterBuilder::

+buildTree()

+getTreeList()

+getTreeSize()

+node2List()

+Tree()

Tree

RosterBuilder:: GAIndividual

+checkEqual()

+getChromID()

+getChromosome()

+getScore()

+GAIndividual()

+setChromID()

+setChromosome()

+score()

RosterBuilder:: TreeNode

+addChild()

+getChildList()

+getChildNode()

+getConsecutiveNight()

+getConsecutiveOff()

+getConsecutiveWork()

+getLabel()

+getNodeLevel()

+getParent()

+getShiftCode()

+setConsecutiveNight()

+setConsecutiveOff()

+setConsecutiveWork()

+TreeNode()


Generate Roster

System

Boundry

User fromDatePicker_ValueChanged() toDatePicker_ValueChanged() buttonGenerate_Click()

RosterForm MethodSetupForm

MethodSetupForm() buttonGo_Click() generateRoster() startGeneration()

RosterManager StaffManager getStaffList() staffList getShiftList() shiftList buildTree

ShiftManager searchMethod1 scoreOkSolution showRoster()


Get Demand

General User buttonGet_Click()

System boundry

DemandForm DemandManager getDayDamand() dayDemand

Get Shift

Super User

ShiftFromLoad()

System boundry

ShiftForm getShiftTable() shiftTable

ShiftManager

Since the sequence diagram of other operations are quite similar, they are omitted in this report.


Database Design

7.2.1. ER diagram


7.2.2. Table listing

Table Name Description

Roster To store the ID and description of a saved roster

Shift

Staff

Casebase item is pointing to one rosterID

To store the shift code and shift type.

To store the name and ID of staff that should be included in the roster

To store the demand per shift per day Demand

Constrains To store the constrains of roster generation.

Constrains are stored as a constrain type and constrain value pair.

Users To store the login ID, password and type of users will use the system

To store records of solution found in the past.

7.2.3. Table Details

Table: roster rosterID nvarchar ID of roster

Table: rosterItem itemID int ID of item staffID itemDate itemShift

Table: shift nvarchar id of corresponding staff smalldatetime Date of the item nvarchar Id of the corresponding shift


shiftCode shiftName shiftType nvarchar nvarchar nvarchar

ID of shift

Name of the shift for display

Type of the shift. It can be:

“W” – normal working shift

“N” – night shift

“O” – day off

Table: Staff staffID staffName nvarchar ID of staff nvarchar Name of staff lastShiftCode nvarchar To store the last shift of the staff in previous roster. It is stored for faster reference lastConsecWork int work shift at the end of last roster. It is stored for faster reference lastConsecNight int lastConsecOff int night shift at the end of last roster. It is stored for faster reference

To store the number of accumulated day of at the end of last roster. It is stored for faster reference

Table: demand demandID int ID of demand item demandItemDate smalldatetime Demanding demandItemShift nvarchar demandQty int Number of staff required

Table: constrains constrainID int ID of constrain item constrainType nvarchar Type of constrain

“Shift” – shift block pattern


“DFF” – weight factor for “Day fulfilment

“NDF” – weight factor for “Night shift distribution”

“ODF” – weight factor for “Off shift distribution

“MCN” – max number of consecutive night shift allowed

“MCW” – max number of consecutive work shift allowed

“MCO” – max number of consecutive day off allowed

“SCV” – stop criteria value.

“MSS” – max step size in sampling constrainValue nvarchar The value of corresponding constrain

Table: caseBase problemID nvarchar ID to the problem solutionID nvarchar corresponding solution ID

Table: users username nvarchar Login name of user userPassword nvarchar Login password of user userType nvarchar Type of user:

“Super” – user which can access all functions

“General” – user which can access only the “Rostering” and “Demand setting” modules


Login Menu

Since Visual Studio for .NET provides a powerful UI capability, and a rich set of UI component, the GUI for the system is designed directly inside Visual Studio.

Main Menu


Rostering

Generate Roster – Linear Forward Search

Generate Roster – Multi-directions


Generate Roster – Genetic Algorithm

Roster Result


Demand Setting

Staff Setting


Shift setting

Fitness Function setting


User Management


8. System Implementation

Before starting programming, an important step is to choose the right programming language or programming tools. We have to consider the performance, functions, database connectivity and flexibility of the tools. In additions, we have to consider the form and type of the program output, and of course the availability of the tools.

Since roster generation is an in-house process and there are only a few users needed to operate the system, to reduce complexity and improve performance, the system will be built as a stand-a-lone application. As Microsoft Windows is the most commonly used OS, the program will be built as a Windows application. With such criteria, only Windows based tools are considered.

Looking around the programming tools available to the writer, there are 3 candidate tools selected for consideration. They are:

•

Java of J2SE from Sun Microsystems

•

C# of Visual Studio for .NET from Microsoft

•

C++ of the C++ Builder from Borland


Language type

A comparison between the tools is summarized in the table below:

Java C# C++

Object Oriented Object Oriented Procedural

Performance under

Windows

Functions (library provided)

Database connectivity

Flexibility

Development

Environment

Poor Good Good

Good Good Medium

JDBC-ODBC

•

Multi-platform

ADO.NET

•

Windows or Internet

(depends on availability of

JVM)

•

Can be

• based

.NET compatible converted to

Web application netBeans IDE,

JBuilder

Visual Studio .NET

•

BDE - ODBC

Windows application only

C++ Builder,

Visual Studio .NET

Considered the comparison between tools, C# is chosen as the development language used with the following reasons:

•

The target system require good performance

•

Object oriented language is preferred for easier development and future expansion.

•

C # provides a one-level database access which having better performance and reducing complexity in database connection.

•

Visual Studio for .NET provides a powerful development and debugging environment.

•

Syntax similar to JAVA which shortened the learning time


Besides programming language, the choice of database system is also vital. The criteria of choosing database system for our system would be the storage and query capability. With the two commonly used Windows based database system, Microsoft SQL server 2000 and

Microsoft Access, a comparison is summarized as the table below:

Database Engine

As an server

Backup and recovery

SQL Server 2000

Good

Yes

Yes

Access 2003

Basic

No

No

Form and Report building

Graphical User Interface

No

Basic

Yes

Good

Storage capability

Data types – String/Text

Data types – Integer

Good

Max. 2147483647

Basic

Max. 255 characters characters

Max 2

62

Max

With the comparison result shown above, Microsoft SQL server 2000 is preferred with the following reasons:

•

Large number of records is needed for storing even single roster.

•

In our application, huge number will be processed and may be stored in database, so the size limit of Access will lead to limitation or even error in operation.

•

Roster is important information that a system with backup and recovery is preferred.


8.2.1. System Architecture

Besides class unit tests being done during development, to check whether the system functions as what we designed after integration, a use-case based testing are used.

Test Case Test plan

Login

System

Edit

Demand setting

Login system using correct user name and password with General user type

Login system using correct user name and password with Super user type

Login system with incorrect user name

Login system with incorrect password

Get demand with correct start date and end date

Change start date behind end date

Modify the demand of the any date and shift. Click save button.

Expected result

Application starts with only “Generate roster” and

“Demand setting” enabled

Application starts with all buttons enabled

Warning message prompt. Application does not start.

Warning message prompt. Application does not start.

Demand of the days between start date and end date shows.

Warning message prompt. After user click to close the message, the start date change to 1 day before end date.

Successful message prompt. Records in database updated.

Testing result

As expected

As expected

As expected

As expected

As expected

As expected

As expected

Classes involved

LoginForm,

DBConnector,

StartUpForm

DemandForm,

DemandManager,

DBConnector


Edit staff information

Edit shift setting

Generate roster

Add a staff with correct staff ID

Add a staff with staff ID already stored in database

Remove a staff

Add a shift with correct shift ID

Remove a shift

Add a shift constraint

Edit Fitness function

Modify a weight factor and save.

Generate roster with correct start date and end date with one of the methods.

Change the start date behind end date


Warning message prompt. No modification in the database

Successful message shown. Records in database removed





Roster generate and shown in Grid table, the score of the roster and time used show in the status bar

Warning message prompt. After user click to close the message, the start date change to 1 day before end date.

As expected

As expected

As expected

As expected

As expected

As expected

StaffForm,

StaffManager

DBConnector

ShiftForm,

ShiftManager,

DBConnector

As expected FitnessForm,

DBConnector

As expected

As expected

Edit system user

Add a new user with correct login name

Add a new user with login name already exist in the database

Remove a user


Warning message prompt. No modification in the database


As expected

As expected

As expected

RosterForm,

RosterManager,

Rules,

Tree,

TreeNode,

Statistic,

Roster,

RosterRow,

GAEngine,

GAIndividual

DBConnector

DemandManager

ShiftManager.

StaffManager

UserForm,

UserManager,

DBConnector


8.4.1. Performance Evaluation

To evaluate the performance of the system, a simple Genetic

Algorithm model was built for comparison. The GA model was run in

Microsoft Excel using a commercial GA engine – The GeneHunter. A testing scenario was setup and was solved by the two systems. Several performance indexes were used for analysis.

Besides comparing with other approach, the performances of the three sampling strategies are also evaluated.

8.4.2. The Gene Hunter

GeneHunter is a Microsoft Excel add-in program which allows the user to solve optimization problem from an Excel spreadsheet. It provides ready-to-go GA functions and configurations that can be used without any programming effort.

8.4.3. Simple GA model

The gene definitions are as follow:

Gene Definition

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7

Gene for staff 1 D A S N Off S N

Gene for staff 2 A S N Off D S N

……

The genes for each staff are joined to form the chromosome for operation. So, for a gene for 10 staff and 7 days, the gene will have 70 elements.


Fitness Function

For fair comparison, the same fitness function should be used in both systems, however, as GA algorithm require more index to guide the searching direction, so in addition to the terms used in the original fitness function, a few more terms are added. And this updated fitness function will be used for comparison of result.

The fitness function for GA is defined as follow

GAF

+

100 fitness

×

=

OCW

3

×

ND

+

100

+

2

×

DF

×

OCO

+

OD

+

10000

×

SR

+

10000

×

DU

+

100

×

OCN

where,

OD= Off day distribution

SR= Shift order reversed, shift assigned are not follow shift order

DU=Demand under, number of staff assigned cannot meet the demand

OCN = Over consecutive night

OCW=Over consecutive work

OCO=Over consecutive off

Since the situations of “Demand under” and “Shift order reversed” are highly unwanted, the weight factor for DU and SR is much larger than the others


GA Operation configurations

Objective Minimize fitness function

Population size

Cross over rate

Mutation rate

50

0.9

0.01

Generation Gap 0.98

Diversity operator Applied

Elitist Strategy

Stop criteria

Applied

Best fitness unchanged after 75 generations

8.4.4. Evaluation Scenario

The scenario is to prepare a 7 days roster for 10 staffs with the shift and demand and constrains as follow:

Staff

Staff Name Last shift Accumulated Accumulated number of number of

Accumulated number of off

Staff A

Staff B

Staff C

Staff D

D

A

N

Off working day

1

2

3 night shift

0

0

1 day

0

0

0

Staff E

Staff F

D

A

0

1

2

0

0

0

1

0

0

Staff G

Staff H

Staff I

Staff J

N

Off

D

A

3

0

1

2

2

0

0

0

0

2

0

0


Shifts

Shift Code Shift Description Start time End Time

Shift 16:30

A Afternoon 23:30

N Night Shift 23:00 08:00

(next day)

Demand

Shifts Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7

D 3 3 3 3 3 3 3

A 2 2 2 2 2 2 2

N 2 2 2 2 2 2 2

Constrains

•

The shifts are in the order of D -> A -> N, which every shift must be followed by the same shift or any shift behind itself in the order list. That means, for shift “A”, it can be followed by Shift A, N or

Off. And shift “Off” can be followed by any shifts.

•

The maximum number of consecutive night shifts (N) allowed = 3

•

The maximum number of consecutive working day allowed = 6

•

The maximum number of consecutive off day allowed = 3

•

The night shift (N) and day off (Off) should be evenly distributed.


8.4.5. Result

The scenario is solved using RosterBuilder and the GeneHunter in

Excel.

Result obtained by RosterBuilder

Result obtained by GeneHunter


The results from both systems are compared as follow:

RosterBuilder

(Stop if 5 feasible solutions found)

GeneHunter

(Stop if fitness not improved over 75 generations

Time used

Fitness

22 mins.53 sec. 8 sec.

10.7097 20005.9169

It can be seen that the result of RosterBuilder is much better than

GeneHunter, however, the time used in GeneHunter is much less than

RosterBuilder.

So, in order to have a better comparison, the GeneHunter is rerun with the stopping criteria being set to allow the running time similar to RosterBuilder. The result is shown as below


Time used

Fitness

RosterBuilder

(Stop if 5 feasible solutions found)

GeneHunter

(Stop if run for 23 mins)

22 mins.53 sec. 23 mins

10.7097 10002.9169

It can be seen that there is further improvement in the result from GeneHunter, however it is still far away from the result obtained by RosterBuilder.

Analyzing the results further as the table below, we found that the high score of the GeneHunter fitness is due to one “Shift Reversed

Order” exist in its result. “Shift Reversed Order” is highly unwanted because it means the rest time between two days of the staff cannot meet the requirement set by the regulations.

Demand Under

RosterBuilder Result GeneHunter Result

No No

Demand Over

Shift Reversed Order

Over Consecutive Night

Over Consecutive Work

Over Consecutive Off

No

No

No

No

No

No

Yes

No

No

No

8.4.5.3. Observations from the results

According to the comparison between RosterBuilder and

GeneHunter, we can say that RosterBuilder is better than GeneHunter in the sense that the results from RosterBuilder are promised to comply with the hard constrains, while results from GeneHunter are not, even the penalty for hard constrains are very high.


8.4.6. Sampling Strategies in RosterBuilder

To evaluate the performance of the three sampling strategies, the three sampling strategies are used to solve a smaller rostering problem with different configurations. The following index is used:

1.

Time used to discover the first one and first 5 solution.

2.

Time use to discover the first with different problem size

3.

The quality of the solution found.

8.4.7. Results

The results are shown as below:

1.

Time to discover the first one and first 5 solution.

Time used to discover solution in a 4 days roster

600

500

400

300

200

100

0

Linear Forward Multi-directions

Sa mpling Stra te gy

Genetic Algorithm

1st solution found first 5 solutoins found

2.

Time use to discover the first solution with different problem size

Running time vs Problem Size

10000

1000

100

10

1

0

0.1

0.01

1 2 3 4 5 6

Linear Forward

Numbe r of da y in roste r

Multi-directions Genetic Algorithm


3.

The quality of the solution found

Quality of the solution found

2.5

2

1.5

1

0.5

0

2 3

Numbe r of da ys in roste r

Linear Forward Multi-directions Genetic Algorithms

4

8.4.8. Observations from the results

Referring to the results obtained, the following points are observed.

1.

With the same problem size, “Linear Forward” is the fastest method to find solution. And “Genetic Algorithm” is the slowest.

2.

Increasing the problem size (number of days in roster),

“Genetic Algorithm” has the fastest increase in running time.

3.

“Genetic Algorithm” has the higher chance to get “good” solution comparing to the other 2 methods.

4.

The speed and solution quality of Multi-directions method lies between “Linear Forward” and “Genetic Algorithm”.

5.

The running time of all methods increase rapidly with the

Speed for 1 st

solution problem size (number of days in roster).

6.

Each sampling strategy has its own strength and weakness and are tabled below:

Linear Forward Multi-directions Genetic Algorithm

Fast Medium Slow

Quality of solution

Running time increase with problem size (comparatively)

Low Medium High small medium large


7.

Recommendations: Using the case base to store past result in the database, user can use the “Linear forward” or

“Multi-directions” to find the solution first, then use

“Genetic Algorithm” to look for better solution around the solution found.


9. Conclusion

9.1. Achievements

The characteristic of the problem being solved is analysed, a search on the literature is down to find possible solutions published are explored. After studied approaches have been tried in the field, a customized algorithm is designed using ideas obtained during literature review. The algorithm is adjusted and modified several times to improve its performance.

Having the algorithm defined, a rostering system, called

RosterBuilder, is built to implement the concepts. Before building the system, an Object Oriented system analysis and design is done by using UML and a database design is done by using ER diagram. The system is then coded using C# and the database is built using SQL server.

The functions of the system are tested with unit testing during development. And a integration use-case based testing has been done to verify the behaviour of the system as designed.

The performance of the system is evaluated using an evaluation scenario. The scenario is also run using another algorithm, the Genetic

Algorithm, which is commonly used in recent research. The results from two algorithms are compared and observations on the performance are noted.

To test the effect of sampling strategy, three sampling strategies are implemented and evaluated. The performances of the three implemented strategy is evaluated with different problem configuration.

Recommendation has been made on the use of different sampling stragegy.


With the result and observation in the evaluation, several further development areas can be suggested.

1.

Further reduction of the solution space size

In the algorithm presented in this paper, the size of the solution space is reduced by using the horizontal constrains to limit the choice of the rows. Although a large portion of rows are filtered using this method, the size of the overall solution space is still very huge. So, more constrains or methodology is needed to further reduce the size of the solution space. One of the possible directions is to filter the rows using the demand constrains. The idea is that if there is no demand for, say, D shift for the first day, any row having “D” in the first day can be ignored. Of course, further study on the details methodology and performance is needed before implementing the idea.

2.

Multi-skills consideration

In the system presented in this paper, skill is assumed homogeneous for staff. That means every staff has only one skill. The assumption is set solely because of simplicity. Since fitness function scoring is used in the system, multi-skills problem should be solved by redefining the fitness function. Of course more work is needed to verify this approach in multi-skills situation.


3.

Demand estimation

In current system, the demand - which is one of the critical factors to the problem - is entered by user. And users are assumed to be experienced to enter the correct demand input and they estimate the demand by their experience or memory. Actually, the staff demand in aircraft maintenance can be calculated by the pre-noticed work list. So, one of the valuable further development is to add demand estimation capability to the system.

4.

Reduce resources consumptions

In current system, large portion of system resources including

CPU time and memory are consummated even for generating a roster for only a few days. Due to the limited resource in the computer used for testing, roster with longer duration will result in lack of memory error. This is mainly caused by the tree representation of the possible row. Although tree already is an effective representation, it still consume a lot of memory if the tree is extremely large, which occurs in the case of long period roster. So, ways to further reduce the resources consumptions are needed.


References

[1] Michael Pinedo

Scheduling Theory, Algorithms, and Systems

Prentice Hall

Boston : Kluwer Academic Publishers, c1997.

An Introduction to Tabu Search

University of Montreal

[4] John M. Usher

Preliminary Review of the Airline Scheduling Domain

[5] NIKLAS KOHL, STEFAN E. KARISCH

Airline Crew Rostering: Problem Types, Modeling, and Optimisation

Annals of Operations Research 127, 223-257, 2004

[6] A.T. ERNST, H. JIANG, M. KRISHNAMOORTHY, B. OWENS and D.

SIER

An Annotated Bibliography of Personnel Scheduling and Rostering

Annals of Operations Research 127, 21–144, 2004

[7] Azmat, C.S., T. Hürlimann, and M. Widmer. (2004).

“Mixed Integer Programming to Schedule a Single-Shift Workforce under

Annualized Hours.”

Annals of Operations Research 128, Special Issue on Staff Scheduling and

Rostering, 199–215.

[8] Eitzen, G., G. Mills, and D. Panton. (2004). “

Multi-Skilled Workforce Optimisation.”

Annals of Operations Research 127, Special Issue on Staff Scheduling and

Rostering, 359–372.

[9] Alfares, H. (1988).

“Aircraft Maintenance Workforce Scheduling: A Case Study.”

Journal of Quality in Maintenance Engineering 5(2), 78–88.

[10] Dijkstra, M., L. Kroon, J. van Nunen, and M. Salomon. (1991).


“A DSS for Capacity Planning of Aircraft Maintenance Personnel.”

International Journal of Production Economics 23(1–3), 69–78.

[11] Kroon, L., M. Salomon, and L. VanWassenhove. (1997).

“Exact and Approximation Algorithms for the Tactical Fixed Interval

Scheduling Problem.”

Operations Research 45(4), 624–638.

“Algorithms Design Techniques and Analysis”

World Scientific

[13] Jawahar Puvvala and Alok Pota

“.NET for Java Developers”

Addison-Wesley

[14] John Sharp and Jon Jagger

“Microsoft Visual C# .NET”


10. Appendix

Period Task

September 2004 Background study

October 2004 Background study

Literature review

November 2004 Literature review

December 2004

January 2005

February 2005

March 2005

April 2005

Literature review

Define & testing solution model

Define & testing solution model

System Analysis and design

System Design & Coding

System Coding & Testing

Documentation

Report writing

Presentation preparation

10.2. Attachment CD content

•

Report Document (Acrobat PDF format)

•

RosterBuilder Source Code (Visual Studio Project Format)

•

RosterBuilder Database (Microsoft SQL server 2000 backup file)

•

GeneHunter testing spreadsheet (Microsoft Excel Format)

•

OS: Windows XP with .NET framework installed

•

Database: Microsoft SQL server 2000

•

PC running the application and the database server are connected in the same network.


1.

Restore the database backup in the CD (“\DB backup\”) to

Microsoft SQL server 2000 to a database named

“RosterBuilderDB”.

2.

Copy all files in the

“\samproject\RosterBuilder\RosterBuilder\bin\Debug\” folder to a new folder.

3.

In the new folder created, edit the “config.xml” file using text editor.

4.

Modify the string value between the <Database> and </Database> tags, change the sub-string “(local)” to the IP of the database server.

5.

Double click the RosterBuilder icon to start the program. Default login name and password are “Admin” and “123456”.


Department of Computer Science Dissertation in

City University of Hong Kong

Department of Computer Science

Dissertation

Rostering System for aircraft service industry

Lam Chi Wo

50447402

2004-2005

Supervisor: Dr. Andy Chun

Master of Science in

Computing

TABLE OF CONTENT

1. Introduction

1.1. Background

2. Project Aim & Objectives

3. Problem description

4. Literature Review

5. Algorithm Design

5.3. Problem solving approach

5.6. Evaluation

5.7. The overall algorithm

6. System Analysis

6.1. Basic system requirement

6.3. Use Cases analysis

6.5. Conceptual Class diagram

7. System Design

7.1. Design Class Diagram

Database Design

8. System Implementation

9. Conclusion

9.1. Achievements

References

10. Appendix

10.2. Attachment CD content

Related documents

Products

Support

Department of Computer Science Dissertation in

City University of Hong Kong

Department of Computer Science

Dissertation

Rostering System for aircraft service industry

Lam Chi Wo

50447402

2004-2005

Supervisor: Dr. Andy Chun

Master of Science in

Computing

TABLE OF CONTENT

1. Introduction

1.1. Background

2. Project Aim & Objectives

3. Problem description

4. Literature Review

5. Algorithm Design

5.3. Problem solving approach

5.6. Evaluation

5.7. The overall algorithm

6. System Analysis

6.1. Basic system requirement

6.3. Use Cases analysis

6.5. Conceptual Class diagram

7. System Design

7.1. Design Class Diagram

Database Design

8. System Implementation

9. Conclusion

9.1. Achievements

References

10. Appendix

10.2. Attachment CD content

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib