Information Sciences 177 (2007) 23802401 www.elsevier.

com/locate/ins

Software project management with GAs

Abstract A Project Scheduling Problem consists in deciding who does what during the software project lifetime. This is a capital issue in the practice of software engineering, since the total budget and human resources involved must be managed optimally in order to end in a successful project. In short, companies are principally concerned with reducing the duration and cost of projects, and these two goals are in conict with each other. In this work we tackle the problem by using genetic algorithms (GAs) to solve many dierent software project scenarios. Thanks to our newly developed instance generator we can perform structured studies on the inuence the most important problem attributes have on the solutions. Our conclusions show that GAs are quite exible and accurate for this application, and an important tool for automatic project management. 2007 Elsevier Inc. All rights reserved.
Keywords: Automatic software management; Genetic algorithm; Project scheduling

1. Introduction The high complexity of currently existing software projects justies the research into computer aided tools to properly plan the project development. Current software projects usually demand complex management involving scheduling, planning, and monitoring tasks. There is a need to control people and processes, and to eciently allocate resources in order to achieve specic objectives while satisfying a variety of constraints. In a general way, the project scheduling problem consists in dening which resources are used to perform each task and when each one should be carried out. Tasks may be anything from maintaining documents to writing programs, and the resources include people, machines, time, etc. The objectives are usually to minimize the project duration, to minimize the project cost, and to maximize the product quality [4]. In an real project, the manager wants an automatic plan which will reconcile as far as possible these three conicting goals. Some work exists which proposes and discusses advanced management techniques [2,22] and tools [15,17] which can help software managers in their work. Computers are usually applied at several steps of the

Corresponding author. Tel.: +34 95213 3303; fax: +34 95213 1397. E-mail addresses: [email protected] (E. Alba), [email protected] (J. Francisco Chicano).

0020-0255/$ - see front matter 2007 Elsevier Inc. All rights reserved. doi:10.1016/j.ins.2006.12.020

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2381

software management process. We can nd expert systems to diagnose problems in software development [21], neural networks for deciding when to deliver software to the users [7], genetic algorithms for project scheduling [4], CASE tools for the knowledge management of software development [11], all of which together form a new eld of knowledge related to computer assisted project management. In this paper we focus on the Project Scheduling Problem solved with genetic algorithms [10]. The issues addressed are related to the time, human skills, budget, and project complexity involved. All of these issues make our study more dicult and nearer to actual software project planning scenarios. We rst dene an optimization problem to deal with the search for highly ecient management and propose the use of genetic algorithms to solve this problem [1]. With the proposed tool, a project manager can evaluate dierent scenarios in order to later be able to take decisions on the actual project itself. We perform some in silico experiments [25] based on several automatically generated project scenarios. The article is organized as follows. In Section 2 the Project Scheduling Problem is dened. Section 3 describes the genetic algorithms proposed and Section 4 discusses the representation of the individuals and the tness function, two very important issues when applying GAs to any problem. We use an instance generator to automatically create the dierent project scenarios, which is described in Section 5. Finally, the experimental study and results are presented in Section 6, and some conclusions and future work are outlined in Section 7. 2. The project scheduling problem (PSP) The PSP is related to the Resource-Constrained Project Scheduling (RCPS), an existing problem which has been extensively tackled in the literature using both exact techniques [6,19,24] and metaheuristic ones [12,18,20]. However, there are some dierences between PSP and RCPS. Firstly, in PSP there is a cost associated with the employees and a project cost which must be minimized (in addition to the project duration). Additionally, in RCPS there are several kinds of resources while PSP has only one (the employee) with several possible skills. We should notice that PSP skills are dierent from RCPS resource types. In addition, each activity in the RCPS requires dierent quantities of each resource while PSP skills are not quantiable entities. The problem as dened here is more realistic than the RCPS because it includes the concept of an employee with a salary and personal skills, also capable of performing several tasks during a regular working day. In [4] a genetic algorithm is used to solve this kind of problem with an approach which is similar to our statement. Let us specify the details of the problem tackled in this work. The resources considered are people with a set of skills, and a salary. These employees have a maximum degree of dedication to the project. Formally, each person (employee) is denoted with ei, where i ranges from 1 to E (the number of employees). Let SK be the set of skills, and si the ith skill with i varying from 1 to S jSKj. The skills of employee ei will be denoted with eskills  SK, the monthly salary with esalary , and the i i maximum dedication to the project with emaxded . Both the salary and the maximum dedication are real numi bers. The former is expressed in ctitious currency units, while the latter is the ratio between the amount of hours dedicated to the project and the full length of the employees working day. Let us consider an example to clarify the concepts. Let us suppose that we have a software company with ve employees. We need to perform a software application for a bank presenting the scenario shown in Fig. 1. In this gure we supply information about the dierent skills of the employees, their maximum dedication to the project at hand, and their monthly salary. For example, employee e2, who earns $2500 each month, is a database expert (s3), a UML expert (s4), and is able to lead a group of people (s2). Her/his colleague, employee e4, is also able to lead a group (s2) and, in addition, s/he is a great programmer (s1). These two employees and employee e1 can spend all of their working day developing the application (maximum dedication equal to one) but this does not necessarily mean that they do so. On the contrary, employee e3 can only dedicate half of her/ his working day to the project. There may be several reasons for this fact: perhaps the employee has a parttime contract, or s/he has administrative tasks to carry out in the company during part of the day. Employee e5 can work overtime, her/his maximum dedication is greater than one emaxded 1:2, and this means that s/he 5 can work on the bank application up to 20% more than in an ordinary working day. In this way, we can model the extra time of the employees, a fairly real world feature included in the problem denition. However, the project manager must take into account that an overloaded employee can increase her/his mistake rate and,

2382

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

Fig. 1. Possible sta of an example software company.

consequently, the number of errors in the software developed. This leads to a lower quality of the nal product and, possibly, to the need to correct or to re-develop the erroneous parts. In any case, the outcome may be an increase in the overall project duration. This does not aect the problem denition, it is a matter of psychology, but it is an important issue that project managers must take into account. Let us leave the example for a moment and study how the tasks of a software project are modelled. The tasks are denoted with ti, where i ranges from 1 to T (the number of tasks). Each task ti has a set of required skills associated with it denoted by tskills and an eort teffort expressed in person-month (PM). The tasks must be i i performed according to a Task Precedence Graph (TPG). This indicates which tasks must be completed before a new task is begun. The TPG is an acyclic directed graph GV ; A with a vertex set V ft1 ; t2 ; . . . ; tT g and an arc set A, where ti ; tj 2 A if task ti must be completed, with no other intervening tasks, before task tj can start. In order to continue with our example we show in Fig. 2 all the tasks of the software project in hand. For each task we provide information on the eort in person-month and the set of required skills. For example, task t1, which consists in creating the UML diagrams of the project in order to be used later by the employees in the following tasks, requires UML expertise (skill s4) and ve person-month. In the same gure we show the TPG of the project, drawing an arrow from task ti to task tj if the former must be completed before the latter starts. For example, after the UML diagrams of the application are completed (t1), both the design of the web page templates for the documentation of the application (t4) and the database

Fig. 2. Task precedence graph of the bank application.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2383

design (t2) can be started. However, these two tasks must be completed before the database design documentation is produced (t6). Our objectives are to minimize the cost and the duration of the project. The constraints are that each task must be performed by at least one person, the set of required skills of a task must be included in the union of the skills of the employees performing the task, and no employee must exceed her/his maximum dedication to the project. The rst constraint is necessary in order to complete the project: the project will not be complete if even one task is left undone. The third constraint is obvious after the denition of maximum dedication. However, more could be said regarding the second constraint and therefore we will deal with it below. At this point we can talk about the number of skills involved in a project. This number can be viewed as a measure of the degree of specialization of the abilities involved in the project. That is, the more skills, the more portions the abilities required to perform the whole software project must be divided into. In our example we could further break down some of the skills. For instance, we can divide the programming expertise into three skills: Java expertise, C/C++ expertise, and Visual Basic expertise. On the other hand, the number of skills can be viewed as a measure of the amount of abilities needed to carry out a project. One example could be developing software for controlling an airplane (large variety of skills needed) versus our bank application. Thus, in our model, the number of skills involved in a project has a dual interpretation in the real world: the degree of specialization of the abilities involved versus the amount of abilities needed to carry out the project. The correct interpretation depends on the specic project. From the project manager point of view, the skills assigned to each task and employee depends on the division of the abilities required for the project at hand. For example, we can do a very ne division of the abilities if our employees are very specialized (they are experts in very specic domains). In such a situation we have a lot of very specic skills involved in the project. Each task can require many of these skills and the employees may have a few skills each. In a dierent scenario, if our employees have some knowledge of several topics then we will have a few skills associated with vast domains. In this case, the number of skills required by the tasks is smaller than in the previous scenario. Once we know the elements of a problem instance, we can proceed to describe the elements of a solution to the problem. A solution can be represented with a matrix X xij of size E T where xij P 0. The element xij is the degree of dedication of employee ei to task tj. If employee ei performs task tj with a 0.5 dedication degree s/he spends half of her/his working day on the task. If an employee does not perform a task s/he will have a dedication degree of 0 for that task. This information is used to compute the duration of each task and, indeed, the starting and nishing time of each one, i.e., the time schedule of the tasks (Gantt diagram). From this schedule we can compute the duration of the project (see Fig. 3). The cost can be calculated after the duration of the tasks has been established, taking into account the dedication and the salary of the employees.

Fig. 3. A tentative solution for the previous example. Using the task durations and the TPG, the Gantt diagram of the project can be computed.

2384

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

Finally, the overwork of each employee can be calculated using the time schedule of the tasks and the dedication matrix X. In order to evaluate the quality of a given project management solution, we take three issues into account: project duration, project cost, and solution feasibility. To compute the project duration, denoted with pdur, we need to calculate the duration of each individual task tdur . This is calculated in the following way: j teffort j tdur PE j i1 xij 1

The next step is to compute the starting and nishing times for each task tstart and tend . At the same time (thus j j allowing our algorithm to have a reduced computational cost), the algorithm also calculates the project duration, which will be the maximum nishing time ever found. The project cost pcost is the sum of the fees paid to the employees for their dedication to the project. These costs are computed by multiplying the salary of the employee by the time spent on the project. The time spent on the project is the sum of the dedication multiplied by the duration of each task. In summary: pcost
E T XX i1 j1

esalary xij tdur i j

Now, we detail how the constraints are checked. In order to nd whether a solution is feasible, we must rst check that all tasks will be performed by somebody, i.e., no task is left undone. That is:
E X i1

xij > 0

8j 2 f1; 2; . . . ; T g

The second constraint of a feasible solution is that the employees performing one task must have the skills required by that task: [ tskills  eskills 8j 2 f1; 2; . . . ; T g 4 j i
fijxij >0g

Now, we can discuss the meaning of this constraint. Observe that, if a task requires a skill, the constraint demands that at least one person, not necessarily all of them, have that skill. This makes sense in some situations, for example when the skill is the capacity to lead a group of people and the task requires a single leader to be appointed. Hence, it is possible that one employee working on a task may have none of the skills specically required, or indeed no skills. In this way, we can model scenarios where some employees do not have the skills required of the task at hand, but they are in contact with and can therefore learn from other employees who have these skills. However, in some scenarios we need all the people working on a task to have a required skill. For example, coming back to our bank application we can require that all the employees implementing the application (t3) be expert programmers. To tackle this scenario we can allocate a dedication degree of zero on the task to all the employees without the required skill. In our particular case we can set xi3 0:0 for all employees ei without the skill s1, that is, e2, e3, e5. This means that the elements of the solution matrix with a zero value imposed are not considered when the optimization algorithm is applied, reducing thereby the number of problem variables. However, when the solution is evaluated a zero value is inserted in the corresponding positions of the matrix. According to the second constraint, the tasks requiring a skill which no employee has cannot be performed and the project cannot be nished. When this happens all the solutions proposed for the scheduling problem are unfeasible because they violate the second constraint. The project manager can solve this problem in several ways. Firstly, s/he can hire one or several new employees with the required skills. We can model this situation in our formulation of the PSP by enlarging the set of employees with the new ones. Furthermore, if the new employees are hired only to perform the task with the skill demanded we can set the degree of dedication of the new employees to zero for all the other tasks. A second solution to the problem consists in training some of the employees in order to obtain the required skills. In our model this solution is performed by adding new skills to the employees trained.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2385

t6

t4 t1 t2 t3 Time t5 t7

Fig. 4. Working function of employee e5 in our example.

Finally, in order to compute the overwork pover we need the starting and nishing times for each task, previously computed. For each employee ei we dene her/his working function as X ework t xij 5 i
fjjtstart 6t6tend g j j

If ework t > emaxded employee ei exceeds her/his maximum dedication at instant t. The overwork of employee i i eover is i Z tpdur over rampework t emaxded dt 6 ei i i
t0

where ramp is the function dened by  x if x > 0 rampx 0 if x 6 0

In Fig. 4 we illustrate the working function of employee e5 in our example. We have included the tasks that s/ he performs at any time. The bold line is the function ework t and the dashed line indicates the maximum dedi ication of the employee (1.2). When the working function passes above the maximum dedication there is overwork. The total overwork of the project is the sum of the overwork for all the employees, i.e. pover
E X i1

eover i

3. Genetic algorithms In this article we use a GA to solve the PSP, and thus a discussion of this kind of metaheuristic is appropriate in order to make this work self contained. Genetic Algorithms (GAs) are stochastic search methods that have been successfully applied in many search, optimization, and machine learning problems in the past [1]. Unlike other optimization techniques, GAs maintain a population of encoded tentative solutions that are competitively manipulated by applying some variation operators to nd a global optimum. To achieve this goal the problem variables are encoded (binary or oating point, for example) into what are called the chromosomes, which are merged and manipulated by the genetic operators to improve their associated quality (called the tness). Thus, one individual is composed of one chromosome and its associated tness, and the set of individuals forms the population used by the algorithm. Population-based algorithms contrast with trajectory-based ones (like simulated annealing) in that they search from multiple points at the same time, thus reducing the probability of getting stuck in local optima; in addition, they can oer multiple optima to the same problem, an interesting feature that the researchers can use to have an assorted set of solutions to the problems at hand. After creating an initial set of solutions (randomly or by using a seeding algorithm) GAs normally apply a crossover operation to combine the contents of two parents forming a new solution. This will be modied later by the mutation operation which alters some of the contents of the individual. Not all the individuals participate in the reproduction, only the ttest ones (elitism is very common) are selected from the population by a

2386

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

Fig. 5. Pseudocode of a genetic algorithm.

selection operator such as binary tournament (each parent is selected as the best of two randomly taken individuals). The operators are applied in a stochastic way, thus each one has an associated probability of application in the iterative loop (each step is called a generation). Usually, the best individuals in the present and the newly created generation are combined in order that the best ones can be retained for use in the next step of the algorithm (elitist replacement). The outline of a general GA is presented in Fig. 5. It begins by randomly creating a population P t 0 of l solutions (individuals), each one encoding the p problem variables, usually as a vector over B f0; 1g I Bplx or R I Rp . An evaluation function U is used to associate a quality real value to every solution. The stopping criterion i of the reproductive loop is to fulll some condition such as reaching a number of generations or nding a solution. The nal solution is identied as the best solution found. Metaheuristics and, in particular, GAs are not as intensively applied in the software engineering domain as they are in elds like engineering, mathematics, economics, telecommunications or bioinformatics [1,13]. However, the work of Clarke et al. [5] is a good reference for solving software engineering problems with metaheuristics. They identify three areas where the metaheuristics have been successfully applied: software testing, module clustering, and cost estimation. In software testing the approach adopted in the literature is the generation of test data with metaheuristics in order to detect faults in the software execution [14,16] or to nd out the worst case execution time of a code fragment [27]. For module clustering, the metaheuristic algorithms are used to get a partition of the system components into clusters with high cohesion among components in the same cluster and a loose coupling among dierent clusters [8]. Finally, in the cost estimation problem the goal is to estimate the eort needed to carry out a software project [3]. Clarke et al. point out other software engineering domains where metaheuristics could be applied: denition of requirements, system integration, maintenance, and re-engineering using program transformation. In fact, some applications of GAs exist concerning the software engineering experimentation [9], software integration [23], and software release planning [28]. 4. Representation and tness function In this section we discuss the solution representation and the tness function used in the genetic algorithm. As we stated in Section 2, a solution to the problem is a matrix X whose elements xij are non-negative. Here we have to decide how these elements are encoded. In this article we consider that no employee works overtime, so the maximum dedication of all the employees is 1. For this reason, the maximum value for xij is 1 and therefore xij 2 0; 1. On the other hand, we use a GA with binary string chromosomes to represent problem solutions. Hence we need to discretize the interval 0; 1 in order to encode the dedication degree xij. We distinguish eight values in this interval which are equally distributed. Therefore, three bits are required for representing them. The matrix X is stored into the chromosome ~ in row major order.1 The chromosome length is E T 3. x Fig. 6 shows the representation used.
1

We use ~ to refer to the chromosome (binary string) which represents the matrix solution X. x

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2387

Fig. 6. Representation of a solution in the genetic algorithm.

To compute the tness of a chromosome ~ we use the next expression x  1=q if the solution is feasible f ~ x 1=q p otherwise where q wcost pcost wdur pdur and p wpenal wundt undt wreqsk reqsk wover pover

10 11

The tness function has two terms: the cost of the solution (q) and the penalty for unfeasible solutions (p). The two terms appear in the denominator because the goal is to minimize them, i.e., maximize f ~ The rst term x. is the weighted sum of the project cost and duration. In this term, wcost and wdur are values weighting the relative importance of the two objectives. These weights allow the tness to be adapted according to our needs as project managers. For example, if the cost of the project is a primary concern, the corresponding weight must be high. However, we must take into account the order of magnitude of both the project cost and duration. This can be done by setting all the weights to one initially and then executing the GA several times. Next, the cost weight is divided by the average project cost and the duration weight is divided by the average project duration. In this way, the weighted terms related to project cost and duration are in the same order of magnitude. At this point, the project manager can try dierent weight values in order to adapt the solutions proposed by the GA to her/his requirements. The penalty term p is the weighted sum of the parameters of the solution that make it unfeasible, that is: the overwork of the project (pover), the number of tasks with no employee associated (undt), and the number of skills still required in order to perform all project tasks (reqsk). Each of these parameters is weighted and added to the penalty constant wpenal. This constant is included in order to separate the tness range of the feasible solutions from that of the unfeasible ones. The weights related to the penalties must be increased until a great number of feasible solutions is obtained. The values for the weights used in this work are shown in Table 1. They have been obtained by exploring several solutions and with the aim of maintaining all the terms of the sum within the same order of magnitude.
Table 1 Weights of the tness function Weight wcost wdur wpenal wundt wreqsk wover Value 106 0.1 100 10 10 0.1

2388

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

5. Instance generator In order to perform a meaningful study we must analyze several instances of the scheduling problem instead of focusing on only one, which could bias the conclusions. To do this we have developed an instance generator which creates ctitious software projects after setting a set of parameters such as the number of tasks, the number of employees, etc. An instance generator is an easily parameterizable tool which derives instances with growing diculty at will. Also, using a problem generator removes the possibility of hand-tuning algorithms to a particular problem, therefore allowing greater fairness when comparing algorithms. With a problem generator the algorithms can be evaluated on a high number of random problem instances, because a dierent instance can be solved each time the algorithm is run. Consequently, the predictive power of the results for the problem class as a whole is increased. In this section we describe the instance generator in detail. The components of an instance are: employees, tasks, skills, and the task precedence graph (TPG). Each of these components has several parameters which must be determined by the instance generator. There are two kinds of values to be generated: single numeric values and sets. For the numeric values a probability distribution is given by the user and the values are generated by sampling this distribution. In the case of sets, the user provides a probability distribution for the cardinality (a numeric value) and then, the elements of the set are randomly chosen from its superset. All the probability distributions are specied in a conguration le. This le is a plain text le containing attribute-value pairs. We can see a sample le in Fig. 7. Each parameter of the instance has a key name in the conguration le. These key names are included in Table 2. The value of a key name is the name of the probability distribution sampled to generate the value of the parameter. The probability distributions have param-

Fig. 7. A sample conguration le for the instance generator.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401 Table 2 Key names of the conguration le and their associated parameter Key name task.number task.cost task.skill employee.number employee.salary employee.skill graph.e-v-rate skill.number Parameter Number of tasks Eort of the tasks Number of the required skills of the tasks Number of employees Salary of the employees Number of skills of the employee Ratio edges/vertices of the TPG Cardinality of the skills set

2389

eters that are specied with additional key-value pairs of the form: hkey-namei.parameter.hparami = hvaluei. For example, the property employee.skill in the sample le of Fig. 7 indicates that employees have either 6 or 7 of the 10 possible skills (property skill.number). The instance generator reads the conguration le and then it generates the skills, the tasks, the TPG, and the employees, in that order. For each task, it generates the eort value and the required skill set. For each employee it generates the salary and the set of skills. The pseudocode of the instance generator is shown in Fig. 8.

Fig. 8. Pseudocode of the instance generator.

2390

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

The numeric values of an instance are: the number of tasks, the eort of the tasks, the number of employees, the salary of the employees, and the number of skills. The sets of an instance are: the required skills of the tasks, the skills of the employees, and the set of edges of the TPG graph. For the set of edges we do not specify a distribution for the cardinality directly, but rather for the ratio edges/vertices, that is, the generated numeric value is multiplied by the number of tasks in order to get the number of edges of the TPG. The maximum degree of dedication of the employees is not part of the instance itself, but a part of the optimization problem. This parameter can be dierent for each employee and it is established in the solver conguration le. For this reason the values for this parameter are not generated. A deeper description of the generator, and the program itself can be found at URL http://tracer.lcc.uma.es/problems/psp. In this work, we use the instance generator to study instances with dierent parameterizations, that is, different number of tasks, employees, and skills. The diculty of the instances depends on these parameters. For example, we expect the instances with a larger number of tasks to be more dicult than those with a smaller set of tasks, as in real world projects. This is common sense since it is dicult to do more work with the same number of empdoyees (without working overtime). Following this reasoning, when we increase the number of employees while maintaining the number of tasks we expect easier instances to emerge from the generator. However, these rules of thumb are hard to nd in complex projects like ours, because there are interdependencies of some other parameters which have an inuence on the diculty of an instance. One of these parameters is the TPG: with the same number of tasks, one project can be tackled by fewer employees in the same time as another project with a dierent TPG. On the other hand, if we compare instances with the same number of tasks we expect that, as the number of employees decreases, the project will last longer. However, with an increment in the number of employees we identify two opposite eects related to the cost: with more people working, operational costs rise; but at the same time the project duration and the expenditure are reduced. Hence, we cannot conclude anything about the project cost directly from the number of employees. With respect to the number of project skills, we expect instances which have a higher number of demanded skills to be more dicult to solve. With more skills, we have more specialized employees and we expect to need more employees to cover the required skills involved in a task. Hence, the employees work on more tasks and probably some of them may exceed their maximum dedication degree thus making the solution unfeasible. All these features make it very important for the project manager to have an automatic computer tool for taking decisions. 6. Experimental study and results For the experimental study we generated a total of 48 dierent instances with the instance generator and solved them with a genetic algorithm. We have grouped the instances into ve benchmarks. In the rst three groups we change only one parameter of the problem. With these studies we want to analyze how sensitive the results obtained are to the variation of these parameters. In the last two groups we change several parameters at the same time. In this way we study whether the results change in the way suggested by the studies of the rst three groups. To solve the instances, we use a genetic algorithm with a population of 64 individuals, binary tournament selection, 2-D single point crossover, bit-ip mutation, and elitist replacement of the worst (steady-sate genetic

Table 3 Parameters of the GA GA parameters Population Selection Recombination Mutation Replacement Stop 64 2-tournament (2 inds.) 2-D SPX Bit-Flip (1/length) Elitist 5000 steps

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2391

Fig. 9. 2-D single point crossover.

algorithm). The stopping criterion is to reach 5000 steps of the main loop (5064 evaluations). We performed 100 independent runs for each instance. In Table 3 we summarize the GA parameters. The 2-D single point crossover [26] is an unusual recombination operator applied to matrices. It randomly selects a row and a column (the same in the two parents) and then it swaps the elements in the upper left quadrant and in the lower right quadrant in both individuals (Fig. 9). In the following subsections we present the studies performed and the results for all the identied benchmarks. 6.1. First benchmark: changing the number of employees The rst step is to study the inuence which the number of employees has on the solutions. We use four dierent instances of the problem with the same software project, i.e., they have the same tasks and the same TPG. The only dierence in the instances is the number of employees. The maximum dedication and the salary of the employees is also the same. In addition, the constraint related to the skills is not taken into account. That is, all the employees have the necessary skills to perform any given task. This situation has been modelled by introducing only one skill and providing all the employees with that skill. All the instances are based on the same software project with 10 tasks, thus, the total work to be done is always the same. For this reason we expect the project duration of the solutions proposed by the genetic algorithm to decrease when the number of employees increases. More precisely, the project duration and the number of employees must have an inverse relationship and their product must be constant. In Table 4 we show the results obtained with four dierent numbers of employees: 5, 10, 15, and 20. For each case we present the hit rate (percentage of runs getting a feasible solution), the average duration of the feasible solutions proposed, and the product of the number of employees and the average project duration in months. We observe in the results that the hit rate decreases when the number of employees increases, that is, the problem becomes more dicult when we increase the number of employees. One would have imagined that with more employees it would be easier to nd a solution for the problem. However, in this situation the third constraint (requiring no overwork) is more dicult to satisfy. At the same time, the search space is larger and this does not help the search process. As we predicted before, the project duration decreases when the number of employees increases. In fact, the product of the number of employees and the average duration is very similar for the dierent instances (fourth column). However, it increases slightly with the number of employees for the same reason as the hit rate is reduced: the instances are more dicult for the GA. The cost of the software project is exactly the same in all the solutions because all the employees have the same salary, that is, the cost of a one person-month is xed throughout all the instances. 6.2. Second benchmark: changing the number of tasks Now we study the inuence of the number of tasks on the solutions. We solve three instances where we maintain the employees and we change the software projects. In particular, the three software projects have
Table 4 Results obtained when the number of employees changes Employees 5 10 15 20 Hit rate 87 65 49 51 Avg. duration 21.88 11.27 7.73 5.88 Avg. E pdur 109.40 112.70 115.95 117.60

2392

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

Table 5 Results obtained when the TPG changes Tasks 10 20 30 Hit rate 73 33 0 Cost 980,000 2,600,000 Avg. duration 21.84 58.29 Avg. pcost =pdur 44,944.33 44,748.35

a dierent number of tasks: 10, 20, and 30. As in the previous benchmark, all the employees have the same salary and maximum dedication. For this reason all the solutions for the same project have the same cost. Since we use the same probability distribution in order to generate the cost of the project tasks in the three projects, we expect an increase in the project cost with an increase in the number of tasks. In addition, we do not consider the second constraint, so we expect a proportional relationship between the duration and the cost of the projects. Furthermore, if all the employees are working all the time for the project, the ratio between the cost and the duration must be exactly the sum of the salary of the employees. In the instances there are ve employees with a monthly salary of $10,000, so the cost-duration ratio must be nearly $50,000. We present the results of the three instances in Table 5. We show the hit rate, the project cost in dollars, the average duration in months of the feasible solutions proposed, and the average cost per month of the projects in dollars per month. From the results we observe that the problem becomes harder when the number of tasks increases. In fact, the genetic algorithm is not able to obtain any feasible solution for the software project with 30 tasks. The reason for this behavior is the same as in the previous benchmark: when the number of tasks increases it is more dicult for the GA to get a solution satisfying the overwork constraint. We also observe that both the cost of the projects (third column) and the project duration (fourth column) increase with the number of tasks. The cost per month of the project (fth column) is nearly $50,000 in the two cases as we predicted. This parameter cannot be greater than $50,000 because this implies a violation of the overwork constraint. When the value of this parameter is near the optimal one ($50,000 in our case) this means an ecient allocation of employees to tasks. We conclude from the results that the allocation gained for the 10 tasks instance is more ecient than that obtained for the 20 tasks one. We can explain this result with the increase in the search space when shifting from 10 to 20 tasks. 6.3. Third benchmark: changing the employee expertise In this section we study how the number of skills per employee, i.e., the expertise of the employees, inuences the results. We solve ve instances with the same software project and the same number of employees. The employees all have the same monthly salary and the same maximum dedication. Instances dier from each other in the employee skills. We analyze ve dierent values for the number of skills of the employees: 2, 4, 6, 8, and 10. The employee skills are randomly selected from the set of 10 project skills. All the tasks require ve dierent skills. We present the hit rate, the average duration of the projects, and the average cost per month in Table 6. We observe that the problem is harder to solve with a lower number of skills per employee, that is, if the expertise of the employees is low, it is more dicult to allocate them to the tasks without violating the skills constraint (the second one). We can also notice that the average project duration obtained in the dierent
Table 6 Results obtained when the number of skills per employee changes Skills 2 4 6 8 10 Hit rate 39 53 77 66 75 Avg. duration 21.71 21.77 21.98 22.00 22.11 Avg. pcost =pdur 45,230.15 45,068.64 44,651.28 44,617.02 44,426.90

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2393

instances remains almost constant with a slight increase for higher values of the employee expertise. This means that the GA is able to allocate the employees to the tasks in a more ecient way when the level of employee expertise is lower. The reason is that the feasible region of the search space is enlarged when the employees have more skills, and therefore the average quality of the solutions included in the feasible region decreases. 6.4. Fourth benchmark: expertise specialization xed We include in this group 18 dierent problem instances generated by the instance generator. The instances include dierent software projects and they dier from each other in all the previously studied parameters. In particular, we assign dierent values to the number of employees, the number of tasks, and the number of employee skills. The number of dierent skills of the project is set to 10 in all the instances. The number of employees can be 5, 10, or 15 and the number of tasks 10, 20, or 30. Two ranges of values are considered separately for the number of skills of the employees: from 4 to 5, and from 6 to 7. As in the previous benchmarks, the maximum dedication for all the employees is 1.0 (full working day). We show in Table 7 the hit rate for all the instances (from 100 independent runs). From these results we can conclude that the instances with a larger number of tasks are more dicult to solve than those with a smaller set of tasks, as we concluded in Section 6.2. In the second row of results, we observe an inverse relationship between the number of employees and the diculty of the problem. This contrasts with the results of the rst benchmark (Section 6.1). What is happening? The main dierence between the two cases resides in the skills. In the rst benchmark the skills constraint was not considered whereas in this case it is. When the number of employees increases, it is more dicult to fulll the overwork constraint but it is easier to fulll the skills constraint because the sta is highly skilled. These two trends are in conict with each other, but in this case the second one seems to be predominant. In order to better illustrate the meaning of these results we plot the solutions obtained in a graph showing their cost versus their duration (Figs. 10 and 11). Cost and duration are clear tradeo criteria in any project. This is the kind of graph that a manager would like to see before taking any decision on the project. We have put a label htasksi-hemployeesi near the solutions of the same instance. In the gures, the solutions of the instances can be seen as point clusters. Their elongated form depends on the scale of the axis (chosen to maintain the solutions of all the instances in the same graph), however we can appreciate a slight inclination of the clusters showing the tradeo mentioned between cost and duration: when the cost of a solution is lower, its duration is longer. As we expected, when the number of employees decreases for a given number of tasks, the project lasts longer. This observation is maintained despite each point cluster representing a dierent instance with dierent TPG. In the gures, we can observe that a larger number of employees does not necessarily mean a more expensive project in all the cases. However, we cannot obtain any fundamental conclusion on this fact because the instances belong to very dierent software projects. 6.5. Fifth benchmark: employees expertise xed In this nal benchmark composed of 18 instances we study the inuence of the number of dierent skills on a project. This will shed some light on existing large companies where an assorted set of persons of varied
Table 7 Hit rate for the fourth benchmark 45 Skills Employees Tasks 10 20 30 5 94 0 0 10 97 6 0 15 97 43 0 67 Skills Employees 5 84 0 0 10 100 76 0 15 97 0 0

2394

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

30

2010

25

Duration

20
105 2015 1010

15

10

1015

5 0.5

1.5

2.5 x 10
6

Cost

Fig. 10. Results with 45 skills per employee. Labels show the number of tasks and employees of the instance.

35

30

2010

25

Duration

20

105

15

10

1010 1015

5 0.5

1.5

2.5 x 10

3
6

Cost

Fig. 11. Results with 67 skills per employee. Labels show the number of tasks and employees of the instance.

experience are to be optimally assigned to software projects. In this case we x the range of the number of skills per task and employee from 2 to 3. The number of tasks can be 10, 20, or 30 and the number of employees takes values 5, 10, and 15 as in the previous benchmark. The number of dierent skills is either 5 or 10. In Table 8 we show the results. As in the previous subsection we can see that an increment in the number of tasks means an increment in the diculty of the problem. The participation of more employees usually implies a decrement in the diculty of the instance (it is easier to manage the project). However, we can now conclude one additional fact: we conrm, as expected, that a larger number of demanded skills makes the instance more dicult (in general) to solve.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401 Table 8 Hit rate for the fth benchmark 5 Skills Employees Tasks 10 20 30 5 98 6 0 10 99 9 0 15 100 12 0 10 Skills Employees 5 61 8 0 10 85 1 0

2395

15 85 6 0

From Figs. 12 and 13 we conclude that the cost of the project increases with the number of tasks, and the duration of the project decreases with the increment in the number of employees. This was also observed in the previous benchmarks. However, with more employees, the overall cost of the project is reduced in all cases, a fact that was not observed before (only similar to 1015 and 2015 in Fig. 10). Previously we argued that different instances use dierent projects and for this reason we cannot obtain any denitive conclusion. Here, we are in the same situation but analyzing the particular solutions of the instances we observe that with a larger number of employees all of them work on all the tasks at a low degree of dedication. In this way, the tasks are performed more quickly and the global cost of the project is lower. 6.6. Further understanding of the dynamics of our algorithm In order to end our presentation of results we plot the average best tness evolution of some instances in the 100 runs. Our goal is to present a trace of the search performed by the GA. In Fig. 14 on the left we can see the evolution of the instances with 10 tasks and 5 skills: the nal average best tness increases with the number of employees. With a larger number of employees the algorithm can compute a more ecient scheduling reducing the duration and/or the cost of the project, which in turn increases the tness value of the solutions. This trend can also be observed in Fig. 14 on the right for the 10-tasks/10-skills instances. In Fig. 15 we plot the evolution of the average best tness for the instances with 10 tasks, 10 skills, and 45 and 67 skills per employee. In this case the relationship between the tness and the number of employees is

70

60

205

50

Duration

40

30

2010

20

105

2015

10 0 0.6

1010 1015

0.8

1.2

1.4

1.6

1.8

2.2 x 10
6

Cost

Fig. 12. Results with ve skills. Labels show the number of tasks and employees of the instance.

2396

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

50

40

Duration

30
2010 105

20
2015

10
1015

1010

0 0.5

1.5

2.5 x 10

3
6

Cost

Fig. 13. Results with 10 skills. Labels show the number of tasks and employees of the instance.

0.8 0.7 0.6 emp15

0.7 0.6 emp10 0.5 emp10 emp15

Fitness

Fitness

0.5 0.4 0.3 0.2 0.1 0 0 1000 2000

0.4 0.3 0.2 0.1 0 emp5

emp5

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

Generation

Generation

Fig. 14. Average best tness evolution of the instances with 10-tasks/5-skills (left) and 10-tasks/10-skills (right). The label empi identies the instance with i employees.

not so clear. However, we can notice that for the instances with 10 and 15 employees the number of skills per employee signicantly aects the best attained tness: with 67 skills per employee the best tness is higher than with 45; i.e., a varied and larger set of skills can be proted from if an automatic tool such as ours is used in project management. This is in accordance with the idea that more qualied people do the work better. However, this trend was not observed with ve employees, meaning that even ecient people need a group of help in real world projects. The two nal plots (Fig. 16) show the evolution in the instances with ve skills and 20 and 30 tasks. Note in the right plot that the instances have a quasi-logarithmic evolution with a very low tness. The algorithm fails to nd a feasible solution for these instances and all the individuals are then penalized, thus keeping their tness values below 0.01.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2397

0.7 0.6 emp10 0.5 emp15

Fitness

Fitness

0.3 0.25 0.2 0.15 0.1 0.05 0 0 1000 2000

0.4 0.3 0.2 0.1 emp5

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

Generation

Generation

Fig. 15. Average best tness evolution of the instances with 10-tasks/4-5-skills per employee (left) and 10-tasks/6-7-skills per employee (right). The label empi identies the instance with i employees.

0.045 0.04 0.035 emp15

9.8 9.6 9.4

x 10

emp15 emp10

Fitness

Fitness

0.03 0.025 0.02 0.015 emp5 0.01 0.005 0 1000 2000 3000 4000 5000 6000 emp10

9.2 9 8.8 8.6 8.4 8.2 0 1000 2000

emp5

3000

4000

5000

6000

Generation

Generation

Fig. 16. Average best tness evolution of the instances with 20-tasks/5-skills (left) and 30-tasks/5-skills (right). The label empi identies the instance with i employees.

7. Conclusions In this work we have tackled the general Project Scheduling Problem with genetic algorithms. This problem is essential for the software engineering industry nowadays and automatically nding good solutions to it can save software companies lots of time and money. A software manager can study dierent scenarios with such an automatic tool in order to take appropriate decisions on the best project for her/his company. Furthermore, in our approach, s/he can adjust the tness weights to better represent particular real world projects. The Project Scheduling is a combinatorial optimization problem and an exhaustive search can take too much time to get a solution. Here, as in some other work [4], the utility of metaheuristic techniques for the problem is clearly stated. Our contribution to the software engineering management is an automated tool based on genetic algorithms that can be used to assign people to the project tasks in a near optimal way, trying dierent congurations concerning the relative importance of the cost and duration of the project. Although the project model is very simple it can serve as a rst step in the application of evolutionary algorithms to the in silico experiments in software engineering. We have used a genetic algorithm, and have performed an in depth analysis with an instance generator. We have solved 48 dierent project scenarios and performed 100 independent runs for each test in order to get

2398

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

statistically meaningful solutions. The results show that the instances with more tasks are more dicult to solve and their solutions are more expensive. In the same way, the projects with a larger number of employees are easier to tackle and can be led to a successful end in a shorter time. However, the relationship between employees and cost is not so simple: in some cases it is direct and in other cases it is inverse. In the future we plan to add new instances with additional aspects to study the inuence of the instance parameters on the diculty, such as the complexity of dealing with a large team or the overhead of assigning a large set of tasks to an employee. Also, we will solve the problem with other metaheuristic algorithms. In particular, we can directly apply multiobjective metaheuristic algorithms to optimize the two objectives tackled in the work (duration and cost of the projects). In addition, we plan to apply our algorithms to real world data in order to illustrate how to use the techniques in a real software project. Finally, we will extend the model to face real world problems from industry, once we know which are the best techniques to apply (the goal of this initial study). Acknowledgements This work has been partially funded by the Ministry of Science and Technology (MCYT) and Regional Development European Found (FEDER) under contract TIN2005-08818-C04-01 (the OPLINK project). Francisco Chicano is supported by a grant (BOJA 68/2003) from the Junta de Andaluca (Spain). We also thank to Guillerme Horta Travassos for easing the access to several publications and to an anonymous review for her/his constructive comments. Appendix A. Average best tness evolution plots In this appendix we include the evolution of the average best tness in the instances of the last two benchmarks. We decided to include this appendix to oer an in depth view of our results that could be interesting for

0.8 0.7 0.6 emp15

0.7 0.6 emp10 0.5 emp15

0.5 0.45 0.4 emp5 emp15

0.7 0.6 emp10 0.5

Fitness

Fitness

Fitness

0.5 0.4 0.3 0.2 0.1 0 0 1000 2000

0.4 0.3 0.2 0.1 emp5

0.3 0.25 0.2 0.15 0.1 0.05

Fitness

emp10

0.35

emp15

0.4 0.3 0.2 0.1 emp5

emp5

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

Generation
0.045 0.04 0.035
emp15

Generation
0.028 0.026 0.024
emp15

Generation
0.12 0.1
emp15

Generation
0.14 0.12 0.1

Fitness

Fitness

0.03 0.025 0.02 0.015

Fitness

Fitness

0.022 0.02 0.018 0.016 0.014 0.012 0.01 1000 2000 3000 4000 5000 6000 0.008 0 1000 2000 3000 4000
emp5

0.08 0.06 0.04 0.02 0

0.08 0.06 0.04 0.02 0 0 1000 2000

emp10

0.01 0.005 0

emp10

emp15

5000

6000

1000

2000

3000

4000

5000

6000

3000

4000

5000

6000

Generation
9.8 9.6 9.4 emp15 9 x 10 9.5 x 10

Generation
9.5 emp10 emp15 emp5 9 x 10

Generation
9.5 emp10 x 10

Generation

emp10

Fitness

Fitness

Fitness

9.2 9 8.8 8.6 8.4 8.2 0 1000 2000

emp10

8.5

Fitness

emp15 emp5

emp15 emp5

emp5

8.5 7.5

8.5

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

1000

2000

3000

4000

5000

6000

Generation

Generation

Generation

Generation

Fig. A.1. Tasks and skills xed (horizontal: 5, 10, 10/45, 10/67 skills, vertical: 10, 20, 30 tasks).

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2399

only some readers. We group related instances in the same graph in order to compare the traces. When doing so, the question is how to group the instances. To clarify the presentation we decided to group the instances according to three dierent criteria. The rst criterion consists of maintaining in the same graph all the instances which have the same number of project skills, skills per employee, and the same number of tasks. As we have four possible congurations of project skills and three dierent tasks we have obtained 12 graphs in this way, shown in Fig. A.1. In this gure we nd all the graphs shown in Section 6. Let us observe the smooth curves of the third row, all of them belonging to the 30 tasks instances where the GA does not obtain any feasible solution. This contrasts with the noisy curves of the central row (20 tasks instances) for which the GA does indeed enter into the feasible region of solutions (always after 2000 steps approx.). The main conclusion that we draw from these graphs is that the nal best tness value generally increases with the number of employees. The second grouping is made by plotting together in the same graph the instances which have the same number of employees and the same conguration of skills (Fig. A.2). Again we have 12 graphs with three traces per graph (number of tasks). The rst observation is that only the curves of the 10-tasks instances always get a higher tness value than the feasible solution tness value (0.01). The point at which the curve starts rising depends on the number of employees. With a larger number of employees the rising is delayed, perhaps due to the larger size of the chromosome. In some graphs (like the one of the 5-employees/10-skills instance) we see a modest rising of the 20 tasks curves. Finally, the third criterion is to group the instances which have the same number of tasks and employees, thus obtaining the nine graphs of Fig. A.3. In the rst column (10 tasks instances) we can see that the nal best tness of the 5-skills instances is higher than in the case of the 10-skills instances. This was already discussed in Section 6 when we observed that projects involving 10 skills were more dicult to solve than those requiring ve skills. On the other hand, the point at which the curves start a deep ascent is delayed with the increment in the number of employees (this was also observed in Fig. A.2). The second column helps us to conclude that a larger number of employees makes the search easier.

0.4 0.35 task10 0.3

0.2 0.18 0.16 0.14 task10

0.4 0.35 0.3 task10

0.35 0.3 0.25 task10

Fitness

Fitness

Fitness

0.25 0.2 0.15 0.1 0.05 0 0 1000 2000 3000 task20 4000

0.12 0.1 0.08 0.06 0.04 0.02 task20 task30 0 1000 2000 3000 4000 5000 6000

0.25 0.2 0.15 0.1 0.05 task20 0 0 1000 2000 task30 3000 4000 5000 6000

Fitness

0.2 0.15 0.1 0.05 task20 task30 0 0 1000 2000 3000 4000 5000 6000

task30 5000 6000

Generation
0.7 0.6 0.5 task10 0.45 0.4 0.35

Generation
0.4 0.35 task10 0.3

Generation
0.7 0.6 task10 0.5

Generation

Fitness

Fitness

Fitness

0.25 0.2 0.15 0.1

0.4 0.3 0.2 0.1 0 0 1000 2000 3000 task20 task30 4000 5000 6000

Fitness

0.3 0.25 0.2 0.15 0.1 0.05 0 0 1000 2000 3000 task20 4000 task30 5000 6000

task10

0.4 0.3 0.2 task20

0.05 0 0 1000 2000 3000

task20 task30 4000 5000 6000

0.1 task30 0 0 1000 2000 3000 4000 5000 6000

Generation
0.8 0.7 0.6 task10 0.7 0.6 0.5

Generation
0.5 0.45 0.4

Generation
0.7
task10

Generation
0.6 0.5

task10

Fitness

Fitness

Fitness

0.35

Fitness

0.5 0.4 0.3 0.2 0.1 0 0 1000 2000 3000 task20 4000

0.4 0.3 0.2 0.1

0.3 0.25 0.2 0.15 0.1 task20 task30 0 1000 2000 3000 4000 5000 6000

task10 0.4 0.3 0.2 0.1 task20 0 0 1000 2000 3000 task30 4000 5000 6000

task30 5000 6000

task20 0 0 1000 2000 3000 4000

0.05 0

task30 5000 6000

Generation

Generation

Generation

Generation

Fig. A.2. Employees and skills xed (horizontal: 5, 10, 10/45, 10/67 skills, vertical: 5, 10, 15 employees).

2400

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

0.4 skill10/45 0.35 0.3

x 10 skill10 skill5 skill10/45 skill10/67

0.02

8.8 8.6

Fitness

Fitness

Fitness

0.25 0.2 0.15 0.1 0.05 0 0 1000 2000

8.4 8.2 8 7.8 7.6

0.014 0.012 0.01 0.008

skill10

skill5

skill10/67 skill10/45 0 1000 2000 3000 4000 5000 6000

7.4 7.2 0 1000 2000 3000 4000 5000 6000

3000

4000

5000

6000

Generation
0.7 0.6 0.5 skill5 skill10/67
0.14 0.12 0.1

Generation
9.4 9.2 9 x 10

Generation

skill10 skill5

skill10/67 skill10/45

Fitness

0.4 0.3 0.2 0.1 0 0 1000 2000 3000 4000 5000 6000 skill10/45

Fitness

0.08 0.06 0.04 0.02 0 0 1000 2000 3000 4000 skill5 skill10/45 skill10 5000 6000

Fitness

skill10

skill10/67

8.8 8.6 8.4 8.2

1000

2000

3000

4000

5000

6000

Generation
0.8 0.7 0.6 skill5 skill10 skill10/67
0.1 0.08 0.12

Generation
9.5 x 10

Generation

skill5 9 skill10 skill10/67 skill10/45 8.5

Fitness

0.4 0.3 0.2 0.1 0 0 1000 2000 3000

skill10/45

Fitness

0.06 skill5 0.04 0.02 0 skill10 skill10/67 0 1000 2000 3000 4000 5000 6000

Fitness
8 0

0.5

skill10/45

4000

5000

6000

1000

2000

3000

4000

5000

6000

Generation

Generation

Generation

Fig. A.3. Employees and tasks xed (horizontal: 10, 20, 30 tasks, vertical: 5, 10, 15 employees).

References
[1] T. Back, D.B. Fogel, Z. Michalewicz, Handbook of Evolutionary Computation, Oxford University Press, New York, USA, 1997. [2] B. Boehm, R. Ross, Theory-w software project management: principles and examples, IEEE Transaction on Software Engineering 15 (7) (1989) 902916. [3] C. Burgess, M. Leey, Can genetic programming improve software eort estimation? a comparative evaluation, Information and Software Technology 43 (14) (2001) 863873. [4] C.K. Chang, M.J. Christensen, T. Zhang, Genetic algorithms for project management, Annals of Software Engineering 11 (2001) 107139. [5] J. Clarke, J. Dolado, M. Harman, R. Hierons, B. Jones, M. Lumkin, B. Mitchell, S. Mancoridis, K. Rees, M. Roper, M. Shepperd, Reformulating software engineering as a search problem, IEE Proc. Software 150 (3) (2003) 161175. [6] E. Demeulemeester, W. Herroelen, A branch-and-bound procedure for the multiple resource-constrained project scheduling problem, Management Science 38 (1992) 18031818. [7] T. Dohi, Y. Nishio, S. Osaki, Optimal software release scheduling based on articial neural networks, Annals of Software Engineering 8 (1999) 167185. [8] D. Doval, S. Mancordis, B. Mitchell, Automatic clustering of software systems using a genetic algorithm, in: Proceedings of the International Conference on Software Technology and Engineering Practice, IEEE Computer Society, Washington, DC, USA, 1999, pp. 7381. a, [9] R. Garc M. Oliveira, J. Maldonado, Genetic algorithms to support software engineering experimentation, in: Proceedings of the International Symposium on Empirical Software Engineering, IEEE Computer Society, Noosa Heads, Australia, 2005, pp. 488497.

E. Alba, J. Francisco Chicano / Information Sciences 177 (2007) 23802401

2401

[10] D.E. Goldberg, Genetic Algorithms in Search, Optimization and Machine Learning, Addison-Wesley, Reading, Massachusetts, USA, 1989. [11] S. Henninger, Case-based knowledge management tools for software development, Automated Software Engineering 4 (1997) 319 340. [12] K.S. Hindi, H. Yang, K. Fleszar, An evolutionary algorithm for resource-constrained project scheduling, IEEE Transactions on Evolutionary Computation 6 (5) (2002) 512518. [13] F. Jimenez, J.M. Cadenas, J.L. Verdegay, G. Sanchez, Solving fuzzy optimization problems by evolutionary algorithms, Information Sciences 152 (2003) 303311. [14] B.F. Jones, H.-H. Sthamer, D.E. Eyres, Automatic structural testing using genetic algorithms, Software Engineering Journal 11 (5) (1996) 299306. [15] H.-M. Lee, S.-Y. Lee, T.-Y. Lee, J.-J. Chen, A new algorithm for applying fuzzy set theory to evaluate the rate of aggregative risk in software development, Information Sciences 153 (2003) 177197. [16] J.-C. Lin, P.-L. Yeh, Automatic test data generation for path testing using GAs, Information Sciences 131 (14) (2001) 4764. [17] L.-C. Liu, E. Horowitz, A formal model for software management, IEEE Transaction on Software Engineering 15 (10) (1989) 1280 1293. [18] D. Merkle, M. Middendorf, H. Schmeck, Ant colony optimization for resource-constrained project scheduling, IEEE Transactions on Evolutionary Computation 6 (4) (2002) 333346. [19] A. Mingozzi, V. Maniezzo, S. Ricciardelli, L. Bianco, An exact algorithm for project scheduling with resource constraints based on a new mathematical formulation, Management Science 44 (5) (1998) 714729. [20] M. Palpant, C. Artigues, P. Michelon, LSSPER: solving the resource-constrained project scheduling problem with large neighbourhood search, Annals of Operations Research 131 (2004) 237257. [21] C.L. Ramsey, V.R. Basili, An evaluation of expert systems for software engineering management, IEEE Transactions on Software Engineering 15 (6) (1989) 747759. [22] M. Ronchetti, G. Succi, W. Pedrycz, B. Russo, Early estimation of software size in object-oriented environments a case study in a CMM level 3 software rm, Information Sciences 176 (5) (2006) 475489. [23] G. Ruhe, D. Greer, Quantitative studies in software release planning under risk and resource constraints, in: Proceedings of the International Symposium on Empirical Software Engineering, IEEE Computer Society, Roman Castles, Rome, Italy, 2003, pp. 262 270. [24] B. Talbot, J. Patterson, An ecient integer programming algorithm with network cuts for solving resource-constrained scheduling problems, Management Science 24 (1978) 11631174. [25] G.H. Travassos, M.O. Barros, Contributions of in virtuo and in silico experiments for the future of empirical studies in software engineering, in: Proceedings of the ESEIW 2003 Workshop on Empirical Studies in Software Engineering, Fraunhofer IRB Verlag, Roman Castles, Italy, 2003, pp. 117130. [26] B. Wall, A genetic algorithm for resource-constrained scheduling, Ph.D. thesis, Massachusetts Institute of Technology, 1996. [27] J. Wegener, H. Sthamer, B. Jones, D. Eyres, Testing real-time systems using genetic algorithms, Software Quality Journal 6 (2) (1997) 127135. [28] L. Yang, B.F. Jones, S.H. Yang, Genetic algorithm based software integration with minimum software risk, Information and Software Technology 48 (3) (2006) 133141.