Estimating Software Effort Based on Use Case ... - Semantic Scholar

1 downloads 190913 Views 328KB Size Report
software effort estimation based on use case point model. ... cost estimation techniques exist and they can be classified .... Application performance objectives. 1.
2011 23rd IEEE International Conference on Tools with Artificial Intelligence

Estimating Software Effort Based on Use Case Point Model Using Sugeno Fuzzy Inference System Ali Bou Nassif and Luiz Fernando Capretz

Danny Ho

Department of ECE, University of Western Ontario London, Ontario, Canada {abounass, lcapretz}@uwo.ca

NFA Estimation Inc. Richmond Hill, Ontario, Canada [email protected] None of the above techniques are perfect and can fit all situations [8]. In this paper, a machine learning technique (fuzzy logic) is used with an algorithmic model (use case point model) for better software estimation results. Software estimation is important in the early stages of the software life cycle. As UML diagrams have become popular in the last decade, software developers have become more interested in conducting software estimation based on UML models and especially the use case diagrams. The use case diagram conveys the functional requirements of a system and it is usually included in the Software Requirements Specification (SRS) documents. One of the models that is based on the use case diagrams is the use case point model (UCP) [9]. The UCP model has widely been used in the last decade [10], yet it has several limitations. One of the limitations is that the software effort equation is not well accepted by software estimators because it assumes the relationship between software effort and size is linear. In this paper, a new model based on regression analysis is introduced to tackle the limitations of the UCP model and has enhanced the software effort estimation by 6%. A Sugeno FIS has been used to adjust the crisp values of the productivity factor of the regression model. This has led to an additional 5% improvement in the effort estimation. The remainder of the paper is organized as follows: Section II presents the background of the work. Section III states the problem definition whereas Section IV lists some related work. Section V and Section VI demonstrate the proposed model. Section VII evaluates the proposed approach. Finally, Section VIII concludes the paper and proposes future work.

Abstract— Software effort estimation is one of the most important tasks in software engineering. Software developers conduct software estimation in the early stages of the software life cycle to derive the required cost and schedule for a project. In the requirements stage, where most software estimation is conducted, the available information is usually imprecise or incomplete. In this paper, a new regression model is created for software effort estimation based on use case point model. Furthermore, a Sugeno Fuzzy Inference System (FIS) approach is applied on this model to improve the estimation. Results show that an improvement of 11% can be achieved in MMRE after applying the Sugeno fuzzy logic approach. Keywords- Sugeno fuzzy logic, early software estimation, software engineering, Use Case Points

I.

INTRODUCTION

Artificial intelligence (AI) has been widely used in many domains such as medicine, economics, business, and others. Recently, the interest of applying AI in software engineering has been soaring. Conducting software estimation is essential in any project as it helps project managers plan, identify risks, and determine the effort and cost of projects. Several cost estimation techniques exist and they can be classified under three main categories [1]. These categories are: 1. Expert Judgment: In this category, a software project estimator tends to use his or her expertise which is based on historical data and similar projects to estimate software. This method is very subjective and it lacks standardizations and thus, cannot be reusable. Another drawback of this method is the lack of analytical argumentation because of the frequent use of phrases such as “I believe that …” or “I feel that …” [2]. 2. Algorithmic Models: This is still the most popular category in the literature [3]. These models include COCOMO [4], SLIM [5] and SEER-SEM [6]. The main cost driver of these models is the software size, usually the Source Lines Of Code (SLOC). Algorithmic models either use a linear regression equation, the one used by Kok et al. [7] or non-linear regression equations, those which are used by Boehm [4]. 3. Machine Learning: Recently, machine learning techniques are being used in conjunction or as alternatives to algorithmic models. These techniques include neural networks, fuzzy logic, neuro-fuzzy, genetic algorithm and regression trees.

1082-3409/11 $26.00 © 2011 IEEE DOI 10.1109/ICTAI.2011.64

II.

BACKGROUND

The use case point method was proposed by Karner in 1993 [9] and it is used for size and effort estimation that is based on use case diagrams. The main components of the use case diagrams are actors and use cases. The use case point model (UCP) is detailed as follows: 1. Unadjusted Actor Weight (UAW): In the UCP, actors are classified as simple, average or complex. A weight is assigned to each category as follows: • Simple actor: This is described as another system through an API. Its weight is 1. • Average actor: This is described as another system interacting through a text-based user interface or a protocol. Its weight is 2. 393

Where 1 = 0.6, 2 = 0.01 and is a factor that takes values between “0” and “5”. The value “0” means the factor is irrelevant while the value “5” is essential. The value “3” means that the factor is not very essential, neither irrelevant (average). For instance, if all the factors have a value of “3”, the TF will be 1.

• Complex actor: This is described as a system interacting through a graphical user interface (GUI). Its weight is 3. The UAW is calculated as: = ∑

×1



×2



×3

(1)

5. Environmental Factor (EF): These factors contribute to the team efficiency and productivity. The environmental factors are presented in Table II.

Where SA, AA, and CA correspond to Simple Actors, Average Actors and Complex Actors, respectively. 2. Unadjusted Use Case Weight (UUCW): Use cases are classified based on the number of transactions in the success and alternative scenarios. A weight is assigned to each category as follows: • Simple Use Case: A use case is classified as Simple if the number of transactions is ≤ 3. Its weight is 5. • Average Use Case: A use case is classified as Average if the number of the transactions is between 4 and 7. Its weight is 10. • Complex Use Case: A use case is classified as Complex if the number of transactions is more than 7. Its weight is 15. The UUCW is calculated as: = ∑

×5





× 10

× 15

The environmental factor (EF) is calculated as follows: = 1

UCP = UUCP × TF × EF.

(2)

7. Effort: This is the final stage of the use case point model. Karner proposed 20 person-hours for each UCP. This can be represented as:

The Unadjusted Use Case Points are adjusted based on the technical and environmental factors. 4. Technical Factor (TF): These factors contribute to the complexity of the project. The technical factors are depicted in Table I. The technical factor (TF) is calculated as follows:

TABLE I. Fi F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13

.

Effort = Size × 20.

(7)

where size is the calculated software size in adjusted use cases (UCP) and the effort is measured in person-hours.

(4)

III.

PROBLEM DEFINITION

In Equation 7, Karner proposed a method to calculate the software effort from the software size. However, this method has several shortcomings, which include:

TECHNICAL FACTORS [9]

Factors contributing to complexity Distributed systems Application performance objectives End user efficiency Complex internal processing Reusability Easy installation Usability Portability Changeability Concurrency Special security features Provide direct access for third parties Special user training facilities

(6)

The maximum value of TF is 1.3, if the value of all technical factors is 5. If the project complexity is high and the team efficiency is low, there will be a high risk that this project will fail [11]. Typically, by taking the technical and the environmental factors into consideration, the value of the adjusted use case points (UCP) will be 30% more or less than the unadjusted use case points (UUCP).

(3)

2∑

(5)

6. Adjusted Use Case Points (UCP): The UCP is calculated by multiplying the UUCP by the technical and environmental factors as follows:

3. Unadjusted Use Case Points (UUCP): This is the summation of UAW with UUCW. This is described as:

= 1

.

Where 1 = 1.4, 2 = 0.03 and is a factor which is equivalent to the of the technical factor (i.e. between 0 and 5).

Where SU, AU, and CU correspond to Simple Use Case, Average Use Case and Complex Use Case.

=

2∑

Wi 2 1 1 1 1 0.5 0.5 2 1 1 1 1 1

TABLE II. Fi F1 F2 F3 F4 F5 F6 F7 F8

394

ENVIRONMENTAL FACTORS [9]

Factors contributing to efficiency Familiar with Objectory Stable requirements Analyst capability Application experience Object oriented experience Motivation Difficult programming language Part-time workers

Wi 1.5 2 0.5 0.5 1 1 -1 -1

1. Karner assumed that the relationship between the effort and size is linear. This assumption does not reflect the actual situation in the software industry. For instance, if the effort required to build a software project of size 250 UCP is 5,000 person-hours, the effort needed to build the same project type of size 500 UCP would be more than 10,000 person-hours. 2. In Equation 7, the effort is a function of the adjusted use case point (UCP) size. As explained in the previous section, the UCP encompasses the non-functional requirements of the system and it may increase the original unadjusted use case point (UUCP) by 30%. However, IBM states that non-functional requirements might represent more than 50% of the total effort [12]. This means that the non-functional requirements may virtually increase the unadjusted size by 100%. This paper presents a novel regression model to tackle these shortcomings. Furthermore, a Sugeno fuzzy logic approach is used to adjust the productivity factor in the proposed model, and thus, enhances the estimation. IV.

V.

UCP REGRESSION MODEL

In this section, a regression model based on the UCP model is introduced. This is an extension to the model proposed in [22]. Section VI presents a Sugeno fuzzy logic approach to improve the proposed regression model. The general equation of software effort can be represented as [6]: ×

Effort =

.

(8)

where Complexity is the complexity factor of a project and Productivity is the productivity factor of the team that is developing this project. The first step of the regression model is to discover the non-linear relationship between software size and software effort. For this purpose, regression analysis was applied on several projects that have similar projects complexity and team productivity. Regression analysis assumes that data should be normally distributed [23]. If the histograms of software size and effort were normally distributed, the regression equation would be:

RELATED WORK

Effort = a × Size + b.

Some work has been done to enhance the effort estimation of the use case point model and other work was done to build regression models based on Function Points. Periyasamy et al. [13] extended the UCP by classifying actors into 7 groups. Moreover, the authors proposed new weights for use cases. The weight of a use case is determined based on the number of associations between actors and the use case. Wang et al. [14] extended the UCP by integrating a fuzzy set theory with Bayesian Belief Networks. Schneider et al. [11] mentioned that environmental factors should be considered while calculating the effort. The authors suggested counting the number of factor ratings of F1-F6 in Table II (Environmental Factors) that are below 3 and the number of factor ratings of F7-F8 that are above 3. If the total is less than 3, then 20 person-hours per UCP should be used. If the total is 3 or 4, then 28 person-hours per UCP should be used. If the total is 5 or more, then the project team should be reconstructed so that the numbers fall at least below 5. A value of 5 indicates that the project is at significant risk of failure with this team. The main limitation of this method is that the effort required to develop one UCP is either 20 or 28 person-hours. Jiang et al. [15] and Xia et al. [16] built regression models based on function points using ISBSG data. The main concern of these models is that they ignore the influence of the non-functional requirements on estimation. As well, machine learning models exist and are used to improve the accuracy of software estimation. Examples of these models include [17], [18], [19], [20], and [21]. None of the existing work deals with creating regression models based on the use case points.

(9)

where a and b are constants. Several experiments were conducted using Minitab to determine how data were distributed. The histograms of software size (Figure 1) and effort (Figure 2) showed that data were not normally distributed. After normalizing data using logarithmic transformation, data (ln size and ln effort) became normally distributed (Figures 3 and 4). The regression equation after logarithmic transformation is: ln Effort = c × ln Size + d.

(10)

Where c and d are constants. Equation 10 can be rewritten as: (11)

.

Effort = A ×

Using Minitab version 16, the values of A and B are 8.16 and 1.17 respectively. The proposed regression equation is: .

Effort = 8.16 ×

(12)

.

Histogram of size (ucp) 50

Frequency

40

30

20

10

0

0

48

96

Figure 1.

395

144

192 size (ucp)

240

Histogram of Size

288

336

In our experiments, the Spearman and Pearson coefficients are 0.98 and 0.97 respectively. This shows that the two variables Effort and Size have a strong positive relationship. The main equation for software effort in the proposed model is expressed as:

Histogram of Effort (person-hour) 60 50

Frequency

40 30 20

0

0

1200

2400

3600 4800 6000 Effort (person-hour)

7200

8400

Histogram of ln(size) Normal 20

Mean StDev N

3.964 0.4766 125

Frequency

15

10

5

0 2.8

3.2

3.6

4.0

4.4 ln(size)

4.8

5.2

5.6

Figure 3. Histogram of ln(Size) Histogram of ln(Effort) Normal Mean StDev N

25

6.748 0.5670 125

20

15

10

5

0

5.4

6.0

6.6

7.2 7.8 ln(Effort)

8.4

.

×

.

(13)

The second step of the proposed model is to calculate the values of Project_complexity and Productivity. Although the technical factors in Table I do not include all complexity factors, yet, Karner’s technical factor TF can represent the Project_Complexity factor during the estimation of UCP and consequently, the Project_Complexity factor in Equation 13 can be ignored. With respect to productivity, Table II lists some productivity attributes. A better approach than Schneider has been taken to calculate the Productivity factor. Based on Table II, the highest Productivity factor is achieved when the value of the factors F1 to F6 is 5 and the value of the factors F7 and F8 is 0. This implies that the value of (∑ is 32.5. On the other hand, the lowest productivity factor is achieved when the value of F1 to F6 is set to 0 and the value of F7 and F8 is set to 5. This implies that the value of is -10. The productivity factor is determined (∑ based on the value of (∑ . Table III shows the proposed values of the Productivity. The final equation of effort estimation in the proposed model becomes:

Figure 2. Histogram of Effort

Frequency

_C

Effort = 8.16 ×

10

.

Effort =

9.0

×

.

.

(14)

Where the values of the Productivity are shown in Table III. For instance, Equation 14 addresses the second limitation illustrated in Section III. The main drawback of the productivity factor shown in Table III is that the values are crisp and there is no graduation of the productivity factor values as the value of increases. For instance, if the value of (∑ (∑ is 10, the productivity factor is 0.7, however, if the value of ( ∑ is 11, the value of the productivity factor is 1. To tackle this drawback, a fuzzy logic approach based on Sugeno FIS has been used.

Figure 4. Histogram of ln(Effort)

Where Size is the software size in UCP and Effort is the software effort in person-hours. For instance, Equation 12 shows the non-linear relationship between Effort and Size and ignores the Complexity and Productivity factors. The main equation of software effort is expressed in Equation 13. For instance, Equation 12 tackles the first shortcoming presented in Section III. To measure the accuracy of the regression equation (see Equation 12), we measured the value of the coefficient of determination R2. R2 is the percentage of variation in Effort explained by the variable Size. An acceptable value of R2 is ≥ 0.5 [24].The value R2 reported for the regression model in Equation 9 is 0.972. Approximately 97 % of the variation in Effort can be explained by the variable Size. This shows a strong relation between Size and Effort. To thoroughly test the regression model, Spearman [25] and Pearson [26] coefficients were determined to measure the correlation strength between the Effort and Size. The coefficients range of both Spearman and Pearson is between -1 and 1. The value 0 means that these two variables are not correlated. A positive value represents a positive correlation. Larger coefficient values correspond to stronger correlations. On the contrast, negative values mean negative correlations.

VI.

FUZZY LOGIC APPROACH

Fuzzy logic is a branch of Artificial Intelligence that has been widely used in many areas such as control and expert systems. This is because fuzzy logic can handle uncertain inputs and fuzzy rules can be subjective. TABLE III. (∑ Less than 0 Between 1 and 10 Between 11 and 20 Greater than 20

396

PRODUCTIVITY FACTOR Productivity Description Very Low Low Average High

Productivity Factor 0.4 0.7 1 1.3

TABLE IV.

In fuzzy logic, input and output memberrships should be defined as well as fuzzy rules. A membersship function is a curve that defines the mapping between an input and an output. Membership functions incluude Triangular, Trapezoidal, Gaussian Bell and Singletonn. There are two main types of fuzzy inference system; Maamdani [27] and Sugeno [28]. Both Mamdani and Sugeno caan have the same input (membership functions). However, thee main difference between these two models is that the outputt of Mamdani can take any membership function like the inputt but the output of Sugeno can be either constant or a straight liine. In this paper, Sugeno FIS has been used. Based on the prroposed values in Table III, the input membership chosen for tthe Sugeno FIS is Trapezoidal where the output is constant. Fiigure 5 shows the input membership function of Sugeno FIS. There are two main approaches to elicit fuzzy rules [29]. These include: 1. The expert knowledge is translated intoo if-then rules. A structured model can be used to incorpoorate these rules. Membership functions and weights oof rules can be calibrated using input and output data. 2. No prior knowledge about the system is initially used. A fuzzy model is constructed based on a ccertain algorithm. Fuzzy rules and membership functions are expected to describe the system behavior. An expertt can modify the rules and the membership functions. In this paper, the fist approach will be ussed. There are four fuzzy rules in the prooposed approach. These include: 1. If (∑ is less than 0, then prodductivity factor = 0.4. 2. If (∑ is between 0 and 10, tthen productivity factor = 0.7. 3. If (∑ is between 10 and 20, tthen productivity factor = 1. 4. If ( ∑ is greater than 20, th then productivity factor = 1.3.

IN

PO -10 -9 -8 -7 -6 0 1

UCTIVY FACTOR NEW PRODU

PN 0.4 0.4 0.4 0.4 0.4 0.4 0.7

IN

0.4 0.42 0.45 0.46 0.48 0.55 0.58

PO 8 9 10 11 12 20 2 21 2

PN 0.7 0.7 0.7 1 1 1 1.3

0.8 0.83 0.86 0.89 0.9 1.15 1.17

p factor values For instance, a complete list of the productivity can be obtained by implementing thee proposed Sugeno FIS . VII. EVALUA ATION The evaluation of the proposed model was performed using 24 projects that were not inclluded among the projects used in the regression analysis. Software S estimation was conducted using Karner’s model, Scchneider’s model and the proposed model. In software estim mation, most practitioners use MMRE and PRED(x) to calcullate the error percentage. MMRE is the Mean of the Magnitu ude of Relative Error and it is a very common criterion used to evaluate software cost nitude of Relative Error estimation models [30]. The Magn (MRE) for each observation i can bee obtained as: =

|

|

.

(15)

MMRE can be achieved through t averaging the summation of MRE over N observattions: =



.

(16)

On the other hand, PRED(x) is the t percentage of projects for which the estimate falls within n x% of the actual value. For instance, if PRED(30) = 60, th his indicates that 60% of the projects fall within 30% error range. Table V shows the evaluation results. The columns Kar, Sch, Pro_B and Pro_A represent Karner, Schneider, the proposed model before osed model after applying applying Sugeno FIS and the propo the Sugeno FIS approach. t the proposed model In table VI, the results show that before applying the fuzzy logic approach improves the MMRE of Karner’s model by 6% and Schneider’s method by 2%. After applying the Sugeeno FIS approach, 11% improvement over Karner’s model was w obtained and 7%

After applying the fuzzy logic approach, the productivity factor has a specific value for each value oof (∑ . Table IV shows some samples of the neew values of the productivity factors. The labels IN, PO and P PN correspond to (∑ , old productivity factor and new productivity factor respectively. As seen in Table IV, tthe values of the new productivity factor (PN) are not crisp as the values of the old productivity factor (PO). This leads to better estimation values.

TABLE V. Critera MMRE PRED (25) PRED (35) PRED (50) PRED (75) PRED (100)

Figure 5. Input Membership Functiion

397

COMPARISON BETWEEN PROPOSED P AND OLD MODELS Kar (%) 34 37.5 50 87.5 95.8 100

Sch (%) 30 62.5 66.6 83.3 91.7 95.8

Pro_B (%) 28 54 75 91.6 95.8 95.8

Pro_A (%) 23 50 75 95.8 95.8 100

TABLE VI. Critera MMRE PRED (25) PRED (35) PRED (50) PRED (75) PRED (100)

IMPROVEMENT OF THE PROPOSED APPROACH

IProBK (%) 6 16.5 25 4.1 0 -4.1

IProBS (%) 2 -8.3 8.3 8.3 4.1 0

IProAK (%) 11 12.5 25 8.3 0 0

[7] P. Kok, B. A. Kitchenham and J. Kirakowski, "The MERMAID approach to software cost estimation," in Esprit Technical Week, 1990. [8] B. Boehm, C. Abts and S. Chulani, "Software development cost estimation approaches: A survey," Annals of Software Engineering, vol. 10, pp. 177-205, 2000. [9] G. Karner, "Resource Estimation for Objectory Projects," Objective Systems, 1993. [10] M. Damodaran, "ESTIMATION USING USE CASE POINTS," Scientific Commons, 2008. [11] G. Schneider and J. P. Winters, Applied use Cases, Second Edition, A Practical Guide. Addison-Wesley, 2001. [12] Y. Ossia. IBM haifa research lab. IBM Haifa Research Lab [Online]. 2011. Available: https://www.research.ibm.com/haifa/projects/software/nfr/index.html. [13] K. Periyasamy and A. Ghode, "Cost estimation using extended use case point (e-UCP) model," in International Conference on Computational Intelligence and Software Engineering,2009. [14] F. Wang, X. Yang, X. Zhu and L. Chen, "Extended use case points method for software cost estimation," in International Conference on Computational Intelligence and Software Engineering,2009. [15] Z. Jiang, P. Naudé and B. Jiang, "The effects of software size on development effort and software quality," International Journal of Computer and Information Science and Engineering, vol. 1, pp. 230-234, 2007. [16] W. Xia, L. F. Capretz, D. Ho and F. Ahmed, "A new calibration for Function Point complexity weights," Information and Software Technology, vol. 50, pp. 670-683, 2008. [17] W. Xia, D. Ho and L. F. Capretz, "A neuro-fuzzy model for function point calibration," WSEAS Trans.Info.Sci.and App., vol. 5, no. 1, pp. 22-30, 2008. [18] W. L. Du, D. Ho and L. F. Capretz, "Improving Software Effort Estimation Using Neuro-Fuzzy Model with SEER-SEM," Global Journal of Computer Science and Technology, vol. 10, no. 12, pp. 52-64, 2010. [19] X. Huang, D. Ho, J. Ren and L. F. Capretz, "Improving the COCOMO model using a neuro-fuzzy approach," Appl. Soft Comput., vol. 7, no. 1, pp. 29-40, 2007. [20] A. Mittal, K. Parkash and H. Mittal, "Software cost estimation using fuzzy logic," SIGSOFT Softw. Eng. Notes, vol. 35, no. 1, pp. 1-7, 2010. [21] A. B. Nassif, L. F. Capretz and D. Ho, "Enhancing Use Case Points Estimation Method using Soft Computing Techniques," Journal of Global Research in Computer Science, vol. 1, no. 4, pp. 12-21, 2010. [22] A. B. Nassif, D. Ho and L. F. Capretz, "Regression model for software effort estimation based on the use case point method," in 2011 International Conference on Computer and Software Modeling, Singapore, 2011, pp. 117-121. [23] A. C. Cameron and P. K. Trivedi, Regression Analysis of Count Data. Cambridge, UK: Cambridge University Press, 1998. [24] W. Humphrey, A Discipline for Software Engineering. Addison Wesley, 1995. [25] E. L. Lehmann, Nonparametrics: Statistical Methods Based on Ranks. Prentice Hall, 1998. [26] A. Edwards, An Introduction to Linear Regression and Correlation. W. H. Freeman and Comp., 1976. [27] E. H. Mamdani, "Application of Fuzzy Logic to Approximate Reasoning Using Linguistic Synthesis," IEEE Transactions on Computers, vol. C-26, pp. 1182-1191, 1977. [28] M. Sugeno and T. Yasukawa, "A fuzzy-logic-based approach to qualitative modeling," IEEE Transactions on Fuzzy Systems, vol. 1, pp. 731, 1993. [29] Z. Xu and T. M. Khoshgoftaar, "Identification of fuzzy models of software cost estimation," Fuzzy Sets and Systems, vol. 145, pp. 141-163, 2004. [30] A. B. Nassif, L. F. Capretz and D. Ho, "Software estimation in the early stages of the software life cycle," in International Conference on Emerging Trends in Computer Science, Communication and Information Technology, 2010, pp. 5-13.

IProAS (%) 7 -12.5 8.3 12.5 4.1 4.1

over Schneider’s model. This means that an additional 5% improvement was obtained after applying the fuzzy logic approach. With respect to PRED(x), the proposed model has an adverse effect on PRED(25), but PRED(35) and higher were improved. For instance, the columns IProBK, IProBS, IProAK and IProAS represent the improvement of the proposed model before fuzzy logic over Karner’s model, improvement of the proposed model before fuzzy logic over Schneider’s model, improvement of the proposed model after fuzzy logic over Karner’s model, and improvement of the proposed model after fuzzy logic over Schneider’s model respectively. VIII. CONCLUSION AND FUTURE WORK The use case point (UCP) model has been widely used to estimate software size and effort. The main advantage of the UCP model is that it can be used in the early stages of the software life cycle when the use case diagram is available. The UCP model has some limitations since it assumes that the relationship between software effort and size is linear. Furthermore, the UCP model ignores the influence of nonfunctional requirements on software effort. To tackle these limitations, a novel regression model has been introduced. Moreover, a Sugeno FIS is applied on the regression model to increase the accuracy of estimation. Experiments show that the accuracy of software effort can be enhanced by 11% by applying the proposed model. Future work will focus on two main concerns. First, the proposed model should be tested with projects of larger sizes (greater than 5,000 person-hours) when data are available. Secondly, the productivity factors proposed in Table III should be calibrated using a neuro-fuzzy approach. REFERENCES [1] E. Mendes, N. Mosley and I. Watson, "A comparison of case-based reasoning approaches," in Proceedings of the 11th International Conference on World Wide Web, Honolulu, Hawaii, USA, 2002, pp. 272280. [2] M. Jørgensen, "Forecasting of software development work effort: Evidence on expert judgement and formal models," International Journal of Forecasting, vol. 23, pp. 449-462, 2007. [3] L. C. Briand and I. Wieczorek, "Resource Estimation in Software Engineering," Encyclopedia of Software Engineering, vol. 2, pp. 11601196, 2002. [4] B. W. Boehm, Software Engineering Economics. Prentice-Hall, 1981. [5] L. H. Putnam, "A General Empirical Solution to the Macro Software Sizing and Estimating Problem," IEEE Transactions on Software Engineering, vol. SE-4, pp. 345-361, 1978. [6] D. D. Galorath and M. W. Evans, Software Sizing, Estimation, and Risk Management. Boston, MA, USA: Auerbach Publications, 2006.

398

Suggest Documents