SlideShare una empresa de Scribd logo
1 de 9
Descargar para leer sin conexión
Refining the Use Case Classification for
Use Case Point Method for Software Effort Estimation
Divya Kashyap 1
, Durgesh Shukla 2
and A. K. Misra2
1,2,3
Department of Computer Science and Engineering Motilal Nehru National Institute of Technology Allahabad, India
Email: {rcs0904@mnnit.ac.in, durgeshkrshukla@gmail.com, Kashyap.div2011@gmail.com}
Abstract— Software cost estimation is a key open issue for the software industry, which
suffers from cost overruns frequently. As the most popular technique for object-oriented
software cost estimation is Use Case Points (UCP) method, however, it has two major
drawbacks: the uncertainty of the cost factors and the abrupt classification. To address
these two issues, refined the use case complexity classification using fuzzy logic theory which
mitigate the uncertainty of cost factors and improve the accuracy of classification.
Software estimation is a crucial task in software engineering. Software estimation
encompasses cost, effort, schedule, and size. The importance of software estimation becomes
critical in the early stages of the software life cycle when the details of software have not
been revealed yet. Several commercial and non-commercial tools exist to estimate software
in the early stages. Most software effort estimation methods require software size as one of
the important metric inputs and consequently, software size estimation in the early stages
becomes essential.
The proposed method presents a techniques using fuzzy logic theory to improve the
accuracy of the use case points method by refining the use case classification.
Index Terms— Cost Estimation, Function Point, Fuzzy Logic, MMRE, and Use case point.
I. INTRODUCTION
Software cost estimation is vital for project bidding, budgeting, controlling and planning. Bad estimation will
lead to the failure and good one will enable the project deliver on time and within budget. Due to lack of
information to make decisions at an early stage in development, the cost estimation is full of uncertainty.
Although in the literature many estimation models like Constructive Cost Model (COCOMO), Function
Points (FP) have been proposed to help manager in estimation task, there is no obvious evidence shows that
the accuracy is improved in last decades [3]. Achieving a highly accurate estimation is still a challenging
issue in software engineering. We believe that there are two reasons: one is that something inside the cost
model is not proper in practical, the other is the inherent uncertainty of assessment of the cost from the cost
factors relied on the expert determination. To address these problems, the first step we need is to find out the
improper part in practical and then improve it accordingly, secondly, we need to manage these uncertainties
to lower the risk of the project being failed [4]. Among various existing cost models, UCP has become well
known and widely accepted because it utilizes two common practices in the industry: the object-oriented
paradigm and use case to describe functionality requirements. Taking deterministic value as inputs, UCP can
give most likely cost estimation.
The reminder of this paper can describe as follows: Section II contains a description of the UCP method,
DOI: 02.ITC.2014.5.501
© Association of Computer Electronics and Electrical Engineers, 2014
Proc. of Int. Conf. on Recent Trends in Information, Telecommunication and Computing, ITC
184
Section III describe Fuzzy logic concept. In Section IV different techniques used to estimate software costs
are discussed, Section V give the details of proposed method with related case study. The paper ends with
conclusion and future work for proposed method.
II. USE CASE POINTS METHOD
An early estimate of effort based on use cases can be made when there is some understanding of the problem
domain, system size and architecture at the stage at which the estimate is made. The use case points method
is a software sizing and estimation method based on use case counts called use case points.
TABLE I: ACTOR WEIGHT FACTOR
Actor Type Weighting Factor
Simple 1
Average 2
Complex 3
TABLE II: USE CASE COMPLEXITY WEIGHT FACTOR
Use Case Type Number Of Transactions Weighting factor
Simple ≤3 5
Average 4 to 7 10
Complex ≥8 15
A. Classifying Actors and Use Cases
Use case points can be counted from the use case analysis of the system. The first step is to classify the actors
as simple, average or complex. A simple actor represents another system with a defined Application
Programming Interface, API, an average actor is another system interacting through a protocol such as
TCP/IP, and a complex actor may be a person interacting through a GUI or a Web page. A weighting factor
is assigned to each actor type according to Table 1.
The total unadjusted actor weights (UAW) is calculated by counting how many actors there are of each kind
(by degree of complexity), multiplying each total by its weighting factor, and adding up the products. Each
use case is then defined as simple, average or complex, depending on number of transactions in the use case
description, including secondary scenarios. A transaction is a set of activities, which is either performed
entirely, or not at all. Counting number of transactions can be done by counting the use case steps.
Another mechanism for measuring use case complexity is counting analysis classes, which can be used in
place of transactions once it has been determined which classes implement a specific use case. A simple use
case is implemented by 5 or fewer classes and average use case by 5 to 10 classes and a complex use case by
more than ten classes. The weights are as in Table 2.
Each type of use case is then multiplied by the weighting factor, and the products are added up to get the
Unadjusted Use Case Weights (UUCW) The UAW is added to the UUCW to get the unadjusted use case
points (UUPC)
UUCP = UAW + UUCW (1.1)
B. Technical and Environmental Factors
The UCP method also employs a technical factors multiplier corresponding to the Technical Complexity
Adjustment factor of the FPA method, and an environmental factors multiplier in order to quantify non-
functional requirements such as ease of use and programmer motivation. Various factors influencing
productivity are associated with weights, and values are assigned to each factor, depending on the degree of
influence. 0 means no influence, 3 is average, and 5 means strong influence throughout. Table 3 and Table 4
show the Technical and Environmental Factors.
The adjustment factors are multiplied by the unadjusted use case points to produce the adjusted use case
points, yielding an estimate of the size of the software. The Technical Complexity Factor (TCF) is calculated
185
by multiplying the value of each factor (T1- T13) by its weight and then adding all these numbers to get the
sum called the TFactor. The following formula is applied:
ܶ‫ܨܥ‬ = 0: 6 + 0: 01_ܶ‫ݎ݋ݐܿܽܨ‬ (1.2)
The Environmental Factor (EF) is calculated by multiplying the value of each factor (F1-F8) by its weight
and adding the products to get the sum called the EFactor. The following formula is applied-
‫ܨܧ‬ = 1.4 + (−0.03 ∗ ‫ݎ݋ݐܿܽܨܧ‬) (1.3)
The adjusted use case points (UPC) are calculated as follows:
ܷܲ‫ܥ‬ = ܷܷ‫ܲܥ‬ ∗ ܶ‫ܨܥ‬ ∗ ‫ܨܧ‬ (1.4)
TABLE III: TECHNICAL COMPLEXITY FACTORS
Factor Description Weight
T1 Distributed System 2
T2 Response adjectives 2
T3 End-User efficiency 1
T4 Complex processing 1
T5 Reusable code 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Security features 1
T12 Access for third party 1
T13 Special training required 1
TABLE IV: ENVIRONMENTAL FACTORS
C. Producing Estimates Based on Use Case Points
Karner proposed a factor of 20 staff hours per use case point for a project estimate. Field experience has
shown that effort can range from 15 to 30 hours per use case point, therefore converting use case points
directly to hours may be an uncertain measure.
Schneider and Winters [2] recommend that the environmental factors should determine the number of staff
hours per use case point as follow:
NF = The number of factors in F1 through F6 that have value < 3 + The number of factors in F7 through F8
that have value > 3
If NF≤ 2 then
PF=20
If NF=3 or 4 then
PF = 28
If NF>4 then
Factor Description Weight
F1 Familiar with RUP 1.5
F2 Application experience 0.5
F3 Object-oriented experience 1
F4 Lead analyst capability 0.5
F5 Motivation 1
F6 Stable Requirements 2
F7 Part-time workers -1
F8 Difficult programming language 2
186
PF=36
The reason for this approach is that the environmental factors measure the experience level of the staff and
the stability of the project. Negative numbers mean extra effort spent on training team members or problems
due to instability. However, using this method of calculation means that even small adjustments of an
environmental factor, for instance by half a point, can make a great difference to the estimate.
III. FUZZY LOGIC
Fuzzy logic is derived from the fuzzy set theory that was proposed by Lotfi Zadeh in 1965 [5]. As a contrary
to the conventional binary logic that can only handle two values True or False (1 or 0), fuzzy logic can have a
truth value which is ranged between 0 and 1. This means that in the binary logic, a member is completely
belonged or not belonged to a certain set, however in the fuzzy logic, a member can partially belong to a
certain set. Mathematically, a fuzzy set A is represented by a membership function as follows:
‫ݖܨ‬[‫ܣ߳ݔ‬] = ߤ‫ܣ‬(‫ݔ‬): ܴ ⟹ [0,1] (2.1)
Where μA is the degree of the membership of element x in the fuzzy set A. A fuzzy set is represented by a
membership function. Each element will have a grade of membership that represents the degree to which a
specific element belongs to the set. Membership functions include Triangular, Trapezoidal and S-Shaped. In
fuzzy logic, linguistic variables are used to express a rule or fact. For example, the temperature is thirty
degrees is expressed in fuzzy logic by the temperature is low or the temperature is high where the words low
and high are linguistic variables. In fuzzy logic, the knowledge based is represented by if-then rules. For
example, if the temperature is high, then turn on the fan. The fuzzy system is mainly composed of three parts.
These include Fuzzification, Fuzzy Rule Application and Defuzzification. Fuzzification means applying
fuzzy membership functions to inputs. Fuzzy Rule Application is to make inferences and associations among
members in different groups. The third step in the fuzzy system is to defuzzify the inferences and
associations and make a decision and provide an output that can be understood. In this proposal, fuzzy logic
will be used to calibrate the complexity weight of use cases.
IV. RELATED WORK
A method for mapping the object-oriented approach into Function point analysis is described by Thomas
Fetke et al., [6]. The authors propose mapping the use cases directly into the Function point model using a set
of concise rules that support the measurement process. These mapping rules are based on the standard FPA
defined in the IFPUG Counting Practices manual. Since the concept of actors in the use case model is
broader than the concept of users and external applications in FPA, there cannot be a one to- one mapping of
actors and users to external applications. But each user of the system is defined as an actor. In the same
manner, all applications which communicate with the system under consideration must also appear as actors.
This corresponds to Karner’s use case point method [7]. The level of detail in the use case model may vary,
and the use case model does not provide enough information to how to count a specific use case according to
function point rules. Therefore, as in Karner’s method, the use cases must be described in further detail in
order to be able to count transactions. John Smith of Rational Software describes a method presenting a
framework for estimation based on use cases translated into lines of code [8] There does not seem to be any
more research done on this method, although the tool ‘Estimate Professional’, which is supplied by the
Software Productivity Center Inc, and the tool ‘CostXpert’ from Marotz Inc. produce estimates of effort per
use case calculated from the number of lines of code.
David Longstreet of Software Metrics observed that applying function points helps to determine if the use
case is written at a suitable level of detail [9]. If it is possible to describe how data passes from the actor to
inside the boundary or how data flows from inside the application boundary to the actor, then that is the right
level of detail, otherwise the use case needs more detail. By adopting both the use case method and the
function points method, the quality of the requirement documents can be improved. Thus, sizing and
estimating is improved.
V. PROBLEM DISCUSSED AND PROPOSED SOLUTION
UCP technique has two major drawbacks:
• The uncertainty of the cost factors
• The ambiguous classification of use cases
187
UUCP is calculated by adding UUCW and UAW, the UAW is easily to be determined, and UUCW is
calculated based on the number of transactions in each use case, which is uncertain in a way, because when
counting the transactions, the human experience, the use case writing style and the level of domain
knowledge will impact the human decision. The number of transactions of a use case may be different if
counted by different people
A. Proposed Solution
This proposal introduces a new approach to overcome the limitations of the UCP. Rather than classifying a
use case as simple, average, or complex, the use case will be classified as ux, such as x 2 [1; 25] where x
represents the number of transactions. This concludes that there will be 25 degrees of complexity for use
cases (u1, u2, u3,.. etc.). The proposed approach will be implemented in two independent stages. First, by
defining the rules, to keep the transactions at a appropriate level and avoid duplicated transactions. Second a
fuzzy logic approach is applied to determine the complexity factor of ux.
B. Refining Use Case Classification
The use case specification is a formal document based on a detailed template with fields which include use
case name, actors, user interface screens, pre-conditions, primary scenario, alternative scenario, exception
scenario, post-conditions and so on. The steps in scenarios describe the interaction between actors and system
at a user view, a step includes actors action and system response. The number of transactions in a use case is
used to classify the difficult level of use case. There is no standard definition of transaction. In this work I use
the definition which is defined as a round trip from the user to the system back to the user [10]. According to
the template of use case specification, a step in use case specification can be regarded as a transaction, but
there are some rules for counting transaction:
• The transactions which are too simple are ignored. e.g. Enter user name, the name are showed in the
screen.
• The transactions which are only different in instantiation are regarded as the same transaction. e.g.
Searching a medicinal book and architectural book can be two different scenarios in use case
specification but the same operation in the database, they can be regarded as the same transaction.
• All exception scenarios in a use case are regarded as one transaction, supposing that a framework is
designed to handle all types of exceptions.
• All transactions in a use case for validating the fields in the screen are regarded as one transaction,
supposing that a framework is designed for validation.
By defining the rules, we can keep the transactions at appropriate level and avoid duplicated transactions.
The following technique can refine the use case classification with fuzzy theory.
C. Fuzzification
Fuzzification of the linguistic terms of use case complexity matrixes by generating fuzzy numbers and extend
three categories to five.
The classification of use cases is extended by adopting the method proposed in [1], two linguistic terms very
simple and very complex are added. The values of these terms are presented in Table 5.
The according fuzzy numbers are presented in Fig:1 according to the membership function in Formula 3.1.
‫ݑ‬(‫ݔ‬) =
⎩
⎪
⎨
⎪
⎧
0 ‫ݔ‬ < ܽ
௫ି௔
௠ି௔
‫ݔ‬ ∈ [ܽ, ݉)
1 ‫ݔ‬ ∈ [݉, ݊]
௕ି௫
௕ି௡
‫ݔ‬ ∈ (݊, ܾ]
0 ‫ݔ‬ > ܾ
(3.1)
D. Defuzzification
After fuzzification the defuzzification of the linguistic terms then give UUCW. According to membership
function and Table 5 values of terms, the weight of the use case can be obtained by formula:
ܹ‫ܨ‬ = ቊ
ܹ‫ܨ‬௖ି௜ #‫݊݋݅ݐܿܽݏ݊ܽݎݐ‬ ∈ [݉௜, ݊௜ ]
‫ݑ‬(‫ݔ‬) ∗ ܹ‫ܨ‬௖ି௜ + ൫1 − ‫ݑ‬(‫ݔ‬)൯ ∗ ܹ‫ܨ‬௖ି௜ାଵ #‫݊݋݅ݐܿܽݏ݊ܽݎݐ‬ ∈ [݊௜, ܾ௜]
(3.2)
188
Finally the UUCW can be calculated by Formula3.3
ܷܷ‫ܹܥ‬ = ∑#ܷ‫ݏ݁ݏܽܥ݁ݏ‬ ∗ ܹ‫ܨ‬ (3.3)
Rather than classifying the use cases into three classes (simple, average and complex) as in Karnerss work
[7], the use cases will be classified into 5 categories according to the number of transactions per use case.
Since the main goal of our approach is to enhance the current model proposed by Karner and not to
completely modifying it, assumed that the largest use case contains 21 transactions. Also assume that the
complexity factor of the largest use case is 25. Table 6 presents a comparison between the original work
(Karners method) and the proposed approach. The table 6 shows that in the proposed approach, the weights
of the use cases are gradually increasing as opposed to the abrupt increase in Karners UCP method.
TABLE V: VALUES OF THE TERMS
Linguistic Terms i mi ni ai bi Weight
Very Simple 1 1 2.5 4 5
Simple 2 4 6 2.5 8 10
Average 3 8 10 6 12 15
Complex 4 12 14 10 16 20
Very Complex 5 16 14 25
Fig 1: Fuzzy numbers After Fuzzification and Extension
TABLE VI: ADJUSTED WEIGHT
No. Of
Transactions in
Use Case
UCP
Weight
Refine
Weight
1 5 5
2 5 5
3 5 6.45
4 10 7.5
5 10 8.55
6 10 10
7 10 11.4
8 15 12.5
9 15 13.6
10 15 15
E. Evaluation Criteria
Several methods exist to compare cost estimation models. Each method has its advantages and disadvantages.
In this work, three methods will be used. These include the Mean of the Magnitude of Relative Error
(MMRE), the Mean of Magnitude of error Relative to the Estimate (MMER) and the Mean Error with
Standard Deviation.
MMRE
This is a very common criterion used to evaluate software cost estimation models [11].
The Magnitude of Relative Error (MRE) for each observation i can be obtained as:
‫ܧܴܯ‬௜ =
|஺௖௧௨௔௟ ா௙௙௢௥௧೔ି௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔|
஺௖௧௨௔௟ ா௙௙௢௥௧೔
(4.1)
MMRE can be achieved through the summation of MRE over N observations:
‫ܧܴܯ‬௜ =
ଵ
ே
∑ ‫ܧܴܯ‬௜
ே
௜ୀଵ (4.2)
189
MMER
MMER is another method for cost estimation models evaluation [12]. MER is similar to MRE with a
difference that the denominator is the predicted effort instead of the actual effort. Consequently, the
equations for MER and MMER are:
‫ܴܧܯ‬௜ =
|஺௖௧௨௔௟ ா௙௙௢௥௧೔ି௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔|
௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔
(4.3)
‫ܴܧܯܯ‬ =
ଵ
ே
∑ ‫ܴܧܯ‬௜
ே
௜ୀଵ (4.4)
When using the MMRE and the MMER in evaluation, good results are implied by lower values of MMRE
and MMER.
Mean Error with Standard Deviation
Although MMRE and MMER have been used for a long time, both methods might lack accuracy. If the
actual effort was small, MMRE would be high. On the other hand, if the predicted effort was low, MMER
would also be high. Foss et al. argued that MMRE should not be used when comparing cost estimation
models and using the standard deviation would be better [13]. The equation for the mean error for each
observation i and total number of observations N is:
‫̅ݔ‬ =
ଵ
ே
∑ ‫ݔ‬௜
ே
௜ୀଵ (4.5)
Where ‫ݔ‬௜ = (‫݈ܽݑݐܿܣ‬ ‫ݐݎ݋݂݂ܧ‬௜ − ܲ‫݀݁ݐܿ݅݀݁ݎ‬ ‫ݐݎ݋݂݂ܧ‬௜)
The equation of the standard deviation can be defined as:
ܵ‫ܦ‬ = ට
ଵ
ேି!
∑ (‫ݔ‬௜ − ‫̅ݔ‬)ଶே
௜ୀଵ (4.6)
F. Case Study
The evaluation of this work was conducted on seven different projects. I collected information about seven
projects information from projects plans, report, and analysis and design documents [14].
There is no standard and known conversion between the size in UCP and the size in function points or SLOC.
Since some information about the complexity of the projects and the team experience is known about each
project, the Technical Factor (TF) and the Environmental Factor (EF) were calculated. Karner suggested that
the effort required to develop one UCP is twenty person hours. This method had been criticized by many
researchers. Schneider et al. [2] refined Karners UCP method in determining the effort from UCP. Schneider
suggested counting the number of factor ratings of F1-F6 in Table 4 (Environmental Factors) that are below
three and the number of factor ratings of F7-F8 that are above three. If the total is three or less, then twenty
person hours per UCP should be used. If the total is three or four, twenty eight person hours per UCP should
be used. If the total is five or more, then the project team should be reconstructed so that the numbers fall at
least below five. A value of five indicates that this project is at significant risk of failure with this team. In
this work, Schneiders method has been used to calculate the size of the projects in UCP from the effort.
Equation 1.4 is used to determine the size of each project in UUCP. To distinguish between the results in the
proposed fuzzy logic, the evaluation of each approach was done separately.
From the Table 7, Fig: 2 shows the comparisons of estimated effort between Actual size UUCP model,
UCPM and Proposed Model and Fig: 3 show the error comparison between UCPM and Proposed Method. It
can concluded that the proposed model improve the software effort estimation with MRE +22% and with
MER +9%.
TABLE VII: COMPARISON BETWEEN UCPM AND THE PROPOSED MODEL
Project Actual
Size
UUCP
UCPM Proposed
Model
MRE
UCPM
MRE
Proposed
Model
MER
UCPM
MER
Proposed
Model
Error
UCPM
Error
Proposed
Model
Project 1 72.44 128.96 104.98 0.78 0.45 0.44 0.31 56.22 32.54
Project 2 74.33 128.54 108.65 0.73 0.46 0.42 0.32 54.21 34.32
Project 3 55.50 51.00 48.70 0.08 0.12 0.09 0.14 -4.50 -6.80
Project 4 68.00 108.50 92.40 0.60 0.36 0.37 0.26 40.50 24.40
Project 5 48.75 74.25 61.25 0.52 0.26 0.34 0.20 25.50 12.50
Project 6 94.50 168.75 144.00 0.79 0.52 0.44 0.34 74.25 49.50
Project 7 72.50 108.41 92.44 0.50 0.28 0.33 0.22 35.91 19.94
Mean 0.57 0.35 0.35 0.26 40.34 23.77
Standard
Dev
25.33 17
190
Fig: 2 Comparison of Estimated Effort
Fig: 3 Error Comparison
VI. CONCLUSION AND FUTURE WORK
In this paper, the weakness of the UCP model are discussed and proposed an enhancement to this model
using fuzzy logic to creation of the linguistic term very simple and very complex. These terms will make the
estimation more accurate specially the use case is comparative complex. Moreover, this approach provides
some rules for counting the transaction which is very crucial for use case complexity weight. From the case
study result it can be concluded that the proposed approach improve the UCP software effort estimation up to
22%.
In future work approach can be applied to other UML diagrams like sequence diagram, state transition
diagram etc. In future work the model can be applied as:
• The largest use case should contain at least 21 transactions.
• Extend and include use cases should be considered when estimating the software size.
191
REFERENCES
[1]. O. Junior, P. Farias, and A. Belchior, “A Fuzzy Model for Function Point Analysis to Development and
Enhancement Project Assessments”, CLE Electronic Journal, 5:2, 1999.
[2]. G. Schneider and J. P. Winters, “Applied use Cases”, Second Edition, A Practical Guide. Addison-Wesley, 2001.
[3]. K. Molokken and M. Jorgensen, “A review of software surveys on software effort estimation” In Empirical Software
Engineering, 2003. ISESE 2003. Proceedings. 2003 International Symposium on, pages 223230.
[4]. B. Kitchenham and S. Linkman. “Estimates, uncertainty, and risk”, IEEE Software, 14(3):6974, 1997.
[5]. L. A. Zadeh,”Fuzzy sets. “Information and Control”, vol. 8, pp. 338-353, 6, 1965.
[6]. Thomas Fetke, Alan Abran, and Tho-Hau Ngyen. “Mapping the oojacobsen approach into function point analysis”
The Proceedings of TOOLS, 23, 1997.
[7]. Karner, G. Metrics for Objectory. “Diploma thesis, University of Linkping” Sweden. No. LiTH-IDAEx- 9344:21.
December 1993.
[8]. John Smith. “The estimation of effort based on use cases,” Rational Software White Paper, 1999.
[9]. David Longstreet. “Use cases and function points” Copyright Longstreet Consulting Inc. www.softwaremetrics.com,
2001.
[10]. Jacobson, I. and Christerson, M. and Jonsson, P. and Overgaard, G. “Object- Oriented Software Engineering: A Use
Case Driven Approach” Harlow, Essex, England: Addison Wesley Longman, 1992.
[11].L. C. Briand, K. E. Emam, D. Surmann, I. Wieczorek and K. D. Maxwell, “An assessment and comparison of
common software cost estimation modeling techniques ”, ICSE’99, vol. 0, pp. 313-322, 1999.
[12].B. A. Kitchenham, L. M. Pickard, S. G. MacDonell and M. J. Shepperd, “Accuracy Statistics Really Measure”, IEE
Proc. -Softw, vol. 148, pp. 81-85, 2001.
[13].T. Foss, E. Stensrud, B. Kitchenham and I. Myrtveit, “A Simulation Study of the Model Evaluation Criterion
MMRE”, IEEE Transactions on Software Engineering, vol. 29, pp. 985-995, 2003.
[14].Ribu, K. “Estimating Object-Oriented Software Projects with Use Cases ” , University of Oslo, Department of
informatics, Master of Science Thesis, 7th November 2001.

Más contenido relacionado

La actualidad más candente

EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...
EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...
EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...ijseajournal
 
A Cost Estimation Model For Reuse Based Software Program
A Cost Estimation Model For Reuse Based Software ProgramA Cost Estimation Model For Reuse Based Software Program
A Cost Estimation Model For Reuse Based Software ProgramIOSR Journals
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...ijceronline
 
IRJET- Machine Learning Techniques for Code Optimization
IRJET-  	  Machine Learning Techniques for Code OptimizationIRJET-  	  Machine Learning Techniques for Code Optimization
IRJET- Machine Learning Techniques for Code OptimizationIRJET Journal
 
OR (JNTUK) III Mech Unit 8 simulation
OR (JNTUK) III Mech Unit 8  simulationOR (JNTUK) III Mech Unit 8  simulation
OR (JNTUK) III Mech Unit 8 simulationNageswara Rao Thots
 
Iso9126 based software quality evaluation using choquet integral
Iso9126 based software quality evaluation using choquet integral Iso9126 based software quality evaluation using choquet integral
Iso9126 based software quality evaluation using choquet integral ijseajournal
 
RME-085_TQM Unit-4 Part 3
RME-085_TQM Unit-4  Part 3RME-085_TQM Unit-4  Part 3
RME-085_TQM Unit-4 Part 3ssuserf6c4bd
 
Comparative Performance Analysis of Machine Learning Techniques for Software ...
Comparative Performance Analysis of Machine Learning Techniques for Software ...Comparative Performance Analysis of Machine Learning Techniques for Software ...
Comparative Performance Analysis of Machine Learning Techniques for Software ...csandit
 
RME-085 TQM Unit-5 part 5
RME-085 TQM Unit-5  part 5RME-085 TQM Unit-5  part 5
RME-085 TQM Unit-5 part 5ssuserf6c4bd
 
Reengineering framework for open source software using decision tree approach
Reengineering framework for open source software using decision tree approachReengineering framework for open source software using decision tree approach
Reengineering framework for open source software using decision tree approachIJECEIAES
 
Cause-Effect Graphing: Rigorous Test Case Design
Cause-Effect Graphing: Rigorous Test Case DesignCause-Effect Graphing: Rigorous Test Case Design
Cause-Effect Graphing: Rigorous Test Case DesignTechWell
 
Configuration Navigation Analysis Model for Regression Test Case Prioritization
Configuration Navigation Analysis Model for Regression Test Case PrioritizationConfiguration Navigation Analysis Model for Regression Test Case Prioritization
Configuration Navigation Analysis Model for Regression Test Case Prioritizationijsrd.com
 
RME-085_TQM_Unit-4 (Part-2)
RME-085_TQM_Unit-4  (Part-2)RME-085_TQM_Unit-4  (Part-2)
RME-085_TQM_Unit-4 (Part-2)ssuserf6c4bd
 

La actualidad más candente (19)

EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...
EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...
EFFECTIVE IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO...
 
A Cost Estimation Model For Reuse Based Software Program
A Cost Estimation Model For Reuse Based Software ProgramA Cost Estimation Model For Reuse Based Software Program
A Cost Estimation Model For Reuse Based Software Program
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
 
IRJET- Machine Learning Techniques for Code Optimization
IRJET-  	  Machine Learning Techniques for Code OptimizationIRJET-  	  Machine Learning Techniques for Code Optimization
IRJET- Machine Learning Techniques for Code Optimization
 
OR (JNTUK) III Mech Unit 8 simulation
OR (JNTUK) III Mech Unit 8  simulationOR (JNTUK) III Mech Unit 8  simulation
OR (JNTUK) III Mech Unit 8 simulation
 
Ijetcas14 468
Ijetcas14 468Ijetcas14 468
Ijetcas14 468
 
Iso9126 based software quality evaluation using choquet integral
Iso9126 based software quality evaluation using choquet integral Iso9126 based software quality evaluation using choquet integral
Iso9126 based software quality evaluation using choquet integral
 
Slides chapters 28-32
Slides chapters 28-32Slides chapters 28-32
Slides chapters 28-32
 
RME-085_TQM Unit-4 Part 3
RME-085_TQM Unit-4  Part 3RME-085_TQM Unit-4  Part 3
RME-085_TQM Unit-4 Part 3
 
Comparative Performance Analysis of Machine Learning Techniques for Software ...
Comparative Performance Analysis of Machine Learning Techniques for Software ...Comparative Performance Analysis of Machine Learning Techniques for Software ...
Comparative Performance Analysis of Machine Learning Techniques for Software ...
 
RME-085 TQM Unit-5 part 5
RME-085 TQM Unit-5  part 5RME-085 TQM Unit-5  part 5
RME-085 TQM Unit-5 part 5
 
Reengineering framework for open source software using decision tree approach
Reengineering framework for open source software using decision tree approachReengineering framework for open source software using decision tree approach
Reengineering framework for open source software using decision tree approach
 
Ijetcas14 340
Ijetcas14 340Ijetcas14 340
Ijetcas14 340
 
Cause-Effect Graphing: Rigorous Test Case Design
Cause-Effect Graphing: Rigorous Test Case DesignCause-Effect Graphing: Rigorous Test Case Design
Cause-Effect Graphing: Rigorous Test Case Design
 
Configuration Navigation Analysis Model for Regression Test Case Prioritization
Configuration Navigation Analysis Model for Regression Test Case PrioritizationConfiguration Navigation Analysis Model for Regression Test Case Prioritization
Configuration Navigation Analysis Model for Regression Test Case Prioritization
 
Optimazation
OptimazationOptimazation
Optimazation
 
Software metrics
Software metricsSoftware metrics
Software metrics
 
RME-085_TQM_Unit-4 (Part-2)
RME-085_TQM_Unit-4  (Part-2)RME-085_TQM_Unit-4  (Part-2)
RME-085_TQM_Unit-4 (Part-2)
 
1841 1843
1841 18431841 1843
1841 1843
 

Destacado

Iwsm2014 an analogy-based approach to estimation of software development ef...
Iwsm2014   an analogy-based approach to estimation of software development ef...Iwsm2014   an analogy-based approach to estimation of software development ef...
Iwsm2014 an analogy-based approach to estimation of software development ef...Nesma
 
Supervised machine learning based dynamic estimation
Supervised machine learning based dynamic estimationSupervised machine learning based dynamic estimation
Supervised machine learning based dynamic estimationeSAT Publishing House
 
A Hybrid Approach to Expert and Model Based Effort Estimation
A Hybrid Approach to Expert and Model Based Effort Estimation  A Hybrid Approach to Expert and Model Based Effort Estimation
A Hybrid Approach to Expert and Model Based Effort Estimation CS, NcState
 
Principles of effort estimation
Principles of effort estimationPrinciples of effort estimation
Principles of effort estimationCS, NcState
 
Software Cost Estimation Methods:A Review - Persian
Software Cost Estimation Methods:A Review - PersianSoftware Cost Estimation Methods:A Review - Persian
Software Cost Estimation Methods:A Review - PersianMobin Ranjbar
 
Software effort estimation through clustering techniques of RBFN network
Software effort estimation through clustering techniques of RBFN networkSoftware effort estimation through clustering techniques of RBFN network
Software effort estimation through clustering techniques of RBFN networkIOSR Journals
 
Issues in software cost estimation
Issues in software cost estimationIssues in software cost estimation
Issues in software cost estimationKashif Aleem
 
How to Find Relevant Data for Effort Estimation
How to Find Relevant Data for Effort EstimationHow to Find Relevant Data for Effort Estimation
How to Find Relevant Data for Effort EstimationCS, NcState
 
مفاهیم رایانش ابری
مفاهیم رایانش ابریمفاهیم رایانش ابری
مفاهیم رایانش ابریAli Aboutalebi
 
Role of Big Data in Start-ups - Persian
Role of Big Data in Start-ups - PersianRole of Big Data in Start-ups - Persian
Role of Big Data in Start-ups - PersianMobin Ranjbar
 
software effort estimation
 software effort estimation software effort estimation
software effort estimationBesharam Dil
 
Software estimation techniques
Software estimation techniquesSoftware estimation techniques
Software estimation techniquesTan Tran
 
Software cost estimation project
Software  cost estimation projectSoftware  cost estimation project
Software cost estimation projectShashank Puppala
 
166 - ISBSG variables most frequently used for software effort estimation: A ...
166 - ISBSG variables most frequently used for software effort estimation: A ...166 - ISBSG variables most frequently used for software effort estimation: A ...
166 - ISBSG variables most frequently used for software effort estimation: A ...ESEM 2014
 
Software Estimation Techniques
Software Estimation TechniquesSoftware Estimation Techniques
Software Estimation Techniqueskamal
 

Destacado (17)

Iwsm2014 an analogy-based approach to estimation of software development ef...
Iwsm2014   an analogy-based approach to estimation of software development ef...Iwsm2014   an analogy-based approach to estimation of software development ef...
Iwsm2014 an analogy-based approach to estimation of software development ef...
 
Supervised machine learning based dynamic estimation
Supervised machine learning based dynamic estimationSupervised machine learning based dynamic estimation
Supervised machine learning based dynamic estimation
 
A Hybrid Approach to Expert and Model Based Effort Estimation
A Hybrid Approach to Expert and Model Based Effort Estimation  A Hybrid Approach to Expert and Model Based Effort Estimation
A Hybrid Approach to Expert and Model Based Effort Estimation
 
Principles of effort estimation
Principles of effort estimationPrinciples of effort estimation
Principles of effort estimation
 
Software Cost Estimation Methods:A Review - Persian
Software Cost Estimation Methods:A Review - PersianSoftware Cost Estimation Methods:A Review - Persian
Software Cost Estimation Methods:A Review - Persian
 
Effort estimation1
Effort estimation1Effort estimation1
Effort estimation1
 
Software effort estimation through clustering techniques of RBFN network
Software effort estimation through clustering techniques of RBFN networkSoftware effort estimation through clustering techniques of RBFN network
Software effort estimation through clustering techniques of RBFN network
 
Issues in software cost estimation
Issues in software cost estimationIssues in software cost estimation
Issues in software cost estimation
 
How to Find Relevant Data for Effort Estimation
How to Find Relevant Data for Effort EstimationHow to Find Relevant Data for Effort Estimation
How to Find Relevant Data for Effort Estimation
 
مفاهیم رایانش ابری
مفاهیم رایانش ابریمفاهیم رایانش ابری
مفاهیم رایانش ابری
 
Role of Big Data in Start-ups - Persian
Role of Big Data in Start-ups - PersianRole of Big Data in Start-ups - Persian
Role of Big Data in Start-ups - Persian
 
software effort estimation
 software effort estimation software effort estimation
software effort estimation
 
Software estimation techniques
Software estimation techniquesSoftware estimation techniques
Software estimation techniques
 
Guide to Software Estimation
Guide to Software EstimationGuide to Software Estimation
Guide to Software Estimation
 
Software cost estimation project
Software  cost estimation projectSoftware  cost estimation project
Software cost estimation project
 
166 - ISBSG variables most frequently used for software effort estimation: A ...
166 - ISBSG variables most frequently used for software effort estimation: A ...166 - ISBSG variables most frequently used for software effort estimation: A ...
166 - ISBSG variables most frequently used for software effort estimation: A ...
 
Software Estimation Techniques
Software Estimation TechniquesSoftware Estimation Techniques
Software Estimation Techniques
 

Similar a 501 183-191

Karner resource estimation for objectory projects
Karner   resource estimation for objectory projectsKarner   resource estimation for objectory projects
Karner resource estimation for objectory projectsOcho08
 
Use case point ( Software Estimation Technique)
Use case point ( Software Estimation Technique)Use case point ( Software Estimation Technique)
Use case point ( Software Estimation Technique)Punjab University
 
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveySize and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveyIJERA Editor
 
Advancement of ucp with end user
Advancement of ucp with end userAdvancement of ucp with end user
Advancement of ucp with end userijseajournal
 
Software Engineering Fundamentals in Computer Science
Software Engineering Fundamentals in Computer ScienceSoftware Engineering Fundamentals in Computer Science
Software Engineering Fundamentals in Computer ScienceArti Parab Academics
 
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...ijaia
 
IRJET- Analysis of Software Cost Estimation Techniques
IRJET- Analysis of Software Cost Estimation TechniquesIRJET- Analysis of Software Cost Estimation Techniques
IRJET- Analysis of Software Cost Estimation TechniquesIRJET Journal
 
Cost Analysis of ComFrame: A Communication Framework for Data Management in ...
Cost Analysis of ComFrame: A Communication Framework for  Data Management in ...Cost Analysis of ComFrame: A Communication Framework for  Data Management in ...
Cost Analysis of ComFrame: A Communication Framework for Data Management in ...IOSR Journals
 
Top-Down Estimation Approach
Top-Down Estimation ApproachTop-Down Estimation Approach
Top-Down Estimation ApproachSabiha M
 
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITS
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITSSOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITS
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITSvivatechijri
 
PIDtuningsoftwareApracticalreview.pdf
PIDtuningsoftwareApracticalreview.pdfPIDtuningsoftwareApracticalreview.pdf
PIDtuningsoftwareApracticalreview.pdfAbdulSalamSagir1
 
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENT
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENTENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENT
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENTIRJET Journal
 
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks Test Case Optimization and Redundancy Reduction Using GA and Neural Networks
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks IJECEIAES
 
SE-CyclomaticComplexityand Testing.ppt
SE-CyclomaticComplexityand Testing.pptSE-CyclomaticComplexityand Testing.ppt
SE-CyclomaticComplexityand Testing.pptvishal choudhary
 
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWARE
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWAREA METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWARE
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWAREijseajournal
 

Similar a 501 183-191 (20)

Karner resource estimation for objectory projects
Karner   resource estimation for objectory projectsKarner   resource estimation for objectory projects
Karner resource estimation for objectory projects
 
Use case point ( Software Estimation Technique)
Use case point ( Software Estimation Technique)Use case point ( Software Estimation Technique)
Use case point ( Software Estimation Technique)
 
Kitamura1992
Kitamura1992Kitamura1992
Kitamura1992
 
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveySize and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
 
Costing ass4
Costing ass4Costing ass4
Costing ass4
 
Advancement of ucp with end user
Advancement of ucp with end userAdvancement of ucp with end user
Advancement of ucp with end user
 
Comparison of available Methods to Estimate Effort, Performance and Cost with...
Comparison of available Methods to Estimate Effort, Performance and Cost with...Comparison of available Methods to Estimate Effort, Performance and Cost with...
Comparison of available Methods to Estimate Effort, Performance and Cost with...
 
Software Engineering Fundamentals in Computer Science
Software Engineering Fundamentals in Computer ScienceSoftware Engineering Fundamentals in Computer Science
Software Engineering Fundamentals in Computer Science
 
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...
REGULARIZED FUZZY NEURAL NETWORKS TO AID EFFORT FORECASTING IN THE CONSTRUCTI...
 
IRJET- Analysis of Software Cost Estimation Techniques
IRJET- Analysis of Software Cost Estimation TechniquesIRJET- Analysis of Software Cost Estimation Techniques
IRJET- Analysis of Software Cost Estimation Techniques
 
Cost Analysis of ComFrame: A Communication Framework for Data Management in ...
Cost Analysis of ComFrame: A Communication Framework for  Data Management in ...Cost Analysis of ComFrame: A Communication Framework for  Data Management in ...
Cost Analysis of ComFrame: A Communication Framework for Data Management in ...
 
Top-Down Estimation Approach
Top-Down Estimation ApproachTop-Down Estimation Approach
Top-Down Estimation Approach
 
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITS
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITSSOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITS
SOFTWARE BASED CALCULATION OF CAPACITY OUTAGE OF GENERATING UNITS
 
V2I6_IJERTV2IS60721
V2I6_IJERTV2IS60721V2I6_IJERTV2IS60721
V2I6_IJERTV2IS60721
 
PIDtuningsoftwareApracticalreview.pdf
PIDtuningsoftwareApracticalreview.pdfPIDtuningsoftwareApracticalreview.pdf
PIDtuningsoftwareApracticalreview.pdf
 
Print report
Print reportPrint report
Print report
 
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENT
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENTENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENT
ENVIRONMENTAL QUALITY PREDICTION AND ITS DEPLOYMENT
 
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks Test Case Optimization and Redundancy Reduction Using GA and Neural Networks
Test Case Optimization and Redundancy Reduction Using GA and Neural Networks
 
SE-CyclomaticComplexityand Testing.ppt
SE-CyclomaticComplexityand Testing.pptSE-CyclomaticComplexityand Testing.ppt
SE-CyclomaticComplexityand Testing.ppt
 
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWARE
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWAREA METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWARE
A METRICS -BASED MODEL FOR ESTIMATING THE MAINTENANCE EFFORT OF PYTHON SOFTWARE
 

Más de idescitation (20)

65 113-121
65 113-12165 113-121
65 113-121
 
69 122-128
69 122-12869 122-128
69 122-128
 
71 338-347
71 338-34771 338-347
71 338-347
 
72 129-135
72 129-13572 129-135
72 129-135
 
74 136-143
74 136-14374 136-143
74 136-143
 
80 152-157
80 152-15780 152-157
80 152-157
 
82 348-355
82 348-35582 348-355
82 348-355
 
84 11-21
84 11-2184 11-21
84 11-21
 
62 328-337
62 328-33762 328-337
62 328-337
 
46 102-112
46 102-11246 102-112
46 102-112
 
47 292-298
47 292-29847 292-298
47 292-298
 
49 299-305
49 299-30549 299-305
49 299-305
 
57 306-311
57 306-31157 306-311
57 306-311
 
60 312-318
60 312-31860 312-318
60 312-318
 
5 1-10
5 1-105 1-10
5 1-10
 
11 69-81
11 69-8111 69-81
11 69-81
 
14 284-291
14 284-29114 284-291
14 284-291
 
15 82-87
15 82-8715 82-87
15 82-87
 
29 88-96
29 88-9629 88-96
29 88-96
 
43 97-101
43 97-10143 97-101
43 97-101
 

Último

PISA-VET launch_El Iza Mohamedou_19 March 2024.pptx
PISA-VET launch_El Iza Mohamedou_19 March 2024.pptxPISA-VET launch_El Iza Mohamedou_19 March 2024.pptx
PISA-VET launch_El Iza Mohamedou_19 March 2024.pptxEduSkills OECD
 
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdf
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdfP4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdf
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdfYu Kanazawa / Osaka University
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...raviapr7
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxheathfieldcps1
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRATanmoy Mishra
 
How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17Celine George
 
Presentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphPresentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphNetziValdelomar1
 
CapTechU Doctoral Presentation -March 2024 slides.pptx
CapTechU Doctoral Presentation -March 2024 slides.pptxCapTechU Doctoral Presentation -March 2024 slides.pptx
CapTechU Doctoral Presentation -March 2024 slides.pptxCapitolTechU
 
HED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfHED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfMohonDas
 
M-2- General Reactions of amino acids.pptx
M-2- General Reactions of amino acids.pptxM-2- General Reactions of amino acids.pptx
M-2- General Reactions of amino acids.pptxDr. Santhosh Kumar. N
 
Philosophy of Education and Educational Philosophy
Philosophy of Education  and Educational PhilosophyPhilosophy of Education  and Educational Philosophy
Philosophy of Education and Educational PhilosophyShuvankar Madhu
 
The Singapore Teaching Practice document
The Singapore Teaching Practice documentThe Singapore Teaching Practice document
The Singapore Teaching Practice documentXsasf Sfdfasd
 
How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17Celine George
 
How to Add a New Field in Existing Kanban View in Odoo 17
How to Add a New Field in Existing Kanban View in Odoo 17How to Add a New Field in Existing Kanban View in Odoo 17
How to Add a New Field in Existing Kanban View in Odoo 17Celine George
 
Human-AI Co-Creation of Worked Examples for Programming Classes
Human-AI Co-Creation of Worked Examples for Programming ClassesHuman-AI Co-Creation of Worked Examples for Programming Classes
Human-AI Co-Creation of Worked Examples for Programming ClassesMohammad Hassany
 
General views of Histopathology and step
General views of Histopathology and stepGeneral views of Histopathology and step
General views of Histopathology and stepobaje godwin sunday
 
Diploma in Nursing Admission Test Question Solution 2023.pdf
Diploma in Nursing Admission Test Question Solution 2023.pdfDiploma in Nursing Admission Test Question Solution 2023.pdf
Diploma in Nursing Admission Test Question Solution 2023.pdfMohonDas
 
UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE
 

Último (20)

PISA-VET launch_El Iza Mohamedou_19 March 2024.pptx
PISA-VET launch_El Iza Mohamedou_19 March 2024.pptxPISA-VET launch_El Iza Mohamedou_19 March 2024.pptx
PISA-VET launch_El Iza Mohamedou_19 March 2024.pptx
 
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdf
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdfP4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdf
P4C x ELT = P4ELT: Its Theoretical Background (Kanazawa, 2024 March).pdf
 
Prelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quizPrelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quiz
 
Finals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quizFinals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quiz
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptx
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
 
How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17
 
Presentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphPresentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a Paragraph
 
CapTechU Doctoral Presentation -March 2024 slides.pptx
CapTechU Doctoral Presentation -March 2024 slides.pptxCapTechU Doctoral Presentation -March 2024 slides.pptx
CapTechU Doctoral Presentation -March 2024 slides.pptx
 
HED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfHED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdf
 
M-2- General Reactions of amino acids.pptx
M-2- General Reactions of amino acids.pptxM-2- General Reactions of amino acids.pptx
M-2- General Reactions of amino acids.pptx
 
Philosophy of Education and Educational Philosophy
Philosophy of Education  and Educational PhilosophyPhilosophy of Education  and Educational Philosophy
Philosophy of Education and Educational Philosophy
 
The Singapore Teaching Practice document
The Singapore Teaching Practice documentThe Singapore Teaching Practice document
The Singapore Teaching Practice document
 
How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17
 
How to Add a New Field in Existing Kanban View in Odoo 17
How to Add a New Field in Existing Kanban View in Odoo 17How to Add a New Field in Existing Kanban View in Odoo 17
How to Add a New Field in Existing Kanban View in Odoo 17
 
Human-AI Co-Creation of Worked Examples for Programming Classes
Human-AI Co-Creation of Worked Examples for Programming ClassesHuman-AI Co-Creation of Worked Examples for Programming Classes
Human-AI Co-Creation of Worked Examples for Programming Classes
 
General views of Histopathology and step
General views of Histopathology and stepGeneral views of Histopathology and step
General views of Histopathology and step
 
Diploma in Nursing Admission Test Question Solution 2023.pdf
Diploma in Nursing Admission Test Question Solution 2023.pdfDiploma in Nursing Admission Test Question Solution 2023.pdf
Diploma in Nursing Admission Test Question Solution 2023.pdf
 
UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024
 

501 183-191

  • 1. Refining the Use Case Classification for Use Case Point Method for Software Effort Estimation Divya Kashyap 1 , Durgesh Shukla 2 and A. K. Misra2 1,2,3 Department of Computer Science and Engineering Motilal Nehru National Institute of Technology Allahabad, India Email: {rcs0904@mnnit.ac.in, durgeshkrshukla@gmail.com, Kashyap.div2011@gmail.com} Abstract— Software cost estimation is a key open issue for the software industry, which suffers from cost overruns frequently. As the most popular technique for object-oriented software cost estimation is Use Case Points (UCP) method, however, it has two major drawbacks: the uncertainty of the cost factors and the abrupt classification. To address these two issues, refined the use case complexity classification using fuzzy logic theory which mitigate the uncertainty of cost factors and improve the accuracy of classification. Software estimation is a crucial task in software engineering. Software estimation encompasses cost, effort, schedule, and size. The importance of software estimation becomes critical in the early stages of the software life cycle when the details of software have not been revealed yet. Several commercial and non-commercial tools exist to estimate software in the early stages. Most software effort estimation methods require software size as one of the important metric inputs and consequently, software size estimation in the early stages becomes essential. The proposed method presents a techniques using fuzzy logic theory to improve the accuracy of the use case points method by refining the use case classification. Index Terms— Cost Estimation, Function Point, Fuzzy Logic, MMRE, and Use case point. I. INTRODUCTION Software cost estimation is vital for project bidding, budgeting, controlling and planning. Bad estimation will lead to the failure and good one will enable the project deliver on time and within budget. Due to lack of information to make decisions at an early stage in development, the cost estimation is full of uncertainty. Although in the literature many estimation models like Constructive Cost Model (COCOMO), Function Points (FP) have been proposed to help manager in estimation task, there is no obvious evidence shows that the accuracy is improved in last decades [3]. Achieving a highly accurate estimation is still a challenging issue in software engineering. We believe that there are two reasons: one is that something inside the cost model is not proper in practical, the other is the inherent uncertainty of assessment of the cost from the cost factors relied on the expert determination. To address these problems, the first step we need is to find out the improper part in practical and then improve it accordingly, secondly, we need to manage these uncertainties to lower the risk of the project being failed [4]. Among various existing cost models, UCP has become well known and widely accepted because it utilizes two common practices in the industry: the object-oriented paradigm and use case to describe functionality requirements. Taking deterministic value as inputs, UCP can give most likely cost estimation. The reminder of this paper can describe as follows: Section II contains a description of the UCP method, DOI: 02.ITC.2014.5.501 © Association of Computer Electronics and Electrical Engineers, 2014 Proc. of Int. Conf. on Recent Trends in Information, Telecommunication and Computing, ITC
  • 2. 184 Section III describe Fuzzy logic concept. In Section IV different techniques used to estimate software costs are discussed, Section V give the details of proposed method with related case study. The paper ends with conclusion and future work for proposed method. II. USE CASE POINTS METHOD An early estimate of effort based on use cases can be made when there is some understanding of the problem domain, system size and architecture at the stage at which the estimate is made. The use case points method is a software sizing and estimation method based on use case counts called use case points. TABLE I: ACTOR WEIGHT FACTOR Actor Type Weighting Factor Simple 1 Average 2 Complex 3 TABLE II: USE CASE COMPLEXITY WEIGHT FACTOR Use Case Type Number Of Transactions Weighting factor Simple ≤3 5 Average 4 to 7 10 Complex ≥8 15 A. Classifying Actors and Use Cases Use case points can be counted from the use case analysis of the system. The first step is to classify the actors as simple, average or complex. A simple actor represents another system with a defined Application Programming Interface, API, an average actor is another system interacting through a protocol such as TCP/IP, and a complex actor may be a person interacting through a GUI or a Web page. A weighting factor is assigned to each actor type according to Table 1. The total unadjusted actor weights (UAW) is calculated by counting how many actors there are of each kind (by degree of complexity), multiplying each total by its weighting factor, and adding up the products. Each use case is then defined as simple, average or complex, depending on number of transactions in the use case description, including secondary scenarios. A transaction is a set of activities, which is either performed entirely, or not at all. Counting number of transactions can be done by counting the use case steps. Another mechanism for measuring use case complexity is counting analysis classes, which can be used in place of transactions once it has been determined which classes implement a specific use case. A simple use case is implemented by 5 or fewer classes and average use case by 5 to 10 classes and a complex use case by more than ten classes. The weights are as in Table 2. Each type of use case is then multiplied by the weighting factor, and the products are added up to get the Unadjusted Use Case Weights (UUCW) The UAW is added to the UUCW to get the unadjusted use case points (UUPC) UUCP = UAW + UUCW (1.1) B. Technical and Environmental Factors The UCP method also employs a technical factors multiplier corresponding to the Technical Complexity Adjustment factor of the FPA method, and an environmental factors multiplier in order to quantify non- functional requirements such as ease of use and programmer motivation. Various factors influencing productivity are associated with weights, and values are assigned to each factor, depending on the degree of influence. 0 means no influence, 3 is average, and 5 means strong influence throughout. Table 3 and Table 4 show the Technical and Environmental Factors. The adjustment factors are multiplied by the unadjusted use case points to produce the adjusted use case points, yielding an estimate of the size of the software. The Technical Complexity Factor (TCF) is calculated
  • 3. 185 by multiplying the value of each factor (T1- T13) by its weight and then adding all these numbers to get the sum called the TFactor. The following formula is applied: ܶ‫ܨܥ‬ = 0: 6 + 0: 01_ܶ‫ݎ݋ݐܿܽܨ‬ (1.2) The Environmental Factor (EF) is calculated by multiplying the value of each factor (F1-F8) by its weight and adding the products to get the sum called the EFactor. The following formula is applied- ‫ܨܧ‬ = 1.4 + (−0.03 ∗ ‫ݎ݋ݐܿܽܨܧ‬) (1.3) The adjusted use case points (UPC) are calculated as follows: ܷܲ‫ܥ‬ = ܷܷ‫ܲܥ‬ ∗ ܶ‫ܨܥ‬ ∗ ‫ܨܧ‬ (1.4) TABLE III: TECHNICAL COMPLEXITY FACTORS Factor Description Weight T1 Distributed System 2 T2 Response adjectives 2 T3 End-User efficiency 1 T4 Complex processing 1 T5 Reusable code 1 T6 Easy to install 0.5 T7 Easy to use 0.5 T8 Portable 2 T9 Easy to change 1 T10 Concurrent 1 T11 Security features 1 T12 Access for third party 1 T13 Special training required 1 TABLE IV: ENVIRONMENTAL FACTORS C. Producing Estimates Based on Use Case Points Karner proposed a factor of 20 staff hours per use case point for a project estimate. Field experience has shown that effort can range from 15 to 30 hours per use case point, therefore converting use case points directly to hours may be an uncertain measure. Schneider and Winters [2] recommend that the environmental factors should determine the number of staff hours per use case point as follow: NF = The number of factors in F1 through F6 that have value < 3 + The number of factors in F7 through F8 that have value > 3 If NF≤ 2 then PF=20 If NF=3 or 4 then PF = 28 If NF>4 then Factor Description Weight F1 Familiar with RUP 1.5 F2 Application experience 0.5 F3 Object-oriented experience 1 F4 Lead analyst capability 0.5 F5 Motivation 1 F6 Stable Requirements 2 F7 Part-time workers -1 F8 Difficult programming language 2
  • 4. 186 PF=36 The reason for this approach is that the environmental factors measure the experience level of the staff and the stability of the project. Negative numbers mean extra effort spent on training team members or problems due to instability. However, using this method of calculation means that even small adjustments of an environmental factor, for instance by half a point, can make a great difference to the estimate. III. FUZZY LOGIC Fuzzy logic is derived from the fuzzy set theory that was proposed by Lotfi Zadeh in 1965 [5]. As a contrary to the conventional binary logic that can only handle two values True or False (1 or 0), fuzzy logic can have a truth value which is ranged between 0 and 1. This means that in the binary logic, a member is completely belonged or not belonged to a certain set, however in the fuzzy logic, a member can partially belong to a certain set. Mathematically, a fuzzy set A is represented by a membership function as follows: ‫ݖܨ‬[‫ܣ߳ݔ‬] = ߤ‫ܣ‬(‫ݔ‬): ܴ ⟹ [0,1] (2.1) Where μA is the degree of the membership of element x in the fuzzy set A. A fuzzy set is represented by a membership function. Each element will have a grade of membership that represents the degree to which a specific element belongs to the set. Membership functions include Triangular, Trapezoidal and S-Shaped. In fuzzy logic, linguistic variables are used to express a rule or fact. For example, the temperature is thirty degrees is expressed in fuzzy logic by the temperature is low or the temperature is high where the words low and high are linguistic variables. In fuzzy logic, the knowledge based is represented by if-then rules. For example, if the temperature is high, then turn on the fan. The fuzzy system is mainly composed of three parts. These include Fuzzification, Fuzzy Rule Application and Defuzzification. Fuzzification means applying fuzzy membership functions to inputs. Fuzzy Rule Application is to make inferences and associations among members in different groups. The third step in the fuzzy system is to defuzzify the inferences and associations and make a decision and provide an output that can be understood. In this proposal, fuzzy logic will be used to calibrate the complexity weight of use cases. IV. RELATED WORK A method for mapping the object-oriented approach into Function point analysis is described by Thomas Fetke et al., [6]. The authors propose mapping the use cases directly into the Function point model using a set of concise rules that support the measurement process. These mapping rules are based on the standard FPA defined in the IFPUG Counting Practices manual. Since the concept of actors in the use case model is broader than the concept of users and external applications in FPA, there cannot be a one to- one mapping of actors and users to external applications. But each user of the system is defined as an actor. In the same manner, all applications which communicate with the system under consideration must also appear as actors. This corresponds to Karner’s use case point method [7]. The level of detail in the use case model may vary, and the use case model does not provide enough information to how to count a specific use case according to function point rules. Therefore, as in Karner’s method, the use cases must be described in further detail in order to be able to count transactions. John Smith of Rational Software describes a method presenting a framework for estimation based on use cases translated into lines of code [8] There does not seem to be any more research done on this method, although the tool ‘Estimate Professional’, which is supplied by the Software Productivity Center Inc, and the tool ‘CostXpert’ from Marotz Inc. produce estimates of effort per use case calculated from the number of lines of code. David Longstreet of Software Metrics observed that applying function points helps to determine if the use case is written at a suitable level of detail [9]. If it is possible to describe how data passes from the actor to inside the boundary or how data flows from inside the application boundary to the actor, then that is the right level of detail, otherwise the use case needs more detail. By adopting both the use case method and the function points method, the quality of the requirement documents can be improved. Thus, sizing and estimating is improved. V. PROBLEM DISCUSSED AND PROPOSED SOLUTION UCP technique has two major drawbacks: • The uncertainty of the cost factors • The ambiguous classification of use cases
  • 5. 187 UUCP is calculated by adding UUCW and UAW, the UAW is easily to be determined, and UUCW is calculated based on the number of transactions in each use case, which is uncertain in a way, because when counting the transactions, the human experience, the use case writing style and the level of domain knowledge will impact the human decision. The number of transactions of a use case may be different if counted by different people A. Proposed Solution This proposal introduces a new approach to overcome the limitations of the UCP. Rather than classifying a use case as simple, average, or complex, the use case will be classified as ux, such as x 2 [1; 25] where x represents the number of transactions. This concludes that there will be 25 degrees of complexity for use cases (u1, u2, u3,.. etc.). The proposed approach will be implemented in two independent stages. First, by defining the rules, to keep the transactions at a appropriate level and avoid duplicated transactions. Second a fuzzy logic approach is applied to determine the complexity factor of ux. B. Refining Use Case Classification The use case specification is a formal document based on a detailed template with fields which include use case name, actors, user interface screens, pre-conditions, primary scenario, alternative scenario, exception scenario, post-conditions and so on. The steps in scenarios describe the interaction between actors and system at a user view, a step includes actors action and system response. The number of transactions in a use case is used to classify the difficult level of use case. There is no standard definition of transaction. In this work I use the definition which is defined as a round trip from the user to the system back to the user [10]. According to the template of use case specification, a step in use case specification can be regarded as a transaction, but there are some rules for counting transaction: • The transactions which are too simple are ignored. e.g. Enter user name, the name are showed in the screen. • The transactions which are only different in instantiation are regarded as the same transaction. e.g. Searching a medicinal book and architectural book can be two different scenarios in use case specification but the same operation in the database, they can be regarded as the same transaction. • All exception scenarios in a use case are regarded as one transaction, supposing that a framework is designed to handle all types of exceptions. • All transactions in a use case for validating the fields in the screen are regarded as one transaction, supposing that a framework is designed for validation. By defining the rules, we can keep the transactions at appropriate level and avoid duplicated transactions. The following technique can refine the use case classification with fuzzy theory. C. Fuzzification Fuzzification of the linguistic terms of use case complexity matrixes by generating fuzzy numbers and extend three categories to five. The classification of use cases is extended by adopting the method proposed in [1], two linguistic terms very simple and very complex are added. The values of these terms are presented in Table 5. The according fuzzy numbers are presented in Fig:1 according to the membership function in Formula 3.1. ‫ݑ‬(‫ݔ‬) = ⎩ ⎪ ⎨ ⎪ ⎧ 0 ‫ݔ‬ < ܽ ௫ି௔ ௠ି௔ ‫ݔ‬ ∈ [ܽ, ݉) 1 ‫ݔ‬ ∈ [݉, ݊] ௕ି௫ ௕ି௡ ‫ݔ‬ ∈ (݊, ܾ] 0 ‫ݔ‬ > ܾ (3.1) D. Defuzzification After fuzzification the defuzzification of the linguistic terms then give UUCW. According to membership function and Table 5 values of terms, the weight of the use case can be obtained by formula: ܹ‫ܨ‬ = ቊ ܹ‫ܨ‬௖ି௜ #‫݊݋݅ݐܿܽݏ݊ܽݎݐ‬ ∈ [݉௜, ݊௜ ] ‫ݑ‬(‫ݔ‬) ∗ ܹ‫ܨ‬௖ି௜ + ൫1 − ‫ݑ‬(‫ݔ‬)൯ ∗ ܹ‫ܨ‬௖ି௜ାଵ #‫݊݋݅ݐܿܽݏ݊ܽݎݐ‬ ∈ [݊௜, ܾ௜] (3.2)
  • 6. 188 Finally the UUCW can be calculated by Formula3.3 ܷܷ‫ܹܥ‬ = ∑#ܷ‫ݏ݁ݏܽܥ݁ݏ‬ ∗ ܹ‫ܨ‬ (3.3) Rather than classifying the use cases into three classes (simple, average and complex) as in Karnerss work [7], the use cases will be classified into 5 categories according to the number of transactions per use case. Since the main goal of our approach is to enhance the current model proposed by Karner and not to completely modifying it, assumed that the largest use case contains 21 transactions. Also assume that the complexity factor of the largest use case is 25. Table 6 presents a comparison between the original work (Karners method) and the proposed approach. The table 6 shows that in the proposed approach, the weights of the use cases are gradually increasing as opposed to the abrupt increase in Karners UCP method. TABLE V: VALUES OF THE TERMS Linguistic Terms i mi ni ai bi Weight Very Simple 1 1 2.5 4 5 Simple 2 4 6 2.5 8 10 Average 3 8 10 6 12 15 Complex 4 12 14 10 16 20 Very Complex 5 16 14 25 Fig 1: Fuzzy numbers After Fuzzification and Extension TABLE VI: ADJUSTED WEIGHT No. Of Transactions in Use Case UCP Weight Refine Weight 1 5 5 2 5 5 3 5 6.45 4 10 7.5 5 10 8.55 6 10 10 7 10 11.4 8 15 12.5 9 15 13.6 10 15 15 E. Evaluation Criteria Several methods exist to compare cost estimation models. Each method has its advantages and disadvantages. In this work, three methods will be used. These include the Mean of the Magnitude of Relative Error (MMRE), the Mean of Magnitude of error Relative to the Estimate (MMER) and the Mean Error with Standard Deviation. MMRE This is a very common criterion used to evaluate software cost estimation models [11]. The Magnitude of Relative Error (MRE) for each observation i can be obtained as: ‫ܧܴܯ‬௜ = |஺௖௧௨௔௟ ா௙௙௢௥௧೔ି௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔| ஺௖௧௨௔௟ ா௙௙௢௥௧೔ (4.1) MMRE can be achieved through the summation of MRE over N observations: ‫ܧܴܯ‬௜ = ଵ ே ∑ ‫ܧܴܯ‬௜ ே ௜ୀଵ (4.2)
  • 7. 189 MMER MMER is another method for cost estimation models evaluation [12]. MER is similar to MRE with a difference that the denominator is the predicted effort instead of the actual effort. Consequently, the equations for MER and MMER are: ‫ܴܧܯ‬௜ = |஺௖௧௨௔௟ ா௙௙௢௥௧೔ି௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔| ௉௥௘ௗ௜௖௧௘ௗ ா௙௙௢௥௧೔ (4.3) ‫ܴܧܯܯ‬ = ଵ ே ∑ ‫ܴܧܯ‬௜ ே ௜ୀଵ (4.4) When using the MMRE and the MMER in evaluation, good results are implied by lower values of MMRE and MMER. Mean Error with Standard Deviation Although MMRE and MMER have been used for a long time, both methods might lack accuracy. If the actual effort was small, MMRE would be high. On the other hand, if the predicted effort was low, MMER would also be high. Foss et al. argued that MMRE should not be used when comparing cost estimation models and using the standard deviation would be better [13]. The equation for the mean error for each observation i and total number of observations N is: ‫̅ݔ‬ = ଵ ே ∑ ‫ݔ‬௜ ே ௜ୀଵ (4.5) Where ‫ݔ‬௜ = (‫݈ܽݑݐܿܣ‬ ‫ݐݎ݋݂݂ܧ‬௜ − ܲ‫݀݁ݐܿ݅݀݁ݎ‬ ‫ݐݎ݋݂݂ܧ‬௜) The equation of the standard deviation can be defined as: ܵ‫ܦ‬ = ට ଵ ேି! ∑ (‫ݔ‬௜ − ‫̅ݔ‬)ଶே ௜ୀଵ (4.6) F. Case Study The evaluation of this work was conducted on seven different projects. I collected information about seven projects information from projects plans, report, and analysis and design documents [14]. There is no standard and known conversion between the size in UCP and the size in function points or SLOC. Since some information about the complexity of the projects and the team experience is known about each project, the Technical Factor (TF) and the Environmental Factor (EF) were calculated. Karner suggested that the effort required to develop one UCP is twenty person hours. This method had been criticized by many researchers. Schneider et al. [2] refined Karners UCP method in determining the effort from UCP. Schneider suggested counting the number of factor ratings of F1-F6 in Table 4 (Environmental Factors) that are below three and the number of factor ratings of F7-F8 that are above three. If the total is three or less, then twenty person hours per UCP should be used. If the total is three or four, twenty eight person hours per UCP should be used. If the total is five or more, then the project team should be reconstructed so that the numbers fall at least below five. A value of five indicates that this project is at significant risk of failure with this team. In this work, Schneiders method has been used to calculate the size of the projects in UCP from the effort. Equation 1.4 is used to determine the size of each project in UUCP. To distinguish between the results in the proposed fuzzy logic, the evaluation of each approach was done separately. From the Table 7, Fig: 2 shows the comparisons of estimated effort between Actual size UUCP model, UCPM and Proposed Model and Fig: 3 show the error comparison between UCPM and Proposed Method. It can concluded that the proposed model improve the software effort estimation with MRE +22% and with MER +9%. TABLE VII: COMPARISON BETWEEN UCPM AND THE PROPOSED MODEL Project Actual Size UUCP UCPM Proposed Model MRE UCPM MRE Proposed Model MER UCPM MER Proposed Model Error UCPM Error Proposed Model Project 1 72.44 128.96 104.98 0.78 0.45 0.44 0.31 56.22 32.54 Project 2 74.33 128.54 108.65 0.73 0.46 0.42 0.32 54.21 34.32 Project 3 55.50 51.00 48.70 0.08 0.12 0.09 0.14 -4.50 -6.80 Project 4 68.00 108.50 92.40 0.60 0.36 0.37 0.26 40.50 24.40 Project 5 48.75 74.25 61.25 0.52 0.26 0.34 0.20 25.50 12.50 Project 6 94.50 168.75 144.00 0.79 0.52 0.44 0.34 74.25 49.50 Project 7 72.50 108.41 92.44 0.50 0.28 0.33 0.22 35.91 19.94 Mean 0.57 0.35 0.35 0.26 40.34 23.77 Standard Dev 25.33 17
  • 8. 190 Fig: 2 Comparison of Estimated Effort Fig: 3 Error Comparison VI. CONCLUSION AND FUTURE WORK In this paper, the weakness of the UCP model are discussed and proposed an enhancement to this model using fuzzy logic to creation of the linguistic term very simple and very complex. These terms will make the estimation more accurate specially the use case is comparative complex. Moreover, this approach provides some rules for counting the transaction which is very crucial for use case complexity weight. From the case study result it can be concluded that the proposed approach improve the UCP software effort estimation up to 22%. In future work approach can be applied to other UML diagrams like sequence diagram, state transition diagram etc. In future work the model can be applied as: • The largest use case should contain at least 21 transactions. • Extend and include use cases should be considered when estimating the software size.
  • 9. 191 REFERENCES [1]. O. Junior, P. Farias, and A. Belchior, “A Fuzzy Model for Function Point Analysis to Development and Enhancement Project Assessments”, CLE Electronic Journal, 5:2, 1999. [2]. G. Schneider and J. P. Winters, “Applied use Cases”, Second Edition, A Practical Guide. Addison-Wesley, 2001. [3]. K. Molokken and M. Jorgensen, “A review of software surveys on software effort estimation” In Empirical Software Engineering, 2003. ISESE 2003. Proceedings. 2003 International Symposium on, pages 223230. [4]. B. Kitchenham and S. Linkman. “Estimates, uncertainty, and risk”, IEEE Software, 14(3):6974, 1997. [5]. L. A. Zadeh,”Fuzzy sets. “Information and Control”, vol. 8, pp. 338-353, 6, 1965. [6]. Thomas Fetke, Alan Abran, and Tho-Hau Ngyen. “Mapping the oojacobsen approach into function point analysis” The Proceedings of TOOLS, 23, 1997. [7]. Karner, G. Metrics for Objectory. “Diploma thesis, University of Linkping” Sweden. No. LiTH-IDAEx- 9344:21. December 1993. [8]. John Smith. “The estimation of effort based on use cases,” Rational Software White Paper, 1999. [9]. David Longstreet. “Use cases and function points” Copyright Longstreet Consulting Inc. www.softwaremetrics.com, 2001. [10]. Jacobson, I. and Christerson, M. and Jonsson, P. and Overgaard, G. “Object- Oriented Software Engineering: A Use Case Driven Approach” Harlow, Essex, England: Addison Wesley Longman, 1992. [11].L. C. Briand, K. E. Emam, D. Surmann, I. Wieczorek and K. D. Maxwell, “An assessment and comparison of common software cost estimation modeling techniques ”, ICSE’99, vol. 0, pp. 313-322, 1999. [12].B. A. Kitchenham, L. M. Pickard, S. G. MacDonell and M. J. Shepperd, “Accuracy Statistics Really Measure”, IEE Proc. -Softw, vol. 148, pp. 81-85, 2001. [13].T. Foss, E. Stensrud, B. Kitchenham and I. Myrtveit, “A Simulation Study of the Model Evaluation Criterion MMRE”, IEEE Transactions on Software Engineering, vol. 29, pp. 985-995, 2003. [14].Ribu, K. “Estimating Object-Oriented Software Projects with Use Cases ” , University of Oslo, Department of informatics, Master of Science Thesis, 7th November 2001.