assessing staffing needs for a software maintenance project … · 2015. 3. 4. · e-mail:...

Assessing Staffing Needs for aSoftware Maintenance Projectthrough Queuing Simulation

Giuliano Antoniol, Member, IEEE, Aniello Cimitile, Member, IEEE,

Giuseppe A. Di Lucca, Member, IEEE Computer Society, and

Massimiliano Di Penta, Student Member, IEEE

Abstract—We present an approach based on queuing theory and stochastic simulation to help planning, managing, and controlling

the project staffing and the resulting service level in distributed multiphase maintenance processes. Data from a Y2K massive

maintenance intervention on a large COBOL/JCL financial software system were used to simulate and study different service center

configurations for a geographically distributed software maintenance project. In particular, a monolithic configuration corresponding to

the customer’s point-of-view and more fine-grained configurations, accounting for different process phases as well as for rework, were

studied. The queuing theory and stochastic simulation provided a means to assess staffing, evaluate service level, and assess the

likelihood to meet the project deadline while executing the project. It turned out to be an effective staffing tool for managers, provided

that it is complemented with other project-management tools, in order to prioritize activities, avoid conflicts, and check the availability of

resources.

Index Terms—Software maintenance staffing, software process management, discrete-event simulation, process modeling, process

simulation, queuing theory, schedule estimation.

�

1 INTRODUCTION

COST and effort estimations are important aspects of themanagement of software maintenance projects. Soft-

ware development and maintenance are labor-intensiveactivities; the project cost is strictly tied to the requiredeffort, i.e., to the project staffing. In today’s competitivemarket, a compromise has to be found between the servicelevels experienced by the customers and the project costs;sometimes, increasing the project staffing may not beconvenient. Cost/effort estimation is not a one-time activityat project initiation. Initial estimates should be refinedthroughout a project [1], verifying each time the likelihoodto meet the established deadline. Thus, it is essential to trackthe effort spent and reestimate staffing level throughout theentire project lifespan.

Traditional tools such as PERT, CPM, Gantt diagrams,

and earned value analysis help to plan and track the project

activities. However, they play a little role in assessing the

likelihood of meeting the project deadline, staffing main-

tenance projects, helping predict and track the service level

as perceived by customers.We propose an approach based on queuing theory and

stochastic simulation to deal with the staffing, the process

management, and the service level evaluation of coopera-tive distributed maintenance projects. The method has beenvalidated on data from a massive1 Y2K maintenanceintervention on a large COBOL/JCL financial softwaresystem of a European firm. Up to 80 people were assignedto the project, which spanned across four maintenancecenters, maintainers were organized into teams, andmaintenance teams operated both at the customer site andhome site. All maintenance centers cooperated under thecoordination of a control board. The main responsibility ofthe control board was to avoid conflicts, assigning to eachmaintenance center/team a suitable workload.

Queuing theory is a well-consolidated field. Earlystudies on queuing theory date back to 1900 [3]. The theoryhas been successfully applied to a large variety of problems:telephone switching/network design, part repair andmaintenance center staffing, merchandise distribution,and, more generally, service center management. Tradi-tional queuing theory can be adopted to help projectstaffing, restaffing, and service-level evaluation at differentdates. Incoming maintenance requests may be thought of ascustomers queuing up at the supermarket checkoutcounters. The time spent in the queue is related to thecustomer arrival rate and to the type of service obtained.The perceived service levels, measured as queuing systemwaiting times, are obviously related to the number ofcounters, to the distribution of the service times (i.e., thenumber of items each customer acquires), and to the

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 1, JANUARY 2004 43

. The authors are with RCOST—Research Centre on Software Technology,Department of Engineering, University of Sannio, Via Traiano, I-82100Benevento, Italy.E-mail: [email protected], {cimitile, dilucca, dipenta}@unisannio.it.

Manuscript received 11 Jan. 2002; revised 10 Sept. 2003; accepted 17 Sept.2003.Recommended for acceptance by G. Ciardo.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number 115684.

1. The term “massive” refers to those maintenance interventions, such asY2K remediation, Euro conversion, or phone numbering change, involvinga large number of applications simultaneously [2].

0098-5589/04/$20.00 � 2004 IEEE Published by the IEEE Computer Society

configuration of the service centers. Increasing the numberof counters, also called servers, decreases the time spent toobtain a service. However, increasing the number of serversmay not be economically convenient: A compromisebetween costs and customer satisfaction has to be pursued.

Queuing network models representing, at different levelsof granularity, the maintenance processes were considered.A monolithic configuration corresponds to the customer’scoarse-grained point-of-view, while fine-grained modelsexplicitly account for different maintenance process phases,project distribution across different maintenance centers,and rework activities.

In the proposed approach, stochastic simulations ofqueuing networks permit a fine-grained evaluation ofstaffing levels at the project startup and close-down whenstatistical equilibrium (see (1) in Section 3.1) is not achieved.The approach also provides a means to assess the likelihoodof meeting the project deadline and balancing the workloadbetween maintenance centers while executing the project.Different service center configurations may exhibit differentperformance levels and may increase (without changing thenumber of servers) the average perceived service level, aswell as increase the likelihood of meeting the projectdeadline. The features described above combined with thepossibility of viewing the maintenance process from aqueuing network perspective (thus determining the optimalnumber of servants for each maintenance phase, as well asconsidering the effect of phenomena such as abandon orrework) make the proposed approach a valid complementto the previously mentioned mainstream techniques (PERT,CPM, etc.).

This paper extends and complements previous works[4], [5] with a new approach to deal with queuing networks,representing different process phases or maintenance teamallocations. Furthermore, by applying stochastic simulation,statistical equilibrium is no longer required, thus allowingan evaluation of staffing levels at the project startup andclose-down and performing dynamic restaffing. Given theassumptions made (detailed in Section 5.1), the proposedapproach is immediately applicable to massive mainte-nance interventions, such as currency or phone numberingchange, and easily extensible to more sophisticated main-tenance processes.

The remainder of the paper is organized as follows:After an overview on the related work (Section 2), basicnotions on queuing theory and stochastic simulation aresummarized in Section 3 for the sake of completeness.Then, Section 4 introduces the proposed queuing systemmodels. Section 5 presents the case study description, theresearch questions to address, the case study methodol-ogy, and the adopted tools. Case study results arepresented in Section 6. The last sections are dedicated toa summary of lessons learned, paper contributions, andoutline of future works.

2 RELATED WORK

In the past, several studies attempted to draw relationsbetween product/process metrics/analysis and mainte-nance process improvement (e.g., [6], [7]) or productintrinsic characteristics (e.g., [8], [9], [10]), aiming at

enhancing customer satisfaction and reducing costs. Theseapproaches were more focused on process or productimprovement than defining/assessing the staffing, forecast-ing maintenance resources, and managing costs.

In 1981 and then in 2000, Boehm et al. [11], [12] proposedderiving the testing effort and the annual maintenance costfrom the development effort. The COnstructive COstMOdel (COCOMO) is founded on empirical formulae forsoftware cost estimation; the model used in forwardengineering is integrated with the Annual Change Traffic(ACT) parameter to estimate, at the macro level, main-tenance costs. Wiener-Ehrlich et al. [13] presented a formalmodel, based on the Rayleigh model, to estimate the neededmanpower for projects in the Bank Trust Company domain.

An important issue when facing maintenance requests isthat of classifying them to improve planning when/howthey will be served to reduce total effort and costs. Briandand Basili [14] proposed a modeling approach, based onstatistical techniques, to support the classification task.

Literature reports several works applying Process Simula-

tion Modeling to plan, manage and control software life-cycle activities. Kellner et al. [15] describe motivations andpurposes of software development process modeling andsimulation. They highlight the factors characterizing simu-lation and classify the main techniques of simulation andmodeling. As will be described in Section 3, softwareprocess simulation is usually carried out by using systemdynamics and discrete modeling paradigms. In [16], Martinand Raffo, to overcome some of the disadvantages of thetwo paradigms, propose a combined model that representsthe software development process as a series of discreteprocess steps executed in a continuously varying projectenvironment.

Issues connected to empirical studies of software processsimulation modeling are discussed in [17] with particularreference to the estimate of simulation parameters fromreal-world data and to compare actual results to the model’sresults. The paper discusses several statistical and analyticaltechniques to choose among various process alternatives, aswell as examples of how utility functions, financialmeasures, and data envelopment analysis could be usedto evaluate simulation model outputs.

An important contribution to the literature of processsimulation has been given by Abdel-Hamid [18], [19], [20].In [18], Abdel-Hamid published an approach based onsystem dynamics modeling to simulate the staffing of real-world software projects; the model has been used to verifythe degree of interchangeability of men and months [21].Results from the analyzed case study do not fully supportBrooks’ law. A hybrid estimation model is proposed in [20]:The model exploits the system dynamics simulator ofsoftware development presented in [19], coupled with avariety of algorithmic estimators. This approach, accordingto the author, can be used to allow continuous-timemodeling/estimation. In particular, as the project pro-gresses, the model variables can be adjusted in real timeto reflect improved knowledge of the management, while,at project completion, the model can be used for post-mortem analysis.

44 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 1, JANUARY 2004

In [22], software maintenance management strategiesimplemented by some organizations are described and

compared on the attributes of performance, economics,

efficiency, and end-product quality. Subsequently, some

measurements are defined for each attribute. It is then theresponsibility of the manager to choose/define the most

suitable subset of attributes that support his/her own

strategy.An important issue about any prediction model is the

accuracy of its estimates. Jorgensen [23] reports an experi-ence from the development and use of 11 software

maintenance effort prediction models. In this study, the

most accurate predictions were obtained by applyingmodels based on multiple regression analysis and on

pattern recognition.Host et al. [24] published a study that shows how

discrete-event simulation can be used to explore overload

conditions. In particular, a software requirements manage-ment process for packaged software systems was analyzed.

The simulation model was created according to a previous

study of the process and the simulation parameters were

estimated from interviews with process experts.The idea of applying queuing theory to software

maintenance was proposed by Papapanagiotakis and

Breuer in [25]. They proposed a model for the management

of software maintenance based on queuing networks. The

model accounted for technical aspects of the softwaremaintenance process, for metrics obtained on the applica-

tion, and, finally, for the organization’s resources and

requirements. Although they developed a tool to simulatethe behavior of a queuing-based process and to support the

management, no data about application to real projects was

reported.Queuing theory was recently applied by Ramaswamy

[26] to model software maintenance requests. A similarapproach used to model a Web-centric maintenance center

was described in [5]. By adopting a fast lane approach,

authors were able to improve maintenance center perfor-

mances, as experienced by the majority of customers.Commonalities can be found with these two works.

However, the research questions addressed here are

different. Simulations of a software maintenance processwere performed by Podnar and Mikac in [27] with the

purpose of evaluating different process strategies rather

than staffing the system.Most of the work described above deals with the

problem of cost and effort estimation; the problem ofmeeting the project deadline is seldom considered. The

latter may represent a critical issue for massive maintenance

interventions, often addressed by over-staffing the project

(and, thus, increasing the costs). These issues, with someanalyses reported in the present paper (related to the

simplest models), were introduced in [4].

3 BACKGROUND NOTIONS

In this section, background notions about queuing theory,

queuing networks, and statistical simulations will be

summarized. Further details can be found in [3].

3.1 Queuing Theory Notions

A queuing system can be described as customers arrivingfor service, waiting for service if it is not immediate, andleaving the system after being served (by servers). The termcustomer is used in a general sense and does not necessarilyimply a human customer (e.g., maintenance requests can bethought of as customers). A queuing system models thesteady state of the process, while transient situations are nottaken into account. The observable queuing system para-meters are:

1. Arrival traffic rate: the average rate of customersentering the queuing system, � (and/or the inter-arrival time t� ¼ 1=�), and, if available, its statisticaldistribution;

2. Service time: the time a server needs to process arequest, ts, and, if available, its statistical distribution;

3. Queue capacity: finite or infinite; and4. Queue discipline: FIFO, LIFO, random, with priority,

etc.

With reference to Fig. 1, a queue bookkeeping mayregister the distribution and the average values of waitingtimes (tw), the times spent by customers in the system (alsocalled response times—tr), and, finally, the average numberand distribution of customers in the system and in thequeue.

As a shorthand for describing queuing phenomena, anotation has been defined; a queuing system is described bya series of symbols and slashes A=B=m=a1=a2, where A isthe interarrival time distribution, B is the service timedistribution,m is the number of servers, a1 is the capacity ofqueue (infinite if omitted), and a2 is the queue discipline(FIFO if omitted).

A and B may be Markovian distributions (M), determi-nistic distributions (D), Erlang distributions (Ek), or generaldistributions (G). The Erlang distribution is a Gammadistribution with positive integer parameter k and itbecomes an exponential distribution if k ¼ 1 [3], where k

is the number of stages composing the Erlang process.Often, a priori statistical knowledge of the process is

limited; the selection of interarrival and service timedistribution families may be guided by the square of thecoefficient of variation C, defined as the ratio of thestandard deviation to the mean. Available literature [3]

ANTONIOL ET AL.: ASSESSING STAFFING NEEDS FOR A SOFTWARE MAINTENANCE PROJECT THROUGH QUEUING SIMULATION 45

Fig. 1. Queuing model parameters.

suggests an assumption of deterministic distribution whenC2 < 0:3, an Erlang distribution when 0:3 < C2 < 0:7, andan exponential distribution when 0:7 < C2 < 1:3. Values ofC2 > 1:3 require a general distribution.

Note that, if C2 < 1, an exponential distribution may beapplied, giving rise to an overly conservative estimate. Thecase where C2 � 1 models cluster arrivals, such as trainarrivals. Goodness-of-fit tests are required to support andvalidate the assumptions about the chosen distributionfamily.

To measure queuing system performance, several para-meters may be considered; for example, the average timespent by a customer waiting for a server (i.e., tw), theaverage queue length, the average number of busy servers,the server use coefficient (i.e., �, see below), or theprobability SB that all servers are busy. The server usecoefficient is related to the system statistical equilibrium:

� ¼ �tsm

< 1: ð1Þ

This means that the chosen number of servers m avoidsinfinite queue growth. The average time spent by acustomer waiting for a server can be evaluated for anM=M=m model using the following equation:

twðexpÞ ¼ SB

m

ts1� �

: ð2Þ

Equation (2) represents the steady state solution for theM=M=m model, in other words, service time distribution ismodeled by an exponential distribution (C2 ¼ 1). When C2

departs from the exponential distribution value, morecomplex and less tractable models known as M=G=m haveto be adopted. The Pollaczek-Khintchine equation [3]expresses the average time spent by a customer waitingfor a server as:

tw ¼ twðexpÞ1þ C2

s

2; ð3Þ

where twðexpÞ is the waiting time as predicted by theM=M=m model and C2

s is the square of the coefficient ofvariation of service times.

3.2 Queuing Networks

Fig. 1 represents a queuing model at a very high level ofabstraction: Incoming requests are enqueued and processedby one or more servers. More complex models, based onqueuing networks [3], are required to obtain detailedinformation on different process phases.

Queuing network analysis is complex and, in most cases(especially when service times are not exponentiallydistributed and the model is not trivial), it requires asimulation. However, a preliminary conservative analysisassuming exponential distributions (for all the nodes of themodel) is often feasible.

Queuing network parameters are determined by apply-ing Jackson’s theorem [3]. The theorem states that, in anetwork composed of w nodes, each one characterized byparameters Nk (number of servers), tsk (average servicetime, exponentially distributed), and �k (incoming arrivalrate, see Fig. 2), a request may flow to node j (j ¼ 1 . . .w)

with probability pkj or may exit from the system withprobability:

1�Xw

j¼1

pkj: ð4Þ

This means that, for the k� st node, the total arrival rate is

�k ¼ �k þXw

j¼1

pkj�j: ð5Þ

Therefore, once assigned �k (traffic incoming fromoutside the system) and transition probabilities pkj, �k canbe determined by solving a system of linear equations. It isworth noting that the Jackson’s theorem applies only if thesystem is at statistical equilibrium. Even if, due to the taskperformed or to different teams’ expertise, different serversmay exhibit different performances, the number of serversis chosen to ensure flow balance: The exit rate of a node isequal to its incoming rate.

3.3 Simulation

As previously stated, a queuing system only models thesteady state. Therefore, to analyze transient and dynamicbehavior, a simulation is required. Simulation modelsnonstationary processes (or processes not following aknown distribution), as well as complex dynamics andrules (e.g., reworks, routing problems, etc.).

Simulation attempts to build a model that will mimic areal system for most of its relevant aspects. A simulationmay be deterministic or stochastic. In the first case, thebehavior is “point-wise” defined by the output of the model(a point estimate is made for each of the variables ofinterest) and results are repeatable. Stochastic simulationinvolves randomness: Multiple runs may generate differentvalues. Moreover, a simulation may be static or dynamicdepending upon whether or not it involves time.

Finally, simulation may be classified as system dynamicssimulation, discrete-event simulation [15], [16], and state-basedsimulation [28]. System dynamics simulation is well-suitedto describe the interaction between several project factors, torepresent situations such as feedback loops, etc. Discrete-event simulation describes process steps and is well-suitedto model queuing systems such as those described in this


Fig. 2. Queuing network node.

paper. Stochastic state-based simulation models explicitlycapture process-level details, including complex interde-pendencies among process components.

Discrete-event simulation may be approached in threedifferent ways [29]:

. Event scheduling: The idea is to move along the timescale until an event occurs and then, depending onthe nature of the event (arrival of a request, finishingof a process phase, etc.), modify the system stateand, possibly, schedule new events.

. Activity scanning: As time passes, the activities arecontinuously monitored for the satisfaction of aparticular activity, named a conditional activity [29].Such an activity occurs when there are requests inqueue and at least one server is idle.

. Process-oriented: The queuing simulator providesthree essential components: a source that generatescustomer arrivals, a queue to hold waiting custo-mers, and a facility to serve customers. Onceprocess-oriented components are available as build-ing blocks, the modeler need only provide processparameters.

This paper addresses the analysis of the dynamic behaviorof queuing networks via stochastic, dynamic, discrete-eventsimulations. The simulator has been implemented (see

Section 5.5) adopting a process-oriented approach. Thechoice of this approach was motivated by design considera-tions, i.e., we decided to create a library of classes represent-ing the basic building blocks of the queuing system.

4 THE MODEL

To model a maintenance process using queues, differentlevels of abstraction corresponding to different granularityand approximation levels can be considered:

. In the simplest model (Fig. 1), maintenance activitiesand centers are not distinguished; a single queue(i.e., node) models the system.

. At a finer level of detail, different maintenancephases are modeled by different nodes, assigningresources (i.e., servers) to each modeled activity(Fig. 3a).

. The possibility that a request may leave the systemafter a certain phase is taken into account (Fig. 3b).

. Finally, the possibility of rework among differentmaintenance phases is considered (Fig. 3c).

The single-queue model may be regarded as thecustomer view: Requests enter the system and, eventually,a maintenance activity is billed; such a coarse-grained viewmay be extremely useful to easily assess the overall


Fig. 3. (a) Queuing model of a multistage, multicenter maintenance process. (b) Model with exit from the system. (c) Model with rework.

probability of success with a tractable mathematical model.However, for more complex topologies, stochastic simula-tion is needed.

Fig. 3a shows a high level view of a multicenter,multistage maintenance process modeled by a cascade ofqueues. Each stage may involve several maintenancecenters with different numbers of assigned programmers.Maintenance requests enter the system with a constant rateof � requests per day and are processed sequentially (i.e.,FIFO) by one or more nodes.2 Each node, composed of aqueue and one or more servers, represents a phase of thewhole maintenance process. There is no limitation on thegeographical localization of the servers in that the modelabstracts unnecessary details. Communication and coordi-nation activities are accounted for by the estimated modelparameters. This corresponds to the software maintenancecompany internal view: Requests enter the system, undergoa sequence of activities, and finally leave the system.

Fig. 3b shows a model where a request may exit after acertain node of the “chain.” Consider, for example, acomplex system: There may exist components that do notneed any maintenance interventions. Thus, after thecomponents have been analyzed, they leave the systemwithout modification.

Finally, Fig. 3c shows an example of a system in whichthere is the possibility of rework: Some phases may beperformed more than once. In a maintenance process, forexample, after unit testing, one may realize that it isnecessary to remodify the code. In this case, requests thatenter into each node may arrive from the previous node (orfrom outside the system for the first node) or from one ofthe subsequent nodes. Arrival rates, as stated in Section 3.2and also shown in Fig. 2, have been computed using theJackson’s theorem. For sake of simplicity, formulae havebeen omitted in Fig. 3c.

Maintenance centers may be described by a combinationof M=M=m models. However, while, in the case studyreported here, request interarrival times may be describedby exponential probability distribution, service times some-times grossly deviate from M=M=m theoretical assump-tions. In other words, when C2

s > 1, theM=M=mmodel wasreplaced by an M=G=m. In M=G=m, the general distribu-tion G accounts for the increase in waiting times due tohigher service time variability.

5 CASE STUDY

The case study reported here is a massive maintenanceproject, related to fixing the Y2K problem in a largefinancial software system of a European business firm. Theproject started on 2 January 1999 and finished (formally) on14 January 2000. The contract required that all maintenanceactivities were completed by December 1999.

The project, managed and coordinated by a ProductionManager, was organized into three levels:

. Area: an aggregation of one or more applications,managed by an Area Manager.

. Application: a set of functions related to a particularpart of the business, managed by an ApplicationLeader; each application is composed of one or moreWork Packets (WPs).

. (WPs): loosely coupled, elementary units (from oneto nine for each application) subject to maintenanceactivities; each arriving WP was managed by a WPleader and assigned to a maintenance team (theaverage team size was about four programmers).

The system was composed of 84 WPs, each onecomposed, on average, of 300 COBOL and JCL files. These

WPs were produced by the Inventory phase (see below)

from January to the end of July and all maintenance directlyrelated activities for those WPs ended in October. About 80

people (i.e., maintainers, managers, technicians, and secre-taries) were involved (not full-time) in the maintenance of

these WPs. As detailed in Section 5.3, one of the case

objectives is to determine the number of people that,working full-time, would allow successful completion of

the project within the established deadline.The project followed a phased maintenance process

(similar to what defined in [30]), defined inside themaintenance organization, encompassing five macrophases:

1. Inventory deals with the decomposition of theapplication portfolio into independent applicationsand successive decomposition of each applicationinto WPs. The activity was performed in conjunctionwith domain and application experts. Consistencychecks ensured that all the required componentswere included in each WP. For such a large project,the identification of WPs proceeded incrementally,while processing already identified WPs: Thiscreated, as stated in Section 6.1, a Poisson processof incoming maintenance requests. Finally, duringthe Inventory phase, managers carried out earlyeffort estimation and preliminary project staffing.These activities were performed by applying ana-logy-based effort estimation [31], using informationgathered during the assessment phase on about50 percent of the (previously arrived) WPs and ondata available from similar Y2K and Euro projects.

2. Assessment identifies, for each WP, candidate im-

pacted items, using automatic tools. Typically, a

starting impact set is identified (i.e., program points

directly impacted) and then it is augmented by the

set of points impacted by ripple effects [32].3. Technical Analysis (TA) deals with the analysis of

impacted items and identifies a candidate solution

among a set of predefined solution patterns. The

identified solution was documented by adding a

standard-format comment to the item.4. Enactment (Enact): An automatic tool was used to

apply patches to the problems identified andanalyzed in the previous phases. The solution was

often based on windowing [33].5. Unit Testing (UT) was performed on each impacted

WP; tools were used for automatic generation of test

cases. Testing was limited, in the absence of ripple

effects, to the code surrounding the impacted point


2. If the arrival rate � is not constant, simulation is necessary to studysystem behavior.

(extracted using program slicing): This technique,called isolation testing, reduces testing costs in that

drivers can be constructed from a predefined

template.

The first two phases were performed on the customersites by a dedicated team of senior programmers. The teamresponsibilities included inventory, assessment, workloaddispatching, and conflict resolution; all the remainingactivities were carried out by maintenance teams assignedto four different sites. The phases described above werefollowed by integration and delivery related activities,which were not subject of our case study. In order tointegrate and deliver the system within the contractualdeadlines, it was required that all WPs underwent main-tenance by the end of October. Conflict resolution andscheduling were under control of the team manager, whilethe Application Leader handled dependencies among files.Because the inventory was preliminarily performed offlinewith respect to the project, that activity was not included inthe modeled maintenance process.

5.1 Assumptions

This section summarizes all the assumptions made to modelthe software maintenance project described above using thequeuing models detailed in Section 4.

As stated in Section 5.2, this paper assumes requestsgenerated by a Poisson stochastic process (assumptionsupported by tests detailed in Section 5.4.1), an unlimitedqueue size, and a FIFO queue discipline. However,different software maintenance projects may or may notfollow the above assumptions: There may be batch arrivalsor different maintenance requests may have differentpriorities. Details on how queuing models address thesefactors are beyond the scope of this paper and can be foundin [3]. Limited-capacity queues were not consideredbecause, in the organization subject of our case study,there were no cases in which a request was not accepted(and sent back to the customer or to the previous node)because the queue was full.

As previously highlighted, the maintenance interven-tions were carried out by applying a standardizedprocedure; in most cases, problem identification, patchapplication, and unit testing were supported by automatictools. The following assumption were made:

. No particular priority was requested for any WP.The project (except the integration and systemtesting phases, not considered in our case study)dealt with the application of patches to COBOL andJCL sources affected by the Y2K problem: Integra-tion was performed only at the end of the project.

. Because the intervention was highly standardized,different programmer skills and experiences playedlittle (or no) role. The maintenance process wasconsidered as a pool of incoming requests enqueuedand dispatched to the first available maintenanceteam, thereby justifying the FIFO queuing discipline.

. For the same reason, and following in [18], Brooks’law will be assumed not to apply in the case study. Itwas, in fact, assumed that interchangeability be-tween men and months is possible, hence:

ts ’ effort

team size: ð6Þ

It is well-known [21] that this could be an overlyoptimistic assumption. However, given the teamsizes (fewer than eight people) and the maintenancetask (see Section 5), this approximation was con-sidered reasonable. Furthermore, the model can begeneralized to cases for which the Brooks’ law doesapply, e.g., introducing a nonlinearity factor in (6).

5.2 Instantiated Models

Models described in Fig. 3 were instantiated according tothe adopted maintenance process. In particular, threedifferent models were applied to the process:

. A single-queue system (Fig. 4a);

. A system composed of a tandem of two queues(Fig. 4b), one for the Assessment phase and anotherfor all other phases (this model takes into accountthe geographical distribution of the project); and

. A system composed of three nodes (Fig. 4c), one forAssessment, one for Technical Analysis and anotherfor Enactment and Unit Testing. It is worth notingthat not all the requests go beyond the TechnicalAnalysis phase and there may be a percentage ofrework on Enactment and Unit Testing.

Though project data revealed a negligible level of rework,investigation on the effects of different rework levels ispresented in Section 6.3.

5.3 Research Questions

Queuing system basic parameters can be either estimatedby analogy on past projects or derived from the log of anongoing activity. However, as time passes, availableinformation increases, and refined estimates can beobtained. In other words, the research questions addressedin this paper are, to some extent time dependent, anddifferent milestones were established to track projectevolution. The following research questions were investi-gated:

1. How can the collected information on ongoingactivities be used to readjust project staffing?(Sections 5.4.1 and 5.4.2, see results in Table 4).


Fig. 4. Queuing network models instantiated in the case study.

2. For a given staffing level, how accurate are the trestimates obtained by different models, e.g., singlenode model compared to a system explicitlymodeling the different phases? (Section 5.4.2,results are shown in Figs. 6b, 7, and 8).

3. How does the likelihood of meeting the projectdeadline change as the project progresses?(Section 5.4.3, results are plotted in Fig. 9).

4. How do rework and abandonment affect the results?(Rework effects are shown in Section 6.3, whileabandonment effects are shown, for the three-queuemodels, in Table 4 and discussed in Section 6.2).

5. May a periodic restaffing reduce personnel costs?(Section 5.4.5, results are discussed in Section 6.5).

5.4 The Method

An approach inspired by the leave-one-out cross-validationprocedure [34] and by time series analysis [35] was used tomeasure model performances. Collected data points wereconsidered as a time series with a past, a present, and afuture. The first p (past) points, the training set, were used totrain the model, while the remaining n� p (future) points,the test set, were used to assess model accuracy.

As sketched in Fig. 5, each check was articulated in thefollowing steps:

1. data distribution analysis and model parametersestimation;

2. project staffing;3. likelihood of meeting the project deadline estima-

tion; and4. test set model assessment.

In addition, simulation was performed (see Section 5.4.5) toanalyze the behavior of the model in case of periodicalrestaffing.

5.4.1 Data Distribution Analysis and Estimation of

Model Parameters

In order to verify that case study data (interarrival timesand service times) follow a statistical pattern, two taskswere carried out. First, histograms of the data were plottedand their shapes analyzed to select a candidate distribution.Then, the Kolmogorov-Smirnov (KS) goodness-of-fit test[36] and the Chi-square goodness-of-fit test [37] were

performed to assess the similarity of the data distributionwith the candidate distribution.

The KS test computes the largest distance Dn between acandidate distribution function FF ðxÞ and the distributionfunction FnðxÞ computed from the data. The test (i.e., thenull hypothesis that the data fit the expected distribution) isrejected if Dn > dn;1�� (dn;1�� values, said critical KS test

values, are tabulated [36]).The Chi-squared test measures the error between a

candidate distribution’s density function and the datahistogram. The test (i.e., the same null hypothesis as theKS test) is rejected if �2 > �2

k�1;�, where �2 is theChi-squared statistic and �2

k�1;� is the Chi-squaredpercent-point function with k� 1 degrees of freedomand significance level �.

To select the family of distributions, tests on theinterarrival time distribution and on the service timedistributions were performed for the different nodes ofthe queuing system. It is worth noting that the M=G=m

model does not require any hypothesis on service timedistribution.

Once it had been verified that the incoming data follow awell-known statistical pattern, the interarrival rate � wasestimated using the Maximum Likelihood Estimator (MLE).It can be shown that, for exponential distributions, the MLEis equal to the arithmetic mean. Service time descriptivestatistics (mean and standard deviation) were computedover a training set: According to [3], no particular estimatorwas needed in this case.

5.4.2 Project Staffing

Once parameters were estimated, stochastic simulation wasused to compute team sizes (for the different nodes of eachmodel) under the constraint to complete maintenanceactivities, on average, within a given date. Several simula-tions were carried out with increasing team size for eachnode of the model, until all the expected WPs wereprocessed by the chosen deadline. The number of servers(maintenance teams3 for each node) was chosen sufficientlyhigh to ensure that adding further resources did notsubstantially modify the simulated project life-span.


3. From this point, the terms servers and teams will be used indifferently.

Fig. 5. Information flow among the method’s steps.

Project staffing levels are then refined to reach acompromise between personnel cost and waiting time. If

the number of teams per node (servers) is too small, thenthis may produce system instability (the request arrival rate

is greater than request dispatch rate), while increasing thenumber of teams increases the project cost.

Response times evaluated from training set parameterswere compared with those evaluated from the same model,

with � and service times of the test set, to measure the erroroccurred estimating the response times.

5.4.3 Likelihood to Meet the Project Deadline Estimation

The project staffing level cannot be considered withouttaking into account the risks related to an excessive slack time

and the related contractual penalties. The massive main-tenance project was devoted to modifying mission/business

critical software: Remediation costs were not considered theprincipal issue.

The likelihood of meeting the project deadline wasestimated by numerical stochastic simulation based on therefined staffing level (in that it guarantees small responsetimes and the statistical equilibrium of the system). For theexpected workload and any given possible project time-to-finish, in a range of interest around the required projectdeadline, iterative simulations (the number of simulationswas doubled each time until the results for two successiveiterations matched) were performed to compute the like-lihood as the ratio:

# of simulations finished within the deadline

Total # of simulations performed:

5.4.4 Test Set Model Assessment

All of the above activities were carried out on the modelbuilt by means of a simulation on training set parameters.Model assessment was performed on the actual arrival


Fig. 6. Single-queue model: estimated tw and percentage error on tr.

Fig. 7. Queue series: estimated waiting times.

Fig. 8. Three nodes network: overall estimated waiting times and errors on response times for some combinations of servers.

dates and service times (test set). In other words, adeterministic simulation was executed with WPs belongingto the test set.

5.4.5 Analysis of Transient and Adaptive Restaffing

The main drawback of the process described above is thatthe staffing level is constant across the entire project,therefore:

. Project initial and final transients are not handled:Although at the beginning and at the end of theproject, the number of WPs to process concurrentlyis considerably lower, the staffing level considered isthe same as the steady state.

. The possibility of an “adaptive staffing” is notconsidered. It may be useful to restaff the projectwhenever the rate of arrivals and the average servicetimes exceed certain thresholds.

To study the effect of periodic restaffing, new simula-tions were performed as follows:

1. Once a small number of WPs (say 10), necessary fora preliminary estimate of model parameters, arrived,the project was staffed to meet the deadline. Inparticular, given a deadline d, the average finishingdate of the simulation dd, and an acceptable delay(positive or negative) t, a simulation is consideredsuccessful if

jdd� dj � t: ð7Þ

2. Periodically (say every 10 days), parameters werereestimated on data collected from arrived WPs,simulation was executed, and project staffing ac-cordingly modified (if needed).

In the case study reported here, the delay t was chosenequal to 10 days, corresponding to two weeks.

5.5 Tool Support

To train queuing models (i.e., to estimate model parameters)to simulate system evolutions and compute the likelihoodpresented in Section 6, two different tools were used:

1. a queuing system simulator and2. a tool for computing queuing theory parameters.

The queuing system simulator was developed to supportthe determination of the team size required to complete theproject within a given deadline. In the meantime, thelikelihood of meeting the deadline is obtained. The softwareallows the execution of both deterministic and stochasticsimulations. In the latter case, interarrival times and servicetimes are randomly generated and the simulation is iteratedfor a sufficiently high number of times so that resultsobtained do not significantly vary between experiments. Fordeterministic simulations, interarrival times and servicetimes are read from files.

The queuing system simulator consists of a library of C++classes, implementing objects of a queuing system:

. Sources of service requests: An ASCII data file(used for deterministic simulations: requests are read

from a file, containing the arrival dates of therequests) or random sources (used for stochasticsimulations: requests are produced with an expo-nential distribution).

. Queuing nodes composed of a queue and one ormore servers that serve requests enqueued from asource. Service times may be both read from a file orrandomly produced with an exponential distribu-tion (if the distribution of service times is general,then the Pollaczek-Khintchine formula is used toapproximate response times).

. Dispatchers used for queuing networks. This systemrandomly decides (given a transition probabilitymatrix) to which nodes a request goes.

The queuing-theory parameters computing tool is a Perlscript that, given a set of parameters �, ts, C

2s , and number

of servers m, computes the queuing model relevantparameters introduced in Section 3 (e.g., waiting time,server use coefficient, probability that all servers are busy,etc.). Moreover, it also handles queuing networks, given thematrix of pij, that indicates the probability a request has tomove from node i to node j.

6 CASE STUDY RESULTS

The method described in Section 5.4 has been applied to theempirical data obtained by monitoring the project describedin Section 5. Data were initially scrutinized with a seniormanager to assess data quality and to avoid duplication. Theproject plan, assigned by the customer, was assumed as timereference for any further activity. According to the projectmilestones, a target finishing date was fixed at the end ofSeptember. This allowed minimizing the risks of finishingafter the established deadline, i.e., the end of October.

The experiments described in this section were per-formed as follows:

1. The entire data set (composed of arrival date andeffort for all 84 WPs) was split, at different dates,into a training set (WPs arrived before the considereddate) and a test set (WPs arrived after that date).

2. Then, the model was built using the parameters

estimated from the training set, and assessed using

the test set data. In particular, the three project

milestones (end of March, end of April, and end of

May) were considered as reference points for

splitting the data set, i.e., three pairs of training

set and test set were considered. On the available

data set, fixing a restaffing milestone at the end of

March did not allow efficient project restaffing; it

was too early and data available represented only

the initial transient, rather then the project itself.

Similarly, restaffing at the end of May produces

overstaffing because of the final transient. As

reported in [4], a restaffing performed too earlyor too late also produced a poor response time

estimate. A good solution would be fixing a

milestone after half of the WPs were received

(i.e., at the end of April). This date corresponds to

the project midterm that, according to the company


quality guidelines, corresponds to the ideal project

milestone to check project-schedule and/or per-

form restaffing. From this point, the 42 WPs thatarrived from January to April will be referred to as

the training set and the remaining 42, arrived from

May to July, as the test set.3. In a different approach, as described at the end of

this section, the model parameters were periodicallyestimated and a new staffing was determinedaccording to the target date.

6.1 Data Distribution Analysis and ParametersEstimation

Table 1 reports results from KS-Test and Chi-Squared Testperformed on distributions of the training set and the test setdata. As shown, all tests passed successfully for tadistributions (that was required from the assumption thatrequests generated by a Poisson process), while failed forsome ts distributions (in particular, for the assessmentactivity and for the overall ts). However, this did notconstitute a problem: M=G=m models make no assumptionon ts distributions (general, not a priori known) andguarantee a conservative staffing.4

Table 2 shows an excerpt of the maintenance process

parameters corresponding to the time interval (training set)

from January to April. The table summarizes parameters for

the three modeled configurations.

6.2 Project Staffing

The steps explained in Section 5.4 were performed to

determine, at the end of April, the staffing required to

complete the project by the end of September. First, as

explained in Section 5.4.2, it was necessary to determine

team sizes, for the different models, with the estimated

average project completion date. Results are shown in

Table 3.


4. Test results for ts distributions were reported for the sake ofcompleteness since this constitutes a fundamental step in the choice ofthe queuing model to be instantiated.

TABLE 1KS-Test and Chi-Squared Test Results

TABLE 2Maintenance Process Parameters (Times Are Expressed in Hours and Efforts in Men Hours)

TABLE 3Preliminary Project Staffing

Subsequently, queuing theory was used to determine, foreach phase of each model, the number of servers per node,pursuing a compromise between personnel cost andresponse time. Even if a short response time was lessimportant in order to fulfill the established deadline, thisstep was necessary to ensure the statistical equilibriumdefined by (1) and to make all the WPs available as soon aspossible for the integration phase.

The first model analyzed was the single-queue multiple-server model. Fig. 6 shows the waiting time as a function ofthe staffing level, estimated on the training set, and thetr percentage error over the test set. As can be seen, a goodcompromise between performance and cost is near theknee of the tw curve, that means staffing the system with14-15 servers. In this case, the tr error is about 10 percentand, in any case, is always smaller than 30 percent.

A slightly more sophisticated model separates theAssessment phase from the remaining ones (explicitlymodeling the geographical distribution of the project):Fig. 7 shows, for this topology and different staffinglevels, the estimated waiting times. In particular, twoservers for Assessment and 13-14 for TA+Enact+UTensure the best compromise between personnel cost andlow tw (tr prediction errors below 10 percent, see [4]).

Fig. 7, compared with Fig. 6, also highlights that, onthe available data, a separate assessment team does notameliorate the overall tw. In fact, once fixed, the numberof servers m1 (assessment phase) with a correspondingtw1 and the number of servers m2, with tw2, for the servicecenter performing Technical Analysis, Enactment, andUnit Testing, a single maintenance center (responsible forthe entire process) with m ¼ m1 þm2 maintainers obtainstw < tw1 þ tw2. The fact is not surprising; assessment teamshave low utilization coefficients. This means that havingexplicit resources (choice made because of the differentexpertise needed) devoted to assessment prevents the fullresource utilization within the project.

The third model analyzed comprises three differentnodes: one for Assessment, one for Technical Analysis,and one for Enactment and Unit Testing. Furthermore,the model accounts for the fact that not all requests needthe Enactment/Unit Testing (in particular, as shown inTable 2, the percentage of WPs from the training set

requiring Enactment/Unit Testing is 64 percent). Afterperforming (similarly to the previous models) analysis oftw and tr error graphs, the compromise configuration waschosen considering the best combination of staffing forthe different phases.

Fig. 8 reports the total tw (considered as the sum ofwaiting times for the three different nodes, taking intoaccount the fact that only a certain percentage of requestsarrive at the final node) and the percentage errors for tr,varying with different server combinations. It is worthnoting how, for example, 47 different maintainers may beassigned to different phases, a configuration of 3-10-7(Assessment-Technical Analysis-Enactment+Unit Testing)performs better than a 2-9-9. This is not surprising since apercentage of the requests do not require Enactment andUnit Testing. Even in this case, a reasonable compromisebetween cost and performance occurs near the knee of thecurves. The figure suggests a configuration of three serversfor Assessment, nine for Technical Analysis, and eight forEnactment and Unit Testing.

The above considerations lead to the staffing reported inTable 4. It is worth noting that the ts values reported arefunctions of the team sizes (i.e., each ts is computed bydividing the team size the effort shown in Table 2).

As explained in Section 5.4.3, project restaffing needs tobe complemented by the evaluation of the likelihood ofmeeting the established deadline (i.e., the end of October).Simulations to estimate the likelihood of ending the projecton a certain date were carried out for the three models, withthe total number of programmers involved ranging from 44to 46. Fig. 9a shows the results for different dates, rangingfrom September 30th through to December 15th.

6.3 Analysis of Delays Due to Rework

Although data collected from the present case studyrevealed a negligible level of rework, it is interesting toinvestigate how rework could affect the project comple-tion date and the likelihood of meeting the deadline.Simulation was therefore performed assuming that acertain percentage of WPs were randomly subject torework for the Enact-UT phase. It was assumed that therework effort was independent of the effort previouslyspent for Enact-UT, even though the distribution was thesame. It is worth noting that, if a request was previously


TABLE 4Final Project Staffing after Queuing Analysis

subject to rework, it would still have the same probability

of being reworked again. Fig. 9b reports the likelihood of

finishing within a certain deadline as function of the

percentage of rework.

6.4 Model Assessment

As a final step, the test set data were seeded into the model

staffed according to Table 4, simulating the behavior on the

actual data. Results, reported in Table 5, show that, for both

the single queue model and queue series models, the actual

finishing date is very close to the estimated deadline

(30 September). In the three queues network, the error

occurring in the estimation was higher. However, as

highlighted from Fig. 9a, as time advances, the likelihood

of finishing with a three-queues model is always higher

than those of other models.

6.5 Analysis of Transient and Adaptive Restaffing

Fig. 10 shows how the total staffing and the number of

servers for the three different phases change during the

project. The average (simulated) staffing consisted of about

36 people, lower than those (46) obtained by considering

constant staffing. The advantages of adaptive restaffing

may be summarized as follows:

. At the beginning of the project, the number ofrequests enqueued into the system did not requirefull staffing.

. Similarly, at the end of the project, the number ofpending requests decreased so that a smallernumber of servers sufficed. A few days before thedeadline, only one WP remained and, as shown in

the figure, a single server for each phase wasrequired.

. Finally, there are cases for which the arrival rate orthe average service times may be subject to relevantvariations during the project so that restaffing tomeet the deadline or to avoid wasting resources isnecessary.

Fig. 10a also reports the actual project staffing. Theseactual staffing levels were obtained by dividing the daily-recorded effort by eight (the number of working hours perday). This is an optimistic estimate, not accounting foroverheads such as training on the job, administrative duties,or absences such as vacations. The simulated curvecorresponds to an average staffing of 36 people per day,while the actual staffing was, on average, 29 people per day.In other words, the simulation tends to produce an averageoverstaffing of about 20 percent. The figure also highlightsan initial overstaffing (the leftmost point on the simulatedcurve), due to the absence of sufficient training material.The Mann-Whitney test (p-value 1.4e-5 for a significancelevel of 95 percent) confirmed that the difference betweenthe two curves was significant. Thus, the simulation tendsto give us a pessimistic, conservative estimate of thestaffing. However, the overall accuracy is higher since theactual staffing shown in Fig. 10a is the theoretical equivalentactual staffing corresponding to an ideal situation wherepeople work 20 days a month.

7 LESSONS LEARNED

Massive maintenance interventions, as well as many othersoftware engineering projects, are firm deadline projects.Thus, a key parameter to monitor is the likelihood ofmeeting the deadline, in that delays may substantiallyinfluence the project cost. We experienced that queuingsimulation is an effective tool to monitor and assessed thelikelihood of meeting a given project deadline, whilemonitoring the project staffing level.

Another advantage of the proposed approach is thatrework impact may be easily estimated. Different simula-tions with different team sizes and rework levels will leadto different estimates, giving relevant insights to themanagers.


Fig. 9. (a) Likelihood of finishing maintenance within a certain date. (b) Impact of rework.

TABLE 5Finishing Dates Computed by Test Set Simulation

Model parameters could be adjusted as new data arrives,thus refining early estimates. Queuing simulation and,more generally, queuing theory, has further advantageswhen applied to software maintenance projects. Indeed, it isessential that the number of model input parameters is keptlow and, furthermore, that those input parameters can beeasily estimated and understood by managers. Though themodel per-se can be highly complex, the key observation isthat its interface can be kept relatively simple and intuitive.We believe that the parameters required to run a simulationare readily understandable to people working in thesoftware industry. Even with a complex model accountingfor multiple maintenance centers and multiphase main-tenance processes, the required input parameters aresimply: the maintenance request interarrival times, themean effort required by a maintenance task, and a targetdeadline (see Fig. 5). Thus, queue parameters have intuitivephysical meaning and they may be easily obtained fromexisting project baselines by computing simple descriptivestatistics.

When talking to project managers of the Y2K project, wenoticed that they had no difficulty in providing estimatesfor the model required parameters. However, they oftenbased those estimates on a hybrid approach, using analogyand algorithmic methods. Basically, interarrival times andeffort required in a maintenance intervention were com-puted as the average value over past project data. Figureswere then validated and adjusted according to the managerexperience. This empirical study confirmed that queuingsimulation requires fine-grain recorded data, daily or half-daily based; weekly based recording of effort and inter-arrival times produces models which are too coarse, evenworse, more complex models accounting for batch arrivalsmay be required.

Software projects exhibit characteristics quite differentfrom other phenomena that can be modeled by classic (non-simulation-based) queuing theory. In our case study,stochastic simulations revealed the necessity to study thedynamic aspects of the process (i.e., project startup andclose-down, average finishing date, likelihood of finishingwithin a certain date). In this case study, project life spanwas about one year, project startup and close-down covered

about 30 percent of the entire project: In other words, thetransient part was a substantial portion of the entire projectand non-simulation-based approaches should only beconsidered as a first approximation.

Queuing-based models tend to produce a staffing levelthat overestimates the actual staffing. This is especially truefor the transient phases. Thus, for a firm deadline project, inthe worst-case scenario, a queue-based model will lead to aminimization of the project manager risk of excessive delays.In the case study reported here, it was also observed that thetotal effort spent on the project and the area under thesimulated curve shown in Fig. 10 do not appear to be close. Adeeper analysis revealed that the accuracy of the method ishigher than the 20 percent average error shown in the figure.Discussion with company managers revealed that, accord-ing to a company guideline, the average number of workingdays in a month was estimated to be between 17 and 17.5instead of 20. This figure accounts for the different source ofoverheads and absences. Thus, the actual staffing of Fig. 10must be increased by about 13-15 percent. In other words,the average staffing level any manager of the companywould have accepted was not 29 but 33/34 maintainers witha corresponding error of about 6-9 percent.

In the experience of the authors, the proposed approachhas to be complemented and integrated with a detailedwork-breakdown structure and a planning process, todispatch maintenance requests. Given the current state ofthe art in software engineering, we perceive humanintervention to be essential in order to minimize conflictingmaintenance interventions to evaluate the impact ofcommunication overhead inside and among maintenanceteams, etc.

A final issue is the applicability and generality of theapproach. As pointed out in Section 2, simulation-basedapproaches were previously proposed in the literature; inparticular, in [18], the author observed that there areprojects where Brooks’ law seems not to be completelyapplicable. This is also central to our approach; we rely onthe hypothesis that maintenance interventions may bestandardized. In other words, increasing the number ofpeople decreases the project duration. Other massivemaintenance projects, such as the Euro conversion for the


Fig. 10. Periodic restaffing: (a) Comparison between actual and simulated staffing. (b) Periodic restaffing of different activities (simulated curves).

new European Union members or changing the phone

numbering system (to be performed in the US by 2010), are

likely to exhibit characteristics very similar to a Y2K

massive maintenance intervention [2].

8 CONCLUSIONS

Data from a massive, corrective maintenance project have

been presented together with an approach based on

queuing theory and stochastic simulation to deal with the

staffing, management, and assessment of maintenance

projects.Queuing theory and stochastic simulations are highly

effective at evaluating staffing levels, as well as supporting

and assessing restaffing decisions. The paper shows how

simulations can be carried out to model project startup,

close-down, and to evaluate the likelihood of meeting the

project deadline. The latter fact, evaluated for different

network topologies and rework levels, gives to manage-

ment a broader view of the comparison between the actual

project estimated status and the project plan. The likelihood

of success can be used to establish a trade off between

staffing/restaffing, accepted risks, project delays, and

customer expectations.The main advantages of the proposed approach can be

summarized as follows:

. It is highly effective at evaluating the likelihood ofmeeting the project deadline.

. Rework, as well as abandonment, can be explicitlymodeled and their effects on project staffing andproject milestones assessed.

. Project start-up and close-down can be explicitlymodeled.

As a final remark, it has been shown how different

project management approaches impact on resource utiliza-

tion, thereby allowing effective comparison of different

topologies with respect to the likelihood of meeting the

project deadline.

ACKNOWLEDGMENTS

This research has been supported by the project “Virtual

Software Factory,” funded by the Ministero della Ricerca

Scientifica e Tecnologica (MURST) and jointly carried out

by EDS Italia Software, University of Sannio, University of

Naples “Federico II” and University of Bari.

REFERENCES

[1] T. DeMarco, Controlling Software Projects. Yourdon Press, 1982.[2] C. Jones, “Mass-Updates and Software Project Management in Is

Organizations,” http://www.artemis.it/artemis/artemis/lang_en/libreria/mass-updates.htm, 1999.

[3] D. Gross and C. Harris, Foundamentals of Queuing Theory. JohnWiley & Sons, 1998.

[4] G. Antoniol, G. Casazza, and G.A. Di Lucca, M. Di Penta, and F.Rago, “A Queue Theory-Based Approach to Staff SoftwareMaintenance Centers,” Proc. IEEE Int’l Conf. Software Maintenance,pp. 510-519, Nov. 2001.

[5] M. Di Penta, G. Casazza, G. Antoniol, and E. Merlo, “ModelingWeb Maintenance Centers through Queue Models,” Proc. Conf.Software Maintenance and Reeng., pp. 131-138, Mar. 2001.

[6] T.M. Pigoski and L.E. Nelson, “Software Maintenance Metrics: ACase Study,” Proc. IEEE Int’l Conf. Software Maintenance, pp. 392-401, 1994.

[7] G.E. Stark, “Measurements for Managing Software Maintenance,”Proc. IEEE Int’l Conf. Software Maintenance, pp. 152-161 1996.

[8] J. Daly, A. Brooks, J. Miller, M. Roper, and M. Wood, “The Effectof Inheritance on the Maintainability of Object-Oriented Software:An Empirical Study,” Proc. IEEE Int’l Conf. Software Maintenance,pp. 20-29, Oct. 1995.

[9] T. Khoshgoftaar, B.E. Allen, R. Halstead, and G.P. Trio, “Detectionof Fault-Prone Software Modules during a Spiral Life Cycle,” Proc.IEEE Int’l Conf. Software Maintenance, pp. 69-76, 1996.

[10] T. Pearse and P. Oman, “Maintainability Measurements onIndustrial Source Code Maintenance Activities,” Proc. IEEE Int’lConf. Software Maintenance, pp. 295-303, Oct. 1995.

[11] B.W. Boehm, Software Engineering Economics. Prentice Hall, 1981.[12] B.W. Boehm, E. Horowitz, R. Madachy, D. Reifer, B.K. Clark, B.

Steece, A.W. Brown, S. Chulani, and C. Abts, Software CostEstimation with Cocomo II. Prentice Hall, 2000.

[13] W.K. Wiener-Ehrlich, J.R. Hamrick, and V.F. Rupolo, “ModelingSoftware Behaviour in Terms of a Formal Life Cycle Curve:Implications for Software Maintenance,” IEEE Trans. SoftwareEng., vol. 10, no. 4, pp. 376-383 1984.

[14] L.C. Briand and V.R. Basili, “A Classification Procedure for anEffective Management of Changes during the Software Main-tenance Process,” Proc. IEEE Int’l Conf. Software Maintenance, 1992.

[15] M.I. Kellner, R.J. Madachy, and D.M. Raffo, “Software ProcessSimulation Modelling: Why? What? How?,” J. Systems andSoftware, vol. 46, nos. 2/3, pp. 91-106, 1999.

[16] R.H. Martin and D.M. Raffo, “A Model of the SoftwareDevelopment Process Using Both Continuous and DiscreteModels,” Int’l J. Software Process Improvement and Practice, vol. 5,nos. 2/3, pp. 147-157, 2000.

[17] D.M. Raffo and M.I. Kellner, “Empirical Analysis in SoftwareProcess Simulation Modeling,” J. Systems and Software, vol. 47,no. 9, 2000.

[18] T.K. Abdel-Hamid, “The Dynamics of Software Project Staffing: ASystem Dynamics Based Simulation Approach,” IEEE Trans.Software Eng., vol. 15, no. 2, pp. 109-119, Feb. 1989.

[19] T.K. Abdel-Hamid and S.E. Madnick, Software Project Dynamics:An Integrated Approach. Prentice Hall, 1991.

[20] T.K. Abdel-Hamid, “Adapting, Correcting, and Perfecting Soft-ware Estimates: A Maintenance Metaphor,” Computer, vol. 26,no. 3, pp. 20-29, Mar. 1993.

[21] F. Brooks, The Mythical Man-Month, 20th anniversary ed. AddisonWesley, 1995.

[22] G.E. Stark and P.W. Oman, “Software Maintenance ManagementStrategies; Observations from the Field,” J. Software Maintenance—Research and Practice, vol. 9, pp. 365-378, Dec. 1997.

[23] M. Jorgensen, “Experience with the Accuracy of SoftwareMaintenance Task Effort Prediction Models,” IEEE Trans. SoftwareEng., vol. 21, no. 8, pp. 674-681, Aug. 1995.

[24] M. Host, B. Regnell, J. Natt och Dag, J. Nedstam, and C. Nyberg,“Exploring Bottlenecks in Market-Driven Requirements Manage-ment Processes with Discrete Event Simulation,” Prosim, July1999.

[25] G. Papapanagiotakis and P. Breuer, “A Software MaintenanceManagement Model Based on Queuing Networks,” J. SoftwareMaintenance—Research and Practice, vol. 6, no. 1, pp. 73-97, 1994.

[26] R. Ramaswamy, “How to Staff Business Critical MaintenanceProjects,” IEEE Software, vol. 17, no. 3, pp. 90-94, May/June 2000.

[27] I. Podnar and B. Mikac, “Software Maintenance Process AnalysisUsing Discrete-Event Simulation,” Proc. Conf. Software Maintenanceand Reeng., pp. 192-195, Mar. 2001.

[28] D.M. Raffo, W. Harrison, and J. Vandeville, “Coordinating Modelsand Metrics to Manage Software Projects,” Int’l J. Software ProcessImprovement and Practice, vol. 5, nos. 2/3, pp. 159-168, 2000.

[29] J. Banks, J. Carson, and B.L. Nelson, Discrete-Event SystemSimulation. Prentice Hall, 1998.

[30] IEEE std 1219: Standard for Software Maintenance, 1998.[31] M.J. Shepperd and C. Schofield, “Estimating Software Project

Effort Using Analogies,” IEEE Trans. Software Eng., vol. 23, no. 11,pp. 736-743, 1997.

[32] Software Re-engineering, R. Arnold, ed. IEEE Computer SocietyPress, Nov. 1993.


[33] E.C. Lynd, “Living with the 2-Digit Year, Year 2000 MaintenanceUsing a Procedural Solution,” Proc. IEEE Int’l Conf. SoftwareMaintenance, pp. 206-212, 1997.

[34] M. Stone, “Cross-Validatory Choice and Assessment of StatisticalPredictions (with Discussion),” J. the Royal Statistical Soc. B, vol. 36,pp. 111-147, 1974.

[35] G. Box and M. Jenkins, Time Series Forecasting Analysis and Control.San Franscisco: Holden Day, 1970.

[36] M. Hollander and D.A. Wolfe, Nonparametric Statistical Methods,second ed. Wiley-Interscience, 1999.

[37] J.L. Devore, Probability and Statistics for Engineering and the Science.Duxbury Press, 1999.

Giuliano Antoniol received the doctoral de-gree in electronic engineering from the Uni-versity of Padua in 1982. He worked at Irst for10 years were he led the the Irst ProgramUnderstanding and Reverse Engineering(PURE) Project team. He has published morethan 60 papers in journals and internationalconferences. He served as a member of theprogram committee of international conferencesand workshops such as the International Con-

ference on Software Maintenance, the International Workshop onProgram Comprehension, and the International Symposium on Soft-ware Metrics. He is presently a member of the editorial board of theJournal Software Testing Verification and Reliability, the JournalInformation and Software Technology, Empirical Software Engineering,and the Journal of Software Quality. He is currently an associateprofessor the University of Sannio, Faculty of Engineering, where heworks in the area of software metrics, process modeling, softwareevolution, and maintenance. He is a member of the IEEE and the IEEEComputer Society.

Aniello Cimitile received the Laurea degree inelectronic engineering from the University ofNaples, Italy, in 1973. He is currently thechancellor of the University of Sannio inBenevento, Italy, where he is a full professorof computer science. Previously, he was withthe Department of “Informatica e Sistemistica”at the University of Naples Federico II. Since1973, he has been a researcher in the field ofsoftware engineering and his list of publications

contains more than 100 papers published in journals and conferenceproceedings. He serves on the program and organizing committees ofseveral international conferences and on the editorial and reviewercommittees of several international scientific journals in the fields ofsoftware engineering and software maintenance. He is a co-editor-in-chief of the Journal of Software Maintenance and Evolution: Researchand Practice. He has been responsible for many international andnational applied research projects. His research interests includesoftware maintenance and testing, software quality, reverse engineer-ing, and reuse reengineering. He is a member of the IEEE and theIEEE Computer Society.

Giuseppe A. Di Lucca received the Laureadegree in electronic engineering from the Uni-versity of Naples “Federico II,” Italy, in 1987 andthe PhD degree in electronic engineering andcomputer science from the same university in1992. He is currently an associate professor ofcomputer science in the Department of “Ingeg-neria” at the University of Sannio. Previously, hewas with the Department of “Informatica eSistemistica” at the University of Naples “Fed-

erico II.” Since 1987, he has been a researcher in the field of softwareengineering and his list of publications contains more than 50 paperspublished in journals and conference proceedings. He serves in theprogram and organizing committees of conferences in the field ofsoftware maintenance and program comprehension. His researchinterests include software engineering, software maintenance, reverseengineering, software reuse, software reengineering, web engineering,and software migration. He is a member of the IEEE Computer Society.

Massimiliano Di Penta received the laureadegree in computer engineering in 1999 and thePhD degree in computer science engineering in2003 from the University of Sannio in Bene-vento, Italy. Currently, he is with RCOST–Research Centre On Software Technology atthe same university. His main research interestsinclude software maintenance, reverse engi-neering, program comprehension, and search-based software engineering. He is the author of

more than 20 papers which appeared in international journals,conferences, and workshops. He serves on the organizing committeesof workshops and conferences in the software maintenance field. He is astudent member of the IEEE.

. For more information on this or any computing topic, please visitour Digital Library at http://computer.org/publications/dlib.


assessing staffing needs for a software maintenance project … · 2015. 3. 4. · e-mail:...

Documents