Acknowledgements. Nella the checkout manager of Waitrose South Woodford who allowed me to use her Master Rotas.

Transcription

1 Summary Large supermarkets face big problems when creating checkout rotas for their staff. Many factors need to be adhered to whilst others can be broken. Currently rota creation is done by hand. Naturally this takes a long time and the results obtained would be far from optimal. This project looks at how the supermarket checkout staff rota problem can be modelled computationally and solved using algorithmic techniques based on mathematics. Once the algorithm has been applied an objective function is then used to measure the strength of the given solution. The question of why such a program has not already been written. Is it because no-one's tried writing one before, or because it would not be economically viable? i - -

2 Acknowledgements The person who I have to thank the most is Natasha my project supervisor who has tirelessly read copy after copy of drafts, provided much help and support and has generally been there to keep me going. Secondly my good friend TimE who was my Waitrose contact for the duration of the project without whom I may never have got the Waitrose Master Rotas. Thank you. Nella the checkout manager of Waitrose South Woodford who allowed me to use her Master Rotas. Drew for your support when no-one else understood. Hannah for putting up with my endless stream of work and often incorrect outbursts of 'This time it's gonna work!' Finally, thank you to Chris and Daniel for testing and feedback. ii - -

3 Contents 1 Introduction Project title Project aims and objectives Minimum requirements Further improvements Deliverables Methodologies Initial project schedule Relevance to degree program 4 2 Project Description Terms Problem description Input and output Schedules Objective function Comparing two schedules Constraints Typical values 12 3 The Solution Stage 1 - Fast heuristic Stage 2 - Local Search (move search) 16 4 The Program GUI Staff Details Rota Implementation of algorithms Testing Algorithm development Evaluation testing 28 iii - -

4 5.2.1 Objective function value for schedule provided by Waitrose South Woodford Objective function value for schedule provided by my software Analysis Evaluation Evaluation of solution Evaluation of project What I have learnt Enhancements Possible future enhancements to the project Possible future enhancements for a large IT solution 37 iv - -

5 Chapter 1 - Introduction 1.1 Project title IT Solution to a Supermarket Checkout Timetable. 1.2 Project aims and objectives To develop a piece of software that creates a weekly rota for checkout staff. The software should implement an algorithm that applies optimisation techniques to offer a better solution than can be provided by manual methods and in a much quicker time. To model the problem and design an algorithm that can be used to solve the problem quickly. To develop an object-orientated piece of software that uses this algorithm to give a graphical output useful to supermarket checkout management. To ensure the software can work with large quantities of data. To define an objective function that measures how well a solution conforms to a set of constraints. 1.3 Minimum requirements A fast heuristic solution. An algorithm that produces a schedule that satisfies all the major constraints commonly found in large stores, such as ensuring that a member of staff is not allocated to two different tills simultaneously. A method of calculating an objective function as a measure of how good the schedule is. A graphical interface (GUI) to display the input details and results of the algorithm. 1.4 Further improvements To use a local search algorithm to get an improvement on the original heuristic. To add features to the GUI to improve usability of the software, for example creating and deleting staff while the program is running. -1-

6 1.5 Deliverables An algorithm that schedules supermarket checkout staff to tills. A piece of software that implements this algorithm. A written report detailing my approach and solution to the problem. 1.6 Methodology A few different types of methodology are required for this project: Mathematical programming consisting of modelling, heuristic algorithm design and local search. Mathematical modelling is the process of analysing a problem to create a mathematical representation of the problem using variables and constraints. Once these have been assigned, an algorithm can then be designed to process the input data to create an output. Finally a local search can be applied to this data to try and find a better objective function. One such local search method is called iterative improvement. This takes a single node and offers it a neighbour which is only accepted if the neighbour provides a better objective function to the starting node. Tabu search works in a similar way but may allow a move to a 'worse' node by blocking certain moves that have already been visited. If only neighbours with a higher objective function are not blocked, the node is allowed to move to this 'best' of these 'worst' neighbours. This may not always be a downside though as this may often prevent becoming stuck in a local minimum. One potentially bad thing, according to Burke and Cowling (2001), is that tabu search algorithms are not robust enough to handle difficult problems well. This may cause a problem in my program as running times may spiral out of control if there are many staff with many shifts in the workforce and although running times may not be important, the machine running the program may run out of memory. For the purposes of the local search I want to implement, I will use iterative improvement as for the first iteration of the local search, I would want something that is quick to implement as proof of concept. The objective function will require some form of mathematical programming as it will provide a numerical representation of the strength of the output of the problem. For this I will mathematically define how the objective function is calculated from a given schedule. -2-

7 Another methodology that could be used is Branch&Bound, where each possible combination of staff on tills is applied to find the most optimal solution. This would have a huge running time on even a fairly simple problem with few tills and staff, so I do not feel this is the best solution to use. Many types of methodology can be used for the creation of good software. In modules studied in university I have covered the Waterfall Model and the Rational Unified Process (RUP) amongst others. The RUP is heavily based on UML and attempts to define an entire system so that the development of the software can occur more smoothly as it will have been properly defined. The Waterfall Model does not try to solve the entire problem in one attempt, but solves small parts of the larger problem with every iteration. As my program will have a small set of different tasks to achieve, I feel the Waterfall Model is best to use as it will allow the algorithms to be tested quickly to ensure they work properly, without having to wait for the entire GUI side of the program to be designed and built. 1.7 Initial project schedule Nov - Formulate specifications. Approach a company. Dec - Problem Modelling. Formulate an objective function using mathematical programming techniques. Construct a simple heuristic. Jan - Build simple GUI. Page to display input data. Pages to display output data. Feb - Produce an algorithm that gives a feasible solution satisfying major hard constraints. Begin testing using sample data. Suggest an idea for a local search. Mar - Solution which satisfies all hard constraints. Begin writing the final report. Apr - Implement algorithm within GUI and complete final report. Perform an evaluation by testing it against my initial sample data (and other chosen [likely] sets of data). If possible, I will try and get a photocopy of a rota used in a real life situation and provide my program with the input data and check how good the result is compared to that created by hand. -3-

8 Initially I decided to spend the majority of my time on the algorithm side as my project supervisor was an expert in this area and could provide me with a lot of guidance. I later changed my mind to work about 60:40 on the GUI and algorithm respectively as I wanted to build software which had more use than simply viewing the input and output data. 1.8 Relevance to degree program This problem involves mathematical analysis, an appreciation of algorithms and their design and the ability to combine these together into a functional resource. Over the course of three years studying Artificial Intelligence and Mathematics I have covered these topics in some detail, and have drawn upon this knowledge in my approach to the problem. -4-

9 Chapter 2 - Project Description My project is in the field of personnel scheduling, a field that has been widely studied in academia, largely in nurse roistering, and whilst many academic papers cover this field none apply directly to the problem of supermarket checkout staff. I therefore concluded that this is an area that would benefit from research. Having worked part-time in supermarkets over the course of four years, once as a checkout supervisor, I feel I have an understanding of the core ideals and regulations of staff allocation within this environment. The software's ultimate aim is to save time and money for large supermarkets. Many hours are wasted each week on the manual creation of checkout rotas that are often inefficient and are altered many times both before and during each working day. This can leave the paper form messy and illegible which can cause problems on the shop floor and when entering staff work hours into the pay system. The scheduling process has a number of 'hard' and 'soft' constraints. All 'hard' constraints must be met, whilst 'soft' constraints may be broken but should be adhered to as strongly as possible; the difference between 'hard' and 'soft' constraints is explained later. The creation of a rota by hand is difficult as minimisation of the constraints depends on the mental ability of the creator; the sheer number of combinations will overwhelm anyone attempting this and so a near-optimal solution is unlikely to be found. The system I am proposing will take the constraints into account and produce a weekly rota more efficiently and in less time than the equivalent 'manual' rota, with the added bonus of an objective function to measure the rota's suitability. One of the main advantages of this problem is its mathematical nature, in that solutions can be assessed using mathematical rules, which makes testing and evaluation much easier than using visual methods. 2.1 Terms Hard-coded I will use this to indicate data that cannot be changed while the program is running, nor very easily in the source code. Pre-coded Similar to 'hard-coded' in that the data cannot be altered at runtime, but can be changed easily in the source code. -5-

10 Tills Till status Indicates whether a till is broken and cannot be used. This falls outside the scope of my project but there is a possibility of it being used in future extensions of the program. Normal/Customer service (C/S) tills Customer service tills are able to perform the same operations as normal tills but have extra capabilities, meaning they require a more diverse skill set. Staff may be trained on one or both of these types of till and while staff trained to use 'C/S' tills are also able to work 'normal' tills, their job is specifically to work as 'customer service only' staff. Staff Workforce The set of all staff. Name Any rota requires that all staff have a distinct representation to prevent ambiguity; you shouldn't have two people with exactly the same name on one day's rota. If two staff within the workforce have the same first name, one or both of their names should be altered so they appear differently on the rota e.g. 'TimE' and 'TimR'. It is for this reason that I have chosen the staff name attribute to be the individual identifier. Lunch-relief 'Lunch-relief' staff work over the set lunch hours to cover tills when other staff are on their lunch break. They are not eligible for a lunch hour or any breaks. Normal till status C/S till status The staff member is able to work on a normal till. The staff member is able to work on a customer service till. Solo status This means the float in the till being used by this staff member must be checked at the start and end of each shift as the staff member is prone to losing money and their competence needs assessing. While this attribute works as part of the GUI as it provides useful information for the user, it does not currently affect the algorithm in any way. Time Time-slot Each day is broken down into small segments of time called 'time-slots'; these are stored in a 24-hour clock format (e.g. 9:00 as 9am and 15:15 as 3.15pm). The value of the timeslot indicates the start time of that slot. The duration of each time-slot is determined by the time at which the next time-slot begins with the exception of the last time-slot of the -6-

11 day which indicates both its start and end time. For the example, all time-slots will be precoded and cannot by changed whilst the program is running. Shift-times 'Shift-times' is the name given to the set of time-slots. Lunch hour For the example, lunch times are pre-coded as 11:00 12:00 and 12:00 13:00. Lunch hours must be continuous and all times have to appear in the list of time-slots as lunchrelief staff will use these times to cover tills. Staff eligible for lunch are those who start work on or before 11:30 and finish on or after 14:30, with the exception of lunch-relief staff who can work over these three hours and Sunday staff who are not entitled to a lunch. They will be allocated one of the available hours as time off and will not be paid for this hour. As these hours will change between branches, I will implement a way of changing these hours in the code. Breaks Break times are like lunch hour breaks, except they can happen at any time and are not a fixed length; the length depends on the age of the staff member and the start and finish times of their shift. While some code has been written to display lengths of break times, I will omit the business logic as it is outside the scope of the project as it would involve a lot of coding which I considered outside the scope of the project i.e. the break length depends on the age of the staff member, requiring a D.O.B. (date of birth) to be stored; it would also need a large number of 'if' statements such time spent on this trivial work could be better spent elsewhere, so I omitted this. A copy of the Waitrose 'break allocation time sheet' to give an idea of the break and lunch allowances available can be found in appendix 'I'. Contracted work times For non-lunch-relief staff, any of the time-slots can be selected as the start time of a shift except the last time-slot of the day the reverse is true for finish times where the first time-slot of the day cannot be selected obviously the only selection allowed is where the start time is earlier than the finish time. Lunch-relief hours are based on the pre-coded lunch hour slots, e.g. if lunches are from 11:00-12:00, 12:00-13:00 and 13:00-14:00, lunch-relief staff work from 11:00-14:00. Non-lunch-relief staff are free to start and finish any time that the store is open. Generally these times will occur 15 minutes past, half past, 45 minutes past or on the hour. Each time must be present in the shift-times, if not it can not be used at run time. -7-

12 Days Mon-Sat Monday Saturday all use the same time-slots and can have lunch-relief staff. Sunday As trading hours on a Sunday are restricted by law, there are many less time-slots used for this day and as such can be represented as a subset of the time-slots used from MonSat. Variables are used in the program to store the first and last time-slot of a Sunday; in the example program, the time-slots allowed lie from 10:45 17:15. Also, lunch-relief staff are not required as no-one is eligible for a lunch break. 2.2 Problem description Input and output Workforce, comprised of staff collected by the GUI and/or pre-coded Name Normal till status Customer Service till status Contracted work times Time Pre-coded Set lunch times Shift-times Tills Pre-coded Name (Hard-Coded) Status (broken/available) Quantity of normal tills Quantity of customer service tills The input data for evaluation of the project's output was provided by Waitrose, including the skill level and working times for each member of staff. The program needs to display this input data, process it and provide a graphical representation of the resulting schedule. This is not typical of normal input for a scheduling problem and as such adds another constraint for consideration within the problem. -8-

13 The output of the process will produce values for x ijkd where: i = the member of staff j = the till number k = the time-slot d = the day of the week If a member of staff 'i' is due to work on till 'j' at time-slot 'k' on day 'd', x ijkd = 1, otherwise Schedules A 'schedule' is defined as the output generated from the processing of the problem input. In order to store a schedule within the software, I will need to develop a way of representing the problem and solution on the computer. A 'schedule' is made by assigning staff to tills using the output from the algorithm: if x ijkd = 1, the staff member's name will be added to time-slot 'k' on the till 'j' of day 'd'. Once this has been done for all staff, tills, time-slots and days and the data has been stored in the schedule representation it can then either be shown graphically via the GUI or feasibility assessed by the following objective function Objective function The objective function provides a value which indicates how good a particular schedule is, with lower values being better and the lowest value possible as 0. This value depends on how well the constraints stated below are met. Constraints are split into two categories: 'hard' and 'soft'. If any 'hard' constraint is broken then the objective function value should be very high as this means a fault has occurred in the input data or solution process. For the 'soft' constraints, each value will be multiplied by a weight that will depend on how important each constraint is deemed to be. These weights should be easy to change. While there are just three 'soft' constraints, they cover everything necessary to obtain an optimal schedule if none are broken. 7 The calculation would therefore be wi f i where w 1,..., w 7 are weights specified by the user i=1 depending on what factors the user believes to be more important. I have chosen w 1=w 2=w3=w 4=1000 and w 5=w 6=w7=1 to ensure that hard constraints always result in a colossal (and therefore easily distinguishable) objective function. -9-

14 2.2.4 Comparing two schedules Given a schedule, its objective function value can be calculated as described above. When two schedules are compared, the schedule with the lowest objective function value is deemed to be the better schedule and if the same value is returned then the schedules are equivalent and either can be used Constraints Hard constraints must be met. They are constraints which have been put in place to ensure the algorithm works correctly i.e. if the algorithm works incorrectly the resulting values will not be 0. Reasons why this could happen could include the algorithm design or implementation being incorrect, or the sample data having errors e.g. two different staff being given the same name: Staff cannot work on multiple tills simultaneously. For each staff member, the number of tills they are working on over every time-slot is summed. f 1= { jmax 1 if x ijkd 1 for 0 otherwise j =1 i = 1,...,i max k = 1,..., k max d = 1,..., 7 Staff can only work for a limited period on Sundays (in larger stores) due to government regulations. For this example I have chosen the opening hours as 11am-5pm where 11am has time-slot 's' and 5pm has timeslot 'f'. 11am-5pm cover time-slots in the middle of the day so both earlier and later time-slots on a Sunday need to be kept free. f 2= { k =s 1 j max i max 1 if k max jmax imax x ijkd x ijkd 0 for d =7 k =1 j=1 i=1 0 k= f j =1 i=1 otherwise Normal tills should only be worked on by staff able to do so. Each Normal till will be checked against all staff assigned to it. For this example 'n' denotes the number of normal tills. f 3= { 7 k max n 1 if x ijkd 0 0 d =1 k =1 j=1 for i staff unable to use normal tills otherwise Customer Service tills should only be worked on by customer service trained staff

15 Each C/S till will be checked against all staff assigned to it. Again 'n' denotes the number of normal tills and 'c' denotes the number of customer service tills. f 4 = { 7 k max 1 if n c d =1 k=1 j=n 1 0 xijkd 0 for i staff unable to usec /S tills otherwise If the program had a way of setting tills to be broken, a further hard constraint would be to check that no staff are allocated on time-slots when a till is broken. There are also three soft constraints which are allowed to be broken however better schedules break these requirements to a lesser extent. The task therefore is to minimise the total number of times each constraint is broken: No two staff should be scheduled to work on the same till simultaneously (this is allowed, but should be kept to a minimum). For each till, at each time-slot, the number of staff scheduled to work should be totalled. If more than 1 member of staff is on the same till at the same time, the total number minus 1 is added to the overall total. f 5= { imax imax x ijkd 1 if i =1 0 xijkd 1 for j = 1,..., jmax i=1 otherwise k = 1,..., k max d = 1,..., 7 Staff should be spread evenly over tills to minimise the number of staff on each till each week. This is largely for financial reasons, e.g. if 100 goes missing, it is easier to guess who is responsible if only 2 people have used that till that week than if 20 people had used it. For each till, the total number of different staff scheduled to work on that till over the week should be calculated. The maximum difference between the lowest and highest value can be one. If the difference is over 1, the difference (minus 1) is returned. Let v [] = [ f 6= { 1 if 0 7 k max x ijkd 0 for i = 1,...,i d =1 k=1 otherwise { 0 if v max v min {0,1} v max v min otherwise max ] for j=1,... j max

16 Individual staff should work on as few tills as possible during one week (for similar reasons; each staff member will be less likely to be on a till that has 100 missing if they have only used one till that day). For each staff member, the number of different tills they are due to work on should be calculated. If this value is above 1, this value (minus 1) is added to the total. Let w = f 7 = { 7 k max 1 if x ijkd 0 0 d =1 k=1 otherwise for j=1,..., j max { 0 if w = 0 for i=1,..., i max w 1 otherwise Typical values Typically, stores will have between 10 and 30 normal tills, anywhere up to 5 or so customer service tills and may even have a variety of other types of till. My program, however, will only deal with the two most common types of till, normal and customer service tills. The program can work with any number of these, provided there is at least one of each. Time-slots will usually be either 15 or 30 minutes apart, depending on the time of day. I will allow uneven length time-slots to be used as this will reduce the number of time-slots required and therefore prevent unnecessary 'clutter' seen in the schedule, which would look worse when more time-slots are used: Example with minimal number of time-slots required:

17 Example with minimal all 15 minute time-slots: Sunday trading hours are restricted to 6 hours (for larger stores) but staff may be expected to start before the store opens or work after the store shuts, so there is no restriction on Sunday's first and last allowed shift-times other than that they are within Mon-Sat opening times. During busy periods, other (non-checkout) staff may be used on tills to ease congestion. I have decided that while this is an important factor to note, it would not affect the creation of the 'Master Rota' which uses initial conditions; I will therefore be ignoring this as it is outside the scope of my project

18 Chapter 3 - The Solution My solution will use an algorithm that schedules each day independently of the others then attempts to minimise the objective function on each day individually. This approach will require two processes, first a fast heuristic algorithm to quickly allocate staff to tills, then a local search in order to reduce the objective function as much as possible. 3.1 Stage 1 Fast heuristic I decided on a heuristic algorithm so a schedule could be obtained quickly. The algorithm detailed below is applied to each day separately. On calling the algorithm, the only parameter required is the day of the week to be processed. As there is little calculation to be made, I would expect this to work very quickly with large amounts of input data. Summary: 1. Keep lunch-relief staff separate. 2. Allocate all customer service only staff to C/S tills. 3. If any other staff are customer service trained, check if they can fill unused time on C/S tills. 4. Allocate the rest of the staff to the normal tills. 5. Allocate lunch breaks to staff requiring lunch. 6. Fill in gaps with remaining lunch-relief staff. In full: 1.1 Create a list 'L' of all staff due to work that day. 1.2 Remove all lunch-relief staff from list 'L' and put them on a new list 'Lr'. 2.1 As there are less customer service tills and generally less customer service trained staff, remove all customer service trained staff that are unable to work on normal tills from the list 'L' and order them in order of their start shift time in a new list 'Ls'. This ensures all customer service only trained staff are allocated to a till. 2.2 Take the first staff member from list 'Ls' and put them on the first available customer service till then remove them from the list 'Ls'. 2.3 Continue until list 'Ls' is empty

19 3.1 If not all the time-slots on the customer service tills are fully covered i.e. there are blank spaces, look for other C/S trained staff from the original list 'L' who are able to work at the necessary times and place them on the free till over the required time. This works by looking at staff that work for the exact time required on the C/S tills e.g. if a C/ S till needs covering from 5pm-8pm and a C/S trained staff is available over these hours they are allocated to the C/S till. 4.1 List all remaining members of non-lunch-relief staff in order of their shift start time. 4.2 Take the earliest available normal till (if there is a choice, choose the till with the lowest number) in relation to the start time of the first staff member in the list (i.e. time-slots before the starting time are not taken into account) and place them on this till. 4.3 Repeat until all staff have been allocated. 5.1 Allocate lunches - All staff that require a lunch are ordered by earliest starting times. Allocation of lunches will depend on the number of lunch slots available in the given store as each will have their own requirements. However, lunch breaks should be evenly allocated so, for example, say there are 5 staff requiring lunch and 3 lunch slots available then the earliest starting 2 staff would take the first lunch hour, the next 2 staff would take the second lunch hour and the 1 remaining staff would take the third lunch hour; the difference between the number of staff allocated on break x is never more than 1 different to y, when x!= y. A better solution would be to have a cleverer algorithm that would even out the number of staff left on tills over the lunch period, i.e. if there are more tills being used over the second lunch hour than the first, more lunch should be allocated during times when more tills are covered, leading to better usage of tills over both hours. 6.1 Cover lunches using lunch staff. For each lunch hour, use a clone of 'Lr' each time: Customer service tills are checked to see if they are free for the entire hour. If they are, a customer service trained staff from the list 'Lr' is placed on the till and removed from the list 'Lr'. If 'Lr' is not empty, all normal tills are checked in the same way. If 'Lr' is still not empty, create as many clones as there are time-slots in the hour and use for each time-slot: Customer service tills are checked to see if they are free. If they are, a customer service trained staff from the list 'Lr' is placed on the till and removed from the list 'Lr'

20 3.2 If 'Lr' is not empty, all normal tills are checked in the same way. Stage 2 - Local search (move search) The local search algorithm will take place after each new day is added, starting with re-arranging the most recent day added and working backwards towards the start of the week (as earlier days will already contain a better solution). This will hopefully find the best solution for the entire week, as previous days will already be optimal when the final day is added. In summary: 1. For each staff member, remove their shift from the schedule and place them on a different till. 2. Calculate the new objective function. 3. If it is better, the move is accepted and the algorithm repeats itself. 4. If it is not better, try the staff member on a different till and repeat step 2 do this until all tills have been tested. When there are no more tills to test, return to step 1. In full: 1.1 For each staff member, remove their shift from the schedule and temporarily place them on the first till instead. 2.1 Calculate a new objective function. If this value is better than the current objective function, the altered schedule is kept and the algorithm should then repeat itself from the beginning. If not, perform step Remove this temporary shift, put them on the next till and repeat step 2.1. If all tills have been tested, the process stops and step 1.1 continues with the next staff member. If, however, all staff members have been considered, the current schedule is deemed to be the optimal

21 Chapter 4 - The Program Java has a brilliant graphics API that can do everything I will need my program to do. Its main advantage over other programming languages is that the language is platform-independent so will run on any operating system. This is useful as there is no guarantee a user will be running Microsoft Windows. Java may not be the fastest at performing mathematical calculations given it is object based, but as my program is only a prototype to show that an IT solution to the problem is possible, running times are not too important. Either way, I do not expect running times to be long, even with a large input dataset. Having used Java to a large extent in the past, I feel the language is capable of achieving the goals of the project. As Java is an Object-Oriented language, I can take full advantage of this by creating different classes for the objects needed for the algorithm e.g. tills, staff etc. A time-slot is modelled as an array of staff names (ArrayList<String>) as this indicates which staff member is working at this time. A till is modelled as an array of time-slots (ArrayList<ArrayList<String>>) as each till can be worked on that many times in one day. A day is modelled as an array of tills (ArrayList<Till>). A week is modelled as an array of days (ArrayList<ArrayList<Till>>). This system makes it very easy to reference a particular day, till or time-slot, which in turn eases the programming complexity and should also make the program run faster. 4.1 GUI Each page can be viewed in one 'JFrame' using a tab system. A JFrame is a container in which other graphical objects can be placed:

22 There are 8 tabs in total; the first being the 'Staff Details' tab and the next 7 being each day's 'Rota'. The 'Staff Details' tab provides a place where the user can interact with staff on the system and 'Rota' tabs provide a place to view the details of that day's schedule (i.e. the results of the algorithm). Rota tab names are the days of the week. As Sunday is the first day of the working week, Sunday's tab is first, then Monday, Tuesday etc. through to Saturday Staff Details The Staff Details tab must have the following features: A table to display a list of current staff I decided that minimal information was required to save space. As first names are used as an individual identifier, I thought it best if a list of staff names were displayed. This seemed most logical to appear in a table, so I used a simple JTable (a Java table) combined with a JScrollPane to enable a scroll pane, to achieve this. The table has a known bug in that when the scroll bar appears, it covers part of the 'Surname' column, and includes the titles of the columns when scrolling. Entry fields for the details required by the Staff class (Name, Surname, Skills and Contracted Hours) These details are grouped into sections of similar importance 'name' and 'surname' are grouped as 'Personal Details', and 'Normal Till', 'C/S Till' and 'Solo' are grouped under 'Skills'. The shift time details are stored together under 'Contracted Hours'. By default 'Normal Till', 'C/S Till', 'Solo' and all lunch-relief states are pre-selected as 'No' to save time entering a new staff member. Buttons to create new staff, delete existing staff and to update the details of existing staff (and re-calculate the rotas). Buttons will only be 'enabled' when they can be pressed. When no staff are selected in the table (the default, as no staff are selected when the program starts), the button to add a new staff member reads Add to Workforce and the options to Update & Re-optimise and Delete from Workforce are disabled. When a staff member is selected in the table the two disabled buttons become enabled and the Add to Workforce button now reads Create New Staff. When Create New Staff is pressed, the screen is reset to the default

23 No staff are selected: I put the 'Personal Details' and 'Skills' on top of each other to keep the similar data next to each other creating a more pleasant experience for the user. The Staff Details tab must have the following functionality: To display details of current staff When a staff member is selected from the table, an ActionListener (a programming method for listening for events) is activated and displays the details of the selected staff member to appear in the appropriate fields, overwriting what was there before

24 Same screen as before, but now a staff member has been selected: Buttons Update & Re-optimise This button is used when a current staff member's details have been altered. If validation is passed the changes are saved in the instance of the Staff class and the rotas are updated given the new information, if the validation is not passed the button will do nothing. Delete from Workforce Can only be used only when a staff member has been selected from the table. When pressed, the selected staff member's details are removed from the system and the screen then resets to its default view

25 Add to Workforce / Create New Staff The text value of this button changes as described above. When the button reads Add to Workforce and is pressed, if the validation (described below) is passed the staff is added to the table of staff and the screen is reset. If the validation is not passed, the button will do nothing. Validation occurs when adding or changing staff details, it ensures the user has: entered a first name. put either 'Yes' or 'No' for 'Solo'. put either 'Yes' or 'No' for 'Normal Till' and 'C/S Till'. not put 'No' for both 'Normal Till' and 'C/S Till' (as this will mean the staff member cannot work anywhere). put either 'Yes' or 'No' for each day's 'Lunch Relief'. left the 'Start' and 'Finish' times blank if the 'Lunch Relief' for that day is 'Yes' (as lunchrelief staff have set hours). put both 'Start' and 'Finish' times as blank or both not blank if the 'Lunch Relief' for that day is 'No' (if they are both blank, the staff member is not working that day, if they are working, both the 'Start' and 'Finish' times need to be filled in) put a later 'Finish' time than 'Start' time if both fields are filled in. Rota Each Rota tab mush have the following features: The Rota, a grid (JTable) to display who is working where and when. The rota is made up of four parts: Slot times are located across the top (column names) with exception of the first column which says 'Till'. The first column is the till name, ranging from 1 to the number of tills available. Normal tills are grouped together (starting from till 1) and are followed by the C/S tills. There is no visual distinction between the two types of till as the user is expected to know how many different types of till there are. The output of the algorithm which indicates where and when each staff member will work. The more time-slots given, the more 'cramped' the rota will look as the width of each column has to be made smaller. A count of the number of tills being used over each time-slot

26 A Shift Details table to display information of all non-lunch-relief staff working that day. This table contains select data which is commonly required in a real situation. As the data is explicitly stated in one place, it makes the supervisor's job easier to search for the information. Details include the till the staff member is using (staff can only work on one till per shift), the start and finish times, how long the staff member is working, what types of till they can work on and if they are a solo worker. The table also shows if the staff member is due a lunch break, and if so, which lunch they are allocated for (1 is the first lunch, 2 is the second etc.); a number like this is sufficient as the user will know what times the number corresponds to. 'Break' is the only column not actively being used. I have put it in because in a real life situation it would be really useful to have each staff's break length already worked out. However this would have involved a lot of trivial coding for very little gain, so was considered outside the scope of the project

27 A Lunch Relief table to display information of all lunch-relief staff working that day. I separated the lunch staff from the rest of the staff as this is something I have seen on real life rotas; it also makes it quicker to find specific staff's information. The 'Lunch', 'Break' and 'Solo' columns are not required in this table, as any lunch-relief staff are not allowed a lunch or break and it is unlikely that a staff member who has a 'solo' status of 'Yes' will be allowed to work as lunch-relief. The final difference is the change from the 'Till' to the 'Till(s)' column, as lunch staff are able to work on more than one till in one shift. As lunch-relief staff are not needed on a Sunday, there is no need for this table on the Sunday tab. Each Rota tab must have the following functionality: Column widths must be editable. Given the (usually) large number of time-slots, none of the columns in the rota will be very wide (they will all start off the same width). It will sometimes be necessary to see all of the data in a particular slot, so the column widths should be changeable. Column width unchanged Column width changed When a staff member is selected in the Shift Details table, their time-slots are highlighted in the rota above. This currently highlights all time-slots from the start to finishing time-slot, so because of this it cannot be used with lunch staff, as they could be working on multiple tills (I could only find a way of selecting one series of cells in a programmable way)

28 4.2 Implementation of algorithms To aid debugging, the algorithms defined earlier had their own class in the program and worked using separate code. This meant each separate algorithm could be tested thoroughly without interfering with the others. It was also important that the software did not need to use the algorithm classes in order to compile as this way the GUI could be debugged separately. The Rota screens are re-created each time the algorithm is run, so the option to run the algorithm is only on the Staff Details screen. Input Data Screen Rota initiates creates Algorithm

29 Chapter 5 - Testing Testing occurred constantly throughout the development of the software. As each new method was added, a test was run to check that it worked correctly. This was especially true when building the algorithm classes as each part depended on the previous one working correctly. The majority of bugs were ironed out straight away, but some stayed until near the end of development when they were highlighted by a friend (another computing student and employee of Waitrose South Woodford) who tested the system I had built. On running tests on sample input data created by me, 'kris data', it was clear that the fast heuristic was not performing to a high standard. I decided that to improve the quality of the algorithm I would use the idea seen in the move search algorithm, where the objective function of each neighbourhood is calculated before deciding on the best location for a shift. The current heuristic allocates staff using a simple rule of first come first served, in that each till (in order) is tested to see if a new shift can be added, leading to high usage of tills 1 and 2 and less usage of the higher numbered tills. I also felt that the move search algorithm was not effective in performing its role. I decided to define the neighbourhood in a new way and use the algorithm once, after all shifts had been allocated, so that the objective function could not become higher. 5.1 Algorithm development The new heuristic works in a 'greedy' way and is therefore called the 'greedy heuristic'. Each time a new shift is added a range of objective functions are calculated by testing the staff member against all possible tills and allocating them to the till that provides the best result. This way a better objective function for the completed schedule should be seen as the overall objective function is minimised on every allocation rather than just at the end. This idea is seen in the iterative improvement methodology mentioned in section 1.6 of this document. Fast heuristic: New greedy heuristic: In the above test case which I ran, staff 'G' is moved to the second till in the new heuristic, giving a better objective function as staff are now more evenly spread over the tills

30 This heuristic has one downfall: as there are now significantly more calculations to be made each time a new shift is added, the running time has increased dramatically. However as my program is simply a prototype; running time is not overly important as long as it is not too excessive. This heuristic can be extended one step further by allowing shifts to be added in a variety of random orders as this will return a variety of objective functions, the best of which can be chosen. To test the new greedy heuristic, I used the same 'kris data' as I had used to test the fast heuristic: Fast heuristic: 10 (One staff per time-slot) 13 (Till variation) 30 (Staff over numerous tills) Total: 53 Greedy heuristic: 10 (One staff per time-slot) 9 (Till variation) 18 (Staff over numerous tills) Total: 37 Clearly the newer heuristic works better for this set of data so I tested both on the Waitrose sample data to formally assess the strength of the project's main output (coming next). The improved local search algorithm I called 'swap search'. It removes the failures of the initial local search algorithm. It occurs only when the final day has been added as this will ensure the resulting objective function can never be worse than the starting value. The order of days or shift swap tests are not important, but to keep things simple, the first day of the week is searched first, through to the final day of the week

31 In summary: 1. Find 'start' and 'finish' time-slots. 2. Find the next 'start' time-slot match and perform step Check to see if any matches occur in the 'finish' time-slots of these two tills. If there are none, go back to step 2. If there is a match, swap the staff onto the opposing tills and get an objective function. If the value is better than the current, keep the new schedule and go back to step 2, but reset the time-slot to If all time-slots have been checked and no lower objective function can be found the algorithm stops because the local minimum has been found. In full: 1.1 For each till on each day, create a list 'Sjd' of 'start time-slots' and a list 'Fjd' of 'finish time-slots'. 'Start time-slots' are defined as time-slots in which none of the people in that time-slot are in the time-slot directly before it. As the first time-slot of the day will always be a start time, this will always be a member of 'Sjd'. Similarly, 'finish time-slots' are worked out the same way, but instead checked with the time-slot directly after the time-slot in question. As the last timeslot of the day will always be a 'finish time', this will always be a member of 'Fjd'. Both 'Sjd' and 'Fjd' should include every empty time-slot. 2.1 For each time-slot of the day, see if the same start time appears on at least two different 'Sjd' lists i.e. check if time-slot 'k' is included in 'S1'; if it is, see if it is also in 'S2', then 'S3'... 'S7'. For any match, perform the algorithm below. 2.2 Once this has been done, or if 'S1' does not contain time-slot 'k', check if 'S2' contains time-slot 'k', and repeat the algorithm for any match with 'S3'...'S7'. Continue this until all combinations for all timeslots of that day are checked. 3.1 For the initial and subsequent time-slots in the first 'Fjd' list (as shift lengths may be for only one time-slot), see if the same time-slot value appears in the second 'Fjd' list. 3.2 For each match, check to see if all staff working between the two time-slots on the first till are able to work to work on the second till, and visa versa. 3.3 If they cannot, this is ignored and this loop should break (pass back to 2.1) as no swapping can be achieved. 3.4 If they can, the data is temporarily swapped and a new objective function is calculated. If this value is better than the current objective function, the altered schedule is kept and the time-slot being looked at in step 2.1 is reset to the first time-slot (the algorithm repeats itself)

32 4.1 If all time-slots have been tested and no better solution can be found, the process stops and the current schedule is deemed the local optimum. 5.2 Evaluation testing The main ideas and concepts for the project were taken from my practical experience as a checkout supervisor at Waitrose Buckhurst Hill, where I had to deal directly with the rota on a day-to-day basis. I made an assumption that all Waitrose stores and other major supermarkets had similar ideals and objectives to what I was used to. For evaluation testing of my software, I used real data in the form of one week's 'Master Rotas' provided by Waitrose South Woodford. These rotas are essentially the same as the output of my algorithm a model set of rotas that are deemed to have a low objective function. A copy of these rotas can be found in appendix B H. On receiving the data I noticed some fundamental differences between the way the rota was presented and calculated from what I was used to from my own experience. The main differences included the number of tills, the type of tills (there were more than just normal and CS tills), also lunch breaks were not explicitly scheduled and there was no mention of lunch-relief staff to cover lunches. On two occasions staff were working two shifts in the same day, and other staff had to work on both CS till then a normal till in the same day. With these differences in mind, I had to re-code the majority of my program to be able to adapt to some of the differences seen at this branch. While these differences were noted, on discussing my problem with the checkout manager at Waitrose South Woodford, it was clear that the overall objectives were the same as what I originally thought; so the objective function was still applicable and did not need to be altered in any way. Given the awkward shift arrangements that were not possible to use as input data for my program, I first needed to devise a way of using the test data effectively to obtain a sensible result that could be compared to an output of my algorithm. I decided to get an objective function value for just normal tills usage as this covered the largest number of staff. On the two occasions (on Friday) where the staff were allocated two shifts in one day, I removed one of the two shifts each staff member does (i.e. I omitted Leanne from 14:30 18:00 and Meena from 13:30 16:15). These changes now meant I could compare the results with no bias. A final point I had to consider was the calculation of f 5, the variable associated with more than one staff member using the same till at the same time. Currently the objective function value for this

33 is given by the number of time-slots that have more than one staff in them. This was originally because for the first iteration of the algorithm, each time-slot being the same length (30 minutes). Clearly, this is now not the best calculation to make, as not all time-slots may be the same length. So, for the purposes of this test, each 15 minutes of overlap counts as 1 objective function point, as 15 minutes is the shortest time-slot length Objective function value for schedule provided by Waitrose South Woodford This method uses empirical analysis of the real life data. Hard Constraints: It is assumed that staff can work on the tills they have been allocated to and that all other hard constraints are satisfied i.e. f 1= f 2= f 3= f 4 =0. Soft Constraints: 1. A till is used by one staff at a time. Six occasions were found when tills were staffed by more than one staff member: Tuesday, till 5 from 13:00 13:30. Wednesday, till 2 from 17:00 17:30. Wednesday, till 6 from 17:00 18:00. Wednesday, till 8 from 12:00 13:00. Saturday, till 5 from 14:00 14:30. Saturday, till 9 from 12:00 14:00. This totalled 4 hours and 30 minutes of overlapped time, giving f 5= Till variation. Till - Staff using the till 1 - Izzy, Anju, Diane, ElizabethC, Caroline, Nicki, Alice 2 - Issabell, Anju, Laura, Diane, Trudi, Michael, Janice, Lauren, Fiona, Alice, Charlotte 3 - Izzy, Issabell, JoeT, Joe, Ian, Kirsty, Charlotte 4 - Izzy, Beverly, Rebecca, Meena, Vanisha, Melissa, Lauren, Leanne, Caroline, ElizabethT, Connor, AlexK

34 5 - Beverly, Loveleen, Debra, Vanisha, AbigailT, ElizabethT, Vinnie, Vicky, Johanna 6 - Marilyn, Poonam, Catherine, Melissa, AbigailT, Nicki, Naomi, AbigailO 7 - Eleni, Sivanithy, Alexandra, Joe, Mikala, Peter 8 - Poonam, Meena, Sivanithy, Doreen, Elise 9 - Loveleen, Poonam, Meena, Ann, ElizabethC, Kirsty, Vinnie 10 - Poonam, Emily, Hayley Till 4 is the most used with 12 staff and till 10 is least used with 3 staff, giving f 6=9. 3. Staff using multiple tills. From the above tree, the value of f 7=26 can be calculated, using the usual rules. To conclude, given the weights are w 1=w 2=w3=w 4=1000 and w 5=w 6=w7=1, 7 wi f i = 53. i= Objective function value for schedule provided by my software The first task was to use the provided schedule to re-create the input data. This can be found in appendices 'J' and 'K'. On testing this data with the fast heuristic the objective function was comparable to a hand written solution. I realised there were two problems: one because of the large value of f 7 due to the initial idea that the algorithm should allocate staff to tills in a way which does not consider the objective function then let the local search attempt to improve on it; the second problem was that C/S tills were being considered when looking at differences between till usage. To make the test fairer, C/S tills should be ignored as they are not in use: for (int j=0 ; j<(main.getno_of_norm_tills()+main.getno_of_cs_tills());j++) should be changed to: for (int j=0 ; j<(main.getno_of_norm_tills()) ; j++) At this stage I used the improved greedy heuristic and whilst taking a longer time to compute, it reduced the objective function of the original heuristic algorithm by 63.3%

35 First heuristic: 4 1 slot overlapping lasting 30 minutes giving wi f i=0, i=1 f 5=2, f 6=12, f 7=35. 7 Total: wi f i = 49. i=1 Running time: < 1 second. Improved greedy heuristic: 4 1 slot overlapping lasting 30 minutes giving wi f i=0, i=1 7 Total: wi f i = 18. i=1 Running time: 14 seconds f 5=2, f 6=2, f 7=14.