Software project management with GAs

Informaton Scences 177 (27) 238 241 www.elsever.com/locate/ns Software project management wth GAs Enrque Alba *, J. Francsco Chcano Unversty of Málaga, Grupo GISUM, Departamento de Lenguajes y Cencas de la Computacón, E.T.S. Ingenería Informátca, Campus de Teatnos, 2971 Málaga, Span Receved 4 February 25; receved n revsed form 27 September 26; accepted 24 December 26 Abstract A Project Schedulng Problem conssts n decdng who does what durng the software project lfetme. Ths s a captal ssue n the practce of software engneerng, snce the total budget and human resources nvolved must be managed optmally n order to end n a successful project. In short, companes are prncpally concerned wth reducng the duraton and cost of projects, and these two goals are n conflct wth each other. In ths work we tackle the problem by usng genetc algorthms (GAs) to solve many dfferent software project scenaros. Thanks to our newly developed nstance generator we can perform structured studes on the nfluence the most mportant problem attrbutes have on the solutons. Our conclusons show that GAs are qute flexble and accurate for ths applcaton, and an mportant tool for automatc project management. Ó 27 Elsever Inc. All rghts reserved. Keywords: Automatc software management; Genetc algorthm; Project schedulng 1. Introducton The hgh complexty of currently exstng software projects justfes the research nto computer aded tools to properly plan the project development. Current software projects usually demand complex management nvolvng schedulng, plannng, and montorng tasks. There s a need to control people and processes, and to effcently allocate resources n order to acheve specfc objectves whle satsfyng a varety of constrants. In a general way, the project schedulng problem conssts n defnng whch resources are used to perform each task and when each one should be carred out. Tasks may be anythng from mantanng documents to wrtng programs, and the resources nclude people, machnes, tme, etc. The objectves are usually to mnmze the project duraton, to mnmze the project cost, and to maxmze the product qualty [4]. In an real project, the manager wants an automatc plan whch wll reconcle as far as possble these three conflctng goals. Some work exsts whch proposes and dscusses advanced management technques [2,22] and tools [15,17] whch can help software managers n ther work. Computers are usually appled at several steps of the * Correspondng author. Tel.: +34 95213 333; fax: +34 95213 1397. E-mal addresses: eat@lcc.uma.es (E. Alba), chcano@lcc.uma.es (J. Francsco Chcano). 2-255/$ - see front matter Ó 27 Elsever Inc. All rghts reserved. do:1.116/j.ns.26.12.2

software management process. We can fnd expert systems to dagnose problems n software development [21], neural networks for decdng when to delver software to the users [7], genetc algorthms for project schedulng [4], CASE tools for the knowledge management of software development [11], all of whch together form a new feld of knowledge related to computer asssted project management. In ths paper we focus on the Project Schedulng Problem solved wth genetc algorthms [1]. The ssues addressed are related to the tme, human sklls, budget, and project complexty nvolved. All of these ssues make our study more dffcult and nearer to actual software project plannng scenaros. We frst defne an optmzaton problem to deal wth the search for hghly effcent management and propose the use of genetc algorthms to solve ths problem [1]. Wth the proposed tool, a project manager can evaluate dfferent scenaros n order to later be able to take decsons on the actual project tself. We perform some n slco experments [25] based on several automatcally generated project scenaros. The artcle s organzed as follows. In Secton 2 the Project Schedulng Problem s defned. Secton 3 descrbes the genetc algorthms proposed and Secton 4 dscusses the representaton of the ndvduals and the ftness functon, two very mportant ssues when applyng GAs to any problem. We use an nstance generator to automatcally create the dfferent project scenaros, whch s descrbed n Secton 5. Fnally, the expermental study and results are presented n Secton 6, and some conclusons and future work are outlned n Secton 7. 2. The project schedulng problem (PSP) The PSP s related to the Resource-Constraned Project Schedulng (RCPS), an exstng problem whch has been extensvely tackled n the lterature usng both exact technques [6,19,24] and metaheurstc ones [12,18,2]. However, there are some dfferences between PSP and RCPS. Frstly, n PSP there s a cost assocated wth the employees and a project cost whch must be mnmzed (n addton to the project duraton). Addtonally, n RCPS there are several knds of resources whle PSP has only one (the employee) wth several possble sklls. We should notce that PSP sklls are dfferent from RCPS resource types. In addton, each actvty n the RCPS requres dfferent quanttes of each resource whle PSP sklls are not quantfable enttes. The problem as defned here s more realstc than the RCPS because t ncludes the concept of an employee wth a salary and personal sklls, also capable of performng several tasks durng a regular workng day. In [4] a genetc algorthm s used to solve ths knd of problem wth an approach whch s smlar to our statement. Let us specfy the detals of the problem tackled n ths work. The resources consdered are people wth a set of sklls, and a salary. These employees have a maxmum degree of dedcaton to the project. Formally, each person (employee) s denoted wth e, where ranges from 1toE (the number of employees). Let SK be the set of sklls, and s the th skll wth varyng from 1 to S ¼jSKj. The sklls of employee e wll be denoted wth e sklls maxmum dedcaton to the project wth e maxded E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2381 SK, the monthly salary wth e salary, and the. Both the salary and the maxmum dedcaton are real numbers. The former s expressed n fcttous currency unts, whle the latter s the rato between the amount of hours dedcated to the project and the full length of the employee s workng day. Let us consder an example to clarfy the concepts. Let us suppose that we have a software company wth fve employees. We need to perform a software applcaton for a bank presentng the scenaro shown n Fg. 1. In ths fgure we supply nformaton about the dfferent sklls of the employees, ther maxmum dedcaton to the project at hand, and ther monthly salary. For example, employee e 2, who earns $25 each month, s a database expert (s 3 ), a UML expert (s 4 ), and s able to lead a group of people (s 2 ). Her/hs colleague, employee e 4, s also able to lead a group (s 2 ) and, n addton, s/he s a great programmer (s 1 ). These two employees and employee e 1 can spend all of ther workng day developng the applcaton (maxmum dedcaton equal to one) but ths does not necessarly mean that they do so. On the contrary, employee e 3 can only dedcate half of her/ hs workng day to the project. There may be several reasons for ths fact: perhaps the employee has a parttme contract, or s/he has admnstratve tasks to carry out n the company durng part of the day. Employee e 5 can work overtme, her/hs maxmum dedcaton s greater than one ðe maxded 5 ¼ 1:2Þ, and ths means that s/he can work on the bank applcaton up to 2% more than n an ordnary workng day. In ths way, we can model the extra tme of the employees, a farly real world feature ncluded n the problem defnton. However, the project manager must take nto account that an overloaded employee can ncrease her/hs mstake rate and,

2382 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 Fg. 1. Possble staff of an example software company. consequently, the number of errors n the software developed. Ths leads to a lower qualty of the fnal product and, possbly, to the need to correct or to re-develop the erroneous parts. In any case, the outcome may be an ncrease n the overall project duraton. Ths does not affect the problem defnton, t s a matter of psychology, but t s an mportant ssue that project managers must take nto account. Let us leave the example for a moment and study how the tasks of a software project are modelled. The tasks are denoted wth t, where ranges from 1 to T (the number of tasks). Each task t has a set of requred sklls assocated wth t denoted by t sklls and an effort t effort expressed n person-month (PM). The tasks must be performed accordng to a Task Precedence Graph (TPG). Ths ndcates whch tasks must be completed before a new task s begun. The TPG s an acyclc drected graph GðV ; AÞ wth a vertex set V ¼ft 1 ; t 2 ;...; t T g and an arc set A, where ðt ; t j Þ2A f task t must be completed, wth no other ntervenng tasks, before task t j can start. In order to contnue wth our example we show n Fg. 2 all the tasks of the software project n hand. For each task we provde nformaton on the effort n person-month and the set of requred sklls. For example, task t 1, whch conssts n creatng the UML dagrams of the project n order to be used later by the employees n the followng tasks, requres UML expertse (skll s 4 ) and fve person-month. In the same fgure we show the TPG of the project, drawng an arrow from task t to task t j f the former must be completed before the latter starts. For example, after the UML dagrams of the applcaton are completed (t 1 ), both the desgn of the web page templates for the documentaton of the applcaton (t 4 ) and the database Fg. 2. Task precedence graph of the bank applcaton.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2383 desgn (t 2 ) can be started. However, these two tasks must be completed before the database desgn documentaton s produced (t 6 ). Our objectves are to mnmze the cost and the duraton of the project. The constrants are that each task must be performed by at least one person, the set of requred sklls of a task must be ncluded n the unon of the sklls of the employees performng the task, and no employee must exceed her/hs maxmum dedcaton to the project. The frst constrant s necessary n order to complete the project: the project wll not be complete f even one task s left undone. The thrd constrant s obvous after the defnton of maxmum dedcaton. However, more could be sad regardng the second constrant and therefore we wll deal wth t below. At ths pont we can talk about the number of sklls nvolved n a project. Ths number can be vewed as a measure of the degree of specalzaton of the abltes nvolved n the project. That s, the more sklls, the more portons the abltes requred to perform the whole software project must be dvded nto. In our example we could further break down some of the sklls. For nstance, we can dvde the programmng expertse nto three sklls: Java expertse, C/C++ expertse, and Vsual Basc expertse. On the other hand, the number of sklls can be vewed as a measure of the amount of abltes needed to carry out a project. One example could be developng software for controllng an arplane (large varety of sklls needed) versus our bank applcaton. Thus, n our model, the number of sklls nvolved n a project has a dual nterpretaton n the real world: the degree of specalzaton of the abltes nvolved versus the amount of abltes needed to carry out the project. The correct nterpretaton depends on the specfc project. From the project manager pont of vew, the sklls assgned to each task and employee depends on the dvson of the abltes requred for the project at hand. For example, we can do a very fne dvson of the abltes f our employees are very specalzed (they are experts n very specfc domans). In such a stuaton we have a lot of very specfc sklls nvolved n the project. Each task can requre many of these sklls and the employees may have a few sklls each. In a dfferent scenaro, f our employees have some knowledge of several topcs then we wll have a few sklls assocated wth vast domans. In ths case, the number of sklls requred by the tasks s smaller than n the prevous scenaro. Once we know the elements of a problem nstance, we can proceed to descrbe the elements of a soluton to the problem. A soluton can be represented wth a matrx X ¼ðx j Þ of sze E T where x j P. The element x j s the degree of dedcaton of employee e to task t j. If employee e performs task t j wth a.5 dedcaton degree s/he spends half of her/hs workng day on the task. If an employee does not perform a task s/he wll have a dedcaton degree of for that task. Ths nformaton s used to compute the duraton of each task and, ndeed, the startng and fnshng tme of each one,.e., the tme schedule of the tasks (Gantt dagram). From ths schedule we can compute the duraton of the project (see Fg. 3). The cost can be calculated after the duraton of the tasks has been establshed, takng nto account the dedcaton and the salary of the employees. Fg. 3. A tentatve soluton for the prevous example. Usng the task duratons and the TPG, the Gantt dagram of the project can be computed.

2384 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 Fnally, the overwork of each employee can be calculated usng the tme schedule of the tasks and the dedcaton matrx X. In order to evaluate the qualty of a gven project management soluton, we take three ssues nto account: project duraton, project cost, and soluton feasblty. To compute the project duraton, denoted wth p dur,we need to calculate the duraton of each ndvdual task ðt dur j Þ. Ths s calculated n the followng way: t dur j ¼ teffort j P E ¼1 x j ð1þ The next step s to compute the startng and fnshng tmes for each task ðt start j and t end j Þ. At the same tme (thus allowng our algorthm to have a reduced computatonal cost), the algorthm also calculates the project duraton, whch wll be the maxmum fnshng tme ever found. The project cost p cost s the sum of the fees pad to the employees for ther dedcaton to the project. These costs are computed by multplyng the salary of the employee by the tme spent on the project. The tme spent on the project s the sum of the dedcaton multpled by the duraton of each task. In summary: p cost ¼ XE ¼1 X T j¼1 e salary x j t dur j ð2þ Now, we detal how the constrants are checked. In order to fnd whether a soluton s feasble, we must frst check that all tasks wll be performed by somebody,.e., no task s left undone. That s: X E ¼1 x j > 8j 2f1; 2;...; T g ð3þ The second constrant of a feasble soluton s that the employees performng one task must have the sklls requred by that task: t sklls j [ fjx j>g e sklls 8j 2f1; 2;...; T g ð4þ Now, we can dscuss the meanng of ths constrant. Observe that, f a task requres a skll, the constrant demands that at least one person, not necessarly all of them, have that skll. Ths makes sense n some stuatons, for example when the skll s the capacty to lead a group of people and the task requres a sngle leader to be apponted. Hence, t s possble that one employee workng on a task may have none of the sklls specfcally requred, or ndeed no sklls. In ths way, we can model scenaros where some employees do not have the sklls requred of the task at hand, but they are n contact wth and can therefore learn from other employees who have these sklls. However, n some scenaros we need all the people workng on a task to have a requred skll. For example, comng back to our bank applcaton we can requre that all the employees mplementng the applcaton (t 3 ) be expert programmers. To tackle ths scenaro we can allocate a dedcaton degree of zero on the task to all the employees wthout the requred skll. In our partcular case we can set x 3 ¼ : for all employees e wthout the skll s 1, that s, e 2, e 3, e 5. Ths means that the elements of the soluton matrx wth a zero value mposed are not consdered when the optmzaton algorthm s appled, reducng thereby the number of problem varables. However, when the soluton s evaluated a zero value s nserted n the correspondng postons of the matrx. Accordng to the second constrant, the tasks requrng a skll whch no employee has cannot be performed and the project cannot be fnshed. When ths happens all the solutons proposed for the schedulng problem are unfeasble because they volate the second constrant. The project manager can solve ths problem n several ways. Frstly, s/he can hre one or several new employees wth the requred sklls. We can model ths stuaton n our formulaton of the PSP by enlargng the set of employees wth the new ones. Furthermore, f the new employees are hred only to perform the task wth the skll demanded we can set the degree of dedcaton of the new employees to zero for all the other tasks. A second soluton to the problem conssts n tranng some of the employees n order to obtan the requred sklls. In our model ths soluton s performed by addng new sklls to the employees traned.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2385 Overwork Work load Maxmum dedcaton t 4 t 1 t 2 t 3 t 6 t 5 t 7 Tme Fg. 4. Workng functon of employee e 5 n our example. Fnally, n order to compute the overwork p over we need the startng and fnshng tmes for each task, prevously computed. For each employee e we defne her/hs workng functon as X e work ðtþ ¼ x j ð5þ If e work s e over fjjt start j ðtþ > e maxded e over ¼ Z t¼pdur t¼ 6t6t end g j employee e exceeds her/hs maxmum dedcaton at nstant t. The overwork of employee rampðe work ðtþ e maxded Þdt ð6þ where ramp s the functon defned by rampðxþ ¼ x f x > ð7þ f x 6 In Fg. 4 we llustrate the workng functon of employee e 5 n our example. We have ncluded the tasks that s/ he performs at any tme. The bold lne s the functon e work ðtþ and the dashed lne ndcates the maxmum dedcaton of the employee (1.2). When the workng functon passes above the maxmum dedcaton there s overwork. The total overwork of the project s the sum of the overwork for all the employees,.e. p over ¼ XE ¼1 e over ð8þ 3. Genetc algorthms In ths artcle we use a GA to solve the PSP, and thus a dscusson of ths knd of metaheurstc s approprate n order to make ths work self contaned. Genetc Algorthms (GAs) are stochastc search methods that have been successfully appled n many search, optmzaton, and machne learnng problems n the past [1]. Unlke other optmzaton technques, GAs mantan a populaton of encoded tentatve solutons that are compettvely manpulated by applyng some varaton operators to fnd a global optmum. To acheve ths goal the problem varables are encoded (bnary or floatng pont, for example) nto what are called the chromosomes, whch are merged and manpulated by the genetc operators to mprove ther assocated qualty (called the ftness). Thus, one ndvdual s composed of one chromosome and ts assocated ftness, and the set of ndvduals forms the populaton used by the algorthm. Populaton-based algorthms contrast wth trajectory-based ones (lke smulated annealng) n that they search from multple ponts at the same tme, thus reducng the probablty of gettng stuck n local optma; n addton, they can offer multple optma to the same problem, an nterestng feature that the researchers can use to have an assorted set of solutons to the problems at hand. After creatng an ntal set of solutons (randomly or by usng a seedng algorthm) GAs normally apply a crossover operaton to combne the contents of two parents formng a new soluton. Ths wll be modfed later by the mutaton operaton whch alters some of the contents of the ndvdual. Not all the ndvduals partcpate n the reproducton, only the fttest ones (eltsm s very common) are selected from the populaton by a

2386 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 Fg. 5. Pseudocode of a genetc algorthm. selecton operator such as bnary tournament (each parent s selected as the best of two randomly taken ndvduals). The operators are appled n a stochastc way, thus each one has an assocated probablty of applcaton n the teratve loop (each step s called a generaton). Usually, the best ndvduals n the present and the newly created generaton are combned n order that the best ones can be retaned for use n the next step of the algorthm (eltst replacement). The outlne of a general GA s presented n Fg. 5. It begns by randomly creatng a populaton Pðt ¼ Þ of l solutons (ndvduals), each one encodng the p problem varables, usually as a vector over B ¼f; 1g ði ¼ B plx Þ or R ði ¼ R p Þ. An evaluaton functon U s used to assocate a qualty real value to every soluton. The stoppng crteron of the reproductve loop s to fulfll some condton such as reachng a number of generatons or fndng a soluton. The fnal soluton s dentfed as the best soluton found. Metaheurstcs and, n partcular, GAs are not as ntensvely appled n the software engneerng doman as they are n felds lke engneerng, mathematcs, economcs, telecommuncatons or bonformatcs [1,13]. However, the work of Clarke et al. [5] s a good reference for solvng software engneerng problems wth metaheurstcs. They dentfy three areas where the metaheurstcs have been successfully appled: software testng, module clusterng, and cost estmaton. In software testng the approach adopted n the lterature s the generaton of test data wth metaheurstcs n order to detect faults n the software executon [14,16] or to fnd out the worst case executon tme of a code fragment [27]. For module clusterng, the metaheurstc algorthms are used to get a partton of the system components nto clusters wth hgh coheson among components n the same cluster and a loose couplng among dfferent clusters [8]. Fnally, n the cost estmaton problem the goal s to estmate the effort needed to carry out a software project [3]. Clarke et al. pont out other software engneerng domans where metaheurstcs could be appled: defnton of requrements, system ntegraton, mantenance, and re-engneerng usng program transformaton. In fact, some applcatons of GAs exst concernng the software engneerng expermentaton [9], software ntegraton [23], and software release plannng [28]. 4. Representaton and ftness functon In ths secton we dscuss the soluton representaton and the ftness functon used n the genetc algorthm. As we stated n Secton 2, a soluton to the problem s a matrx X whose elements x j are non-negatve. Here we have to decde how these elements are encoded. In ths artcle we consder that no employee works overtme, so the maxmum dedcaton of all the employees s 1. For ths reason, the maxmum value for x j s 1 and therefore x j 2½; 1Š. On the other hand, we use a GA wth bnary strng chromosomes to represent problem solutons. Hence we need to dscretze the nterval ½; 1Š n order to encode the dedcaton degree x j. We dstngush eght values n ths nterval whch are equally dstrbuted. Therefore, three bts are requred for representng them. The matrx X s stored nto the chromosome ~x n row major order. 1 The chromosome length s E T 3. Fg. 6 shows the representaton used. 1 We use ~x to refer to the chromosome (bnary strng) whch represents the matrx soluton X.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2387 Fg. 6. Representaton of a soluton n the genetc algorthm. To compute the ftness of a chromosome ~x we use the next expresson 1=q f the soluton s feasble f ð~xþ ¼ ð9þ 1=ðq þ pþ otherwse where q ¼ w cost p cost þ w dur p dur ð1þ and p ¼ w penal þ w undt undt þ w reqsk reqsk þ w over p over ð11þ The ftness functon has two terms: the cost of the soluton (q) and the penalty for unfeasble solutons (p). The two terms appear n the denomnator because the goal s to mnmze them,.e., maxmze f ð~xþ. The frst term s the weghted sum of the project cost and duraton. In ths term, w cost and w dur are values weghtng the relatve mportance of the two objectves. These weghts allow the ftness to be adapted accordng to our needs as project managers. For example, f the cost of the project s a prmary concern, the correspondng weght must be hgh. However, we must take nto account the order of magntude of both the project cost and duraton. Ths can be done by settng all the weghts to one ntally and then executng the GA several tmes. Next, the cost weght s dvded by the average project cost and the duraton weght s dvded by the average project duraton. In ths way, the weghted terms related to project cost and duraton are n the same order of magntude. At ths pont, the project manager can try dfferent weght values n order to adapt the solutons proposed by the GA to her/hs requrements. The penalty term p s the weghted sum of the parameters of the soluton that make t unfeasble, that s: the overwork of the project (p over ), the number of tasks wth no employee assocated (undt), and the number of sklls stll requred n order to perform all project tasks (reqsk). Each of these parameters s weghted and added to the penalty constant w penal. Ths constant s ncluded n order to separate the ftness range of the feasble solutons from that of the unfeasble ones. The weghts related to the penaltes must be ncreased untl a great number of feasble solutons s obtaned. The values for the weghts used n ths work are shown n Table 1. They have been obtaned by explorng several solutons and wth the am of mantanng all the terms of the sum wthn the same order of magntude. Table 1 Weghts of the ftness functon Weght w cost w dur.1 w penal 1 w undt 1 w reqsk 1 w over.1 Value 1 6

2388 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 5. Instance generator In order to perform a meanngful study we must analyze several nstances of the schedulng problem nstead of focusng on only one, whch could bas the conclusons. To do ths we have developed an nstance generator whch creates fcttous software projects after settng a set of parameters such as the number of tasks, the number of employees, etc. An nstance generator s an easly parameterzable tool whch derves nstances wth growng dffculty at wll. Also, usng a problem generator removes the possblty of hand-tunng algorthms to a partcular problem, therefore allowng greater farness when comparng algorthms. Wth a problem generator the algorthms can be evaluated on a hgh number of random problem nstances, because a dfferent nstance can be solved each tme the algorthm s run. Consequently, the predctve power of the results for the problem class as a whole s ncreased. In ths secton we descrbe the nstance generator n detal. The components of an nstance are: employees, tasks, sklls, and the task precedence graph (TPG). Each of these components has several parameters whch must be determned by the nstance generator. There are two knds of values to be generated: sngle numerc values and sets. For the numerc values a probablty dstrbuton s gven by the user and the values are generated by samplng ths dstrbuton. In the case of sets, the user provdes a probablty dstrbuton for the cardnalty (a numerc value) and then, the elements of the set are randomly chosen from ts superset. All the probablty dstrbutons are specfed n a confguraton fle. Ths fle s a plan text fle contanng attrbute-value pars. We can see a sample fle n Fg. 7. Each parameter of the nstance has a key name n the confguraton fle. These key names are ncluded n Table 2. The value of a key name s the name of the probablty dstrbuton sampled to generate the value of the parameter. The probablty dstrbutons have param- Fg. 7. A sample confguraton fle for the nstance generator.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2389 Table 2 Key names of the confguraton fle and ther assocated parameter Key name task.number task.cost task.skll employee.number employee.salary employee.skll graph.e-v-rate skll.number Parameter Number of tasks Effort of the tasks Number of the requred sklls of the tasks Number of employees Salary of the employees Number of sklls of the employee Rato edges/vertces of the TPG Cardnalty of the sklls set eters that are specfed wth addtonal key-value pars of the form: hkey-name.parameter.hparam = hvalue. For example, the property employee.skll n the sample fle of Fg. 7 ndcates that employees have ether 6 or 7 of the 1 possble sklls (property skll.number). The nstance generator reads the confguraton fle and then t generates the sklls, the tasks, the TPG, and the employees, n that order. For each task, t generates the effort value and the requred skll set. For each employee t generates the salary and the set of sklls. The pseudocode of the nstance generator s shown n Fg. 8. Fg. 8. Pseudocode of the nstance generator.

239 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 The numerc values of an nstance are: the number of tasks, the effort of the tasks, the number of employees, the salary of the employees, and the number of sklls. The sets of an nstance are: the requred sklls of the tasks, the sklls of the employees, and the set of edges of the TPG graph. For the set of edges we do not specfy a dstrbuton for the cardnalty drectly, but rather for the rato edges/vertces, that s, the generated numerc value s multpled by the number of tasks n order to get the number of edges of the TPG. The maxmum degree of dedcaton of the employees s not part of the nstance tself, but a part of the optmzaton problem. Ths parameter can be dfferent for each employee and t s establshed n the solver confguraton fle. For ths reason the values for ths parameter are not generated. A deeper descrpton of the generator, and the program tself can be found at URL http://tracer.lcc.uma.es/problems/psp. In ths work, we use the nstance generator to study nstances wth dfferent parameterzatons, that s, dfferent number of tasks, employees, and sklls. The dffculty of the nstances depends on these parameters. For example, we expect the nstances wth a larger number of tasks to be more dffcult than those wth a smaller set of tasks, as n real world projects. Ths s common sense snce t s dffcult to do more work wth the same number of empdoyees (wthout workng overtme). Followng ths reasonng, when we ncrease the number of employees whle mantanng the number of tasks we expect easer nstances to emerge from the generator. However, these rules of thumb are hard to fnd n complex projects lke ours, because there are nterdependences of some other parameters whch have an nfluence on the dffculty of an nstance. One of these parameters s the TPG: wth the same number of tasks, one project can be tackled by fewer employees n the same tme as another project wth a dfferent TPG. On the other hand, f we compare nstances wth the same number of tasks we expect that, as the number of employees decreases, the project wll last longer. However, wth an ncrement n the number of employees we dentfy two opposte effects related to the cost: wth more people workng, operatonal costs rse; but at the same tme the project duraton and the expendture are reduced. Hence, we cannot conclude anythng about the project cost drectly from the number of employees. Wth respect to the number of project sklls, we expect nstances whch have a hgher number of demanded sklls to be more dffcult to solve. Wth more sklls, we have more specalzed employees and we expect to need more employees to cover the requred sklls nvolved n a task. Hence, the employees work on more tasks and probably some of them may exceed ther maxmum dedcaton degree thus makng the soluton unfeasble. All these features make t very mportant for the project manager to have an automatc computer tool for takng decsons. 6. Expermental study and results For the expermental study we generated a total of 48 dfferent nstances wth the nstance generator and solved them wth a genetc algorthm. We have grouped the nstances nto fve benchmarks. In the frst three groups we change only one parameter of the problem. Wth these studes we want to analyze how senstve the results obtaned are to the varaton of these parameters. In the last two groups we change several parameters at the same tme. In ths way we study whether the results change n the way suggested by the studes of the frst three groups. To solve the nstances, we use a genetc algorthm wth a populaton of 64 ndvduals, bnary tournament selecton, 2-D sngle pont crossover, bt-flp mutaton, and eltst replacement of the worst (steady-sate genetc Table 3 Parameters of the GA GA parameters Populaton 64 Selecton 2-tournament (2 nds.) Recombnaton 2-D SPX Mutaton Bt-Flp (1/length) Replacement Eltst Stop 5 steps

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2391 algorthm). The stoppng crteron s to reach 5 steps of the man loop (564 evaluatons). We performed 1 ndependent runs for each nstance. In Table 3 we summarze the GA parameters. The 2-D sngle pont crossover [26] s an unusual recombnaton operator appled to matrces. It randomly selects a row and a column (the same n the two parents) and then t swaps the elements n the upper left quadrant and n the lower rght quadrant n both ndvduals (Fg. 9). In the followng subsectons we present the studes performed and the results for all the dentfed benchmarks. 6.1. Frst benchmark: changng the number of employees The frst step s to study the nfluence whch the number of employees has on the solutons. We use four dfferent nstances of the problem wth the same software project,.e., they have the same tasks and the same TPG. The only dfference n the nstances s the number of employees. The maxmum dedcaton and the salary of the employees s also the same. In addton, the constrant related to the sklls s not taken nto account. That s, all the employees have the necessary sklls to perform any gven task. Ths stuaton has been modelled by ntroducng only one skll and provdng all the employees wth that skll. All the nstances are based on the same software project wth 1 tasks, thus, the total work to be done s always the same. For ths reason we expect the project duraton of the solutons proposed by the genetc algorthm to decrease when the number of employees ncreases. More precsely, the project duraton and the number of employees must have an nverse relatonshp and ther product must be constant. In Table 4 we show the results obtaned wth four dfferent numbers of employees: 5, 1, 15, and 2. For each case we present the ht rate (percentage of runs gettng a feasble soluton), the average duraton of the feasble solutons proposed, and the product of the number of employees and the average project duraton n months. We observe n the results that the ht rate decreases when the number of employees ncreases, that s, the problem becomes more dffcult when we ncrease the number of employees. One would have magned that wth more employees t would be easer to fnd a soluton for the problem. However, n ths stuaton the thrd constrant (requrng no overwork) s more dffcult to satsfy. At the same tme, the search space s larger and ths does not help the search process. As we predcted before, the project duraton decreases when the number of employees ncreases. In fact, the product of the number of employees and the average duraton s very smlar for the dfferent nstances (fourth column). However, t ncreases slghtly wth the number of employees for the same reason as the ht rate s reduced: the nstances are more dffcult for the GA. The cost of the software project s exactly the same n all the solutons because all the employees have the same salary, that s, the cost of a one person-month s fxed throughout all the nstances. 6.2. Second benchmark: changng the number of tasks Fg. 9. 2-D sngle pont crossover. Now we study the nfluence of the number of tasks on the solutons. We solve three nstances where we mantan the employees and we change the software projects. In partcular, the three software projects have Table 4 Results obtaned when the number of employees changes Employees Ht rate Avg. duraton Avg. E p dur 5 87 21.88 19.4 1 65 11.27 112.7 15 49 7.73 115.95 2 51 5.88 117.6

2392 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 Table 5 Results obtaned when the TPG changes Tasks Ht rate Cost Avg. duraton Avg. p cost =p dur 1 73 98, 21.84 44,944.33 2 33 2,6, 58.29 44,748.35 3 a dfferent number of tasks: 1, 2, and 3. As n the prevous benchmark, all the employees have the same salary and maxmum dedcaton. For ths reason all the solutons for the same project have the same cost. Snce we use the same probablty dstrbuton n order to generate the cost of the project tasks n the three projects, we expect an ncrease n the project cost wth an ncrease n the number of tasks. In addton, we do not consder the second constrant, so we expect a proportonal relatonshp between the duraton and the cost of the projects. Furthermore, f all the employees are workng all the tme for the project, the rato between the cost and the duraton must be exactly the sum of the salary of the employees. In the nstances there are fve employees wth a monthly salary of $1,, so the cost-duraton rato must be nearly $5,. We present the results of the three nstances n Table 5. We show the ht rate, the project cost n dollars, the average duraton n months of the feasble solutons proposed, and the average cost per month of the projects n dollars per month. From the results we observe that the problem becomes harder when the number of tasks ncreases. In fact, the genetc algorthm s not able to obtan any feasble soluton for the software project wth 3 tasks. The reason for ths behavor s the same as n the prevous benchmark: when the number of tasks ncreases t s more dffcult for the GA to get a soluton satsfyng the overwork constrant. We also observe that both the cost of the projects (thrd column) and the project duraton (fourth column) ncrease wth the number of tasks. The cost per month of the project (ffth column) s nearly $5, n the two cases as we predcted. Ths parameter cannot be greater than $5, because ths mples a volaton of the overwork constrant. When the value of ths parameter s near the optmal one ($5, n our case) ths means an effcent allocaton of employees to tasks. We conclude from the results that the allocaton ganed for the 1 tasks nstance s more effcent than that obtaned for the 2 tasks one. We can explan ths result wth the ncrease n the search space when shftng from 1 to 2 tasks. 6.3. Thrd benchmark: changng the employee expertse In ths secton we study how the number of sklls per employee,.e., the expertse of the employees, nfluences the results. We solve fve nstances wth the same software project and the same number of employees. The employees all have the same monthly salary and the same maxmum dedcaton. Instances dffer from each other n the employee sklls. We analyze fve dfferent values for the number of sklls of the employees: 2, 4, 6, 8, and 1. The employee sklls are randomly selected from the set of 1 project sklls. All the tasks requre fve dfferent sklls. We present the ht rate, the average duraton of the projects, and the average cost per month n Table 6. We observe that the problem s harder to solve wth a lower number of sklls per employee, that s, f the expertse of the employees s low, t s more dffcult to allocate them to the tasks wthout volatng the sklls constrant (the second one). We can also notce that the average project duraton obtaned n the dfferent Table 6 Results obtaned when the number of sklls per employee changes Sklls Ht rate Avg. duraton Avg. p cost =p dur 2 39 21.71 45,23.15 4 53 21.77 45,68.64 6 77 21.98 44,651.28 8 66 22. 44,617.2 1 75 22.11 44,426.9

nstances remans almost constant wth a slght ncrease for hgher values of the employee expertse. Ths means that the GA s able to allocate the employees to the tasks n a more effcent way when the level of employee expertse s lower. The reason s that the feasble regon of the search space s enlarged when the employees have more sklls, and therefore the average qualty of the solutons ncluded n the feasble regon decreases. 6.4. Fourth benchmark: expertse specalzaton fxed We nclude n ths group 18 dfferent problem nstances generated by the nstance generator. The nstances nclude dfferent software projects and they dffer from each other n all the prevously studed parameters. In partcular, we assgn dfferent values to the number of employees, the number of tasks, and the number of employee sklls. The number of dfferent sklls of the project s set to 1 n all the nstances. The number of employees can be 5, 1, or 15 and the number of tasks 1, 2, or 3. Two ranges of values are consdered separately for the number of sklls of the employees: from 4 to 5, and from 6 to 7. As n the prevous benchmarks, the maxmum dedcaton for all the employees s 1. (full workng day). We show n Table 7 the ht rate for all the nstances (from 1 ndependent runs). From these results we can conclude that the nstances wth a larger number of tasks are more dffcult to solve than those wth a smaller set of tasks, as we concluded n Secton 6.2. In the second row of results, we observe an nverse relatonshp between the number of employees and the dffculty of the problem. Ths contrasts wth the results of the frst benchmark (Secton 6.1). What s happenng? The man dfference between the two cases resdes n the sklls. In the frst benchmark the sklls constrant was not consdered whereas n ths case t s. When the number of employees ncreases, t s more dffcult to fulfll the overwork constrant but t s easer to fulfll the sklls constrant because the staff s hghly sklled. These two trends are n conflct wth each other, but n ths case the second one seems to be predomnant. In order to better llustrate the meanng of these results we plot the solutons obtaned n a graph showng ther cost versus ther duraton (Fgs. 1 and 11). Cost and duraton are clear tradeoff crtera n any project. Ths s the knd of graph that a manager would lke to see before takng any decson on the project. We have put a label htasks-hemployees near the solutons of the same nstance. In the fgures, the solutons of the nstances can be seen as pont clusters. Ther elongated form depends on the scale of the axs (chosen to mantan the solutons of all the nstances n the same graph), however we can apprecate a slght nclnaton of the clusters showng the tradeoff mentoned between cost and duraton: when the cost of a soluton s lower, ts duraton s longer. As we expected, when the number of employees decreases for a gven number of tasks, the project lasts longer. Ths observaton s mantaned despte each pont cluster representng a dfferent nstance wth dfferent TPG. In the fgures, we can observe that a larger number of employees does not necessarly mean a more expensve project n all the cases. However, we cannot obtan any fundamental concluson on ths fact because the nstances belong to very dfferent software projects. 6.5. Ffth benchmark: employees expertse fxed E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2393 In ths fnal benchmark composed of 18 nstances we study the nfluence of the number of dfferent sklls on a project. Ths wll shed some lght on exstng large companes where an assorted set of persons of vared Table 7 Ht rate for the fourth benchmark 4 5 Sklls 6 7 Sklls Employees Employees Tasks 5 1 15 5 1 15 1 94 97 97 84 1 97 2 6 43 76 3

2394 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 35 3 2 1 25 Duraton 2 15 1 5 1 1 2 15 1 1 15 5.5 1 1.5 2 2.5 x 1 6 Cost Fg. 1. Results wth 4 5 sklls per employee. Labels show the number of tasks and employees of the nstance. 35 3 2 1 25 Duraton 2 15 1 5 1 1 1 1 15 5.5 1 1.5 2 2.5 3 x 1 6 Cost Fg. 11. Results wth 6 7 sklls per employee. Labels show the number of tasks and employees of the nstance. experence are to be optmally assgned to software projects. In ths case we fx the range of the number of sklls per task and employee from 2 to 3. The number of tasks can be 1, 2, or 3 and the number of employees takes values 5, 1, and 15 as n the prevous benchmark. The number of dfferent sklls s ether 5 or 1. In Table 8 we show the results. As n the prevous subsecton we can see that an ncrement n the number of tasks means an ncrement n the dffculty of the problem. The partcpaton of more employees usually mples a decrement n the dffculty of the nstance (t s easer to manage the project). However, we can now conclude one addtonal fact: we confrm, as expected, that a larger number of demanded sklls makes the nstance more dffcult (n general) to solve.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2395 Table 8 Ht rate for the ffth benchmark 5 Sklls 1 Sklls Employees Employees Tasks 5 1 15 5 1 15 1 98 99 1 61 85 85 2 6 9 12 8 1 6 3 From Fgs. 12 and 13 we conclude that the cost of the project ncreases wth the number of tasks, and the duraton of the project decreases wth the ncrement n the number of employees. Ths was also observed n the prevous benchmarks. However, wth more employees, the overall cost of the project s reduced n all cases, a fact that was not observed before (only smlar to 1 15 and 2 15 n Fg. 1). Prevously we argued that dfferent nstances use dfferent projects and for ths reason we cannot obtan any defntve concluson. Here, we are n the same stuaton but analyzng the partcular solutons of the nstances we observe that wth a larger number of employees all of them work on all the tasks at a low degree of dedcaton. In ths way, the tasks are performed more quckly and the global cost of the project s lower. 6.6. Further understandng of the dynamcs of our algorthm In order to end our presentaton of results we plot the average best ftness evoluton of some nstances n the 1 runs. Our goal s to present a trace of the search performed by the GA. In Fg. 14 on the left we can see the evoluton of the nstances wth 1 tasks and 5 sklls: the fnal average best ftness ncreases wth the number of employees. Wth a larger number of employees the algorthm can compute a more effcent schedulng reducng the duraton and/or the cost of the project, whch n turn ncreases the ftness value of the solutons. Ths trend can also be observed n Fg. 14 on the rght for the 1-tasks/1-sklls nstances. In Fg. 15 we plot the evoluton of the average best ftness for the nstances wth 1 tasks, 1 sklls, and 4 5 and 6 7 sklls per employee. In ths case the relatonshp between the ftness and the number of employees s 7 6 2 5 5 Duraton 4 3 2 1 2 1 5 2 15 1 1 1 1 15.6.8 1 1.2 1.4 1.6 1.8 2 2.2 x 1 6 Cost Fg. 12. Results wth fve sklls. Labels show the number of tasks and employees of the nstance.

2396 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 6 2 5 5 4 Duraton 3 2 1 5 2 1 2 15 1 1 1 1 15.5 1 1.5 2 2.5 3 x 1 6 Cost Fg. 13. Results wth 1 sklls. Labels show the number of tasks and employees of the nstance..8.7.7.6.6.5.4.3.2 emp1.5.4.3.2 emp1.1.1 Fg. 14. Average best ftness evoluton of the nstances wth 1-tasks/5-sklls (left) and 1-tasks/1-sklls (rght). The label emp dentfes the nstance wth employees. not so clear. However, we can notce that for the nstances wth 1 and 15 employees the number of sklls per employee sgnfcantly affects the best attaned ftness: wth 6 7 sklls per employee the best ftness s hgher than wth 4 5;.e., a vared and larger set of sklls can be profted from f an automatc tool such as ours s used n project management. Ths s n accordance wth the dea that more qualfed people do the work better. However, ths trend was not observed wth fve employees, meanng that even effcent people need a group of help n real world projects. The two fnal plots (Fg. 16) show the evoluton n the nstances wth fve sklls and 2 and 3 tasks. Note n the rght plot that the nstances have a quas-logarthmc evoluton wth a very low ftness. The algorthm fals to fnd a feasble soluton for these nstances and all the ndvduals are then penalzed, thus keepng ther ftness values below.1.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2397.5.45.4.35.3 emp1.25.2.15.1.5.7.6.5.4.3.2.1 emp1 Fg. 15. Average best ftness evoluton of the nstances wth 1-tasks/4-5-sklls per employee (left) and 1-tasks/6-7-sklls per employee (rght). The label emp dentfes the nstance wth employees..45 9.8 x 1 3.4.35 9.6 9.4.3.25.2 emp1 9.2 9 8.8 emp1.15.1 8.6 8.4.5 8.2 Fg. 16. Average best ftness evoluton of the nstances wth 2-tasks/5-sklls (left) and 3-tasks/5-sklls (rght). The label emp dentfes the nstance wth employees. 7. Conclusons In ths work we have tackled the general Project Schedulng Problem wth genetc algorthms. Ths problem s essental for the software engneerng ndustry nowadays and automatcally fndng good solutons to t can save software companes lots of tme and money. A software manager can study dfferent scenaros wth such an automatc tool n order to take approprate decsons on the best project for her/hs company. Furthermore, n our approach, s/he can adjust the ftness weghts to better represent partcular real world projects. The Project Schedulng s a combnatoral optmzaton problem and an exhaustve search can take too much tme to get a soluton. Here, as n some other work [4], the utlty of metaheurstc technques for the problem s clearly stated. Our contrbuton to the software engneerng management s an automated tool based on genetc algorthms that can be used to assgn people to the project tasks n a near optmal way, tryng dfferent confguratons concernng the relatve mportance of the cost and duraton of the project. Although the project model s very smple t can serve as a frst step n the applcaton of evolutonary algorthms to the n slco experments n software engneerng. We have used a genetc algorthm, and have performed an n depth analyss wth an nstance generator. We have solved 48 dfferent project scenaros and performed 1 ndependent runs for each test n order to get

2398 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 statstcally meanngful solutons. The results show that the nstances wth more tasks are more dffcult to solve and ther solutons are more expensve. In the same way, the projects wth a larger number of employees are easer to tackle and can be led to a successful end n a shorter tme. However, the relatonshp between employees and cost s not so smple: n some cases t s drect and n other cases t s nverse. In the future we plan to add new nstances wth addtonal aspects to study the nfluence of the nstance parameters on the dffculty, such as the complexty of dealng wth a large team or the overhead of assgnng a large set of tasks to an employee. Also, we wll solve the problem wth other metaheurstc algorthms. In partcular, we can drectly apply multobjectve metaheurstc algorthms to optmze the two objectves tackled n the work (duraton and cost of the projects). In addton, we plan to apply our algorthms to real world data n order to llustrate how to use the technques n a real software project. Fnally, we wll extend the model to face real world problems from ndustry, once we know whch are the best technques to apply (the goal of ths ntal study). Acknowledgements Ths work has been partally funded by the Mnstry of Scence and Technology (MCYT) and Regonal Development European Found (FEDER) under contract TIN25-8818-C4-1 (the OPLINK project). Francsco Chcano s supported by a grant (BOJA 68/23) from the Junta de Andalucía (Span). We also thank to Gullerme Horta Travassos for easng the access to several publcatons and to an anonymous revew for her/hs constructve comments. Appendx A. Average best ftness evoluton plots In ths appendx we nclude the evoluton of the average best ftness n the nstances of the last two benchmarks. We decded to nclude ths appendx to offer an n depth vew of our results that could be nterestng for.8.7.6.5.4.3.2.1 emp1.45.4.35.3.25.2.15.1.5 9.8 x 1 9.6 9.4 9.2 9 8.8 8.6 8.4 emp1 emp1.7.6.5.4.3.2.1 emp1.28.26.24.22.2.18.16.14.12.1.8 9.5 x 1 9 8.5 8 7.5 emp1 emp1.5.45.4.35.3.25.2.15.1.5 emp1.12.1.8.6.4.2 emp1 9.5 x 1 9 8.5 emp1.7.6.5.4.3.2.1 emp1.14.12.1.8.6.4.2 emp1 9.5 x 1 9 8.5 emp1 8.2 7 8 8 Fg. A.1. Tasks and sklls fxed (horzontal: 5, 1, 1/4 5, 1/6 7 sklls, vertcal: 1, 2, 3 tasks).

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 2399 only some readers. We group related nstances n the same graph n order to compare the traces. When dong so, the queston s how to group the nstances. To clarfy the presentaton we decded to group the nstances accordng to three dfferent crtera. The frst crteron conssts of mantanng n the same graph all the nstances whch have the same number of project sklls, sklls per employee, and the same number of tasks. As we have four possble confguratons of project sklls and three dfferent tasks we have obtaned 12 graphs n ths way, shown n Fg. A.1. In ths fgure we fnd all the graphs shown n Secton 6. Let us observe the smooth curves of the thrd row, all of them belongng to the 3 tasks nstances where the GA does not obtan any feasble soluton. Ths contrasts wth the nosy curves of the central row (2 tasks nstances) for whch the GA does ndeed enter nto the feasble regon of solutons (always after 2 steps approx.). The man concluson that we draw from these graphs s that the fnal best ftness value generally ncreases wth the number of employees. The second groupng s made by plottng together n the same graph the nstances whch have the same number of employees and the same confguraton of sklls (Fg. A.2). Agan we have 12 graphs wth three traces per graph (number of tasks). The frst observaton s that only the curves of the 1-tasks nstances always get a hgher ftness value than the feasble soluton ftness value (.1). The pont at whch the curve starts rsng depends on the number of employees. Wth a larger number of employees the rsng s delayed, perhaps due to the larger sze of the chromosome. In some graphs (lke the one of the 5-employees/1-sklls nstance) we see a modest rsng of the 2 tasks curves. Fnally, the thrd crteron s to group the nstances whch have the same number of tasks and employees, thus obtanng the nne graphs of Fg. A.3. In the frst column (1 tasks nstances) we can see that the fnal best ftness of the 5-sklls nstances s hgher than n the case of the 1-sklls nstances. Ths was already dscussed n Secton 6 when we observed that projects nvolvng 1 sklls were more dffcult to solve than those requrng fve sklls. On the other hand, the pont at whch the curves start a deep ascent s delayed wth the ncrement n the number of employees (ths was also observed n Fg. A.2). The second column helps us to conclude that a larger number of employees makes the search easer..4.35 task1.3.25.2.15.1.5 task2 task3.7.6 task1.5.4.3.2.1 task2 task3.8.7.6 task1.5.4.3.2.1 task2 task3.2.18.16.14.12.1.8.6 task1.4 task2.2 task3.45.4.35.3.25.2.15.1 task1.5 task2 task3.7.6.5.4.3.2 task1.1 task2 task3.4 task1.35.3.25.2.15.1.5 task2 task3.4.35.3.25.2.15.1 task1.5 task2 task3.5.45.4.35.3.25.2.15.1 task1 task2.5 task3.35.3.25 task1.2.15.1.5 task2 task3.7.6.5 task1.4.3.2 task2.1 task3.7.6.5 task1.4.3.2.1 task2 task3 Fg. A.2. Employees and sklls fxed (horzontal: 5, 1, 1/4 5, 1/6 7 sklls, vertcal: 5, 1, 15 employees).

24 E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241.4.35.3.25.2.15.1.5 skll1/4 5 skll5 skll1/6 7 skll1.7.6.5.4.3.2.1 skll5 skll1/6 7 skll1 skll1/4 5.8 skll5.7 skll1.6 skll1/6 7.5 skll1/4 5.4.3.2.1.2.18.16.14.12 skll1 skll5.1 skll1/6 7 skll1/4 5.8.14.12.1.8.6.4 skll1/6 7 skll5.2 skll1/4 5 skll1.12.1.8 skll1/4 5.6 skll5.4 skll1.2 skll1/6 7 9.2 x 1 9 8.8 8.6 8.4 8.2 8 7.8 7.6 7.4 skll1 skll5 skll1/6 7 skll1/4 5 7.2 9.4 x 1 9.2 9 8.8 8.6 8.4 skll1/6 7 skll1 skll1/4 5 skll5 8.2 9.5 x 1 9 8.5 skll5 skll1 skll1/4 5 skll1/6 7 8 Fg. A.3. Employees and tasks fxed (horzontal: 1, 2, 3 tasks, vertcal: 5, 1, 15 employees). References [1] T. Bäck, D.B. Fogel, Z. Mchalewcz, Handbook of Evolutonary Computaton, Oxford Unversty Press, New York, USA, 1997. [2] B. Boehm, R. Ross, Theory-w software project management: prncples and examples, IEEE Transacton on Software Engneerng 15 (7) (1989) 92 916. [3] C. Burgess, M. Lefley, Can genetc programmng mprove software effort estmaton? a comparatve evaluaton, Informaton and Software Technology 43 (14) (21) 863 873. [4] C.K. Chang, M.J. Chrstensen, T. Zhang, Genetc algorthms for project management, Annals of Software Engneerng 11 (21) 17 139. [5] J. Clarke, J. Dolado, M. Harman, R. Herons, B. Jones, M. Lumkn, B. Mtchell, S. Mancords, K. Rees, M. Roper, M. Shepperd, Reformulatng software engneerng as a search problem, IEE Proc. Software 15 (3) (23) 161 175. [6] E. Demeulemeester, W. Herroelen, A branch-and-bound procedure for the multple resource-constraned project schedulng problem, Management Scence 38 (1992) 183 1818. [7] T. Doh, Y. Nsho, S. Osak, Optmal software release schedulng based on artfcal neural networks, Annals of Software Engneerng 8 (1999) 167 185. [8] D. Doval, S. Mancords, B. Mtchell, Automatc clusterng of software systems usng a genetc algorthm, n: Proceedngs of the Internatonal Conference on Software Technology and Engneerng Practce, IEEE Computer Socety, Washngton, DC, USA, 1999, pp. 73 81. [9] R. García, M. Olvera, J. Maldonado, Genetc algorthms to support software engneerng expermentaton, n: Proceedngs of the Internatonal Symposum on Emprcal Software Engneerng, IEEE Computer Socety, Noosa Heads, Australa, 25, pp. 488 497.

E. Alba, J. Francsco Chcano / Informaton Scences 177 (27) 238 241 241 [1] D.E. Goldberg, Genetc Algorthms n Search, Optmzaton and Machne Learnng, Addson-Wesley, Readng, Massachusetts, USA, 1989. [11] S. Hennnger, Case-based knowledge management tools for software development, Automated Software Engneerng 4 (1997) 319 34. [12] K.S. Hnd, H. Yang, K. Fleszar, An evolutonary algorthm for resource-constraned project schedulng, IEEE Transactons on Evolutonary Computaton 6 (5) (22) 512 518. [13] F. Jménez, J.M. Cadenas, J.L. Verdegay, G. Sánchez, Solvng fuzzy optmzaton problems by evolutonary algorthms, Informaton Scences 152 (23) 33 311. [14] B.F. Jones, H.-H. Sthamer, D.E. Eyres, Automatc structural testng usng genetc algorthms, Software Engneerng Journal 11 (5) (1996) 299 36. [15] H.-M. Lee, S.-Y. Lee, T.-Y. Lee, J.-J. Chen, A new algorthm for applyng fuzzy set theory to evaluate the rate of aggregatve rsk n software development, Informaton Scences 153 (23) 177 197. [16] J.-C. Ln, P.-L. Yeh, Automatc test data generaton for path testng usng GAs, Informaton Scences 131 (1 4) (21) 47 64. [17] L.-C. Lu, E. Horowtz, A formal model for software management, IEEE Transacton on Software Engneerng 15 (1) (1989) 128 1293. [18] D. Merkle, M. Mddendorf, H. Schmeck, Ant colony optmzaton for resource-constraned project schedulng, IEEE Transactons on Evolutonary Computaton 6 (4) (22) 333 346. [19] A. Mngozz, V. Manezzo, S. Rccardell, L. Banco, An exact algorthm for project schedulng wth resource constrants based on a new mathematcal formulaton, Management Scence 44 (5) (1998) 714 729. [2] M. Palpant, C. Artgues, P. Mchelon, LSSPER: solvng the resource-constraned project schedulng problem wth large neghbourhood search, Annals of Operatons Research 131 (24) 237 257. [21] C.L. Ramsey, V.R. Basl, An evaluaton of expert systems for software engneerng management, IEEE Transactons on Software Engneerng 15 (6) (1989) 747 759. [22] M. Ronchett, G. Succ, W. Pedrycz, B. Russo, Early estmaton of software sze n object-orented envronments a case study n a CMM level 3 software frm, Informaton Scences 176 (5) (26) 475 489. [23] G. Ruhe, D. Greer, Quanttatve studes n software release plannng under rsk and resource constrants, n: Proceedngs of the Internatonal Symposum on Emprcal Software Engneerng, IEEE Computer Socety, Roman Castles, Rome, Italy, 23, pp. 262 27. [24] B. Talbot, J. Patterson, An effcent nteger programmng algorthm wth network cuts for solvng resource-constraned schedulng problems, Management Scence 24 (1978) 1163 1174. [25] G.H. Travassos, M.O. Barros, Contrbutons of n vrtuo and n slco experments for the future of emprcal studes n software engneerng, n: Proceedngs of the ESEIW 23 Workshop on Emprcal Studes n Software Engneerng, Fraunhofer IRB Verlag, Roman Castles, Italy, 23, pp. 117 13. [26] B. Wall, A genetc algorthm for resource-constraned schedulng, Ph.D. thess, Massachusetts Insttute of Technology, 1996. [27] J. Wegener, H. Sthamer, B. Jones, D. Eyres, Testng real-tme systems usng genetc algorthms, Software Qualty Journal 6 (2) (1997) 127 135. [28] L. Yang, B.F. Jones, S.H. Yang, Genetc algorthm based software ntegraton wth mnmum software rsk, Informaton and Software Technology 48 (3) (26) 133 141.