Effort estimation model for software development projects based on use case reuse

This paper describes a new effort estimation model based on use case reuse, called the use case reusability (UCR), intended for the projects that are reusing artifacts previously developed in past projects with similar scope. Analysis of the widely spread effort estimation techniques for software development projects shows that these techniques were primarily intended for the development of new software solutions. The baseline for the new effort estimation model is the use case points model. The UCR model introduces new classification of use cases based on their reusability, and it includes only those technical and environmental factors that according to the effort estimation experts have significant impact on effort for the target projects. This paper also presents a study which validates the usage of UCR model. The study is conducted within industry and academic environments using industry project teams and postgraduate students as subjects. The analysis results show that UCR model can be applied in different project environments and that according to the observed mean magnitude relative error, it produced very promising effort estimates.

On the other hand, an accurate project effort estimate affects the efficient use of existing resources. In cases where the amount of the estimated effort exceeds the amount of the actual effort (the planned amount is overpriced), there is a possibility that human resources are committed to the project to a greater extent than necessary for the execution of the project.
Present trends impose goals such as shorter duration of the software development cycle and cheaper product prices. This directly targets lower project effort, but there is still a parallel demand to maintain the agreed quality of the product. To meet set requirements, software development models introduce the practice of defining software modules and their implementation. Those serve as the core solution with a possibility to reuse certain modules in other (separate) software solutions. Core solution beside program code contains a vast number of development process artifacts, such as requirement descriptions, architecture, use cases, test specifications, etc. Reusability practice of software artifacts improves the productivity and quality of new software products, while reducing the resources, cost, and time of the future software development projects. [6][7][8] Conducted studies include an analysis of the most commonly used effort estimation techniques, and those can be categorized into two groups [9][10][11] : algorithmic models based on parameters (constructive cost model, lines of code, functional points, use case points-UCP, etc.) and heuristic approach 12 (expert estimation, neural networks, a rule of thumb, techniques, Delphi, etc.).
Analysis of the estimation techniques listed above 10,11,13 showed that they are primarily intended for new software development. Due to the lack of an appropriate estimation technique that would consider the reusability aspect, some of the observed cases of development projects from practice showed that the alternative technique used is expert assessment, although with inaccurately estimated effort.
Such results clearly show that there is a strong need for defining a new effort estimate model that would serve the projects which are reusing artifacts developed in previous projects within the same program. General recommendation for project organizations is to automate the estimation procedures 9 and adapt tools and approach according to their needs. Tools containing embedded algorithmic models based on parameters that describe the requirements of the software solution provide a standardized assessment process. Therefore, the focus of our research is specifically set on the algorithmic models.
The goal of our research is to define a new effort estimation model intended for projects reusing artifacts developed in previous projects with similar scope. The baseline for a new effort estimation model would be the UCP model, developed by Karner. 14  According to our knowledge, so far none of the estimation models described in literature have been dealing with reusability aspect, and our contribution would be a mathematical model for effort estimation which can be adapted for projects that are reusing artifacts previously developed in past projects with a similar scope of work. The term "projects with a similar scope of work" refers to those projects that have similar functional requirements.
The remaining sections of this paper are organized as follows. Section 2 gives an overview of the UCP model which is used as the baseline for a new effort estimation model as part of related work. Section 3 describes our experience and challenges of applying UCP model in projects that are reusing previously developed artifacts. In Section 4, we propose the definition of a new effort estimation model based on use case reuse (UCR). Section 5 describes the mathematical model of UCR and all related algorithms for producing effort estimation, followed by model parameterization in Section 6. Furthermore, Section 7 describes the validation process of the UCR model. In Section 8, application principles of the UCR model are represented, followed by conclusion and future work statements in Section 9.

| RELATED WORK
As mentioned before, there is evidently a lack of proven estimation methods considering reusability aspect. Widely used estimation models show good results in estimating effort for software development projects where artifacts are built from scratch. The research is initially focused on the selection of an appropriate existing estimation model and then on its modification with new factors that would describe the reusability aspect.
We searched for the previously performed surveys and systematic literature reviews in the journals and conference proceedings based on keyword topic: software effort estimation. The results found in the literatures 1,9,[15][16][17][18] helped us to assess which of the existing effort estimations for software developments projects would provide the most appropriate baseline for the new effort estimation model.
Based on the surveys and systematic literature reviews, we decided that the most appropriate effort estimation model to be used as the starting one is the UCP, developed by Gustav Karner. 14 Within the surveys and systematic literature reviews, UCP was explored in terms of usage and estimation accuracy as (1) original method as defined by Karner, (2) hybrid technique in combination with other estimation technique (eg, constructive cost model), or (3) within broader group of model-based estimates.
The UCP is one of the widely used models to estimate the amount of work to develop software, 16,17,19 and, more importantly, this model is suitable for different types of projects, from short duration ones (up to a month), to those over 1 year. There is wide applicability-no dependence on software architecture or programming language (Java, Web Logic, MS Visual Studio, C ++, etc.). It was developed primarily for the rational unified process (RUP) development methodology, but it is significant that the UCP is also used in agile software development. 16 The next sections will describe the UCP estimation model including the use case concept which forms the basis for effort estimation.
Researches from academia and industry have shown interest in the UCP-based approaches because of the promising results obtained along with their early applicability in budget estimation. 19 Some of the methods developed based on UCP approach are iUCP, 20 e-UCP, 21 and Re-UCP. 22 A challenge in adapting an existing model is to understand possible consequences of the adaptation. Terms of usage, mathematical model, and potential limitations must be well understood by the research team. For the UCP model, these elements were clearly described and easily understood by the research team which makes the UCP model an appropriate baseline for building a new effort estimation model.

| Use cases
Use case describes how the user is interacting with the system. 23 It is defined by a list of possible interactions between the system to be developed and external participants (actors) to achieve a specific objective. Actors are people or information systems; one of the actors is the system that is being developed, which also cooperates with other actors. 23 According to the guidelines for writing use cases 23 the most important parts of a use case are as follows: name/title which describes the goal of a certain functionality, actors participating in the use case (people or cooperating systems), use case overview which describes a main activity performed by an actor, main scenario (basic flow) which is the most common sequence of steps leading to the goal, and extensions to the main scenario describing alternative steps associated with the occurrence of some events.

| Use case points (UCP)
The basis of the UCP model lies in the analysis of the system's use cases. 14 The first step is the classification of actors: simple actor is a system that communicates through defined application programming interface, average actor is a system that interacts via TCP/IP protocol, and complex actor represents a participant who interacts through a graphical user interface or web applications. A weight is assigned to each actor category as follows: • Simple actor, weight: 1, • Average actor, weight: 2, • Complex actor, weight: 3.
The total unadjusted actor weight (UAW) is calculated by counting the number of actors in each category, multiplying each total by its specified weight and then adding the products.
The use cases are also classified into simple, average, and complex, depending on the number of transactions in the use case. The transaction marks the event (activity) between the actors and the system. A weight is assigned to each use case category as follows: • Simple use case (three or fewer transactions), weight: 5, • Average use case (four to seven transactions), weight: 10, • Complex use case (more than seven transactions), weight: 15.
The unadjusted use case weights (UUCW) is calculated counting the number of use cases in each category, multiplying each category of use case with its weight and adding the products. The UAW is added to the UUCW to get the unadjusted use case points (UUCP).
Unadjusted use case points (UUCP) are adjusted by the values assigned to technical factors (Table 1a) and environmental factors (Table 1b).
These factors affect the amount of work irrespective of the size of the software product, and they describe functional and non-functional requirements, as well as the characteristics of the project team. Each factor is assigned a value between 0 and 5 depending on the assumed impact on the software developed. The value of 0 indicates that this factor is irrelevant to the product, while value 5 means that it is essential.
Multiplying the value of each factor in Table 1a by its weight and then adding all these numbers will get the T factor sum. The technical complexity factor (TCF) is calculated as in Equation 1: Multiplying the value of each factor in Table 1b by its weight and adding all the products will get the E factor sum. The EF is calculated as in Equation 2 : The adjusted UCP is calculated as follows in Equation 3: Eventually, in estimating the amount of work required to develop software, it is crucial for a project manager to express the effort in the appropriate unit of measure, eg, man hour (or person hour), man month, etc. For such results, it was necessary to determine how many man hours is needed for one UCP.
Karner suggests the value of 20 man hours per UCP to produce exact effort estimation. 14

| CASE STUDY-EXPERIENCE WITH UCP MODEL IN INDUSTRY PROJECTS
Case study was conducted within the software industry program consisting of more than 20 projects which all had a very similar scope of work: development of solutions that enabled the integration of various IT system management applications. Every project covered the scope of integration activities considering specific requirements imposed by an individual client. Applications for system management used by a great number of different clients had either the same or very similar functionalities.
Projects were united into a program to manage them more efficiently due to following guidelines: human resources were shared between the projects in the program, project issues, and risks applicable for two or more projects were managed at the program level, and software development methodology and processes were aligned for all projects.
The program followed software development methodology RUP. Use case models showed that in terms of projects' size, all the projects could be characterized as small sized according to their scope. The number of actors varied from three to four, and number of use cases varied from 10 to 12.
One of the main advantages of uniting projects in a joint program was the sharing of knowledge and lessons learned about the software development process. To achieve maximum utilization of all resources in the program, it was extremely important to manage them properly and efficiently. It had to be considered that the project team consisted of experts with adequate knowledge and skills to perform their assigned role in the project and in accordance with the needs. In addition, it was necessary to make timely decisions about their engagement in the projects. Precise effort estimation for each of the projects was very important for several aspects of the program management; at the program start it was an input for individual project plans, project costs, and resource management.
At the beginning of the program, it was assessed that the solution framework (including all deliverables) should be reusable as much as possible (respecting contractual obligations for each project as well). Reusable artifacts covered not only source code (or parts of source code) but also project documents: scope of work, solution architecture, system context, business process model, use case model, and test specifications. Reusability of specific artifacts was considered during requirements analysis (elaboration phase) and decided during the project build (construction) phase. On the other hand, effort estimation had to be conducted during the planning phase, based on the information known at that phase: high level functional scope and project team characteristics. Project team had to follow carefully very well-defined rules about documenting each of the project deliverable to ensure that other project members could easily comprehend whether such deliverable could be assessed for reuse in other projects. Project deliverables were available for project team in shared document repository (with certain access restriction based on project role).
In parallel, project team maintained a tracker of artifacts reusability across projects.
The UCP model was followed to estimate efforts of first five projects and after completion of each project the team compared estimated effort versus actual effort. The estimated effort for the first project where all the project artifacts were developed from scratch was 9% higher than the actual effort. Further in the text the term "initial project" will be used to describe a project where all the project artifacts are developed from scratch (development ab initio). However, for the subsequent projects, where the artifacts from the first projects were reused, estimated efforts according to the UCP model were significantly higher than the actual efforts.
Magnitude of relative error (MRE) as a parameter is important and commonly used criterion in estimation. It is calculated as shown in Equation 4. In fact, MRE is the absolute error in estimating project, and the closer to zero it is, the more accurate is related estimation model. The UCP estimation model could provide effort assessment for every individual project, based on the size, functional and non-functional requirements for the particular product developed. Such an approach was appropriate only for the effort estimation of the initial project within the program where all project artifacts were built from scratch. For the subsequent projects, the team could not set any input for the estimation model that would describe that certain solution artifacts were reused from previous projects. As a result, the effort estimated by the UCP model for subsequent projects was not sufficiently accurate as it was significantly higher than the actual effort.

| DEFINITION OF EFFORT ESTIMATION MODEL BASED ON USE CASE REUSE (UCR MODEL)
To provide more precise effort estimation for the projects where artifacts are reused, we propose the definition of a new effort estimation model In the proposed UCR model, use cases would serve as input parameter to compare similarity and compatibility of scope of work between the initial and subsequent projects. Use case comparison between the projects characterize the scale of reused artifacts which does not imply reuse of code only, but potentially other project artifacts such as design model, data models, architectural decisions, and test specifications. Level of reusability of other artifacts increases with the number of equal or similar use cases. Use cases as such are defined in the early stage of the development project, and therefore this estimation model could be used already in the project planning phase.
Our observation after the completion of a few subsequent projects showed three main aspects that determined lower actual effort of subsequent projects comparing to the actual effort of initial project: (1) functional scope of the projects; (2) technical complexity of the solution developed; and (3) environmental factors. Karner based UCP model on the very similar aspects: project scope expressed by UUCP, technical complexity defined by technical complexity factor (TCF), and project team characteristics expressed by environmental complexity factor (EF). Hence, the next step is the assessment of all the factors that made calculation of UUCP, TCF, and EF as defined by Karner and the decision whether they should be included in the new UCR model. To make the assessment more objective, we included in the assessments an expert team that consisted of three project managers and five IT architects, all of them with an experience in effort estimation processes. Project managers were seniors in their roles, all of them with PMP certificate. Senior IT architects had more than 5 years' experience in their current role, and three of them were IBM Certified Architects. Two project managers and two IT architects had worked in the past on the software development projects that were reusing artifacts from the previous projects that included the reuse of project documents and source code. All members of the expert team were asked to list additional factors that according to their opinion influence the project effort on top of the factors defined by Karner. All new factors that impacted effort of subsequent projects (either increased or decreased the effort) were discussed between the experts and all of them appertained to three already known main aspects as per Karner: functional scope, technical complexity and environmental factors.

| Functional scope of the projects
Functional scope refers to the services that a specific system offers. 23 Karner decided to describe it in his UCP model by use cases, and the same approach is followed in the UCR effort estimation model. Original classification of use cases and actors by the same criteria into simple, average, and complex is kept in the UCR model as well. However, the UCR model is distinctive by inclusion of additional classification of use cases for the subsequent projects based on their reusable elements: -New use case (UC_N)-represents completely a new use case that does not represent any part of the previously defined use cases In all the other cases, use case is classified as new one (UC_N).

| Technical complexity
Karner defines 13 technical factors to describe the overall technical complexity of the software product (Table 1a). Scientific studies indicate that the influence of technical factors (TCF) in the UCP model is minor and that these factors do not cover all non-functional requirements of the product. 24 Some of the studies even recommend not to count TCF in UCP calculation (to set the value to 1 in Equation 3). 17,27,28 Therefore, the next step is to define appropriate technical factors for the new effort estimation model UCR that would have impact on the calculation of effort for both-initial and subsequent projects.
The task of the expert team is to assess which of the existing technical factors defined by Karner have significant impact on project effort.
Significance of Karner's technical factors is evaluated by every member of the team by rating factors as extremely important (awarding 3 points), moderately important (awarding 2 points), or slightly important (awarding 1 point). It is proposed that the new UCR model contains only those factors whose score is at least 80% of the maximum possible total score which is the case for the following factors: Distributed System (T1), Reusable code (T5), and Portable (T8).
Nonetheless, the technical factor Reusable code (T5) is not included in the UCR model as the code as such must be reusable by the nature of the target projects (eg, the code in all projects should be reusable in the subsequent projects). In the same manner, the UCR model does not include factors like flexibility and modularity that describe general reusability aspects that have to be followed in the projects that plan to reuse artifacts across the projects.
The expert team agree to rename factor called Distributed Systems into Software Architecture factor as this term includes the wider characteristics, eg, system distribution, architecture layering, complexity of infrastructure, safety requirements, and non-functional requirements.
According to previous experience, the expert team assesses that an additional factor has a significant impact on the actual effort of subsequent projects and can be classified as a technical factor: integration with new systems. This factor is included in the UCR model, describing if the number of integration points for a software product in the subsequent project is higher than it is the case for the previous project.

| Environmental factors
Environmental factors as defined by Karner are primarily related to the competence of the project team (factors F1-F5). Analysis of the actual amount of five completed projects shows that the experience of team members inversely affects the total effort for subsequent projects.
The task of the expert team is to assess the environmental factors of UCP model in the same way as the technical factors: each member of the team evaluates factors as extremely important (awarding 3 points) or moderately important (awarding 2 points) or slightly important (awarding 1 point). Again, the new UCR model includes only those factors whose score is at least 80% of the maximum possible total score, which is the case for the following factors: Application experience (F2), Lead Analyst Capability (F4), and Requirements stability (F6). Factor F6 Requirements stability is renamed to Requirements maturity. It covers the quality of given requirements (eg, business process details and business rules).
Considering their previous experience, the expert team introduces the following new factors into UCR model that describe the characteristics of the project team: -Team colocation-all team members are at the same location or within distributed team (virtual).
-Team size-growing number of team members require more project task integration activities (which can also be placed in the overhead).
-Maintenance of project documentation-availability of quality documentation that describes artifacts of the initial project (the artifacts that are exploited).
-Team cohesion-describes whether the team members and other stakeholders collaborated in previous projects.
The UCR model does not include factors that describe general reusability aspects (eg, flexibility, modularity, and easy to change) that have to be followed in the projects that intend to reuse artifacts across other projects.

| MATHEMATICAL MODEL OF NEW EFFORT ESTIMATION MODEL-UCR
The total unadjusted actor weight in UCR model (UAW R ) is calculated as defined by Karner: counting the number of actors in each category, multiplying each total by its specified weight, and then adding the products.
Given that the use case is classified in relation to the complexity and reusability, unadjusted use case weight for UCR model (UUCW R ) is calculated as the sum of products for each use case weights given for the complexity criteria and reusability criteria.
The UAW R is added to the UUCW R to get the UUCP for UCR model (UUPC R ). Technical complexity factor in UCR model (TCF R ) is counted as product of all technical factors weight, from UCR_T1 till UCR_T3: For i = 1, 2, 3.
The premise of the UCR model is that amount of work depends on the attributes of technical and environmental factors. Therefore, factors of technical complexity and environment have been calculated as the products of these factors' weight.
Adjusted amount of UCR is calculated as the product of UUCW for UCR model (UUCP R ), technical complexity factor (TCF R ) and environmental complexity factor (EF R )both for UCR model: To reach the final measure of estimated effort in man hours, the next step would be to define the value of man hours per UCR. Karner Detailed description of calibration process of UCR measure in man hours is in Section 7.

Maintenance of project documentation and artifacts
There is no standardized process for maintaining project documentation The standard process for maintaining project documentation is defined, but it is not comprehensive or not followed entirely The standard process for maintaining project documentation and artifacts is defined and followed entirely

UCR-F7 Team cohesion
The degree of the previous collaboration of team members The project team members have not previously worked together on the project of a similar scope of work The project team members have previously worked together on the project of a similar scope of work The project team members have previously worked together on two or more projects of a similar scope of work Projects and their historical data are divided into two separate sets: calibration set and validation set. A total of 18 projects from Program A make the calibration set and 11 remaining projects from Programs A, B, and C make the validation set. Projects are primarily divided into the sets by the time of their execution. All the projects in calibration set were completed before the projects in the validation set. In both sets there are "initial" and "subsequent" types of projects. Characteristics of each of the Program within calibration and validation set are listed in Table 4.  For example, the 100% value of PR indicates that the individual factor workload (effort) can increase 100% if the factors attribute changes from low to high. For such example a participant would give value 2. On the other hand, for another factor the PR can be 75% which indicates that the amount of work can be increased to 75% if the factors attribute changes from low to high. In such an example the value is 1.75.

| Historical project data
Technical and environmental factors are awarded three possible attributes (low, medium, high). The decision process is carried out in two rounds of tests. The experiment results using Delphi method are shown in Table 5 (the second round of tests).  To determine numerical value of each attribute, we need to set ratios of attributes. The values for each of three attributes are defined as linearly proportional. Initial weights are calculated based on the rules described in the following paragraph.

| Linear proportions of weights
Weights of attributes for technical and environmental factors are calculated as linearly proportional (L refers to attribute Low, M refers to attribute Medium, H refers to attribute High): For technical factors applies that attribute "Low" requires less project effort than attribute "High" (L < H). Therefore, the weight of attribute "Low" is less than the weight of attribute "High" and PR is calculated as follows: where PR median is the median range value taken from the second (final) round of Delphi method. Sequentially: For environmental factors applies that attribute "Low" requires a greater amount of work than attribute "High" (L > H). Therefore, the weight of attribute "Low" is greater than the weight of attribute "High" and PR is calculated as follows: where PR median is the median range value taken from the second (final) round of Delphi method. Sequentially: Median value of PR for UC_S and UC_R is set as the weight for new classification of use casessimilar (UC_S) and identical use case (UC_R).

| Calibration process
The goal of calibration process is to define the size of UCR expressed in man hours for UCR model. For each of the projects in calibration set UCR size is calculated according to the Equation 13: To derive the size of UCR expressed in man hours, we use historical project data from selected projects within Program A for calibration process of UCR model. We collected historical data from 16 projects that fulfilled the eligible criteria for UCR model application. There were two or more projects with similar scope of work and one or more of them reused the artifacts from the initial project.
UCR value expressed in man hours differs for initial projects once compared with the subsequent projects. Values of UCR for the initial and subsequent project are defined by Equations 14 and 15.
Final weights of input factors are listed in Table 6.

| VALIDATION OF UCR MODEL
Within the validation process, UCR model is applied on both initial and subsequent projects. Goal of the validation process is to evaluate estimation results with respect to estimation accuracy from the point of view of a project team in the context of industry and academic projects. Within the experiment, we define the following hypothesis and the measures that are needed to evaluate hypothesis: Reliability of measures is considered as a threat to conclusion validity. Use case definition and classification as an input factor in UCP and UCR models require human judgment. Hence, to achieve consistency among initial and subsequent projects, it is necessary to apply consistent rules in use case definition and classification.

| Experiment planning
Instrumentation is a threat to internal validity. Historical data about actual project effort must be collected and reported in the same way across different programs and different project teams.
Within construct validity, there is a threat to hypothesis guessing. Although the subjects were not part of estimation expert group, some subjects have noticed themselves the trend of effort decrease in subsequent projects.
Relatively small number of available projects for validation of UCR model (small number of initial and sequential projects) is considered as a threat to external validity.

| Experiment execution-data collection
Project historical data were collected in two ways: (1) project managers provided information about actual effort, and (2) project managers (in some cases together with software architects) provided information about estimated project effort per UCP and UCR models. The data were presented to experimenter to ensure that all subjects have reported accurately about historical data and that they applied the UCP and UCR models in correct order. Such approach was utilized to minimize the impact of two threats to validity: reliability of measures and instrumentation.

| Graphical visualization of data
Collected data about project estimated effort (per UCP and UCR models) and actual project effort is shown in Figure 2. Only for one project within validation set (P6) actual and estimated effort (per both models) is significantly higher comparing to others. This data is not considered as outliner Actual and estimated effort of projects and will not be excluded from data set because related project had wider scope then the other projects within validation set. In addition to that, MRE per UCR model for project P6 is below 1%, which is another argument not to treat this data as outliner.

| Parametric testing (paired t-test)
Paired t-test is performed as per calculations in Table 7. 31 For projects within validation set, MRE project effort estimated by UCP and UCR models are listed in Table 8. Null hypothesis states that there is no difference in estimation accuracy (measured by MRE) of estimated project effort between the application of UCP and UCR model. The alternative hypothesis states that there is a difference.
The results of paired samples test are presented in Table 9.
Limited number of projects (samples) within validation set can represent a threat to external validity. However, according to the results of paired t-test, it is possible to reject null hypothesis.

| Results of the experiment
By rejecting null hypothesis, experiment shows there is a difference in estimation accuracy (measured by MRE), of estimated project effort between the application of UCP and UCR models.
The two-tailed P value equals 0.0009. By conventional criteria, this difference is considered statistically significant.
Accuracy of estimation model is observed as well by these criteria: MMRE (mean magnitude of relative error) and PRED (Percentage of Predictions within 20%) of estimated project effort (20).   All MRE values are used to calculate the value of MMRE following the equation: The MMRE is calculated to indicate the relative amount by which the estimated effort is an underestimate or overestimate in comparison to the actual effort. MMRE is used in most of the research work as evaluation criterion due to its independent-of-units characteristic which means that MMRE is independent of units of estimated effort like man hours, man months, etc. MMRE is a meaningful tool used to summarize statistics and is very important in evaluating a software effort estimation model. 19 PRED(x) is the percentage of estimates that are within x% of the actual efforts. PRED (20) is the percentage of estimated effort that is within 20% of the actual efforts.
Both measures, MMRE and PRED (20) show promising results once calculated for projects within validation set for UCR model (included in Table 8).

| APPLICATION OF THE UCR MODEL
The initial prerequisite for performing an effort estimation using the UCR model is to form a team of experts with proper knowledge of the effort estimation process and experience in projects that are reusing artifacts. On the other hand, it cannot be expected that there is a great number of such experts within an organization.
For UCR model, the estimators need to set all input factors for every project (initial and subsequent projects): Product Line). In such cases, the above listed steps can also be applied to customize the UCR model to specific project environment.
Another potential scenario of applying UCR model is to perform only the last step from the adaptation process described above: calibration of UCR size (expressed in man hours) for the certain project team. UCR size indicates the productivity of a certain project team 33 and based on the historical project data of actual effort and input factors for other projects within that organization, different value of UCR size (for both initial and subsequent projects) might be applicable for another project team.  (20) for UCR is higher than PRED(20) for UCP model). In practice, more precise effort estimation allows the project team to improve overall project management process-planning, scheduling, resource management, and cost estimation. Projects whose historic data was used for model calibration and validation are dominantly small sized in terms of project scope (small or moderate number of deliverables to be produced) and team size (up to five team members), so certain deviations in effort estimation might be expected for medium or large projects. Therefore, in the future research, the focus would be on wider UCR model validation in medium or large projects-for both initial and subsequent projects to increase acceptability.

| CONCLUSIONS AND FUTURE WORK
As part of future work, there is a possibility for medium or large sized projects to enlarge the scale of factor attributes in the UCR model (eg, by introducing very low and very high attributes). Project size and project complexity are increasing from small to large sized projects: medium and large sized projects have a moderate to high number of deliverables which are usually technically more complex, number of team members rises and timeframe for delivery expands. Additional granularity of factor attributes would allow more precise differentiation between the projects in terms of technical complexity solution and project team characteristics.
In medium or large projects, a greater number of use cases is expected. Use case classification in terms of reusability would be time-consuming if their comparison was done manually. Therefore, as part of future work there is an opportunity to introduce the process of automated comparison of use cases potentially as part of a newly developed tool.
This paper has focused on the reuse of artifacts across projects with similar scope. The UCR model was validated separately in three different programs that had different scope and context. As part of future work, authors will consider exploring reuse across projects with different scope.
Such approach will have to be studied thoroughly in terms of the impact on project effort. Level of reuse across projects with different scope is expected to be lower than for the projects with similar scope. At the other hand, artifacts reused from the projects with different scope might need adaptation, which very likely will require additional project effort.