Proceedings of the 38th Hawaii International Conference on System Sciences

Transcription

1 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 Staffig Software Maiteace ad Support rojects Jai Asudi, Sumit Sarkar Iformatio Systems ad Operatios Maagemet, School of Maagemet Uiversity of Texas, Dallas, Richardso, TX-758 {asudi,sumit}@utdallas.edu Abstract I the past decade outsourcig a software system s support ad maiteace has become relatively commo across most orgaizatios. I this paper we cosider a few issues goverig the staffig of support ad maiteace projects from the perspective of the software service provider. Though queueig models have bee used for the estimatio of staffig requiremets ad cotrol i the past, little attetio has bee paid to the service level agreemets (SLAs) that most service providers have to adhere to, as part of the service cotract. I this paper we cosider the problem of fidig the miimum staffig requiremet by modelig the support eviromet as a M/M/s queue while icludig a SLA type requiremet. For the same system, we show that a lower boud o the service rate exists ad how it is to be calculated. We also validate certai rules of thumb that software project maagers ca employ i light of chagig coditios ad discuss the caveats to these rules of thumb. Keywords Software maiteace, systems support, Queueig theory, service level agreemet (SLA) 1. Itroductio Software maiteace is defied as the process of modifyig existig operatioal software while leavig its primary fuctios itact [4]. It applies to activities such as ehacemet, error correctio ad adaptatio[5][7]. Software support ad maiteace as a activity is expected to cosume almost 5 to 8% of the total lifecycle cost of a computer based system [5]. A large umber of software compaies provide outsourced support ad maiteace services of legacy software systems ad applicatios for orgaizatios aroud the world. I coutries such as Idia, the reveues eared from software maiteace ad support costitutes more tha 6% of the total reveues eared i the software idustry [3]. Itese competitio amogst service providig firms leads to the developmet of service cotracts that require adherece to certai miimum quality levels for service provided. These clauses, typically called service level agreemets (SLAs), stipulate, across various dimesios, the type ad quality of service to be provided by the service provider. No-adherece to the SLA stipulatios leads to the accrual of moetary pealties i the short term ad possible loss of a cotract i the log term. With little differetiatio betwee firms i terms of type of service, the competitio for ew cotracts is fierce. Overstaffig of a project team ca guaratee the adherece to the SLAs, but raises costs eough to make the bid less competitive. Uderstaffig will lead to ot oly possibly missig the SLA requiremets, but also to a overstretched, demoralized project team. We thus see a eed for establishig a robust techique to obtai a optimal staffig level for maiteace ad support projects give a specified SLA. I this paper, we describe the use of a M/M/s queue to model the maiteace ad support eviromet. Usig the above model, we describe a process that could be used by project maagers to compute the staffig levels for maiteace ad support projects give the SLA requiremets. While the productivity could differ across software developmet persoel i a orgaizatio [5], i this paper we assume the average productivity is the same for each persoel i a project. We show that there is a miimum value (lower boud) that the average service rate ca take i order that the project ca meet the SLA requiremets. We show a way to compute this lower boud. We mathematically validate a rule of thumb for the staffig of service ceters i the light of icreasig arrival rates ad show that there exists a ecoomy of scale with icreasig size. Sectio 2 provides a brief motivatio for our aalysis ad describes aspects of a maiteace ad support cotract. Sectio 3 reviews basic results of queueig theory, the otatios, ad results for the M/M/s queue ad discusses some of the prior work that has applied queueig models to staffig problems. I sectio 4 we describe the process of determiig the miimum umber of persoel ad prove ad discuss other results. Sectio 5 cocludes with the limitatios of the curret work ad our ideas for future work /5/$2. (C) 25 IEEE 1

2 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces Motivatio: The Maiteace Cotract Software service orgaizatios provide support for problems related to operatio ad maiteace of existig software products. The problem could vary from cofiguratio issues to code-level issues. The type of support provided depeds o the cotract betwee the cliet ad the support orgaizatio. We highlight a feature of the cotract that we model ad address i this paper. With the icreased maturity of software outsourcig, the maiteace cotracts have evolved to iclude progressively more striget requiremets [3]. May firms eter ito fixed-price cotracts. These cotracts stipulate a fixed amout of moey to be paid for the maiteace ad support service for a certai period of time, after which the cotract will be reviewed ad reewed. These cotracts also require that the service firm adhere to certai quality of service requiremets which are typically called Service Level Agreemets (SLAs). Beyod specifyig the level ad coverage of service (8hr/day or 24/7), these SLAs stipulate a time period withi which the service orgaizatio would a) respod to the request ad b) resolve the request. Typical SLAs cosider multiple levels of service, usually grouped by the criticality of the request. The criticality/severity is determied by the extet of fiacial exposure, work outage, umber of cliets affected, etc. The cotracts also stipulate pealty clauses if the service orgaizatio does ot meet the support ad service level requiremets. Typically, the support orgaizatio is supposed to meet the requiremets 9-95% of the time. Give these coditios, there is a icetive for the service providig orgaizatio to be more accurate i their estimates of team size (ad thus provide competitive bids if eed be). Curretly the method adopted by maagers is ad-hoc ad although based o persoal experiece, there is o theoretical model that is used to iform this decisio. This paper shows the applicatio of a soud theoretical model to this situatio. This model ca also be used by the cliet orgaizatio. Traditioally, maiteace cotracts have bee billed accordig to time-ad-material cosumed [3]. There are still may projects that are billed i this maer. With icreasig competitio ad ballooig costs for maiteace, may firms are ow critically examiig the cotracts with their service providers. I time-ad-material cotracts i.e., cotracts where cliets are billed by perso-hour allocated to the support of a software product service orgaizatios ted to pad the support team with extra persoel over a period of time. I this situatio, while obtaiig a higher billable reveue stream, the service orgaizatio is guarateed to meet the service level requiremets of limited resolutio times. I circumstaces with o bechmark or robust way of calculatig the appropriate staffig level, cliets have o way of kowig that they are beig overcharged for the services redered. We thus see that i the case of time-ad-materials based pricig, the cliet orgaizatio should moitor team size to esure that they are ot beig overcharged, ad ca use our model for this purpose. 3. Review of Theory ad ractice 3.1 Queueig Theory Queueig theory is a well developed field ad ivolves the mathematical study of waitig lies [6],[8]. These lies are formed whe the istataeous demad for a particular service exceeds Cliet Orgaizatio Mait./Support requests λ L erso1 erso2 Support/Service Orgaizatio erso3 erso-s Figure 1: The Basic Queueig rocess /5/$2. (C) 25 IEEE 2

3 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 the curret capacity to provide that service. It has bee used extesively for a variety of problems like telephoe switchig, customer call-ceter support, ad for the staffig of repair ad maiteace ceters. We ca also model a software maiteace project as multi-server queue, sice the requests for support/maiteace are usually more tha the limited persoel i a project ca address immediately. This results i the problems queueig up ad are usually addressed o a first-come-first-served basis (for problems of same importace). This is typical of a basic queueig process. Figure 1 describes the basic queueig process where the cliet orgaizatio geerates maiteace or support requests which are received ad queued at the support/service orgaizatio. The various elemets used to characterize a queueig system are: 1. Arrival atter: The arrival patter by which maiteace requests are made must be specified before the system ca be modeled. A commo assumptio is that the requests are geerated out of a oisso process ad hece the elapsed time betwee cosecutive requests has a expoetial distributio. This is deoted by the letter M which stads for the Markovia process. 2. Queue Capacity (a1): This is the maximum permissible umber of requests that ca be i the support orgaizatio s system. For our eviromet we assume the queue legth to be ifiite. 3. Arrival Rate (λ): This is the average rate at which requests arrive ito the system.. 4. Service Disciplie (a2): This refers to the order i which requests from the queue are chose for resolutio. Usually a first-come-first-service disciplie is assumed. 5. Service Rate(): This is the average rate at which a request is resolved. Usually, the distributio of service times is assumed to be expoetial. Hece the average service time for a request t s = (1/). A queueig system is usually described by the series of symbols: A/B/m/a1/a2, where A is the iter-arrival time distributio of requests, B is the service time distributio of requests ad m is the umber of servers or persoel hadlig the requests. Thus a system with oisso arrival distributio, expoetial service times, S umber of persoel, ifiite queue capacity ad a first-come-first-served disciplie, is deoted by M/M/s. Values for a1 ad a2 are dropped for otatioal simplicity. For a M/M/s system, some of the commo otatios we use i this paper are: (t) = probability that exactly requests are i the (queueig) system at time t. icludes those beig served as well as those waitig to be served. W = total time a request speds i the system (queue + service) ρ = λ/(s) = the fractio of time the servers/persoel are busy. It is also called the utilizatio factor. For a system to reach steady-state, this value must ecessarily be less tha 1. Some of the well-kow results (that we use) for a M/M/s queue are [8]: ad = s = 1 = λ! λ =! λ s s! s λ + s!, if s, if 1 1 λ s s s 1 (EQ2) (EQ1) The distributio of the total waitig time W is give by: { W > t} (EQ3) = e t λ s t ( s 1 λ / ) 1 e 1 + s!(1 ρ ) s 1 λ / 3.2 Related Work o Staffig Software Maiteace Ceters I the past few years, researchers have explored the applicatio of queueig theory to determie staffig of software support ad maiteace ceters [1],[2],[11],12]. The problem is to determie the /5/$2. (C) 25 IEEE 3

4 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 umber of persoel eeded i order to service maiteace requests. This umber is usually calculated based o a prior determied performace measure such as a preparedess level, a deadlie date, or the utilizatio factor. The staffig of software maiteace ceters ca be cosidered to be similar to that of staffig ay customer support/maiteace related busiess such as call ceters. For example, [9] examies the staffig of servers for a eviromet ivolvig timevaryig demad for services. However, i most of the cases ivolvig call-ceter type customer support, the measure of performace of the system is usually the time that a request waits i queue before service commeces. I software maiteace queues, there are few cases of balkig (where requests i a queue jump from oe queue to aother) or reegig (where requests suddely leave a queue) which are ofte observed i call-ceter type customer-support queues[14]. Ramaswamy [12] describes a process to staff busiess-critical maiteace projects. The techique describes the use of a pre-computed lookup table for determiig the base staffig level for the project. The decisio variables are the icomig request volume(ρ*) ad the preparedess level (). ρ* is the ratio of the rate at which all requests are made to the rate at which requests are serviced per-perso(λ/). The preparedess level () is the probability that ay request made is immediately serviced. Here the preparedess level is used as a measure of service quality. The preparedess level for a M/M/s system is computed as = s 1 = = s 1 = λ! (EQ4) The preparedess level is thus the probability that a icomig request will see ot more tha (s-1) pedig requests ad hece be serviced immediately. This measure of performace is appropriate oly for very critical maiteace projects or emergecy helplie telephoe services which eed requests to be teded to immediately. However, this may ot be true for all IT systems support. For systems where the resolutio of request must occur withi a reasoable amout of time (i.e. ot immediate), this type of performace measure leads to a relatively higher staffig level (tha a pure resolutio time SLA) for the maiteace ceter. M. D. eta et. al. [11] describe the process of determiig the staffig level for a maiteace project through simulatio. The parameters used for the simulatio are from a publicly archived project ad the results are compared to the actual staffig levels for this project. The performace measures cosidered are: staffig level for o queueig of requests (i.e., request is served immediately, similar to [12]) ad staffig level for a request to be teded to withi 8 hours. I additio to these measures they also explore the effect of havig a express lae for requests. The simulated queueig results show that havig a dual priority system leads to reductio i the waitig time for requests ad that the actual project was overstaffed. The papers by Atoiol et. al. [1],[2] are similar to [11] i their use of a simulatio model for a maiteace project. However, i this case, a multistage, multi-ceter maiteace process is simulated (as a series of M/G/s queues) to determie the probability of fiishig a particular maiteace task by a prescribed deadlie date. They examie issues of re-adjustig project staffig midway through a project ad how well the theoretical queueig model predicts the observed results. Our work here differs from the above cited work as we cosider the issue of meetig specific quality (or SLA) requiremets. The techiques described i [1],[2],[11] ad [12], utilize results that are averaged over time. Usig these techiques to compute the staffig level will result i the requests meetig a particular time costrait or SLA requiremet o average - hece oly 5% of the time, as opposed to 9% or 95% of the time as is the case i reality. With similar assumptios, we show how ew isights ca be gaied cosiderig the SLA requiremet. We also show that the SLA requiremet will make the maagers staff their projects at a higher level as compared to whe SLA requiremets are ot cosidered. 4. Modelig the Maiteace Eviromet 4.1 Computig the Number of ersoel, S Ramaswamy[12] argues that assumig that the iterarrival times ad service times of requests to be expoetial is valid for error correctio ad adaptatio types of maiteace projects. We thus model the maiteace eviromet as a M/M/s queue described i sectio 3 with a sigle service level. We assume that each team member is equally capable i the resolutio of requests. We cosider that, accordig to the cotract, a stipulated service /5/$2. (C) 25 IEEE 4

5 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 time T* withi which the icomig requests must be resolved is already provided. If we cosider a stadard queueig model ad use the average rates to compute the umber of persoel, the we will have a situatio where we will meet the requiremet o average, i.e., (W>T*).5 However, give our eviromet of a pealty clause, we kow that we must satisfy the requiremet at least X% of the time (where X is greater tha 5). This traslates to: (W>T*) (1-X/1) Solvig for S to satisfy this coditio guaratees us that X% of the requests will be resolved withi time T*. From EQ3 we see that, oe caot obtai a explicit expressio i S, the umber of persoel required i a project. Thus we eed to solve this umerically for give values of λ,, T* ad X. Example: Let us cosider a (fairly realistic) project situatio where Arrival rate λ = 15 requests per week, Service rate, = 3. requests per week per perso SLA requiremet T* =.8 weeks (4 days i a 5day week) ad SLA compliace level X = 9% To solve for S, we first determie that the miimum value for S for a feasible solutio is 6 (such that ρ= (15/(3.*S)) < 1). We the calculate the value of (W>T* S=6) usig EQ3. Sice the value of (W>T* S=6) =.22 >.1 (1.-.9), we kow that we will ot be able to satisfy the SLA requiremet. Iteratig for higher values of S = 6,7.., we obtai (W>T* S= 8) =.98 <.1. Thus we kow that if we had 8 persoel i our maiteace team, we will be able to satisfy the SLA of resolvig requests withi 4 days 9% of the time. The above example shows how oe ca compute the umber of persoel required to staff a maiteace project i the presece of striget SLA requiremets. It is true that this is ideed the base level of staffig required to adhere to the SLA. As described i [12] addig a overhead will deped o the complexity ad risk of the project beig cosidered. No. of ersoel (S ,S-5 3.,S Arrival Rate (Lamda) Figure 2: Number of persoel vs arrival rate (λ) for 5 th ad 9 th percetiles We also solved the system for differet values of the arrival rate (λ). Figure 2 compares the umber of persoel required for various λ for the average (5%ile) ad the 9%ile cases (i.e. 9% of the requests are resolved withi 4 days, with average service rate 3. requests per week per perso). Similarly, oly cosiderig the 9%ile case, we plot i Figure 3 the chagig umber of persoel required with differet arrival rates (λ=1 to 5) ad differet service rates ( = 3.5, 4.5, 5.5) Number of ersoel (S ,S-9 4.5,S-9 5.5,S Arrival Rate (lamda) Figure 3: Number servers vs arrival rate for 9 th percetile case For all of the above cases, we use a fixed SLA time of T*=.8 weeks = 4 days. 4.2 Lower boud for the Service Rate () The results obtaied i the previous sectio appeal to our ituitio as we observe (from Figure 3) that with decreasig service rates () we eed more persoel to meet our SLA requiremet for the same arrival rate. Ituitio tells us that as log as we icrease the umber of persoel, we will be able to lower the resolutio time of requests. Thus a heuristic for decreasig service rates is to proportioally icrease the umber of servers /5/$2. (C) 25 IEEE 5

6 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 However, there are limitatios to this heuristic. Cosider the situatio where the average arrival rate (λ) = 15 requests per week, the service rate () = 3. requests per week ad the time by which we eed to resolve 95% of the requests is T* =.8 (4days). A prelimiary calculatio shows that 1/ < T* which tells us that o a average we should be able to meet this service level requiremet. However, solvig EQ3 for the asymptotic case of s=, we obtai the followig: t { > t} = e { W > T *} W Thus for e T* l(1 X ) T * For X =.95 ad T* =.8, 3.74 (1 X ) (1 X ); This result shows us that there is a lower boud o i order to satisfy ay particular SLA (T*, X). Thus, for our example of = 3. requests per week, we will ever be able to satisfy the SLA requiremet of 95% requests withi T*=.8 (4 days) irrespective of the umber of persoel we put oto the team. This lower boud is idepedet of the arrival rate ad oly cosiders the time take to resolve requests ad the time stipulated by the cotract. Thus, before a project maager decides to compute the umber of persoel (s)he requires for a give maiteace project situatio, (s)he should esure that the average service rate for requests exceeds the miimum level for the give SLA (T*, X) requiremet. 4.3 Ecoomies of Scale We ow compare two eviromets ad a test a heuristic that maagers ca apply to a maiteace project. Cosider that a maiteace project observes a sudde doublig of the arrival rate (λ to 2 λ). If the maager doubles the umber of persoel o the project, will (s)he still be able to adhere to the SLA requiremet? For solvig this problem we cosider the simple case of arrival rate chagig from λ to (2λ) ad S beig chaged from 1 to 2. We argue that this result ca be geeralized sice the equatios used satisfy boudary coditios for S=1. For case I where arrival rate () 1 For 1 ρ1 = ; where ρ1 = λ, ad 1+ ρ 1 2 t(1 2 ρ ) (1 e t ρ (2) = e ρ1 (1 2ρ1) Cosider the special case of ρ =.5. The, = e (1 ρ ) t,for all t >. case II where arrival rate is = λ ad s = 1 2λ ad s = 2 t t t 2 ( 2 ) = e 1 + ad (1) = e. 3 Clearly (1) > (2), ad similarly,we ca show that for all ρ1 < 1, () 1 > (2). Thus we see that (W>t λ, s=1) for case I is always greater tha (W>t 2λ, s=2) for case II. This shows that as we icrease λ, we progressively require proportioally lesser umber of persoel to meet the same service level requiremet. Due to the iteger costrait o the persoel for lower values of λ, the differece is ot very proouced. Thus for our example, we ca assure the project maager that the rule of thumb of doublig umber of persoel for a doubled arrival rate for request will esure adherece to the stipulated SLA time. This result is similar to the oe show i [13] where it is proved that the utilizatio typically icreases with icreasig umber of servers ad arrival rate. A iterestig implicatio of this result is that larger maiteace service ceters are preferred for outsourcig tha smaller ceters i the presece of SLA deadlies. This result appeals to ituitio, sice a larger facility will be better at pickig up the slack time eeded to maitai a particular service level tha a smaller facility. 4.4 Assumptios ad Cotributio The aalysis show i this paper rests o the assumptio that the arrival rates are oisso ad the service rates are expoetial. While this approximatio has bee observed i some cases [1], the case studies described i [1], ad [11] exhibit larger variace i service time tha a typical /5/$2. (C) 25 IEEE 6

7 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 expoetial distributio. For this purpose oe may have to cosider a differet queueig model such as the M/G/s queue which uses a geeral distributio istead of a expoetial oe for the service rate. However, we believe our methodology ad results will hold eve for the geeral distributio case. Ideed, as the service time (ad its variace) for requests icreases, the differece betwee the umber of persoel required to satisfy SLAs ad the average case will be more proouced. The M/M/s queue is a special case of the M/G/s [6] ad i our situatio ca be cosidered to be a lower boud o the umber of persoel required. Our example uses coveiet values for X ad T* to covey our ideas. These values may be differet for differet projects. However, we believe that the cotributio of part of this paper is to show that uder circumstaces of SLA requiremets, team size eeds to be carefully chose. We also describe the process by which oe ca compute the umber of persoel required i order to meet the SLA requiremets stipulated i the cotract. Aother cotributio is establishig the lower boud o the service rate for a give SLA requiremet. This lower boud establishes the miimum umber of persoel that a maager requires for a service project i order to meet the SLA requiremet. Give a rule of thumb of icreasig the umber of persoel i a team proportioally to the icrease i the arrival rate, we proved that this rule of thumb will guaratee meetig the SLA requiremets (give that they did so prior to the icrease i arrival rates). I fact, we show that there is a ecoomy of scale with a icrease the umber of persoel i a maiteace team ad the project maager would do well to reduce the team size ad yet maitai the same service level. The implicatio of this result is that maagers would do better to have a large service team tha a umber of smaller service teams addressig specific applicatios as log as the average service rate remais the same. Aother applicatio of this work is that maagers ca use the results obtaied from this model to moitor their maiteace project closely ad cotrol it. Over time, the arrival rate(λ), service rate() or eve the SLA will chage. Computig the results usig the ew parameters, the maager would kow exactly whe (s)he must add/remove persoel from the project. Thus, this model provides a meas for the maager to moitor ad cotrol the quality of maiteace service from the perspective of resolutio times. 5. Limitatios ad Future Work Mathematical models are abstractios of reality, whose purpose is to impart a certai level of ituitio to the practitioer. Sice the models are abstractios, they have their limitatios ad ca address oly specific questios regardig the system beig modeled. I this paper we have tried to model a maiteace project with the SLAs. We assume that the icetive structure of the SLA cotract is such that it is optimal for the service provider to adhere to these SLA requiremets. We believe that this assumptio is valid i the highly competitive eviromet that service providers are operatig i, where there are log term implicatios to beig o-compliat. I reality, most SLAs have multiple service levels with differig required respose times. We believe that our aalysis, while limited i its applicatio provides us some ecessary isights ito the staffig problem, before we try to solve a more complicated problem of multiple service levels with differig respose times. Quite aturally this will be a area of future work we pla to pursue ad we will borrow from established cocepts i priority queues. Queueig theory assumes that all the persoel have the same average service rate. Thus a extesio of this work could be i the area of project staffig i the light of differig productivity levels amogst persoel. This differece is reported to be as large as a order of magitude i some cases [5]. With the icrease i the amout of outsourcig of software support ad maiteace services, developig a theoretical basis for measurig ad cotrollig the maiteace process becomes critical. Establishig a quatitative basis for measuremet is a essetial part of this exercise, which the above mathematical models attempt to address. We are curretly i the process of acquirig maiteace related data from several such projects. We pla to use this data to improve our models either i terms of accurate descriptios of the relevat distributios or accurate depictio of the maiteace process itself (with priorities ad a reward structure). 6. Refereces [1] G. Atoiol, G. Casazza, G.A. Di Lucca, M. Di eta ad F. Rago, A queue theory-based approach to staff software maiteace ceters, /5/$2. (C) 25 IEEE 7

8 roceedigs of the 38th Hawaii Iteratioal Coferece o System Scieces - 25 roceedigs of the IEEE Iteratioal Coferece o Software Maiteace, 21, 7-9 Nov. 21, pp [2] G. Atoiol, A. Cimitile, G. A. Di Lucca ad M. Di eta, Assessig Staffig Needs for a Software Maiteace roject through Queueig Simulatio, IEEE Trasactios o Software Egieerig, Vol 3 Num 1, Ja 24, pp [3] A. Arora, V.S. Aruachalam, J. M. Asudi, ad R. Ferades, The Idia Software Services Idustry, Research olicy (3) 8, 21, pp [4] V. Basili, L. Briad, S. Codo, Yog-Mi Kim, W.L. Melo, J.D. Vale, Uderstadig ad predictig the process of software maiteace releases, roceedigs of the 18th Iteratioal Coferece o Software Egieerig, 1996 pp [5] B. Boehm, Software Egieerig Ecoomics, retice Hall, 1981 [6] D. Gross ad C.M. Harris, Fudametals of Queueig Theory, 3 rd Editio, Wiley, 1998 [7] W. Harriso, C. Cook, Isights o improvig the maiteace process through software measuremet, roceedigs of Itl. Coferece o Software Maiteace, 199, pp [8] F. S. Hillier ad G. J. Lieberma, Itroductio to Operatios Research, 7 th Editio, McGraw Hill, New York, 21 [9] O. B. Jeigs, A. Madelbaum, W. A. Massey ad W. Whitt, Server Staffig to Meet Time- Varyig Demad, Maagemet Sciece, vol. 42, No. 1, 1996, pp [1] H. Kug ad C. Hsu Software Maiteace Life-Cycle Model, roceedigs of the Iteratioal Coferece o Software Maiteace, 1998, pp [11] M. D. eta, G. Casazza, G. Atoiol ad E. Merlo, Modelig web maiteace ceters through queue models, Coferece o Software Maiteace ad Reegieerig, March 21. [12] R. Ramaswamy, How to staff busiess-critical maiteace projects, IEEE Software, 17(3), May-Jue 2, pp 9-94 [13] W. Whitt, Uderstadig the Efficiecy of Multi-Server Service Systems, Maagemet Sciece, vol. 38, No. 5, 1992, pp [14] W. Whitt, Improvig Service by Iformig Customers About Aticipated Delays, Maagemet Sciece, vol. 45, No. 2, February 1999, pp /5/$2. (C) 25 IEEE 8