The effort estimation calculation method allows the stakeholders to estimate on how much effort can be saved by modularizing the component after t months, which answers the research question RQb. However, the model also gives information such as how many months it takes until the refactoring will save effort. This is useful information to have when making the decision if to refactoring or not. The reason for this is that if the refactoring will never pay back, then it is not a refactoring worth doing as the effort spent on the refactoring would be more than the effort payed on the interest.
6.2.1
Impact on the Industry and the Academia
The method does have an impact on the industry. As the method allows for es- timating the amount of effort that can be saved a certain period of time after the refactoring, it provide useful information to have when making the decision on refac- toring. This can be useful for both the developers themselves to know, but also for developers to convince the upper management that refactoring a component is not a waste of effort, but an investment for future development. However, it does not only provide information in support of refactoring. Depending on the case, the model can indicate that refactoring a component will not give a return on the refactoring
effort investment. This is just as useful information to have as when the result of the method is that the refactoring investment will give a return.
The method also has impact on the research as well. Previous work, such as Nugroho et al. (2011), investigate the interest of a system or component as a whole and thereby the effect of refactoring the whole system. The method defined in this study investigate the interest on a specific part of a component, the FOIs. Hence, this study contributes to research with an exploratory method of calculating the effort on part of a component, whereas previous studies have calculated the whole component. Furthermore, Sered and Reich (2006) designed an effort calculation on how much the cost would be to design the next generation of component to remove interest. What differentiate this thesis study’s method from theirs is that this thesis study focus more on the effort it takes to refactor an existing component to repay TD while their study focus more on the design effort to create a new component to repay TD.
6.2.2
Problem Size Scaling
The problem size scaling was difficult to estimate since there was no clear factor to use when scaling data from RC to NRC. As this is something that is not taken into consideration by other studies, it makes this a first approach in taking this into consideration to scaling data between components. Thus, one way of scaling RC in order to fit NRC was to count the number of objects for each component. Another way was to ask developers who have been working with both components to get an estimation of the problem size. Thus, by not finding any paper discussing on how to decide the scaling (or normalizing) of the problem size, the study decided to go with the number of difference between the objects. With that said, both of these methods are linked to the reliability threat (see Section 6.6.4) because of the estimation made on what the problem size could be.
A more accurate way of scaling the data from between two components depending on the FOI is by scaling dependent on the number of change request affecting the FOIs. This would allow the scaling not to be that dependent on the components to have the same amount of effort ratio put into the FOIs. Although, the most important part when it comes to the scaling is to find a scaling that works for each individual component combination. The reason for this is that for this study the scaling worked the way it is presented in the result, but applying it on another component and the scaling between the problem size may not be as linear.
6.2.3
Effort Estimation Equation
The effort calculation does not take into account the TD that would be accumulated if the component would not be refactored as defined by Martini et al. (2015). This was not considered due to the increase complexity that would be added to the effort calculation. The consequence of this is that doing the refactoring would probably save more effort than the calculation will show. A future work within this area could take this into consideration and thereby making the model more accurate.
6.2.4
Effort Data Collection
There is a limitation in the way the data was elicited. As it stands now it focuses on the historical data. This means that if the equation was to be used to predict the effort saved for future development on FOIs which has been dormant for a long period of time but is going to be active again, then a new way of eliciting the data is needed. This is because the steps described in Section 5.1.2.3 relies on the historical data that may not exist or not to the extent that is needed to give a good estimate.