MSc Informatics Research Proposal. Human Resource Scheduling in Software Project. Gerhard Wickler Matriculation Number

Transcription

1 MSc Informatics Research Proposal Human Resource Scheduling in Software Project Name Hsueh-Hsing Chao Supervisors Paul Jackson Gerhard Wickler Matriculation Number Purpose The aim of this project is to develop a knowledge-based human resource scheduling system for software development industry. A software development project normally includes three stages: design stage, development stage and testing stage. Each stage needs different but related human resources to perform some tasks. The entire process moves from a stage to the next stage, when all tasks in the pervious one have been done. After three stages have all been completed, the final goal of a software project is reached. Like machine scheduling, free resources that are satisfied with the project requirements will be assigned into particular jobs. However, two main issues may arise from scheduling this special type of resources humans. Firstly, unlike a machine, which may only perform a particular type of jobs, the personnel in a software design firm often multi-disciplined. Some might only know one skill, some might have multiple skills, and few might be very versatile so understand all skills. Secondly, the performance of human resources is often variable. This instability makes the completion time of a task not decidedly predicable. To achieve the goal of this project, a list of major objectives are given below, and more detailed information will be provided in Section Ontology and System Design: Design the vocabularies and architecture of the system. 1.2 Data Modelling, Design and Development: Design and develop the components that will be used in this project, including, Project, Skill, Resource, Resource Pool and Workspace. 1

2 1.3 Simulator Design and Development: Design and develop the mechanisms that will simulate a software design firm that include project parser, project queue and system monitor. 1.4 Scheduler Design and Development: Design and develop the mechanisms of the scheduler, including task-and-resource matchmaker and resource allocator. And, it will first solve the problem of resources with multiple skills. 1.5 Scheduler Revision: Modify human resource to behave in unstable performance, and redesign the scheduler with rescheduling mechanism to solve the problem of human instability. 1.6 Leaning for Scheduling: Learning and measuring the performance of each human resource to tackle the problem of ability improvement. 2. Background Scheduling deals with the allocation of limited resources to tasks. A scheduling system provides a decision-making processing with the goal to optimise performance and some important objectives, for example minimising makespan, or the number of late jobs. The scheduling study and research can be dated back to 1950s [3], with researchers in various areas: operation engineering, industrial engineering, management, etc. A good scheduling algorithm in that period was only for reducing production costs. In the late 1960s, computer scientists started encountering scheduling problems due to the development of operating systems. Since the computational resources were very limited, lowering the time of computational programs with limited resources became a new key issue, which provided a reason for the study of scheduling. In past years, a substantial amount of scheduling research has been done in scheduling field. In all considered scheduling problems, the number of jobs and resources are assumed to be finite. The main factors in scheduling problems are processing time, release date, due date and weight of tasks. A scheduling problem is described within three fields: [3]. The field describes the environment. The field describes the details of processing characteristics and constraints. The field describes the objective to be minimised. In this project, the possible environment in the field are single machine, identical machines in parallel, machines in parallel with different speeds. And the possible restrictions and constraints in the field are release dates, preemptions, precedence constraints, machine eligibility restrictions and permutation. The possible objectives to be minimised in field are makespan, maximum lateness, total weighted completion time, total weighted tardiness and weighted number of tardy jobs. All the 2

3 above factors in,, will be taken into account. Resource constrained project scheduling problems (RCPSPs [6]) focus on resource problems. It involves assigning tasks to a resource or set of resource with limited capacity in order to meet some predefined objective. RCPSP problems can be classified into 6 classes: Basic Single-Mode RCPSP, Basic Multi-Mode RCPSP, RCPSP problems with Non-regular objective functions, Stochastic RCPSP, Bin-packing-related RCPSP problems and Multi-RCPSP problems. Scheduling criteria are the core of scheduling system. It states the desired objectives to be met. But, they are numerous, complex, and often conflicting [7]. Some commonly used criteria are [1]: minimize total tardiness, minimise the number of late jobs, maximise system/resource utilisation, minimise in-process inventory, balance resource usage and maximise production rate. A popular solution for scheduling is [4] branch-and-bound among enumerative techniques. The idea of branch-and-bound is to conceptualise the problem into a tree. Each node corresponds to a partial solution. From each node, a number of new branches continue to grow as possible decisions. The process stops, when no more branches can grow any further. And, these leaf nodes are solutions to the scheduling problem. And, all the possible solutions can be used in measuring the performance. These solutions can be estimated by Job Flow Time (time a job is completed minus the time the job was first available for processing), Average # Jobs (amount of work-in-progress), Makespan (the time it takes to finish a batch of jobs), Job Lateness (the job is completed ahead of, on, or behind schedule), or Job Tardiness (how long after the due date a job was completed). Dispatching rules are procedures designed to provide solutions for complex problems in real-time [2]. They have been classified, according to the performance criteria, into several classes. First class is priority rules, which are based on the priority factors related to the jobs, for example processing time, such as SPT (shortest Processing time) and WSPT (weighted shortest processing time) rules, due dates, such as EDD rule (Earliest Due Date), slack, such as S/OR (slack per reaming operations), and arrival time, such as FCFS (first come, first served). The second class consists of a combination of the rules from first class. For example, use the rule of SPT (shortest processing time) until the number of jobs exceeds 10, and then switch to FCFS. The 3

4 third class refers to the weight of jobs that contains more than one information about the relative importance to determine a schedule. The pervious works related to scheduling were mostly about machine scheduling, not human resource scheduling. Or, in other words, there are some scheduling systems about scheduling the timetable of human resources. But, every person in the system is treated as the identical resource, which is very rare in many practical cases. With uncertainty caused by human resources, such as with multi abilities, variable performance and gradual improvement, human resource scheduling system has to consider some problems that a machine will never occur. To tackle these problems we will introduce heuristic solution searching, rescheduling process, and learning mechanisms. Hopefully, this project can contribute its aspects to human resource scheduling. 3. Methods 3.1 Ontology Design Before starting the system design, an ontology will be defined as system vocabularies for this project. It will include four categories: Project,, Resource and Skill. With a meaningful number of attributes, the ontology can help the current system design and also further uses. 3.2 Data Modelling and Design. To development a human resource scheduling system, we will start from modelling and design of the essential components as follows. : A task is the smallest job component of a software project. A software project will contain some tasks assigned in each of three stages: design, development and testing. model includes Release Date, Due Date, Weight (the weight reflecting the importance and urgency of the task), Precedence Constraints (e.g. required skill), Process Time (the process time of the task on the particular resource), Percentage of completion (the proportion of the job being completed). Project: A project is a collection of tasks. A project includes Release Date, Makespan, List of s for each stage, Due Date, Deadline (the hard deadline must be respected), Weight, Process Time, Percentage of completion. Skill: A skill is an ability to determine what kind of tasks it can perform. A skill 4

5 includes the definition and the familiarity, etc. Resource: A resource is a person who knows several skills. A resource has a matrix in which skills and knowings with familiarities are matched. Resource Pool: A resource pool is an object container for all resources. A resource pool has a table reflecting the power and the availability of the entire pool of resources, which can be used to estimate the possibility of a project success. Workplace: A workplace is an object container for managing the ongoing projects and the resource pool. It also includes a runtime calendar, which indicates a simulated time in progress, and a queue with ready projects as a hypothesis input. 3.3 Simulator Design and Development The simulator of a software design firm will be built in order to simulate irregularly scheduled projects entering the company, and changes among projects, tasks and resources. Project Parser: Before starting designing the scheduler, we will define several types of hypothetic project data for system tuning and testing. A list of projects will be predefined within a text file. When the system is launched, the parser will read the data into a waiting queue. System Monitor: The changes of ongoing projects, tasks and resources have to be monitored in order to manage and maintain the system. 3.4 Scheduler Design and Development The next phase is the core phase of this project. The key mechanisms and the first version of the scheduler will be developed in this phase. A scheduler has three main functionalities as below. -and-resource Matchmaker: A matchmaking mechanism is for matching tasks with available and suitable resources. A task contains weight, due date, some constraints, etc. Because a resource includes its available skills and familiarity, Matchmaker is to weight both sides and search for the best matchmaking solution. A list of inference rules has to be defined for possible solutions and a decision tree (or alternatively a heuristic function) has to be developed for the best matchmaking. Resource Allocator: Resource allocator is to assign a resource into a particular task. Net linkages between tasks and resources will be created in this module. 5

6 3.5 First System Testing After all components and the scheduler have been developed as the figure 3.1, the end of this phase is to test the first version of the system. A human resource at this moment is actually defined as a machine but with multiple skills so the scheduler will be able to solve the problem of multiple skills. And, output results will be provided as a reference. March 2005 T W T S M F S Simulated Calendar Virtual Workplace Project Queue Ongoing Projects Project N Project 6 Project 5 Human Resource Pool Design Stage Design Stage Matching Scheduler Development Stage Development Stage Matching Resource Testing Stage Testing Stage Figure 3.1 System Structure 3.6 Scheduler Revision In this phase, we will start simulating one obvious human behaviour so the resource model has to be modified. Although the attribute, named familiarity, of a skill can indicate the performance of a resource when performing a particular task, it should not be fixed as a human does. It should work as a human that one s performance is randomly oscillating within an approximate range. And, this feature will break the first version of the scheduler as we expect. Output results will be provided again for a comparison. To tackle the instability problem of human resource, some mechanisms 6

7 will be either amended or added. The monitoring module will be altered to provide more information for the scheduler such as Lateness, Penalty of Lateness, Total Weighted Lateness, Total Weighted Penalty, etc. The rescheduling mechanism will be added into scheduler system. With the information provided by System Monitor, the rescheduling module will, based on different circumstances, change the resource allocation when the penalty gets higher. Thus, both Matchmaker and Resource Allocator will be modified. 3.7 Second System Testing The end of this phase is to test the second version of the scheduling system. A human resource now will work as our main issues: multiple skills and instability. The scheduler at this stage will be able to cope both problems. And, output results will be provided as a reference. 3.8 Optional Design Learning for Scheduling To more explicitly consider the characteristics of a human being. A human s ability is not only unstable but also improvable. In general, the performance of a particular skill of a person will be gradually improved. And, an unknown skill of a person is possible to be learned in the future. Human resource component, which is designed with fixed skills and unmoved familiarities, is actually unrealistic. One might say that, to schedule human resources, a real person who knows very well of everyone can take the responsibility of maintaining the system configuration. But, our goal is to design an automated scheduling system with as less as possible human involvement. Moreover, putting more efforts to develop a complicated, improvable and learnable human resource component will also mistake the aim of this project. Hence, we will not change the design of resource component, but we will hide the familiarity of each skill so the scheduler will not be able to retrieve the value of those attributes. Instead, to tackle this problem, the scheduler will retrieve the value from itself by learning from the past results as training examples (the results can be recorded by an electronic reporting system in the real world). So, if the project time is available, project and task recording module and a learning algorithm will be introduced into our system, and the system will work in an automated way without human supervision. 4. Evaluation The evaluation of this project will be based on experimental results. For the first 7

8 version of the system, the difference between our system and machine scheduling system is multiple skills. By feeding some predefined project samples, we will see the results of the system, and the output data will be provided as a proof. And after changing the human resource behaviour to be more human-like, we will see the system work with undesirable results, again which will be provided with some output data. And, by introducing the revision of the system design, coping with the new problems, we will expect to see the system work with better results. The last stage will introduce a learning mechanism to tackle the problem of human improvement. The results should not be worse than that in the previous stage, although we will not redesign the human resource with more and more sophisticated behaviour. 5. Outputs The outcomes of this project will be a prototype of a scheduling system, which will solve the problems of scheduling human resource. Humans often are often versatile so they can perform different tasks. The scheduling system first will solve this multiple skill problem. The performance of a human in most cases is variable. The scheduling system secondly will solve performance instability problem. Humans can learn new skills and the can also improve the performance of the skills. This causes a scheduling system has to heavily reply on data maintenance. Therefore, the scheduling system thirdly will solve the ability improvement problem. In this project, the development environment will be Java 1, Prolog 2 and Jasper 3 due to the consideration of multi-platform compatibility. 6. Workplan Please see the appendix. 7. References [1] Albert Jones and Luis C. Rabelo. Survey of Job Shop Scheduling Techniques. Natioinal Institute of Standards and Technology. [2] J. Blackstone, D. Phillips, and G. Hogg (1982). A state-of-the-art suvey of dispatching rules for manufacturing job shop operations. International Journal of 1 A platform-independent object-oriented programming language developed by Sun Microsystems. 2 Acronym for Programming in Logic, Prolog was designed for natural-language processing but has become one of the most widely used languages for artificial intelligence. 3 A bi-directional interface between Java and SICStus Prolog. 8

9 Production Research. [3] Michael Pinedo (2001). Scheduling Theory, Algorithms, and Systems. 2 nd Edition. Upper Saddle River, New Jersey, Prentice Hall. [4] N. Agin (1966), Optimum seeking with branch and bound. Management Science. [5] Prof. Dr. J. Kaschel, Dr. T. Teich, G. Kobernik, B. Meier. Algorithms for the Job Shop Scheduling Problem a comparison of different methods. Technical University Chemnitz, Germany. [6] Bibo Yang, Joseph Geunes and William J. O Brien (2001). Resource-Constrained Project Scheduling: Past Work and New Directions. Department of Industrial and Systems Engineering, University of Florida, Gainesville, FL. [7] S. French (1982). Sequencing and Scheduling. New York: Halsted Press. [8] T. Starkweather, D. Whitley and B. Cookson (1993). A genetic Algorithm for scheduling with resource consumption. Proceedings of the Joint German/US Conference on Operations Research in Production Planning and Control. 9

10 ID Name Start Finish 1 Preparation 2005 May May 31 2 Preliminary Research 2005 May May 31 3 System Design and Development 2005 June June 29 4 Ontology and Sytem Desgin 2005 June June 7 5 Data Modelling, Design and Development 2005 June June 14 6 Scheduler Design and Development 2005 June June 24 7 First System Testing 2005 June June 29 8 System Revision 2005 June July 20 9 Human Resource Behaviour Modification 2005 June July 1 10 Scheduler Modification 2005 July July Second System Testing 2005 July July Optional System Design 2005 July August 3 13 Learning from Past Projects 2005 July July Third System Testing 2005 August August 3 15 Documentation 2005 August August 25 June July August S /23 7 days 7 days 5 days 5 days 15 days 2 days 8 days 10 days 21 days 3 days 3 days 7/20 10 days 8/3 7 days 3 days 16 days Project: workplan Date: 2005 March 18 Split Progress Milestone Summary Project Summary External s External Milestone Deadline Page 1