2011 5th Malaysian Conference in Software Engineering

Software Complexity Level Determination Using

Software Effort Estimation Use Case Points Metrics
3
1 2
Mohsen Afsharchi Mojtaba Karami
Yaeghoob yavari
Department of Computer Engineering Department of Computer Engineering
Department of Computer Engineering
Zanjan University Hamedan Branch Islamic Azad University
Hamedan Branch Islamic Azad University
Zanjan, Iran Hamedan, Iran
Hamedan, Iran
afsharchim@znu.ac.ir mjt.karami@gmail.com
Yavari64@gmail.com

Abstract- Software estimations are regarding based on prediction II. RELATED WORK
properties of system, with attention to development methodology.
In object-oriented analysis, Use Case models describe the A. Karner’s Use Case Points Method
functional requirements of a software system, so they can be Use Case diagrams contain the functional requirements of
basis for software measurement and sizing. Use Case points the target system that determined during the requirement
method that suggested by karner, is based on size and complexity analysis phase. [5]. Karner with focus on main elements in
of Use Cases. This method earns the great successes in industry
and university. Although this method doesn’t have enough
Use Case diagram (Use Cases and actors) and attention to
precision and accuracy, because of inaccuracy in determining non-functional requirements in software system provide an
Use Case complexity metrics. In this research, we are going to estimation method. This approach is an extension of existing
assessment weak points of Use Case complexity metrics specially estimation methods, such as function point analysis and MK II
transaction metric in Use Case points method and then we will function point’s analysis. The objective of it was providing a
introduce other metrics for determining Use Case complexity simple estimation method compatible with object-oriented
that it can be led to simplify calculating UUC and it can be also projects. [6,7] Use Case points method is contain the
tried to cover the most of aspects of Use Cases. following stages:
1. categorized actors and assigned Unadjusted Actor Weights
Keywords- software estimation ; software requirements ; (UAW). (See Table I)
software complexity ; Use Case points ; Use Case complexity.
UAW =  (Actors in each group*WF) (1)
I. INTRODUCTION
There are variety methods for software estimation. One of TABLE I. ACTORS CLASSIFYING & COMPLEXITY
these methods has great success in industry and academy is Actor Complexity Level Description Weight
Use Case points method. G. karner in 1993 suggested this Simple An API or program interface 1
method for compatibility with object-oriented projects. This Average Network protocols such as TCP/IP , 2
HTTP
method is based on Use Case models [1, 2, 3]. Complex Graphical User Interface 3
In one case study, the Use Case points method was compared
with expert estimates and actual effort for three industrial 2. calculating Use Case weighting for Unadjusted Use Case
development projects (e-commerce and call-centers within Weights (UUCW). (See Table II)
banking and finance). These projects were being lasted from 3
to 7 months with a total effort of 3000 to 4000 person hours. UUCW =  (Use Cases in each group*WF) (2)
The Use Case points method gave estimates that were almost
as close to actual effort as the estimates produced by very TABLE II. USE CASE CLASSIFYING & COMPLEXITY
experienced software developers with good knowledge of the Use Case Complexity Level Description Weight
application domains and the technology to be used. The Use Simple 1 to 3 transactions 5
Case based estimates were between 4.5% and 30% lower than Average 4 to 7 transactions 10
the actual effort for the projects. [4] Complex More than 7 transactions 15
Karner’s method consists both functional and
3. Calculating Unadjusted Use Case Points (UUCP)
nonfunctional requirements in software systems, since Use
Cases consist of the strategic goals and scenarios which
UUCP = UAW + UUCW (3)
provide a valuable business domain, and an insight into an
application’s complexity. But in many studies we are going to
4. Determining the Technical Factors (TF) for system and
refer to them in blew, Use Case points method has less
deviation , it is supposed , as a result , Use Case complexity Environmental Factors (EF) for the team by given equations.
metrics would be one of the reasons of that. (See Table III)

257
978-1-4577-1531-0/11/$26.00 ©2011 IEEE
 TABLE III. TECHNICAL AND ENVIRONMENTAL FACTORS TABLE IV.15 ESTIMATION INFORMATION OF COMMERCIAL SOFTWARE
Factor Description Weight Sector A:project B:estimated Deviation (B-
T1 Distributed system 2 effort [h] effort [h] A)/A
T2 Response or throughput performance objectives 2 Apparel industry 728 1.205 66%
T3 End-user efficiency 1 Automotive 1 15.500 11.667 -25%
T4 Complex internal processing 1 Automotive 1 136.320 114.023 -16%
T5 Code must be reusable 1 Finance 1 2.992 1.002 -67%
Technical T6 Easy to install 0.5 Finance 2 3.680 3.301 -10%
factors T7 Easy to use 0.5 Insurance 1 4.800 2.115 -56%
T8 Portable 2 Logistics 1 944 1.406 49%
T9 Easy to change 2 Logistics 2 2.567 1.751 -32%
T10 Concurrent 1 Logistics 3 7.250 8.840 22%
T11 Includes special security features 1 Logistics 4 61.172 52.219 -15%
T12 Provides direct access for third parties 1 Public 1 46.900 39.030 -17%
T13 Special user training facilities required 1 Public 2 13.200 19.442 47%
F1 Familiar with the Rational Unified Process 1.5 Telco 1 2.456 3.588 46%
F2 Application experience 1.5 Telco 2 2.432 3.186 31%
F3 Object-Oriented Experience 1 Telco 3 1.056 1.518 44%
Environmental F4 Lead analyst capability 1.5 Total 301.997 264.291 -12%
factors F5 Motivation 1 Average value: 5%
F6 Stable requirements 2 Standard deviation: 42%
F7 Part-time workers -1
F8 Difficult programming language -1 After assessment, they introduce a new influencing
variable representing the process model with scoring :
5. Calculating Technical Complexity Factor (TCF), and x lean development process => 0points
Environmental Factor (EF). Environmental factor (this factor x standard development process => 3points
suggested by karner) is calculated on the same form as the x heavy weight development process => 5points
technical factor: The enhanced method shows a low deviation, expressed by
TFC =0.6+ (0.01*TF) (4) an average value of -0.5 % and a standard deviation of 20%.
Where: TF =T1 +T2 + …….T12+T13 In comparison, applying Karner’s method they achieved an
average value of 5% and a standard deviation of .% 42 [9]
EFC = 1.4+ (0.03*EF) (5)
Where: EF = F1+F2+…+F7+F8 C. Ericson company
The system in this study was INCO project (INcremental
6. Use Case Points is calculated as : and COmponent-based Software Development) in 2001 -2004
UCP = UUCP* TFC*TEC (6) that it was a large distributed telecom system developed by
Ericsson.
They evaluated Use Case point method for estimation in
7. The final step, is generating estimated effort by multiplying
different release in large software project. They modified the
UCP and person-hours per UCP (PHperUCP)
following elements of the original method:
E=UCP *PHperUCP [4, 6, 8]. (7)
x Complexity assessment of actors and Use Cases,
Karner originally proposed a ratio of 20 hours per Use x The handling of non-functional requirements and team
Case point. Kirsten Ribu (2001) reports that this effort can factors that may affect effort.
range from 15 to 30 hours per Use Case point. For incremental development, they added two elements to
Schneider and winters (1998) suggest counting the number the method:
of environmental factors in E1 through E6 that are above 3 x Counting both all and the modified actors and
and those in E7 and E8 that are below three. If the total is two transactions of Use Cases
or less, assume 20 hours per Use Case point. If the total is 3 or x Effort estimation for secondary changes of software
4, assume 28 hours per Use Case. Any total larger than 4 not reflected in Use Cases.
indicates that there are too many environmental factors The method was calibrated using data from one release
stacked against the project. The project should be put on hold and it produced an estimate for the successive release that was
until some environmental factors can be improved.[3] only 17% lower than the actual effort. [10]

B. Company SD & M D. Simplifying Effort Estimation Based On Use Case Points

This study relies on 15commercial software development In this study authors with analysis of affecting the
projects in various sectors in IT-company SD&M AG. The environmental and technical factors on the effort estimation
original UCP method the average value only is 5% higher tried to with ignore some of this factors and change the Use
than the incurred efforts and thus, fits quite well, but the Case complexity metrics simplify Use Case point method.
standard deviation of about %42 is not acceptable for This study investigates the construction of UCP in order to
industrial usage (see Table IV). find possible ways of simplifying it. The cross-validation

258
procedure was used to compare the accuracy of the different And other:
variants of UCP. In this study analysis was based on data x Regression Model for Software Effort Estimation
derived from a set of 14 projects for which effort ranged from Based on the Use Case Point Method (Ali Bou Nassif
277 to 3593 man-hours. Based on result of this study the two at all .2011)
variants of UCP – with and without unadjusted actor weights x Estimating software for spiral model based on Use
(UAW) provided similar prediction accuracy. Case points (Nirupma Pathak, 2011)
The results of the factor analysis indicated that the number x Estimating With Use Case Points (Mike Cohn , 2006)
of adjustment factors could be reduced from 21 to 6 (2
environmental factors and 4 technical complexity factors). III. ANALYZING USE CASE POINTS
Another observation was made that the variants of UCP
calculated based on steps were slightly more accurate than the Based on previous section the Use Case point has some
variants calculated based on transactions. Finally, a recently variation and it has needed to be modified and reviewed to
proposed use-case-based size metric TTPoints provided better improve its accuracy. In the recently study by Benta Ande and
accuracy than any of the investigated variants of UCP. Parastoo Mohagheghi they found that the solution for
The observation in this study was that the UCP method could calculating Use Cases weight must be changed, but their
be simplified by rejecting UAW; calculating UCP based on works on the Use Case don’t make basic change in it, whereas
steps instead of transactions; or just counting the total number the Use Cases are main element in Use Case points method.
of steps in Use Cases. Moreover, two recently proposed use- Karner regarding some metrics divided Use Cases into three
case-based size metrics Transactions and TTPoints could be classes, simple, average, and complex, moreover, he
used as an alternative to UCP to estimate effort at the early appropriated a number to each class based on historical data
stages of software development.[11]. .since number of Use Case in large projects is more than
actors and the weight that assigned to each Use Case is bigger
E. Test Effort Estimation Using Use Case Points than actors, so we make mistake in determining Use Case
In this research authors measure the cost of project test complexity metrics. The effort estimated have high variation.
based on the Use Case points. It is known that a Use Case to By means of assessing Use Cases and their metrics we can
test case mapping is possible. Each scenario and its exception reach challenges and weak points of this method.
flows for each Use Case are input for a test case.
Subsequently, the estimation calculations can commence. A. Analyzing Use Cases
Instead 2 group of technical and environmental factor in Use RUP and UML define one Use Case such as following:
Case point method they suggest 9 technical factors for and “A Use Case defines a sequence of action a system
calculate AUCP based on the below formals : performs that yields and observable result of value to a
practical actor “[14].
AUCP =UUCP *[0.65+(0.01*TEF)] (8) This is similar to transaction definition and identification
of transactions probably the most difficult part of UCP,
They now have to simply multiply the adjusted UCP with a because the definition, which states that transaction is a set of
conversion factor. This conversion factor denotes the man- activities in use-case-scenarios (that is meaningful to the
hours in test effort required for a language/technology actor), which is either performed entirely, or not at all, and
combination. The organization will have to determine the leaves the business of application in consistent state, is vague.
conversion factors for various such combinations. what is the meaning of Use Case transactions, so ?
In describing transaction of one Use Case, Ivar Jacobson ,
E.g. Effort = AUCP * 20 (9) inventor of Use Case Says; a transaction of Use Cases is such
as a mutual interconnection vector and route within a period of
Where 20 man-hours are required to plan, write and execute schedule from user to system and again it returns to user. A
tests on one UCP when using EJB [12]. transaction terminates when system expects one stimulus.
Karner expresses inaccuracy and erroneous cases of
F. Initial Hybrid Method for Software Effort Estimation, transaction such as this:
Benchmarking and Risk Assessment Using Design of Software A transaction is not always a specific stage of Use Case flow.
In this study they proposed a hybrid method for effort A transaction is not a stimulus. Also a transaction is not an
estimation, as an automated tool, the input is XML file, the operation of an activity for basis data.
tool is implemented in JAVA and Xereces2 Java Parser is According to definition of M.Ochodek, J, and Nawrocki
used to analyze the model file. It is necessary to write the Use from transaction, they express that transactions have 2 parts:
Case Model in machine readable format. So, they assume one of them is request of user and the other is response to
that the Use Case model is written in XMI [XML Metadata system request and responses can have ambiguity levels which
Interchange, OMG, (2005)].they Classification actors base on are non-comparison[15].
its names and keywords included in Use Case and experience In result in a complete definition of transaction we can
data [13]. say: a transaction consists of 4 steps:

259
 1. Primary actor sends the request and the data to the project risks, initial and primary works, system necessities,
system customer satisfaction. And also metrics would dominate
2. The system validates the request and the data; variety dimensions of it.
3. The system alters its internal state;
4. The system replies to the actor with the result. TABLE V. NEW USE CASE COMPLEXITY METRICS
As mention above for each step in transaction it can be Metrics Description
UCT Use Case Type
done different effort. It can be very simple work like push a UCP Use Case Priority
button from user or difficult like submitting a very complex UCGL Use Case Goal Levels
page that contains varity data and information. NMLS Number of Main and Alternative Scenario
Regarding to transition definition, as a tangible example, TRA Type of Related Actors
imagine an ATM system. Where application for money saving NRED Number of Related Entity Database
BR Business Rules
in one’s account is a kind of complex transaction.
Based on some transaction definitions determining
transactions are not simple and without ambiguity. They are x Metric 1 : Use Case Type
not the same. We cannot spot them identical. Use-case types are more like use-case patterns -- design
For the following reasons we believe that transaction is patterns -- but at the Use Case level. We will encounter
not a good and precise criteria for determining Use Case different categories of Use Cases in our Project, so select a
complexity level and calculating Unadjusted Use Case representative Use Case from each category early on and
Weights (UUCW) , so it is needed to change . as the result; Work on it. That will help we decide what writing style and
1. Transsactions don’t contain unambiguous criterion. what appendices are required [17].
2. Transactions contain different complexion levels. 1) Data maintenance Use Cases
3. There is no same directive and guidance for writing user These are typically created, read, update, and delete (CRUD)
cases. In this directions, level of trivial for describing Use Use Cases. Writing one per entity is repetitive: normally it is
Cases are different. On the other hand, level of travails has easier to write such Use Cases generically so they can be
effect on estimating Use Cases, so number of transactions applied to multiple entities. These Use Case can be described
depends on writer and used directive Use Cases. It is not a very well by domain modeling and possibly user experience
general stand oral .It depends on individuals. modeling
4. There is a difference between complex level of Use Case 2) Request approval Use Cases
on the on hand and 4 transaction on the other hand .and also These are Use Cases for routing requests through a series of
there is a difference between complex level of Use Case on approval stages. Some approval stages can be skipped or
the one hand and 7 transactions on the other hand. While we combined, depending on the nature of the request. Each stage
know that karner regards them such as average Use Case. in the approval adds a little information about the request.
5. Regarding Shane Sendall and Alfred Strohmeier (Swiss Approval Use Cases can be supplemented with business use-
Federal Institute of Technology in Lausanne Software case specifications if they are nontrivial
Engineering Lab) ,idea If the main success scenario of the Use 3) Data analysis Use Cases
Case is greater than 9 steps, collect steps that encapsulate a These Use Cases are for analyzing transactions on entities that
sub-goal of the primary actor and create a new lower-level are manipulated by other Use Cases. I find domain modeling
Use Case with the steps. Inversely, if the Use Case is smaller appropriate for data analysis Use Cases, since they are data-
than 3 steps, think about expanding it or putting it back in the centric
calling Use Case[16]. 4) Payment Use Cases
Regarding above reason and other reasons for selecting These Use Cases are for making payments. The complexity
transactions as criterion for determining complex level, we comes when there are multiple payment methods, such as
cash, and credit card. Some payments can be made
should say that transactions don’t have essential accuracy.
immediately (e.g., credit card payments). Whereas other take
time to clear (e.g., checks). Computation of payment amount
IV. REASEARCH METHOD also involves a number of business rules, which might be
configurable. Payment Use Cases require quite a lot of
Regarding challenges in Use Case points method which business rules in many cases.
was discussed in recent section. We would recognize sources 5) Loyalty program Use Cases
relating to Use Case and then we would success elicit good These Use Case allow to customer to accrue credits when
metrics related to Use Cases to determine Use Case using a service and these credits can be used either as a
complexity that can establish better effort estimation. We payment method or a rewards for corporate gifts. Accruing of
focus on Use Case specification and flow of vent to explore credits is normally an extension to some other Use Case,
some of the Use Case features in order to determine the Use whereas the redemption of the credits is a Use Case in itself.
Case complexity (see Table V). Loyalty Use Cases are interesting because they insert
These metrics are eventual and effective for evaluating themselves into existing Use Cases
software value and they have a perfect effect on Results of
estimating. Also regarding to metrics, we would reduce x Metric 2 : Use Case Priority

260
 The team sets priorities for Use Cases to determine the will bias the result towards complexity and increase the Use
contents and focus for each iteration within the project. This Case Points. A small number of steps will bias it towards
activity describes the contributing factors to consider when simplicity. Sometimes, groups of steps can be reduced to a
setting priorities. fewer number without sacrificing the business process. Strive
Once the project's scope is known, the Software Architect for a uniform level of detail but don’t force a Use Case to
analyzes the Use Cases to determine which ones are conform to the estimation method.
architecturally significant. These Use Cases, in whole or in For each Use Case: The most important thing is that the
part, have high priority and should be developed during the steps of the Use Case have a consistent level of description, no
Elaboration phase. Other Use Cases are completed during the matter what the level if the main success scenario of the Use
Construction phase. Case is greater than 9 steps, collect steps that encapsulate a
Other factors contributing to Use Case priority and the sub-goal of the primary actor and create a new lower-level
contents of iterations include: Use Case with the steps. Inversely, if the Use Case is smaller
x Risks than 3 steps, think about expanding it or putting it back in the
x Dependencies calling Use Case [18].
x Business priorities
x Available resources x Metric 5 : Type of Related Actors
An actor is anything with behavior, including the system
x Average action usage: with this factor we determine
under discussion (SuD) itself when it calls upon the services
which Use Case be used more than another that used
of other systems. Primary and supporting actors will appear in
seldom.
the action steps of the Use Case text. Actors are roles played
x Average attribute value and object label: often it is
not only by people, but by organizations, software, and
important specific Average attribute value and object
machines.
label that must be managed by user or show to he [18].
There are three kinds of external actors in relation to the
x Metric 3 : Use Case Goals Level SuD:
How will I know when I have finished my Use Cases? o Primary actor has user goals fulfilled through using
You have to evaluate the use-case model with respect to some services of the SuD. The primary actor is the person
frame of Reference, such as business needs, business domain, who is the subject of the Use Case, performing the
and so on. verb of the Use Case on the object. A Use Case may
Cockburn (2001) identified three different goal levels: have multiple actors but has one most important
Summary: level is the 50,000 feet perspective, are large grain person.
Use Cases that encompass multiple lower-level Use Cases; o Why identify? To find user goals, which drive the Use
they provide the context (lifecycle) for those lower-level Use Cases?
Cases. They can act as a table of contents for user goal level x Supporting actor provides a service (for example,
Use Cases. information) to the SuD. The automated payment
User-goal level is the sea-level perspective, describe the authorization service is an example. Often a computer
goal that a primary actor or user has in trying to get work done system, but could be an organization or person the
or in using the system. Are usually done by one person, in one secondary users are other family members and other
place, at one time; the (primary) actor can normally go away software applications.
happy as soon as this goal is completed. o Why identify? To clarify external interfaces and
Sub function is the underwater perspective. Provide protocols.
“execution support” for user-goal level Use Cases; they are x Offstage actor has an interest in the behavior of the Use
low-level and need to be justified, either for reasons of reuse Case, but is not primary or supporting; for example, a
or necessary detail [16]. government tax agency.
For the purpose of software effort estimation, informal Use o Why identify? To ensure that all necessary interests are
Cases are the fastest to define. Formal Use Cases provide a identified and satisfied. Offstage actor interests are
way to capture additional detail that will help to validate the sometimes subtle or easy to miss unless these actors
complexity of the Use Cases. The additional detail available in are explicitly named.
the formal Use Case document is not, however, needed to
create a project cost estimate using Use Case points. x Metric 6: Number of related entity database
For each Use Case we can determine the number of database
x Metric 4 : Number of Main and Alternative Scenario entity. According Use Cases type and interacting between
The most important part of the use-case description is the actors and Use Case and also Use Case Flow of Events we can
Flow of Events. This is the section where the story is told. determine this factor for each Use Case.
Although the flow of events is only considered a single use-
case property by the UML, it has a well-defined and x Metric 7 : Business Rules
significant structure the number of steps in a scenario affects Use Cases cover a great many of the requirements by
the estimate. A large number of steps in a Use Case scenario specifying interactions between actors and an application.

261
Some businesses create lists of business rules for their V. SUMMERY AND CONCLUSION
businesses even though they may not be building any new
computer applications. It is simply important to them to In this paper, we evaluate the Use Case point method and
document how their business runs. discuss its challenge about determining unadjusted Use Case
According to E. Gottesdiener (2002) author and weight; we find that one of the most causal of inaccuracy and
consultant, there are five categories of business rules: variation in estimation based on Use Case points considered as
x Structural facts--Facts or conditions that must be true. Use Cases complexity metrics. We focused on Use Cases and
Example: The first customer contact is always with a resources related to Use Cases, and introduce other metrics for
salesperson. determining Use Case complexity and then calculating
x Action restricting-- Prohibiting one or more actions based unadjusted Use Case weight. These metrics can improve
on a condition. Example: Do not accept a check from a accuracy effort estimation and it can provide more
customer who does not have an acceptable credit history. information about system under discussed, also it can simplify
x Action triggering-- Instigating an action when one or more way of determining UUC, so we don’t act additional work for
conditions become true. Example: Send the shipment as estimation and use the information that is essential for system
soon as the pick items (items selected from inventory) have developing. it is not necessary that we identify all of these
been collected. metrics and we can start with some of them , then by
x Inferences-- Drawing a conclusion when one or more improving the project in next iterations we are able to identify
conditions become true. Example: Members who fly more the remaining metrics and enhance the precision of value in
than 100,000 miles in one calendar year become Elite previous metrics. We are collecting the actual project data to
members. test my method.
x Calculations- Calculating one value given a set of other
values. Example: The sales amount is the total retail value REFERENCES
of the line items but does not include state or federal tax [1] L. Fernando Capretz, V. Marza, “Improving Effort Estimation by Voting
[18]. Software Estimation Models,” HindawiPublishingCorporation, Feb
According to what we introduced as Use Case metrics, as 2009.
a result, in order to create a table as like as (Table VI) and [2] V. Bhattacherjee, P. Mahanti and S. kumar,”Complexity Metric for
Analogy Based Effort Estimation,” 2007.
complete it to determine complexity level of Use Cases. It is [3] Book: M. Linda Laird, M. Carol Brennan,” Software Measurement and
not necessary to complete all those metrics, and according to Estimation a Practical Approach,” Wiley Interscience Publication &
any extend of existing information we can calculate UUCW. If IEEE Computer Society, 2006.
more information is available, estimation accuracy is more. [4] B. Anda,” Comparing Effort Estimates Based on Use Case Points with
Expert Estimates,” 2007.
When we document Use Case specification, Most of these [5] K. Bittner, I. Spence, “Use Case Modeling, “Addison Wesley
metrics are available and it is not necessary to spend addition Publication, 2002.
effort for collecting them. [6] G. Karner,” Resource Estimation for Objectory Projects,” 1993.
In this method we can appropriate one number to each [7] K .Ribu, “Estimating Object-Oriented Software Projects with Use
Cases,” 2008.
metric that is precision and commensurate to complexity level [8] C. Gence, L. Buglione, O. Demirors, P. Efe,” A Case Study on the
of that Use Case so will increase degree of precision and in Evaluation of COSMIC-FFP and Use Case Points,” 2006 .
result estimation accuracy will improve. [9] S. Frohnhoff, G. Engels, “Revised Use Case Point Method-Effort
In this method we calculate UUCW for any kind of Use Case Estimation in Development Projects for Business Applications” 2008.
[10] P. Mohagheghi, B. Anda, R. Conradi,” Effort Estimation of Use Cases
and then calculate the sum of them. for Incremental Large-Scale Software Development ,”Norwegian
University and Simula Research Laboratory, 2005.
UUCW = (Final Weight for each Use Case) (10) [11] M. Ochodek, et al., "Simplifying effort estimation based on Use Case
Points," Inf. Softw. Technol., vol. 53, pp. 200-213, 2011.
[12] S. Nageswaran, “Test Effort Estimation Using Use Case Points”, Quality
TABLE VI. CALCULATING UUCP Week 2001, USA, 2001.
[13] J. Frank Vijay,” Initial Hybrid Method for Software Effort Estimation,
Use Case id

NMLS *WF
description

TRA *WF
UCT *WF

UCP *WF
(summary

Benchmarking and Risk Assessment Using Design of Software”, Global

WIEGHT
UCGL*

BR *WF

Journal of Computer Science and Technology. pp 34-39, 2009.

FINAL
NRED
*WF

[14] C. Larman,” Applying UML and Patterns: An Introduction to Object-

Goal

WF

Oriented Analysis and Design and Iterative Development,” Third

Edition, Addison Wesley Professional, 2004.
#01 [15] M. Ochodek, J. Nawrocki,” Automatic Transactions Identification in
TOTAL UUCP = Use Cases In: Balancing Agility and Formalism in Software
Engineering,” 2nd IFIP Central and East European Conference on
Software Engineering Techniques, 2008.
[16] S. Sendall, A. Strohmeier,” Requirements Elicitation with Use Cases,”
Assigned value to metrics is based on historical data; hence Swiss Federal Institute of Technology in Lausanne Software
we are collecting historical data from actual project. Engineering Lab, 2001
[17] Pan-Wei Ng, “Adopting Use Cases: Understanding Types of Use Cases
and Artifacts,” Rational Software Singapore IBM Software Group, 2003
[18] D. Kulak, E. Guiney,” Use Cases: Requirements in Context,” Second
Edition, Addison Wesley publication, 2003.

262