Assigning Tasks in a -Hour Software Deveopent Mode Pankaj Jaote, Gourav Jain Departent of Coputer Science & Engineering Indian Institute of Technoogy, Kanpur, INDIA 006 Eai:{jaote, gauravj}@iitk.ac.in Fax:+9--90/90 Abstract With the advent of gobaization and the Internet, the concept of goba software deveopent is gaining ground. The goba deveopent ode opens up the possibiity of -hour software deveopent by effectivey utiizing the tie zone differences. To harness the potentia of the - hour software deveopent ode for reducing the overa deveopent tie, a key issue is the aocation of project tasks to the resources in the distributed tea. In this paper, we exaine this issue of task aocation in order to iniize the copetion tie of a project. We discuss a ode for distributed tea across tie-zones and propose a task aocation agorith for the sae. We appy the approach on tasks of a few synthetic projects and two rea projects and show that there is a potentia to reduce the project duration as we as iprove the resource utiization through -hour deveopent. Index Ters: Goba software deveopent, -hour software deveopent, project scheduing, task aocation, dependency graph, optia schedue. Introduction With the advent of gobaization, any copanies have started expanding their presence round the word, which has resuted in a singe organization with utipe geographicay distributed units. With the evoution of internet and other technoogies, the counication aong these distributed units has becoe easier and ore efficient. Organizations that have units in different ocations are naturay considering odes in which goba software teas coaborate across distributed ocations. This idea of goba software deveopent has evoved due to factors ike cost advantage, avaiabiity of arge abour poo, proxiity of oca arket and conditions etc. Iportanty, goba software deveopent aso brings the possibiity of a -hour deveopent ode where the different tiezones of different ocations can be everaged to reduce the tota deveopent tie of a project, through daiy handoffs of work []. The potentia of -hour work day has been expoited to soe extent in software aintenance. For exape, there are any instances of products being supported in India where the custoer in USA ogs the copaint at the end of the day and finds the copaint resoved when the next orning - the resoution takes pace in India when it is night in USA. However, in deveopent projects, goba software deveopent akes a project uti-site and uti-cutura and introduces a new set of counication, technica, anageria, and coordination chaenges [, ]. Soe experience sees to suggest that the counication and coordination difficuties ay have a negative effect on the project schedue [, 6, ]. Soe studies have been done to study the probe of counication in goba software deveopent, and any suggestions have been ade to itigate these[,, ]. Too support has aso been suggested to aeviate soe of the probes []. Even if counication and coordination difficuties can be soved through suitabe toos and technoogies, can distributed software deveopent provide benefits, and if so, to what extent? In this paper we address this question of what potentia benefits can goba software deveopent bring in reducing the project execution tie. For harnessing the benefits that ay be possibe, suitabe counication and coordination systes wi have to be put in pace. An understanding of potentia benefits can hep evauate whether the benefits are worth the costs of such systes. We consider a -hour software factory ode, where utipe teas that are geographicay distributed across different tie zones work on the sae project. Intuitivey, since this ode supports a -hour operation, it shoud be possibe to reduce the deveopent tie. However, the potentia of iproveent is heaviy dependent upon the degree of inter-dependency between project tasks and nature of their various constraints. For exape, if the tasks have fewer dependencies between the, then the deveopent tie depends priariy on the nuber of resources avaiabe, so a uti-site tea provides no extra benefit
over a singe-site tea of the sae size. Ceary, to axiize the reduction in copetion tie through the hour ode, task assignent needs to be done carefuy, so that the project can be copeted in iniu execution tie whie satisfying a the constraints. In this paper, we first present our ode for -hour deveopent and then present a task scheduing agorith. The agorith takes the task ode for a project and the set of avaiabe resources as input and produces a taskschedue with inia schedue ength. We then appy the approach to the task graphs of a few syntheticay generated projects, and the task graphs of two rea projects. We show that not ony there is a substantia reduction in the copetion tie of a project, there is aso an iproveent of the resource utiization in the project. Project Execution Mode We view a software project as a set of activities or tasks. A task is the saest unit of work with a we defined functionaity and externa interface with other tasks. For exape, a task coud be deveoping a software odue, writing a technica docuent, testing a piece of code or any other effort in the process of software deveopent. A task is characterized by the tota effort it needs (we assue that this is in person days). We aso assue that the assignabe tasks are such that they are assigned to one tea eber for execution, which is usuay the case for the owest eve tasks in a project. We assue that the task effort incudes a the tie needed by the resource to perfor the task, incuding the counication tie, and that this effort is the sae for the singe-site deveopent ode, and the utisite, -hour deveopent ode. Software deveopent is a process of ordery execution of these tasks. Since these tasks ay have soe reationship aong the, they cannot be executed independenty. The order of their execution is constrained by the interdependencies between the and their individua requireents. We consider the foowing possibe constraints on the execution of a task:. Operationa Constraint: A task τ j is operationay dependent on another task τ i if task τ j can start ony after the task τ i copetes its execution. For exape, testing a odue is operationay dependent on the coding of that odue.. Ski Constraint: A task has a ski constraint for a particuar ski, if it can be assigned ony to those persons that possess the specified ski. For exape, the task of database design has a ski constraint that it can be assigned to a person that has expertise in database. entry node 0 (0, ) Task # (, S ) (, ) (, S ) (, ) Ski Constraint 6 (, S ) (, S ) (, ) 9 (, ) (, ) 0 (, ) exit node (0, ) (a) Processing tie Figure : An exape task graph 0 6 0 0 (b) 9 If a task does not have any ski constraint, then any resource can execute this task.. Resource Constraint: A task τ has a resource constraint for the task τ if τ ust be executed by the resource which has executed task τ. With this constraint, we cannot assign the resource to task τ unti task τ has been copeted. This type of constraint usuay coes in a project to aintain efficiency. For exape, it is desirabe to assign the task of enhanceent of a software odue to the person who had written that odue. These constraints on the tasks in a project are the ost coon ones that project anagers usuay consider whie scheduing. They need to be satisfied during the execution of tasks. We assue that a the constraints reain sae in singe-site and uti-site deveopents. We represent the task set of a project by a task-graph which is a directed acycic graph (DAG) T = {N, E}, where N is the set of nodes and E is the set of directed edges. Each node represents a task in the task set and edge represents the Operationa dependency between tasks. For a node that represents a task τ i, there is an association (tie(τ i ), S i ), where tie(τ i ) represents the tie required for task τ i for execution and S i is the set of skis for which the task τ i has the ski constraints. For sipicity, we assue that each S i has atost one ski. The nu ski set is represented by the character -. The resource constraint of task τ i for the resource that executed task τ j is represented in the graph by a dotted arrow fro task τ i to task τ j. We refer to the set of iediate predecessor tasks of a task τ i as P (τ i ) and the set of iediate successor tasks of a task τ i as S(τ i ). Figure (a) shows a task graph having tasks, each represented by a node. We assue that T has a singe entry and singe exit node. The entry node is considered as the predecessor of a nodes and the exit node as the successor
of a nodes. Both nodes are considered as duy nodes with zero execution tie. The ength of the path is the su of execution ties of a the nodes on the path. The weight of a node is the argest path ength fro the node to the exit node. In atheatica ter, the weight of node τ is weight(τ) = ax k i φ k tie(i) where φ k represents the k th path fro the node τ to exit node and i represents a task on this path. The individua weight of each node of the exape task graph is shown in Figure (b). The path fro the entry to the exit node whose ength is equa to the weight of the entry node is the critica path of the task graph. A critica path of the exape task graph is shown by the dark arrows. The weight associated with each task represents the iniu tie the schedue ust take fro this task to copete the project. During scheduing, a task with a higher weight wi get the priority if other conditions are satisfied. The seection of a node having the highest weight fro the ready to execute nodes wi ensure that the critica path of a project is being foowed. Resource Mode We assue that a hour day is divided into three - hours tie sots, with a different resource-set for each tie sot. A resource-set coprises a set of individua resources {r, r...r n }. Each resource (i.e. a person) has a set of skis associated with it which represents the skis that person has. The avaiabe resources can be odeed as a resource-tabe, in which each resource is identified by a nuber and for each resource, the resource-set it beongs to, the skis it has, and its working period, are specified. t t+ t+6 R R R r r... r n Figure : Resource Mode Figure represents our resource ode with the three resource-sets R, R, R. Resource-set R ony starts its work when R copetes its tie sot and siiary R ony starts when R copetes its tie sot. For odeing sipicity, we are considering the tie sots that do not overap. In practice, however, an overap between the tie sots of two successive resource-sets is ikey. This overap can be used effectivey for the handing over of tasks, providing carification, and other activities that require interaction. We aso assue that a the resources needed by a project are assigned at the start of the project and are avaiabe throughout the project duration. Theoreticay, the anpower buidup in a project foows a Rayeigh curve[]. However, in practice, in a software project, the resources on a project undergo a few step increases or decreases[9]. And any ties, particuary for saer projects, resources are indeed a assigned in the start and freed at the end. The sack tie avaiabe in such an aocation can be used for activities ike training, docuentation etc. With these odes for tasks and avaiabe resources, our objective is to assign tasks to the avaiabe resources such that the project copetes in shortest duration. The benefit of the -hour deveopent ode wi depend on how efficienty the schedue utiizes the advantage of different tie zones of the resource-sets to reduce the project copetion tie. Task Scheduing Our task schedue agorith is a heuristic based on the critica path ethod. It takes a task graph and a resourcetabe as input and generates a project schedue for the given project. The approach is to foow the critica path of the task graph for scheduing. A ready queue Q of tasks is aintained which contains the tasks that are ready to execute. Initiay, this queue contains a the iediate successors of the entry node. When a task copetes its execution, a of its successors which are ready to execute are added to this ready queue. Ceary, at a given tie, ony tasks in the ready queue can be assigned. However, instead of considering each task in the queue and assigning it, we propose a resource perspective and assign these resources to tasks in an attept to keep the resources as busy as possibe. The idea is that if the resource utiization is high then the task graph wi be copeted quicky. The agorith works as foows. Starting fro tie unit t =, for each tie unit, it considers each of the three tie sots in that tie unit in order. In a tie sot, it considers the avaiabe resources of the corresponding resource-set in order. A resource is avaiabe if it is not executing any task at the current tie unit. For the first avaiabe resource r, it identifies two tasks fro the ready queue τ q, which is the highest weight task that has no ski or resource constraint, and τ r, which is the highest weight task for which r
satisfies its ski or resource constraint. If both of the tasks τ q and τ r do not exist then the agorith oves to the next avaiabe resource. In case if one of these tasks does not exist, then the other is aocated to resource r. If both tasks τ q and τ r exist then one of the wi be assigned to r. If τ r has a higher weight, then it is assigned to r because not ony does it represent the ongest path but aso because r satisfies its ski and resource constraints. If, however, τ q has a higher weight, then assigning it to r ight force task τ r to wait for r ti τ q copetes its execution. It ight ead to increase in the schedue ength. In an attept to iniize the wait for τ r, we copare weight(τ q ) weight(τ r ), which represents the difference between two path engths, with the execution tie of τ q. If the execution tie of τ q is greater than the difference in weights then τ r is assigned to r since otherwise waiting by the task τ r wi ake the path ength fro τ r to exit onger than the path fro task τ q and ay increase the tota copetion tie. On the other hand, if the difference of weights is greater than the execution tie of τ q, then task τ q is assigned to r since the difference in path engths wi accoodate the waiting tie of τ r. The agorith is given in Figure. The fina vaue of t gives the tota tie required to execute the whoe project. This agorith does not guarantee the optia resut but it shoud provide near-optia soutions. This agorith is based on the CP/MISF approach[0], which is regarded as the ost effective heuristic approach for utiprocessor scheduing probe. Our task scheduing probe can be viewed as an extension of traditiona inia execution tie utiprocessor scheduing probe []. With the cobined approach of foowing the critica path and keeping the resources occupied, the fina schedue ength for the given project wi reduce consideraby. Let us see the working of the agorith on the exape task graph of Fig (a). Since the entry and exit nodes are duy nodes, we do not consider the for aocation. The weight of each task is shown in Figure (b). Suppose the avaiabe resources are as shown in resource-tabe of Tabe. Resource # Resource-Set Ski-Sets Work-period R S 00:00-0:00 GMT R S 00:00-0:00 GMT R - 0:00-6:00 GMT R S 0:00-6:00 GMT n R S 6:00-00:00 GMT Inputs: Task graph T, Resource-Tabe. Initiaization: Put a the successors of the entry node in the ready queue Q. Set each resource as avaiabe. Agorith: Repeat step through step 6, for t =,,... :. Repeat step through step 6, for each of the three tie sots (with resource-sets R, R, R respectivey).. If any task τ copetes its processing in previous tie sot, then put a τ S(τ) into ready queue Q provided P(τ ) has copeted execution before this tie-sot. Set the resource r which was executing the task τ, as avaiabe.. If Q then repeat step through 6 for a resources r of the resource-set of this tie sot in order, provided r is avaiabe.. Let τ q be the highest weight task in Q, which has no ski and resource constraint and τ r be the highest priority task such that r satisfies its resource and ski constraint. (If two tasks have sae weight then preference is given to task which has ore iediate successors.). If τ q does not exist then assign τ r to r. If τ r does not exist then assign τ q to r. Reove the assigned task fro Q and set resource r as unavaiabe. 6. If tasks τ q and τ r both exist then, a. if (weight(τ q ) weight(τ r )) > tie(τ q ) then schedue τ q to r; reove τ q fro Q and set r as unavaiabe. b. ese schedue τ r to r. Reove τ r fro Q and set r as unavaiabe. Figure : Task Scheduing Agorith Tabe : Resources for exape task graph At the start of first tie sot of t =, we put task in the ready queue and consider the resources, of the
resource-set R, in order. For the resource, τ r is the task since this is the ony task in ready queue and satisfies its ski constraint for ski S. As τ q does not exist for, thus task is assigned to resource (step ). We now consider the next avaiabe resource. Since there are no ready tasks in ready queue, resource reains ide in this unit of tie. Now we ove to the second tie sot of t =. At the end of the first tie sot, task has copeted its execution as it has one unit of execution tie. So at the start of the second sot of tie unit t =, task, and are in the ready queue. For the resource-set R, both resources and are avaiabe. For resource, task wi be its τ q since it has the highest weight as we as ore nuber of iediate successor than task (step ). There is no τ r for resource, so task is assigned to. For resource, τ q is the task and τ r is the task. As tie()>weight()- weight(), task is assigned to (step 6b). At the start of third tie sot of t =, task is the ony task in the ready queue. For resource n, task is τ q and there is no τ r, so task is assigned to n. This copetes the first tie unit. The schedue at the end of first tie unit is shown in Figure (a). It shows the start and end of the execution of tasks in ters of tie units. At tie unit t =, the ready queue wi be epty at the start of first and second tie sot since no task has copeted its execution in respective previous tie sots. At the end of second tie sot, tasks and has copeted their execution, so tasks and are ready for execution. As resource n is not avaiabe, no task can be assigned in third tie sot. Tasks and are assigned to resources and respectivey at the first tie sot in tie unit t =, since they are τ r for respective resources and there is no τ q. At the second tie sot of tie unit t =, task has copeted execution in first tie sot and hence its successor, task 9 is put in ready queue. At this tie unit, both resources and are avaiabe. For resource, there is no τ q and τ r in ready queue. For resource, task 9 is τ r since has executed task and satisfied the resource constraint of task 9. Consequenty, task 9 is assigned to. n (a) After st tie unit n 9 0 6 (b) Copete Schedue Figure : Task Schedue for exape task graph Siiary, tasks 6, and 0 are schedued and the fina schedue is shown in Figure (b). The tota schedue % reduction 0% 0% 0% > 0% p = 6% 6% % p = % % % p > % % % Tabe : Reduction in Schedue duration ength is tie units. It is aso the optia soution for this probe. Experienta Evauation In order to evauate the effectiveness of the task scheduing agorith, we did a few experients. We generated about 00 task graphs randoy, with the nuber of tasks between to 00. The tie attribute of each task is unifory distributed over the range of to 0 tie units. The nuber of tasks that have been assigned a ski or resource constraints varies fro the 0 percent to 0 percent of the tota nuber of task present in the task graph. The whoe set of task graphs is tested for three different sizes of resource-sets, where the nuber of resources in each resource-set are, and ore than resources respectivey. We chose these resource-set sizes as we expect that a arge project wi be broken into reativey independent, saer sub-projects at a top eve, and the detaied scheduing that we are focusing on wi be appied to these sub-projects, where the tota tea size is not ikey to be too arge. It shoud be pointed out that a resource set size of ipies that the tota tea size for that project is in our ode We appied the agorith on these task graphs and cacuated the respective resutant schedue engths. We aso cacuated the schedue engths this agorith generates if a the resources work at singe ocation, and used that as the basis to deterine the reduction in schedue the - hour ode provides. The resuts are shown in Tabe. The Tabe shows, for different sizes of resource-sets, in what percentage of graphs the reduction in schedue is ess than 0 percent, between 0 to 0 percent and ore than 0 percent. As we can see, the benefit increases as the size of resource-set increases. The ean reduction in schedue ength for the resource-set sizes, and ore than are %,% and 9% respectivey. We aso studied the resource utiization in these projects. Resource utiization is the percentage of tie the resources are occupied by project tasks. We found that the resource utiization aso iproved fro 6% to %, fro 6% to 6%, and fro % to 6%, respectivey, for the different resource-set sizes.
In order to study the potentia benefits on actua projects, we took two actua software projects fro Infosys Technoogies Liited, a Bangaore based software organization. These projects have been executed in the traditiona singe-site anner and their detaied tasks and constraints are avaiabe. We took their actua task schedue, and schedued it using our approach to deterine the overa schedue. In other words, for coparison of schedues, we essentiay siuated the execution of an actua singesite project. The first project is the Weeky Activity Report (WAR)[] syste project and the second is ACIC deveopent project[9]. The detaied project schedue of both projects were exained and various tasks and their dependencies were identified. The task graphs were then generated and various constraints reated to each task were fixed. For effort, we used the estiated effort for each task as given in the project schedue. Activities ike training were not incuded in the task graph. The projects were then schedued in two scenarios when a the resources work in sae tie zone and when a the resources are eveny distributed (to the extent possibe) in three resource-sets. The duration of copetion of different phases in the two scenarios is shown in Tabe and Tabe for the two projects. (An X eans that the phase was not considered for detaied scheduing, osty because these are phases where one or two peope are invoved and detaied scheduing is not an issue. They are there in panning argey because of effort estiation.) For the WAR project the overa reduction in schedue is fro days to days. That is, the overa reduction in the copetion tie of the project by using the -hour ode is %. Siiary, the overa reduction in the ACIC project is %. Note that the actua schedue of these two projects was 9 days and 0 days, respectivey. We did not copare the schedue with the actua, as the actua schedue does not represent the best possibe schedue for a singe-site situation, but a possibe schedue based on the actua resources avaiabe for the project. For a fair coparison, we have copared the schedue for the -hour ode with the schedue that is generated for a singe-site case if the sae scheduing technique was used. 6 Concusions The -hour goba deveopent ode is the approach where a distributed tea works in different tie-zones to estabish a -hour workfow in a singe project. In this paper we discuss the issue of scheduing of tasks to resources for reducing the overa execution tie of a project. We consider a -hour deveopent ode which consists of three teas working in different -hour tie sots. Phases singe resource-set utipe resource-sets Requireent Anaysis X X Project Mngt & Scheduing X X Screen Prototyping 9 Functiona Spec. 9 Sape Appication 9 Architecture & Database Design 0 Detai Design 9 Buiding 6 Unit testing 6 Syste testing & Depoyent Overa Tabe : Resuts for WAR Project Phases singe resource-set utipe resource-sets Project Initiation X X Scheduing and Mngt X X Eaboration Iteration Eaboration Iteration 0 Construction Iteration 6 Construction Iteration 6 Construction Iteration Syste Testing & Depoyent Overa Tabe : Resuts for ACIC Project A software project is viewed as a set of activities or tasks. The project tasks have various constraints for its execution. Operationa dependency of a task constraints its execution order with other tasks. Ski and resource constraint iits the resource space for a task for execution. The goa of task scheduing is to schedue these tasks for execution such that the constraints are satisfied and the graph is executed copetey in the shortest possibe tie. We presented a heuristic for scheduing based on the critica path ethod. It takes the task graph of a project and avaiabe resources as input and generates the inia ength project schedue for the project. We have tried the approach on soe synthetic projects, and on two rea-ife projects. For these two projects, using their actua task sequence, we obtained the schedue for the singe-site case and the schedue for the -hour ode using our scheduing approach. For the exapes, the approach provides a reduction of about 0% to 0%. However, the actua reduction in schedue depends on the nature of the graph. There are any possibe extensions of this work. Ceary the ode can be enriched by taking the counication overhead expicity into account, so as to ode the extra counication cost of the distributed teas. We have worked with non-overapping tie sots. A ore reaistic ode wi consider tie sots that are overapping. In soe projects there ay be soe tasks that have coocation requireent - i.e. engineers working on these tasks shoud be together []. The ode needs to be extended to incorporate this requireent aso. Other constraints that ay exist in soe situations, aso need to be 6
odeed. Overa, we beieve that uch ore work needs to be done to further enrich the ode and then deveop suitabe scheduing agoriths for the. With a better understanding of the benefits and constraints, proper counication and coordination environents can be deveoped to support the tight coordination that is necessary to reap the benefits of the -hour ode. [] L.H. Putan. "A genera epirica soution to the acro software sizing and estiating probe." IEEE Transactions on Software Engineering, Vo, No., 9. pp.-6. [] A. Repenning et. a., "Using coponents for rapid distributed software deveopent", IEEE Software, March/Apri 00, -. References [] I. Ahad, Y.K. Kwok. "Static scheduing agoriths for aocating directed task graphs to utiprocessors". ACM Coputing Survey. Vo., No., Dec,999. pp. 06-. [] E. Care. "Goba Software teas: Coaborating across borders and tie zones". Prentice Ha, NJ. 999. [] E. Care and R. Agarwa, "Tactica approaches for aeviating distance in goba software deveopent", IEEE Software, March/Apri 00, -9. [] C. Ebert and P. De Neve, Surviving goba software deveopent IEEE Software, March/Apri 00, 6-69. [] J. D. Herbseb and R.E. Grinter, "Spitting the organization and Integrating the Code: Conway s Law Revisited" Int. Conf. on Software Engineering 999, pp. -9. [6] J. D. Herbseb, et. a. "An eperica study of goba software deveopent: distance and speed", Int. Conf. on Software Engineering, 00. [] J. D. Herbseb and D. Moitra, "Goba software deveopent", IEEE Software, March/Apri 00, 6-0. [] P. Jaote. "CMM in Practice : Processes for Executing Software Projects at Infosys". Addison-Wesey, 000. [9] P. Jaote. "Software Project Manageent in Practice". Addison-Wesey, 00. [0] H. Kasahara, S. Narita. "Practica utiprocessor scheduing agoriths for efficient parae processing". IEEE Transaction on Coputers. Vo. C-, No., Nov,9. pp. 0-09. [] A. Mockus and D. M. Weiss, "Gobaization by chunking: A quantitative approach", IEEE Software, March/Apri 00, 0-.