Software Project Estimation Using Improved Use
Case Point
Sima Bagheri and Alireza Shameli-Sendi
Faculty of Computer Science and Engineering, Shahid Beheshti University (SBU), Tehran, Iran
Email: sim.bagheri@mail.sbu.ac.ir, a shameli@sbu.ac.ir
Abstract—Estimating metrics, such as effort, schedule and
cost, needed for a software to be created and launched into
market have significant economical effects. One of the most
extensively utilized method for such estimation is a technique
called Use Case Points. It is based on the use case modeling
which is a popular and widely used technique for capturing and
describing the functional requirements of a software system. In
this paper multitude number of techniques have been proposed
as the basis for improving estimation of the effort, schedule, and
costs of software projects. These terms are conceptually similar
but utilize different parameter values and metrics. Moreover,
different versions of use case points have been proposed. This
method suffers some limitations such as less accuracy, failure
to consider software risks, failure to consider software quality
aspects, failure to consider different levels of software security,
and so on.
The aim of this paper is to propose a new approach for cost
estimation, based on use case points method, by considering
all the existing risks related to software projects. The results
indicate that the new estimation approach can produce relatively
accurate estimates and also declare various aspects of project
risks during project estimation. Our results also provide guidance
for organizations that want to develop a software project.
Index Terms—Software Cost; Software Estimation; Software
Risks; Use-case point
I. I NTRODUCTION
Software cost estimation is a very important process for
every software project to guarantee the delivering of the
product on time and within the allocated budget. The Use
Case Points (UCP) [1] provides an estimation method based
on use case diagrams to quantify the size, cost and effort of an
object-oriented software to be completed. The core idea of the
UCP is based on another software sizing estimation technique,
called Function Points (FP) [2], [3]. The UCP provides a well-
defined procedure to convert the use case diagram elements
into a set of metrics that reflects the work effort needed to
accomplish a software project [4].
Estimation process is not an accurate procedure; therefore,
some error is inevitable. Despite all its successes, the UCP
has some limitations that restrict its application and it can
be concluded from comparison between estimated and actual
result. These limitations are a promising motivation to improve
this procedure. To measure the cost and schedule of a project,
we need to have a comprehensive overview on eight different
aspects of a software as follows:
• Requirement
• Design
• Implementation
978-1-5386-5886-4/18/$31.00 ©2018 IEEE 143
SERA 2018, June 13-15, 2018, Kunming, China
• Test
• Quality
• Risks
• Security
• Reports
For example, which level of security is needed to be
implemented in a software? how many test-cases are needed
to be designed and implemented to be sure that the software
is error-free? How hard are them to be written? which level
of quality is expected? In the UCP model, there are a limited
number of questions or even no questions about the aforemen-
tioned aspects exist. In the literature some aspects including
implementation, test and reports were partially studied. To the
best of our knowledge, this paper is the first one to improve
the conventional UCP by adding the risk aspect of a software
project. Other aspects can be considered as future work.
The goal of this paper is to improve the original UCP
through changing the environmental factors by taking into
account the most frequent software project risks. We classified
a list of risks and replaced original environmental factors by
new classification, in order to solve the problems which were
mentioned. Moreover, five different companies are studied in
order to evaluate the impact of new EFs classification. By this
new approach a guidance is provided for project managers and
estimators.
The structure of this paper is as following: Section 2
presents an overview of related work around UCP improve-
ments. Section 3 describes the original UCP method. Section 4
presents the new approach in UCP improvement. Section 5
presents and discusses the results. Finally, in Section 6 we
present the conclusions and future work.
II. R ELATED W ORK
This section presents the related work investigating im-
provements in UCP. Many studies have tried to improve the
UCP technique and increase its accuracy. For example in [5]
both test and project management have been included in UCP
by mapping use cases to test cases. The final result is more
accurate but the scope of test cases are limited.
The estimated size of a software mainly depends on the
value of the Unadjusted Use Case Point (UUCP), which
represents initial complexity of actors and use cases. Anda
et al., [6] states that the internal structure of use case models
can change the final estimates. The level of details in use
case description, use of generalization between actors and
use of included and extending use cases have large impact
on project estimates. Therefore some studies have modified
UUCP. For example Braz et al., [7] have focused on internal
structure of use case diagram and classified actors and use
cases based on an adjustment factor, moreover, fuzzy sets were
used for the estimation [8]. Robiolo et all., [9] have changed
Unadjusted Use Case Weight (UUCW) based on identification
of transactions instead of steps. they also used paths to
improve transactions. [8]. Wang et al., [10] developed different
improvement called extended UCP, which exploited fuzzy sets
and Bayesian networks, this method has been proved to be
very effective for estimating accuracy and risk management.
Mohagheghi et al., [11] proposed another modification of
UCP called Adapted UCP, which is applicable for incremental
large scale software projects, through breaking use cases
into smaller ones and replacing Technical Factors (TF) and
Environmental Factors (EF) (adjustment factors of original
UCP) by two new ones, namely the Equivalent Modification
Factor (EMF) for counting the number of changes in use cases
and Overhead Factor (OF) which is a constant parameter and
covers all phases of development. Amasaki and Lokan [12]
have proposed a linear regression model and used a moving
window on data sets. The window has weighted based on time
order, which is more accurate than unweighted window. Nassif
et al., [14] have presented a linear regression model with a
logarithmic transformation to estimate software effort from use
case diagram via combining fuzzy logic and an artificial neural
network model [4], [14], [15].
In all studies, the improvements were made by changing the
internal structure of UUCP. UCP method has two adjustment
factors, namely the Technical Factors (EF) and Environmental
Factors (EF). There are some difficulties when trying to assign
values to TFs and EFs. In some cases it is not specific that
what is meant by each factor and it demands a review of other
projects for comparison. A particular problem is that the EFs
define the competency of the project team, therefore it is hard
to ask the team for their work evaluation; Specially when the
project members are estimators and have to assign values to
the EFs. As a solution, earlier projects experiences can be
used as a guidance. However, this will require a consistent
level of details in the structure of use case models, which is
not practical [6].
In our research we tried not to manipulate the internal struc-
ture of UUCP because it is an effective estimation method;
Besides it follows the right way in software estimation process.
Although the UCP is a good method, the context of its
improvement is an ongoing process. We assumed considering
extensive spectrum of risks of software projects may approx-
imately fill the existing gap between estimates and actual
values.
III. U SE C ASE P OINTS METHOD
The UCP estimation method was first introduced by Gustav
Karner [1] with the aim of creating a model that would
estimates the resources required to develop a software system.
This method is based on use case diagrams to effectively
144
estimate the size and effort of an object-oriented project.
Basically, this method calculates a metric called Use Case
Points that yields an estimation of the size and complexity of
a software project based on the same philosophy of Function
points (FP).
The UCPs are related to functional, technical and envi-
ronmental complexity of the software project, namely the
following steps [16]:
• Unadjusted Actor Weight
• Unadjusted Use Case Weight
• Technical Factor
• Environmental Factor
Actors and use cases define functional requirements of the
system in the form of use case modeling. When applying
the method we must first calculate the complexity of actors
and use cases to reach the two variables: (i)Unadjusted Actor
Weight (UAW) and (ii)Unadjusted Use Case Weight (UUCW).
By summing the UAW and UUCW the value Unadjusted Use
Case Points ( UUCP) is derived. Nevertheless this value is
an inadequate measure of the size and complexity of the
system and need to be properly adjusted. The next step
is to adjust this value by considering two other variables:
(i)Technical Complexity Factors (TCF) and (ii)Environmental
Complexity Factors (ECF) which are respectively related to
non-functional requirements, environment and circumstance of
the corresponding company. By taking these two variables into
account, the UUCP turns into adjusted UCP and consequently
with knowing the team productivity one can estimate the effort
by person-hour as well as the cost of the project. The details
of the UCP method are presented in the following, in order to
make the improvement process more clear.
A. Unadjusted Actor Weight (UAW)
The UAW procedure starts by finding the complexity of
the actors. Each actor is classified into simple, average and
complex. Table I presents the classification and weights for
different actors. Then after determining the complexity for
each actor, the number of simple, average and complex actors
is enumerated and will be multiplied by their weight, finally
the total results will be added to generate UAW.
TABLE I: Complexity of Actors
Category Description Weight
Simple External system using defined API 1
Average External system using standard 2
protocol (TCP/IP,command line,
...)
Complex human actor using GUI 3
B. Unadjusted Use Case Weight (UUCW)
Complexity of each use case depends on the number
of transactions in every main and alternative scenarios.
Typically a transaction is an atomic set of activities that
are either performed entirely or not at all [13]. Table II
presents the classification and weights for different use D. Environmental Factor (EF)
cases. Then after determining the complexity for each use Another critical factor to adjust the UUCP is the complexity
case the remaining steps to generate UUCW are same as UAW. of software development team, requirements and programming
language called environmental factors (EF). Besides, the value
of EF has a great impact on the productivity value. Based on
TABLE II: Complexity of Use Cases
this consideration, Karner proposed the weights for EFs which
Category Description Weight is based on some interviews of experienced personnel [11].
Simple 3 or less transactions 5 Table IV presents eight environmental factors of a given
Average 4-7 transactions 10 software project.
Complex more than 7 transactions 15
TABLE IV: Environmental Factors

The two respective variables must be combined to deter- EFactor Description Weight
mine an estimation of Unadjusted Use Case Points (UUCP) E1 Experienced with a software devel- 1.5
using Eq. (1). opment process
E2 Application experience 0.5
U U CP = U AW + U U CW (1)
E3 Object-oriented experience 1
This UUCP depends only on functional requirements of the E4 Lead analyst capability 0.5
software project. Therefore, non-functional requirements and E5 Motivation 1
environmental situation of the team are also important to adjust E6 Stable requirements 2
the UUCP. In the following, these two factors are explained E7 Part-time workers -1
in details. E8 Difficulty of programming lan- -1
guage
C. Technical Complexity Factor (TCF)
Technical factors explain the complexity of implementing The steps to generate the EF is same as generating TCF. EF
non-functional requirements of the project, therefore, it has a value can be calculated as shown in Eq. (3).
great effect on the project performance. Table III presents 13
technical factors of a given software project. To calculate the EF = 1.4 + (−0.03 × EF actors) (3)
TCF, a value in range of 0 to 5 is assigned to each factor. E. Use Case Points (UCP)
Then the value of each factor must be multiplied by the
Finally, the adjusted UCP can be estimated using Eq. (4).
associated weight and the sum of all the products results in
TFactor. U CP = U U CP × T F × EF (4)
F. Estimating Effort
TABLE III: Technical Factors By knowing the team productivity, needed effort can be
estimated. There are different approaches to assign a value to
TFactor Description Weight productivity. Karner uses a fixed productivity for every kind
T1 Distributed systems 2 of project. He uses 20 person-hours per UCP as shown in Eq.
T2 Specific performance objectives 2 (5) [1].
T3 End-user efficiency 1 ef f ort = U CP × 20 (5)
T4 Complex internal processing 1
T5 Code re-usability 1 Schneider and Winters [17] believed that the achieved
T6 Easy to install 0.5 productivity ratio differs between projects. Basically, it relies
T7 Easy to use 0.5 on the type, complexity and other metrics. They have applied
T8 Portability 2 EFs to assign a value to productivity ratio; The number of
T9 Easy to change 1 factor ratings of E1-E6 that are below 3 and the number of
T10 Concurrency 1 factor ratings of E7-E8 that are above 3 should be enumerated,
T11 Security features 1 if the total is 2 or less, then 20 person-hour per UCP will be
T12 Access for third parties 1 utilized. As another case if the total is 3 or 4, 28 person-hour
T13 Requires special user training facil- 10 per UCP will be applied, Otherwise if the total result is 5 or
ities more then the team must be restructured due to indicating that
this project is at significant risk of failure using this team [13].
Moreover, Nassif et al., [4] developed a log-linear regression
The value of TCF can be calculated as shown in Eq. (2). model based upon UCP and productivity, as shown in Eq. (6).
The adjustment values of 0.6 and 0.01 are from FP method α
by [2]. ef f ort = × U CP β α = 8.16 β = 1.17
productivity
T F = 0.6 + (0.01 × T F actor) (2) (6)

145
 IV. T HE IMPROVED UCP ESTIMATION METHOD companies, which were involved in our research and obtained
eight groups of risks.
This section describes how we changed UCP method by
As mentioned in previous Section, there were only eight EF
considering risks of software projects. Every software project
questions represented by Karner. We extended these eight EFs
will face many risks during its development and it is crucial to
into eight groups with special attention to the top risks, every
identify and manage these risks in order to reduce the software
group has more detailed questions which helps the project
failure. If we could anticipate these risks in the early phases,
manager, estimator and customer to be more aware of risks
project management and estimation results would be more
and put more emphasis on weighty risks in early phases of
effective and realistic. The main questions is where can we add
development.
risks of a project in the UCP estimation process? By taking a
This new classification asks about 60 questions instead of
look at UCP method we can find out EFs partially consider the
eight EFs in order to identify the existing risks of the target
risks. Note that it is obvious, only eight general questions can
company. Despite of EFs from original UCP, we do not have
not cover all the aspects of a project environment. Therefore
any group with negative weight and injected the negativity into
extending EF questions for a better cover of project risks
the subquestions, afterwards weighted the groups using their
may makeup this deficit. In our research project the list of
frequency from Table V.
most frequent potential risks has injected into EFs and its
Table VII gives our new EFs classification and weights.
productivity has evaluated. We name this approach as Risk
The details of this classification are stated in Table VI.
Extended Use Case Points (RUCP).

A. Top ten risks TABLE VII: New Classification and Weights

A risk is an unpredictable event that, if it occurs, has
Risk dimension Weight
inevitable effects on a project objectives and its development. Technology 0.5
Predicting risks is not an easy process. There are several User 1.5
studies on software project risks since 1981 in order to Process 0.5
determine all possible unpredictable threats. Many researchers Requirements 1.5
Team 1
have tried to suggest a list of frequent software risks in order Planning and control (P&C) 2
to make this process easier; Software project managers can use Organization Environment 1.5
these risk lists to discover related risks to their projects [19]. Development Environment 0.5
Study of software risk has appeared since 1981 by McFar- As table VIII shows there is a mapping between original EF
lan [20]. He identified 54 risks in three dimensions : Project questions and eight domains of Table VII, which means that
size, Technology experience, and Project structure. Handling we did not eliminate original EFs, but extended every question
all the 54 risks is not easy. Therefore, a number of empirical into a group of questions in order to have more precise EFs.
studies appeared later, suggested to put attention on the top
ten software risk list. These include the following studies: TABLE VIII: Mapping between Original EFs and New EFs
Boehm [22], Schmidt et al., [23], Addision and Vallabh [24]
Addision [25], Han and Huang [21] and Pare et al.,. [26]. environmental factor(UCP) Corresponding RUCP group
(subquestion)
Tharwon [19] studied the mentioned eight empirical studies E1: Experienced with a software Process (software engineering stan-
and extracted top ten risks of each, therefore a total of 80 development process dards,...)
risks were achieved. He classified these 80 risks into six E2: Application experience Team (personnel experienced with
groups. Table V gives the classification and frequency of each application...)
E3: Object-oriented experience Team (personnel experienced with
group. OOP...)
E4: Lead analyst capability Requirements (level and quality of
req. analysis...)
TABLE V: Top Risks Classification and Frequency [19] E5: Motivation Team (motivated personnel...)
E6: Stable requirements Requirements (Continually chang-
Risk dimension Frequency ing requirements...)
User 14 E7: Part-time workers Team (enough part-time and full-
Requirements 17 time personnel...)
Project Complexity 4 E8: Difficulty of programming lan- Team (skillful personnel...)
Planning and Control 27 guage
Team 9
Organization Environment 9
Total 80 V. CASE STUDY
In this Section, Based on the previously described approach
On the other hand Pressman [27] introduced a classification for improving EF, a case study was developed to determine
of all possible software project risks into 9 groups. We the productivity of 5 software companies using RUCP method.
combined Table V and the most probable risks from [27] and In our study we went to companies that either implemented
eliminated their overlaps based on some interviews of software or were implementing the ”Production planning” project. Out

146
 TABLE VI: New EF Classification Based on 60 Software Projects Risks, Grouped into eight Domains
Risk dimension Weight Risk Questions Weight
0.5 Is the technology to be built new to your company? -1
Technology
Do the customer requirements demand the creation of new algorithms, input or output technology? -1
Does the software interface with new or unproven hardware? -1
Does the project, interface with a database system whose function and performance have not been proven in this application area? -1
Is a specialized user interface demanded by product requirements? -1
What is the rate of complexity and maturity of the end user? +1
Does government constraints exist? -1
1.5 Have you worked with he customer in the past? +1
User
Does the customer have a solid idea of what is required? +1
Will the customer agree to spend time in formal requirements gathering meetings to identify project scope? +1
Is the customer willing to establish rapid communication links with the developer? +1
Is the customer willing to participate in reviews? +1
Can you manipulate and manage customer requirements? +1
0.5 Is there some mechanism for ensuring that work conducted on a project conforms with software engineering standards +1
Process
Are quality metrics collected for all software projects +1
Are formal technical reviews of requirements specification, design, code, test procedures and test cases conducted regularly? +1
Is the software process used for other projects? +1
Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases? +1
1.5 Are the requirements seem to be frozen?(no permission to change) -1
Requirements
Misunderstanding of requirements -1
Overlap between requirements -1
System requirements not adequately identified (based on requirements specification team experience) -1
Clear system requirements +1
Developing the wrong software functions -1
Developing the wrong user interface -1
Continually changing requirements -1
Is there a documented statement of work, software requirements specification, and software development plan for each subcontract ? +1
Level and quality of requirements analysis +1
1 How is the human resource manager performance in engaging process? +1
Team
Do the team members have specialized knowledge/skill required by the project ? +1
Do you have adequate personnel for the project?(including full-time and part-time personnel) +1
Application development experience level +1
Object-oriented experience level +1
Were the personnel trained in required skills? +1
Changes to membership on the project team -1
Are the team members motivated enough? +1
Planning 2 Lack of effective project management methodology -1
and Control Project progress not monitored closely enough -1
Inadequate estimation of required resources (overly optimistic estimates or ignores project history ) -1
Shortfalls of external supplied components -1
Poor project planning -1
Project mile stone not clearly define -1
Inexperience project managers and lack of skill in project leadership -1
Unrealistic time and cost estimates -1
Not managing changes effectively -1
Ineffective communications between development team and user -1
Gold plating in implementation -1
Misunderstanding/change project scope and objectives -1
Organization 1.5 Change in organizational management during the project development -1
Environment Corporate politics with negative effect on the project -1
Unstable organizational environment -1
Organization undergoing restructuring during the project development -1
Lack of top management commitment to the project -1
Lack of senior management committee -1
Development 0.5 Are project management software tools used to control and manage activities throughout the software process ? +1
Environment Are software tools used to support the testing process ? +1
Are configuration management software tools used to control and track change activity throughout the software process ? +1
Are UML software tools used throughout the software process ? +1
Are risk management software tools used throughout the software process ? +1
Are security test software tools used throughout the software process ? +1

of these companies, 2 of them had already been implemented
the same project, and 3 of the companies were developing the
same project. The main criteria for choosing these 5 companies
was similarity in their use cases and differences in Table VI
values. Company 1, 2 had already completed this project. Our
research conducted in parallel with project development in
company 3, 4, 5. The use cases which provided to company
3,4,5 were attempted to keep the complexity of use cases from
company 1,2.
After some time an interview was conducted in order to
collect use cases data from early phases. By this interview the
new EFs were calculated for each company based on project
manager’s view, in order to start the RUCP estimation process.
Afterwards, in the deployment phase another interview was
conducted. The goal of the second interview was to evaluate
the reasons of differences between RUCP estimates and ac-
tuals, by comparing project manager’s views at the beginning
and end of the project.
The main goal of the case study was to calculate the
estimates based on UCP and RUCP, in order to determine the
amount of improvement. Numerical results are stated in A,
and RUCP evaluation based on the second interview, is stated

147
in B.
A. Numerical results
In this Section estimation process based on UCP and RUCP
is followed in 3 steps.
Step1. Actors and Use Cases. As stated in the beginning of
this Section The main criteria for choosing these 5 companies
was similarity in their use cases. In use case diagrams 6 actors
and 5 use cases were identified. As shown in Table IX the
complexity of actors and use cases are stated. Therefore the
value of UUCP is equal to all.

TABLE IX: Actors, Use Cases Complexity

Fig. 1: Estimated Effort in UCP,RUCP VS Actual
Actor Count Weight Sum Use case Count Weight Sum
Simple 4 1 3 Simple 2 5 15
Average 0 2 4 Average 1 10 20
Complex 2 3 3 Complex 2 15 15 user organization was expected; Therefore the organization
environment group was rated to 0. In general a qualitative
Step2. TF and EF. Assigning values to technical and arrangement in EF classifications for companies can be ob-
environmental factors were done by project managers or served.
project experts, based on their judgment. The TFs reflect
some non-functional requirements and were evaluated based TABLE XII: EF Values for 5 Companies in both UCP and
on description of customer problem. As the project is similar, RUCP Methods
therefore the value of TFs is equal for all companies. Table X
shows TF values. Since the impact of TFs on estimation is Company EF (UCP) EF (RUCP)
small, the EFs have significant impact on the final estimates. C1 0.68 0.98
In this step EF is calculated in both UCP and RUCP methods. C2 0.83 1.12
The details of the EFs based on RUCP method, are shown in C3 0.83 1.18
C4 0.81 1.32
Table XI. Table XII shows the EF values in both methods.
C5 0.67 1.29
TABLE X: TF Values
Step3. Final Estimates. By having estimation parameters,
TFactor Description Rate
final estimates in both UCP and RUCP were calculated using
T1 Distributed systems 4
Eq. (4). Table XIII shows the amounts.
T2 Specific performance objectives 3.5
T3 End-user efficiency 5
T4 Complex internal processing 4.5 TABLE XIII: Estimated Results and Actual effort (Month)
T5 Code re-usability 4 Company UCP RUCP Actual effort
T6 Easy to install 2.5 C1 6.6 5.52 7.2
T7 Easy to use 4.5 C2 8 8.6 10.4
T8 Portability 1 C3 8 9.3 10.8
T9 Easy to change 4 C4 7.9 12.2 11.4
T10 Concurrency 0 C5 6.5 11.6 9.4
T11 Security features 4.5
T12 Access for third parties 2 The deviations between UCP/RUCP and actual efforts are
T13 Requires special user training facilities 1 shown in Table XIV. Besides, amount of UCP, RUCP and
42 actual efforts are illustrated in Fig. 1.

In the first interview, EF questions from Table VI were TABLE XIV: Deviation(%) between UCP/RUCP and Actual
rated from 0 to 10 by project experts of each company. Then effort
multiplied weight of each group into the average rate and
summed the results, which are shown in Table XI. Then the Company UCP VS Actual RUCP VS Actual
C1 9.09% 30.43%
value of final EF was calculated using Eq. (3).
C2 30% 20.93%
Additionally, a comparison can be concluded from Table XI,
C3 35% 16.13%
for example the worst company in requirements is company C4 44.30% -6.56%
4 while the best one is company 1. Also, the best one in C5 46.15% -18.1%
”personnel and team” is company 5, while this company is
the worst in planning and control and so on. No change in

148
 TABLE XI: EF Values for 5 Companies Based on the First Interview
New EF Domain Weight Company1
Technology 0.5 0.14
User 1.5 13
Process 0.5 5 4
Requirements 1.5 1.2
Team 1 6.75
Planning and control 2 -3.33
Organization env 1.5 0 0
Development env 0.5 5 4.8
Sum 14.15
EF=(-0.03*sum)+1.4 0.98
B. RUCP Evaluation
In order to evaluate the productivity of RUCP, the second
interview was held subsequently, as shown in Table XV. By
comparing the two interviews, reasons for differences between
estimates and actuals can be concluded. The differences are
shown as bold numbers.
In company 1, RUCP estimate ended up only slightly below
the UCP estimate. We believe that this is because company
1 had claimed that they are an experienced company and
have much common experience in developing such a project.
This can be concluded from Table XI where EF groups had
highly rated. Also the maturity of this company in ”planning
and control (P&C)”, ”requirements extraction” and ”effective
user communication”, was highly rated by project leaders and
seniors. As Table XIII shows, at the end of the project the
amount of actual effort is much more. The main cause can
be inferred from the second interview; As Table XV shows,
company 1 had some changes during the project development.
The value of ”P&C” and ”Requirements” had been decreased.
Project managers of company 1 stated in the second interview
that they had developed some wrong software functions,
which changed the ”Requirements” amount. Moreover, ”poor
planning” and ”poor performance of project expert”, were the
reasons of change in ”P&C” amount.
As Table XV shows, company 2 had some changes in
”P&C” and ”Team”. ”Inadequate estimation of required re-
sources” and ”gold plating” by developers were the main
reasons of change in ”P&C”. Moreover, changes to the ”mem-
bership on project team” was another reason which made the
project development longer.
In company 3, ”misunderstanding of requirements” caused
negative effect on ”Requirements”.
In company 4, actual effort is a bit below the RUCP
estimates, because at the end of the project they found
their performance better than what they had rated in the
first interview. For this company, the ”P&C” had the most
change between other domains. The reasons were: (i) Handling
changes effectively, (ii) Effective communication between de-
velopment team and customer more than excepted, (iii) Good
performance of project seniors, and (iv) Monitoring project
progress effectively. Moreover, changes to the ”membership on
the project team” was positively effective on ”Team” amount.
Company 5, evaluated itself pessimistically at the early
Company2 Company3 Company4 Company5
-0.72 -1.71 -0.85 0
11 10.5 9 9
4 3 3
-2.1 -1.8 -3.9 -2.1
5.5 6.25 4.25 9
-5.33 -6.33 -9.33 -14.33
0 0 0
4 3.66 2.33
8.68 6 0.97 3.1
1.12 1.18 1.32 1.29
phases. Therefore, the value of RUCP is much more than
actual effort. However, the RUCP estimates are closer to actual
effort than UCP estimates. By the second interview project
managers of this company obtained a more realistic view of
the project risks and company environment. In company 5,
the main reasons which were positively effective on ”P&C”
amount, and were not clear enough at the beginning of the
project are: (i) Effective communication between develop-
ment team and customer, (ii) Effective project management
methodology, (iii) Good performance of project seniors, and
(iv) Realistic Project planning.
Unfortunately, risk management receives considerably less
attention than other disciplines in a software project. In our
interview, we realized that the most companies do not extract
properly the risks and even there is not a proper plan for risk
mitigation. Generally, the interviews helped these companies
to get a more realistic perspective of their environment for
future projects. Our extracted risk list, in this paper, were
delivered to all these companies as an application list to extract
and manage the risks of a software project.
VI. C ONCLUSION AND F UTURE W ORK
Initial project estimate helps the project managers, devel-
opers and testers to make an effective plan for a project.
Estimation before development is one of the novel research
areas in software engineering. In this paper, we have developed
an improved version of the Use Case Point method (UCP) for a
typical industrial project. The main focus and distinct features
of this improvement which named Risk Extended Use Case
Point (RUCP) is based on the existing project risks.
UCP uses technical and environmental factors (EF and TF)
as an adjustment factor. These factors have a significant impact
on the project estimates. We improved the EFs by adding
software project risks. Boehm [18] states that inaccuracies
between UCP estimated effort and actual effort range up to 60
percent or more during the requirements phase. By applying
RUCP, this inaccuracy could be decreased to a significant
amount in most cases, as shown in this paper. Moreover, RUCP
allows the companies to discover the reasons of the existing
gap between estimates and actuals. Assigning value to EFs is
not an easy work. In some cases answers of project managers
or seniors are not mature enough or they are not neutral enough
to evaluate their work. Moreover, unpredictable events may
happen during the project development while this is inevitable.
149
 TABLE XV: EF Values for 5 Companies Based on the Second Interview
New EF Domain Weight Company1 Company2
Technology 0.5 0.14 -0.72
User 1.5 13 11
Process 0.5 5 4
Requirements 1.5 0 -2.1
Team 1 6.75 5.5
Planning and control 2 -4.33 -6
Organization env 1.5 0 0
Development env 0.5 5 4.8
Our new classification for EFs is based on a comprehensive
list which are categorized into eight domains: Technology,
User, Process, Requirements, Team, Planning and Control,
Organization environment and Development environment. As
a conclusion from [19] the most frequent risks are in Planning
and Control (P&C) and Requirements domains, also User and
Organization environment domains are in second hand. P&C is
one of the main steps of project management, and companies
with poor ability in management would be in a high significant
risk of failure. The results show that ignoring one of the most
vital aspects of any software project may lead to imprecise
estimation results.
Moreover, we considered every software project in the form
of eight aspects: Requirement, Design, Implementation, Test,
Quality, Risks, Security, and Reports. The existing risks aspect
has been highlighted as the main focus of the current work.
Rest of aspects will be subjected of future studies.
R EFERENCES
[1] G .Karner, Resource estimation for objectory projects, Objective Systems
SF AB 17, 1993.
[2] A.J .Albrecht, Measuring application development productivity, Proc. of
the Joint SHARE/GUIDE/IBM Applicaiton Development Symposium.
1979.
[3] M .Ochodek, J. Narocki and K. Kwarciak, Simplifying effort estimation
based on Use Case Points, Information and Software Technology 53.3
(2011): 200-213.
[4] M .Azzeh and A.B .Nassif, A hybrid model for estimating software project
effort from Use Case Points, Applied Soft Computing 49 (2016): 981-989.
[5] S .Nageswaran, ”Test effort estimation using use case points, Quality
Week Vol. 6. 2001,USA.
[6] B .Anda, et al. ,Estimating software development effort based on use
casesexperiences from industry.UML The Unified Modeling Language.
Modeling Languages, Concepts, and Tools :487-502, 2001.
[7] M.R .Braz and S.R .Vergilio, Software effort estimation based on use
cases, Computer Software and Applications Conference, 2006. COMP-
SAC’06. 30th Annual International. Vol. 1. IEEE, 2006.
[8] R .Silhavy, P .Silhavy and Z .Prokopova, Analysis and selection of
a regression model for the Use Case Points method using a stepwise
approach, Journal of Systems and Software 125 (2017): 1-14.
[9] G .Robiolo, C .Badano and R .Orosco, Transactions and paths: Two use
case based metrics which improve the early effort estimation, Proceed-
ings of the 2009 3rd International Symposium on Empirical Software
Engineering and Measurement. IEEE Computer Society, 2009.
[10] F .Wang, X .Yang, X .Zhu and L .Chen, Extended use case points method
for software cost estimation, Computational Intelligence and Software
Engineering, 2009. CiSE 2009. International Conference on. IEEE, 2009.
[11] P .Mohagheghi, B .Anda and R .Conradi, Effort estimation of use cases
for incremental large-scale software development, Software Engineering,
2005. ICSE 2005. Proceedings. 27th International Conference on. IEEE,
2005.
[12] S .Amasaki and C .Lokan, On the effectiveness of weighted moving win-
dows: experiment on linear regression based software effort estimation,
Journal of Software: Evolution and Process 27.7 (2015): 488-507.
150
Company3 Company4 Company5
-1.71 -0.85 0
10.5 9 9
4 3 3
-2.1 -3.9 -2.1
6.25 4.75 9
-6.33 -7.33 -11.33
0 0 0
4 3.66 2.33
[13] E.R .Carroll, Estimating software based on use case points, Compan-
ion to the 20th annual ACM SIGPLAN conference on Object-oriented
programming, systems, languages, and applications. ACM, 2005.
[14] A.B .Nassif, D .Ho and L.F .Capretz, Towards an early software
estimation using log-linear regression and a multilayer perceptron model,
Journal of Systems and Software 86.1 (2013): 144-160.
[15] A.B .Nassif, M .Azzeh, L.F .Capretz and D .Ho, Neural network models
for software development effort estimation: a comparative study, Neural
Computing and Applications 27.8 (2016): 2369-2381.
[16] L.M .Alves, A .Sousa, P .Ribeiro and R.J .Machado, An empirical study
on the estimation of software development effort with use case points,
Frontiers in Education Conference, 2013 IEEE. IEEE, 2013.
[17] G .Schneider and J.P .Winters, Applying use cases: a practical guide,
Pearson Education, 2001.
[18] B.W .Boehm, Software engineering economics, Vol. 197. Englewood
Cliffs (NJ): Prentice-hall, 1981.
[19] T .Arnuphaptrairong, Top ten lists of software project risks: Evidence
from the literature survey, Proceedings of the International MultiConfer-
ence of Engineers and Computer Scientists. Vol. 1. 2011.
[20] McFarlan and F. Warren. Portfolio approach to information-systems,
Harvard business review 59.5 (1981): 142-150.
[21] W.M .Han and S.J .Huang, An empirical analysis of risk components
and performance on software projects, Journal of Systems and Software
80.1 (2007): 42-50.
[22] B.W. Boehm, Software Risk Management: Principles and Practices,
IEEE Software vol 8, number 1, pp.32-41,1991.
[23] R .Schmidt, K .Lyytinen, M .Keil, M . and P .Cule, Identifying Software
Project Risks: An International Delphi Study, Journal of Management
Information Systems vol 17, number 4, pp. 5-36, 2001.
[24] T .Addision and S .Vallabh, Controlling Software Project Risks an
Empirical Study of Method used by Experience Project Managers, Pro-
ceeding of SAICSIT 2002, pp.128-140.
[25] T .Addision, E-Commerce Project Development Risks: Evidence from a
Delphi survey, International Journal of Information Management vol 23,
number 1, pp. 25-40, 2003.
[26] G .Pare, C .Sicotte, M .Jaana and D .Girouard, Prioritizing Clinical
Information System Project Risk Factors: A Delphi Study, Proceeding of
the 41st Hawaii Conference on System Sciences -2008, pp.1-10.
[27] R.S .Pressman, Software engineering: a practitioner’s approach, Pal-
grave Macmillan, 2005.