Qualitative Simulation Model for Software Engineering Process

Qualitative Simulation Model for Software Engineering Process He Zhang

Ming Huo

Barbara Kitchenham

Ross Jeffery

School of CSE, UNSW

School of CSE, UNSW

National ICT Australia



[email protected]

School of CSE, UNSW National ICT Australia

[email protected]

[email protected]

Abstract Software process simulation models hold out the promise of improving project planning and control. However, quantitative models require a very detailed understanding of the software process. In particular, process knowledge needs to be represented quantitatively which requires extensive, reliable software project data. When such data is lacking, quantitative models must impose severe constraints, restricting the value of the models. In contrast qualitative models are able to cope with imprecise knowledge by reasoning at a more abstract level. This paper illustrates the value and flexibility of qualitative models by developing a model of the software staffing process and comparing it with other quantitative staffing models. We show that the qualitative model provides more insights into the staffing process than the quantitative models because it requires fewer constraints and can thus simulate more behaviors. In particular, the qualitative model produces three possible outcomes: adding staff can increases project duration (i.e. Brooks’ Law), adding staff may not affect duration, or adding staff may decrease duration. The qualitative model allows us to determine the conditions under which the different outcomes can occur. Keywords software process modeling, staffing process, qualitative simulation model, process simulation, QDE, Brooks’ Law

1. Introduction In the late 80’s, Abdel-Hamid proposed the use of quantitative Systems Dynamic models to simulate the dynamic aspects of a software project [1]. The approach was intended to attain a better understanding of project behaviours and to improve both project planning and project control. Although this approach has shown great promise, in practice, it is not frequently used. The main problem with quantitative

Proceedings of the 2006 Australian Software Engineering Conference (ASWEC’06) 1530-0803/06 $20.00 © 2006

IEEE

[email protected]

simulation models is that they require very detailed understanding of the processes they simulate. Such models require reliable data for their initial construction. Furthermore they require additional data to tailor the general model to the specific working practices of a particular company. When knowledge of the software process is limited or inadequate, quantitative simulation models impose strict constraints on the models which results in deterministic outcomes that neglect other possibilities. Qualitative simulation (also known as qualitative reasoning) is a modeling method that copes with a lack of precise knowledge by reasoning at a more abstract level than quantitative models. It is a powerful technique for creating and applying system/process models especially when the process is only partly understood. With incomplete knowledge, a simulation model generates qualitative descriptions of all the possible behaviours. They are presented as a set of possible behaviors and states consistent with a QDE (qualitative differential equation) model of the world, which expresses natural types of the incomplete knowledge from real world. Ramil and Smith developed a qualitative model with reference to quantitative equations to extract the qualitative trends of software evolution [2]. They employed qualitative simulation to reason about the second-order behaviour patterns of the evolution process, rather than a set of particular behaviours. This is the only example of software process modeling with qualitative simulation. In this paper, a qualitative simulation model of the staffing process in software development has been built. The simulation generates a set of the possible behaviors which may happen when development team size changes during the development process. We examine the possible behaviors and compare them with the results of previous models and empirical evidence. Section 2 provides the description on how to build qualitative simulation models. We describe the qualitative abstracting structure and constraints of the software staffing process model in section 3. In section

4, we compare our results with previous models and discuss the underlying reasons for the differences. Finally, section 5 presents our conclusion on the qualitative staffing model and proposes future work.

2. Qualitative Simulation In this section, we briefly introduce the procedure for developing a qualitative simulation model and identifying the required inputs and outputs. The procedure of qualitative modeling and simulation generally involves the following steps in the sequence shown in Figure 1. We follow this procedure in modeling the software staffing process qualitatively. Model building requires modeling assumptions that specify which aspects of the world can be ignored or must be involved. Physical scenarios are the descriptions of the real world fragments which need to be generated to abstract elements by using the modeling assumptions. Modeling assumptions are based on the incomplete knowledge we gained so far, and then are required to transform a collection of fragments into a model [3].

QDE is the input constraint model to QSIM (the qualitative simulation algorithm and tool, implemented by Lisp [12]). QDE needs to specify: 1) a set of variables, representing a continuously differentiable function of time; 2) a quantity space for each variable, specified in terms of a totally ordered set of symbolic landmark values which are critical values to the system; for example, in the staffing process model, ASG_SIZE is one landmark, which represents the initial requirements of the project, and when remaining-size becomes 0 (another landmark), it indicates that the project is finished; 3) a set of constraints which explicitly state the relationships among the variables; and 4) associated transition functions for switching QDEs. QSIM performs the simulations and generates all possible behaviors. The typical differential constraints in QDE are shown in Table 1: Table 1 Differential Constraints (add x y z) { x t y t z t (mult x y z) { x t x y t z t (minus x y) { x t y t ( d

Figure 1 Steps of Qualitative Modeling and Simulation

A system is normally modeled as a set of ordinary differential equations (ODEs) which are the equations that involve the derivatives of the quantitative functions of variables. At a higher level, a qualitative differential equation (QDE) represents a large set of possible ODEs, for example, each M+ (or M-) function represents the set of all monotonically increasing (or decreasing) functions. When only the incomplete knowledge is available, we can just build QDEs instead of ODEs to represent the relationships and values of the variables qualitatively.


IEEE

x y)

d x t y t dt (constant x) d { x t 0 dt

dt

{

The simulation is based on a constraints satisfaction scheme. The constraints are derived from the knowledge of software processes in the real world. All possible qualitative states are propagated and then the inconsistent values are refuted by the constraints we set at the beginning. The scheme finally decides which behaviors are consistent with the constraints and permitted to be generated. The output produced by QSIM is a set of possible qualitative behaviors and each behavior is a sequence of states. Each state in a behavior describes an open temporal interval or a time point. These qualitative states present the system behavior from its initial state to its final state in graphic views. Time is also treated as a qualitative variable in QSIM. Its landmarks are generated by QSIM when necessary, they indicate critical points of other variables or the transitions [4].

3. QSIM Model for Staffing Process Three previous researches have investigated the software staffing process using quantitative models. This section gives a brief description of these models and then we present our qualitative model for the software staffing process.

3.1 Previous Models Abdel-Hamid's Model: Abdel-Hamid and Madnick modeled the basic process of software human resource management with System Dynamics. They assumed two workforce levels, i.e. "new hired workforce" and "experienced staff", and then formulated the assimilation process as a first-order exponential delay [5]. They then enhanced manpower assimilation by separating the procedure into four stages with different productivity levels. They restricted the scope of their model to middle-sized applications projects. Madachy's Model: Madachy developed a software staffing model using System Dynamics, which examines the classical Brooks' Law [6]. He simplified Abdel-Hamid's model by focusing on the assimilation procedure. He built his model with two connected flow chains representing software development and staff assimilation. The "requirements" are transformed into "developed software" at "software development rate". The "new project personnel" are transformed into "experienced personnel" at "personnel allocation rate". Both of these staffing models were used to verify Brooks’ Law. Unfortunately, these models used specific numeric values, which were selected from the literature or historical data of company projects, to quantify the factors in the models. Further, they simulated the process with the data from particular projects or example as inputs. Stutzke’s Model: Stutzke developed a simple model in order to perform a similar investigation, with a similar result [7]. He undertook the analysis of the process and effort of assimilating the new employees. He then tested his model against an actual project in which the manpower was doubled successfully and the original schedule achieved. Stutzke believed that the added burden of communication in a larger project was a second-order effect and did not model it. None of their models followed the modeling procedure in Figure 1 to develop their models.

3.2 QSIM Model The QSIM (qualitative simulation) model of software staffing process was developed by following the qualitative modeling procedure in Figure1. The “Physical Scenario” is that of adding new staff to a software project. We conduct Step 2 through Step 4 to present the modeling approach. The last step “Quantitative Behaviours” will be used in the future


IEEE

research with semi-quantitative simulation as the extension of this paper. 3.2.1 Qualitative Abstract Elements Both Abdel-Hamid's and Madachy's models are quantitative models which consist of a set of ODEs. In our research, we create the qualitative model on the base of a minimal set of assumptions of the software staffing process, and avoid the quantitative relations which came from the particular types of software projects and may not fit other projects or organisations. The qualitative model is derived from some basic assumptions, including the unstated assumptions in the previous models: 1. Software requirements (project size: SP) do not change during the project life-cycle; 2. SP includes the necessary reworking performed in project; 3. Software requirements (SP) are transformed from remaining size (SR), which initially equals to project size, into the completed size (SC) at the software development rate; 4. Project team (WFT) consists of experienced workforce (WFEX) and newly hired workforce (WFNW); 5. Nominal development rate (RND) has linear relationship with workforce (WF) and their productivity (PD); 6. Adding more people to a project results in a larger communication overhead (RCO); 7. RCO is the only negative impact on RND; 8. A new employee's productivity (PDNW) is initially lower than experienced staff's productivity (PDEX) on average; 9. Average PDEX does not change during project; 10. A new employee must be trained by experienced personnel before reaching their productivity level. Based on the above assumptions, we abstract the corresponding qualitative constraints in Table 2. Table 2 Assumptions of Staffing Model

Assumption 1. no changes of requirements SP 2. no reworking during project 3. SP is transformed to product by RSD 4. WFT consists of WFEX and WFNW 5. RND is calculated by multiplying PD by WF 6. increasing WFT increases RCO

Constraint constant SP S C + SR = SP RSD = d(SC)/dt WFT = WFEX + WFNW REXD = PDEX * WFEX RNWD = PDNW * WFNW RCO = M+(WFT2)

Assumption

Brooks suggests that communication overhead increases by a factor of n(n-1)/2, where n is the project team size [8]. It implies that increasing the size of software project team increases the effort of communication overhead (assumption 6). Further, the qualitative abstract structure was created to visualize the qualitative constraints of software staffing process (Figure 2).

Constraint

7. RSD is difference between RND and RCO 8. PDNW is less than PDEX initially 9. PDEX is constant on average 10. WFNW are assimilated into WFEX by RAS

RSD = RND - RCO INI_NW_PD < NML_EX_PD

constant PDEX WFET + WFED = WFEX RAS = d(PDNW)/dt

SP

SC

d/dt

d/dt

RSD

RCO

- SP: Project Size - SC: Completed Size - SR: Remaining Size - RSD: Software Development Rate - RND: Nominal Development Rate - REXD: Experienced Employee Development Rate - RNWD: New Employee Development Rate - RCO: Communication Overhead Rate - RAS: Assimilation Rate - WFT: Total Workforce - WFEX: Experienced Workforce - WFED: Experienced Workforce for Development - WFET: Experienced Workforce for Training - WFNW: New Hired Workforce - PDEX: Experienced Workforce Productivity - PDNW: New Hired Workforce Productivity

SR RND

REXD

RNWD

X

X

x

M+

PDEX > PDNW WFEX

x

x

d/dt x

RAS WFT

M+

y

z

Monotonically increasing relationship between x, y x+y=z

y

WFED

WFET

M+

WFNW

x y

d/dt d/dt

X

y

y

z

d(x)/dt = y

-d(x)/dt = y

x*y=z

Figure 2 Qualitative Abstracting Structure of Software Staffing Process

Initially, the remaining project size (SR) equals the requirements (SP). As time progresses, the remaining size decreases and will be processed to become completed software size (SC), which represents progress made in development. The project will be completed when completed size equals the initial requirements, or the remaining size drops to zero. There are two major components in this model. The first one is software development rate (RSD), which is the development speed of software project. It is determined by the two factors: the nominal development rate (RND), and the equivalent communication overhead rate (RCO). The RND can be further decomposed into development rate contributions from the experienced personnel and new personnel.


IEEE

The total workforce (WFT) equals the experienced workforce (WFEX) plus the newly hired workforce (WFNW), each group works at different productivity rates. Because new employees join the project, a portion of experienced staff (WFET) have to leave their development tasks to train the new hirees. The experienced employee development rate (REXD) results only from the experienced workforce for development (WFED). A monotonically increasing function (M+) exists between the workforce and corresponding development rate. It means that increasing the manpower in project leads to a higher nominal development rate. However, to determine the actual development rate in project, we also need to consider the communication overhead rate (RCO), which causes a drop in the actual

development rate (RSD) below nominal rate (RND). It is expressed as a nonlinear function of the total workforce (WFT). Abdel-Hamid and Madnick [5] described the function as (0.06n2). While we formulate the relation by the basic accepted Brooks’ assumption (assumption 6) as “the communication overhead rate monotonically increases with the square of total workforce”. The second differential relation is the assimilation rate (RAS) of new workforce injected, which represents how quickly the productivity of new staff increases to the level of experienced staff through training. 3.2.2 QDE Programming Two QDEs were developed to convert the qualitative abstract model (Figure 2) to constraint programs. One QDE is used to describe the normal software development process, and the other to present the interaction and relations in staff assimilation process. Normal Software Development QDE: Figure 3 shows the constraint definitions in software development QDE. This QDE represents the normal software development process without new employees being hired. All the constraints are based on the first four assumptions in Section 3.2.1. (constraints (add Sc Sr Sp) (constant Sp ASG_SIZE) (d/dt Sc Rsd) (d/dt Sr mRsd) (minus Rsd mRsd) (constant WFnw 0) (constant WFt) (add WFex WFnw WFt) (add Rexd Rnwd Rnd) (constant PDex NML_EX_PD) (Mult PDex WFex Rexd) (constant Rco) (add Rsd Rco Rnd) (mult WFt WFt WFsq) (M+ WFsq Rco))

Figure 3 Constraints of "Software Development QDE"

Assimilation Process QDE: Abdel-Hamid only formulated the assimilation process as a first-order exponential delay. The model of this process can be refined in three different ways. Refinement 1: The newly hired staff will be gradually transferred into the experienced staff pool by the assimilation rate (RAS). In this condition, the amount of new staff will be reduced to zero when the assimilation process finishes. The productivity of new employee stays at its initial low level. Because the relationship between experienced workforce for


IEEE

training (WFET) and newly hired workforce (WFNW) is positive monotonically, the amount of trainer needed will also decrease to zero simultaneously. Refinement 2: The newly hired staff will be transferred into the experienced staff pool only when the assimilation process finishes. However, their average productivity will be increasing during the procedure, and will be equal to the productivity of experienced personnel at the end of this procedure. The amount of experienced trainers required will be constant until the assimilation terminates, and then all return to development process. Refinement 3: The productivity of the new employee should be zero during the orientation period, since they have to "learn the project's ground rules, the goals of effort, the plan of work..." [9] and what has been done. Their productivity starts to increase after this period, or they start to be assimilated into the experienced workforce pool as the first approach mentioned. In this paper, we select the second refinement, which is different from Abdel-Hamid's model, to develop our staffing model. The main differences to constraints compared with the first QDE are highlighted (in bold) in Figure 4. (constraints (add Sc Sr Sp) (constant Sp ASG_SIZE) (constant WFt TOTAL_WF) (constant WFnw) (constant WFex) (add WFex WFnw WFt) (add WFed WFet WFex) (M+ WFnw WFet) (d/dt Sc Rsd) (d/dt Sr mRsd) (minus Rsd mRsd) (add Rsd Rco Rnd) (add Rexd Rnwd Rnd) (constant PDex NML_EX_PD) (Mult PDex WFed Rexd) (Mult PDnw WFnw Rnwd) (d/dt PDnw Ras) (constant Ras) (mult WFt WFt WFsq) (M+ WFsq Rco))

Figure 4 Constraints of "Assimilation Process QDE”

The transition condition to switch between two QDEs is that the new staff’s productivity increases until it is equal to the level of experienced personnel.

3.3 Exemplar: Brooks' Law 3.3.1 Brooks' Law Brooks' Law states as follows:

"Adding manpower to a late software project makes it later". Brooks' assertion was based on many studies that have demonstrated the negative impacts of communication and training overheads on software development productivity [8]. With reference to Abdel-Hamid's model, the assimilation procedure is triggered by the Workforce Gap, which presents the difference between the Total Workforce and the Workforce Sought. When the Workforce Sought is larger than the current Total Workforce, new employees will be hired and injected into the software project. However, the Workforce Sought usually depends on the project schedule pressure [5], which is decided by the Completed Size and other outputs from the detailed model of the software development sector. Hence, to simplify the staffing model and focusing on assimilation impact, we

trigger the second QDE when Remaining Size reaches the "PRS_SIZE” (pressured size) in this exemplar. 3.3.2 Possible Behaviours The qualitative model outputs a number of possible behaviours. We filtered them by the constraint that the remaining project size becomes zero when simulation terminates. Then 112 behaviours are generated through simulation. The predicted behaviours are divided into two categories: 1) behaviours only passing the first transition point when the assimilation procedure is triggered, i.e. project finishes before the assimilation done (next transition); 2) behaviours also passing the second transition point when the assimilation completes, and then being followed by project closure.

(a) Behaviour 57 of 112

(b) Behaviour 48 of 112 Figure 5 Examples of Possible Behaviours

Ta is used to represent the transaction time when new staff added in and Tb points the time when all new staffs have been assimilated and transferred to experienced team. In the behaviour Figure 5, the first time point with the symbol of parallel (||) presents the status at time Ta and the second (||) indicates status at time Tb. Two examples of the above behaviour categories are shown in Figure 5 (a) (passing only Ta) and (b) (passing both Ta and Tb). Furthermore, four types of variables are identified from the outputs: 1) variables with constant values (SP, RAS, and PDEX);


IEEE

2) variables change their value only at Ta or Tb (WFT, WFNW, WFEX, WFED, WFET, RCO, and REXD); 3) variables keep changing their value only between Ta and Tb (RSD, RND, RNWD, and PDNW) 4) variables keep changing values throughout the project (SC and SR). Because our modeling is used for continuous and dynamic simulation, we are only interested in the behaviours described by the later three types of variables. According to the model outputs, we examine how these variables change at two transaction points (Ta and Tb), and in the interval between them. Type 2 variables:

There are several variables changing within the simple pattern across the predicted behaviours: they jump from initial values to a larger value at Ta, then no further changes occur until Tb or project finishes. Table 3 shows the change patterns of all type 2 variables through two transitions. Table 3 Type 2 Variables

value at Ta

initial value 0 >0

Ta to Tb

K >0 no change L no change (0,initial) WFT >0 K >initial no change WFED N/A K >0 no change N/A K >0 no change WFET >0 K >initial no change RCO L no change >0 REXD (0,initial) * only applied for behaviours passing Tb WFNW WFEX

*value at Tb L0 K >initial no change L N/A L N/A no change K >initial

in Figure 6. The broken line arrows indicate the time progress directions. The changes of RSD are shown on vertical dimension and the corresponding values SR of presented on horizontal axis. Each point in the plots indicates the both values of RSD and SR at the same transition time point. The left most points in each plot represent the end of project. There are increasing trends of RSD in all behaviours after first transition (Ta). We can identify the pattern of software development rate as “ ” shape in most behaviours as shown in Figure 6 (a, b). The immediate drops are found when adding new staff into project team at “PRS_SIZE”. The final software development rate will achieve the values below (b) or over (a) the initial rate.

Type 3 variables: The variables in this category present more complicated and nonlinear changes in some behaviours. To identify the difference with type 2 variables, we focus on the value changes at Ta, and between two transitions. Table 4 shows the change patterns of all type 3 variables through two transitions. The increasing trend is found for this type variables between Ta and Tb. Table 4 Type 3 Variables

RNWD RND RSD PDNW

initial value 0 >0 >0 0

value at Ta K >0 ? >0 ? t0 K >0

Ta to Tb K K K K

value after Tb L0 no change no change L0

Software Development Rate: Because the software project duration and development speed are directly determined by software development rate (RSD), it can be viewed as the vital variable of our model. It also exhibits complicated changes among the possible behaviours generated by our model. The software development rate declines sharply in most predicted possible behaviours when new personnel are injected in at the transition point (Ta). Then it recovers gradually due to the increasing productivity of the novices. The software development rate may exceed the initial value in some scenarios where the project finishes after the assimilation period. The relations between RSD and remaining project size (SR) are examined by the phase view that is plotted


IEEE

Figure 6 Phase View of RSD vs. SR

However, our qualitative model also outputs some other patterns inconsistent with Brooks’ Law. Figure 6 (c) indicates no significant change of development rate at “PRS_SIZE”, and (d) shows a positive step-up there. 3.3.3 Project Completion The remaining size (SR) and completed size (SC) are the variables changing in opposite directions over the project. We determine whether the project will be later as stated by Brooks’ Law by comparing the simulated project closure time point with the original scenario without new workforce hired. Figure 7 shows the phase views of the comparison: the horizontal axis

indicates the Completed Size (SC) of the project with new staff injected, where the vertical represents the original project. The right most points in each plot represent the end of project. The right plots (d, e, f) include two transition points during project, whereas the left plots (a, b, c) have single transition. Instead of one specific result generated from the quantitative models, this model outputs three states indentified by examining in which scenarios the project achieve the requirements (ASG_SIZE): 1) project with assimilation finishes later than the original schedule, as Figure 7 (a, d); 2) project with assimilation finishes earlier than the original schedule, as Figure 7 (b, e); 3) duration of the project with assimilation just equals the original schedule, as Figure 7 (c, f).

manpower to a late project” cannot necessarily “make it later”.

4. Comparison and Discussion Because a qualitative model simulates all possible behaviours and states of certain system, such a model cannot be evaluated by particular sets of quantitative data. In this section, we conduct the evaluation by comparing the qualitative model outputs with the quantitative staffing models, and further comparing with the empirical evidence.

4.1 Comparison with Outputs of Other Models Stutzke’s model will not be compared with the results of QSIM model, because our model considers the increasing effort on communication, which he did not consider. Both Abdel-Hamid’s and Madachy’s models show the staffing process and examine Brooks’ Law under predetermined conditions, since the equations and parameters must take on quantitative values. Abdel-Hamid and Madnick’s model provides detailed insights into what happens under several assumptions as to how much manpower is added, and when [5]. They identified that the new personnel always have an immediate negative impact on software development rate, and concluded that “adding more people to a late project always makes it more costly, but it does not always cause it to be completed later”. In particular, adding extra workforce early in the schedule is much safer than adding them later. Based on the sensitivity result of his model, Madachy clarified Brooks’ Law qualitatively as “adding manpower to a late software project makes it later if too much is added too late”[10]. Based on the simulation outputs (Section 3.3.3), all the results of previous quantitative models can be obtained by our work. The quantitative models always assume that project schedule is caused by the amount of new manpower and the injection time. However, they didn’t take into consideration the impacts of other relationships associated with project and organization.

4.2 Comparison with Empirical Evidence Figure 7 Phase View of Project Schedules

The first state (a, d) is consistent with Brooks’ Law. The results indicate that the above three final states are all possible for software project in which the new workforce are added in. Therefore, only given “adding


IEEE

Jeffery explored the relationships between productivity, effort and elapsed time that the timesensitive cost models claimed for software development [11]. He collected and analysed the data on 47 projects from 4 large organizations in Australia.

The plot of the ratio of the actual effort to estimated effort against the ratio of actual elapsed time to estimated elapsed time is shown as Figure 8. The gap between the actual remaining effort and the estimated remaining effort results in the gap of manpower. Project managers decide to hire new workforce, because they perceive that more employees are sought to complete the additional workloads [5].

the quantitative models. In our model, we can identify other factors that may impact the result through qualitative simulation. These factors can be located among the variables associated with the qualitative constrained monotonic formulas, i.e. M+ or M-. Communication overheads (RCO) Even though it is widely accepted that communication overheads account for a second-order effect on added effort, the relationship with workforce may vary between projects, even different tasks. It can be expressed by the variance of the constant coefficients of the relationship. For instance, when the project hires new staff to conduct the testing tasks, the communications between them are not so significant as during initial phase of the development. Hence, the drop of software development rate due to communications overheads will be small.

Figure 9 Behaviour 80 of 112 Figure 8 Effort Ratio vs. Elapsed Time Ratio

Quadrants 1 and 2 reflect the scenarios with more actual effort than estimated, whereas quadrants 1 and 4 link with the cases of elapsed time expansion. The points in quadrant 1, which represent more effort and longer elapsed time, are consistent with the situation that Brooks’ Law claims. However, quadrant 2 includes the projects with more effort but less elapsed time, which is inconsistent with Brooks’ Law. The points falling in both quadrants 1 and 2 are consistent with the states predicted through our qualitative simulation. We found that when the actual effort exceeded the estimate, most projects could finish within the actual elapsed time close to the estimate.

4.3 Discussion In section 3.3.3, it was found that the project with new employees might be completed earlier, later, or at the estimated schedule through the qualitative simulation. The three final states are all possible with the base of the basic qualitative assumptions. Even though other researchers found Brooks’ Law might be questionable, they emphasized the causes as being the number of new manpower hired and when, which are the inputs with the values they can change in


IEEE

In the scenario shown as Figure 9, though experienced employee development rate (REXD) declines sharply at first transition, the overall software development rate (RSD) increases significantly at Ta. This might be caused by the situation that many new employees were added in project and they lead to the increase of RND, but no significant increase in communication overheads occurs. Assimilation rate (RAS) Abdel-Hamid decomposed the assimilation rate into “hiring delay” plus “transfer delay”, which assumed to be 40 days and 80 days respectively [5]. Madachy set the delay to be at the average of 20 days [10]. The actual assimilation rate is decided by multiple factors, which include the average capability of new hirees, the mentors’ teaching skills and procedure design, and the tasks being assigned to the new personnel (in fact, we can continue extending the list). In our model, one qualitative rate without specific quantitative value is involved and all consequent possibilities and corresponding impacts can be examined through simulation. New employees’ productivity (PDNW) The low productivity of new manpower was believed to be the vital factor that leads to the immediate decline of the entire development rate. Its value is different between quantitative (System

Dynamics) models: it is set to 0.8 of nominal productivity in Madachy’s model [10], and AbdelHamid separated it into 4 levels with 0.1 to 0.9 [5]. In contrast, assumption 8 of our qualitative model only claims a lower productivity of the new employees than the experienced staff. However, if the project managers weigh the schedule constraint more than cost, they can pay more to hire the software professionals with potential higher productivity. Then they will be absorbed quickly, and more, may increase quality (fewer defects) and improve the productivity of the original team. Ratio of experienced mentors to novices Madachy’s model assumed the default value of 0.25 that indicates one-quarter of an experienced person is needed to train a new employee until they are fully assimilated [10]. Abdel-Hamid estimated the range from 15% to 25% [5], and there are no explicitly proposed formulas in literature. However, the ratio might be lower if the new team members are internal and transferred from the similar projects. The qualitative model can simulates all possible states without further details given. Management adjustment Neither of previous models takes into account the management adjustment, such as the fact that the work must be repartitioned in practice, a process found by Brooks [8]. In terms of the above comparison and discussion, the practical meaning of Brooks’ Law may be that it presents a simplified approximation to the truth of software staffing process for project managers, and as a rule of thumb to warn them against blindly making the simplistic response to a late project. However, by applying appropriate hiring, training and task assignment strategies, it is possible to assimilate new staff without encountering schedule problems.

5. Conclusion and Future Work This paper has reported on a study of the applicability of qualitative simulation to the software staffing process modeling with a minimum set of assumptions. It also demonstrated the work to simulate Brooks’ Law by this qualitative model. The outputs are compared with the results of previous models on the same issue. The analysis reveals a complex structure that is not limited in relationship between “when to add new workforce in project” and “how many new personnel need to be injected”, which was stated in previous models.


IEEE

Qualitative modeling and simulation are presented in this paper as powerful and flexible techniques for developing and running models with reference to insufficient information or knowledge. Qualitative techniques can be further extended to in-depth research of software staffing process and other aspects of software process. Future work can be proposed as (but not limited to): 1. Investigating QSIM’s approach to semiquantitative modeling of software process. 2. Investigating the use of qualitative modeling in other areas of software engineering, e.g. modeling the relationships among the identified risk factors for risk prediction and analysis. 3. Developing the procedure for evaluating qualitative simulation models of software process.

6. References 1. Abdel-Hamid, T., The Dynamics of Software Project Staffing: A System Dynamics Based Simulation Approach. IEEE Transactions on Software Engineering, 1989. SE-15(2): p. 109-119. 2. Ramil, J.F., Smith, N., Qualitative Simulation of Models of Software Evolution. Software process: Improvement and Practice, 2002. 7: p. 95-112. 3. Kuipers, B.J., Qualitative Reasoning: Modeling and Simulation with Incomplete Knowledge. . 1994, Cambridge, Massachusetts: MIT Press. 4. Kuipers, B., Qualitative Simulation, in Encyclopedia of Physical Science and Technology, R.A. Meyers, Editor. 2001, NY: Academic Press. p. 287-300. 5. Abdel-Hamid, T.K., Madnick., S.E., Software Project Dynamics: An Integrated Approach. 1991, Englewood Cliffs, NJ: Prentice-Hall. 6. Madachy, R., Boehm B., ed. Software Process Dynamics. 2005, IEEE Computer Society Press: Washington D.C. 7. Stutzke, R.D., A Mathematical Expression of Brooks's Law, in Ninth International Forum on COCOMO and Cost Modeling. 1994: Los Angeles. 8. Brooks, F.P., The Mythical Man-Month: Essays on Software Engineering 1975: Addison-Wesley. 9. Thayer, R.H., Lehman, J.H., Software Engineering Project Management: A Survey Concerning U.S. Aerospace Industry Management of Software Development Projects. 1977, Sacramento Air Logistics Center: McClellan, CA. 10. Madachy, R., Tarbet D., Case Studies in Software Process Modeling with System Dynamics. Software process: Improvement and Practice, 2000. 5: p. 133-146. 11. Jeffery, D.R., Time-Sensitive Cost Models in the Commercial MIS Environment. IEEE Transactions on Software Engineering, 1987. SE-13(7). 12. QSIM v4.0 Alpha 4, UT Qualitative Reasoning Software, http://www.cs.utexas.edu/users/qr/QR-software.html