Keywords

1 Introduction

In traditional methodologies, software project manager is having the opportunity to accept or reject changes. On the other hand agile methodologies, give high priority of accepting changes throughout Software Development Life Cycle (SDLC) as compared to the traditional methodology [1]. Mostly software failure reasons are due to the change of requirements. Software project’s success or failure depends upon the project manager that how he responds on these changes [2, 3]. Numerous studies have emphasized the significance of the software project manager role in a project’s success or failure especially in managing the changes in software projects. In software project management process the most common causes of project failure are estimation mistakes, ambiguous project goals, objectives and requirement changes during the project. A successful software project manager manages these changes and gives good reason for the change acceptance decisions [4, 5]. Likewise introducing software changes during software development phase, may need to identify the impact of these changes on software artifacts and estimates the required effort.

Software effort estimation is an important approach that helps software project manager in making an effective change approval decision. Software efforts estimation is the process of predicting the most accurate amount of effort required to develop or maintain software based on a large number of changing variables [3]. The estimation of required efforts for requirement changes can be done in many ways, some of them are: Expert Judgment [6], Estimation by Analogy [7], Impact Analysis [8], Source Lines of Code (SLOC) [9] and Function Point Analysis (FPA) [10]. It has been a continuous research because there are still many views and debates in getting an accurate effort estimation result. All techniques showed that they can be useful to estimate effort and cost of software, but not any of them every time provides an accurate estimation result [11].

The estimation of required efforts for the requirement changes can be calculated once the software size is measured. Software size can be measured by using different methods two of them are: SLOC and FPA. In SLOC the number of lines used for source instruction or coding are counted while FPA method is used for measuring the size and complexity of a software by calculating its functionality that system provides the user.

FPA method was introduced by Albert in 1970s. He wanted to develop a method for software size measurement that is independent of technology and can measure software size in early phases of SDLC as compared to SLOC, which can measure software size once the task of coding is completed [12].

Many studies highlighted the importance of FPA method for software effort estimation. FPA method estimates the efforts in the early phases of SDLC or for maintenance phase based on pre-defined requirements [10]. During software development phase software artifacts are in inconsistent states. Such as, some of the artifacts are fully developed, some are partially developed and some are not developed. Therefore it is a challenging task for software project managers to estimate the required efforts for a change request during software development phase [13].

In this paper we have used FPA method in a case study for requirement changes during software development phase. The outcome of this study has highlight the main issues of using FPA method for requirement changes during software development phase.

This paper covers following sections. Section 2 shows the related work, Sect. 3 shows the method that is used during the case study, Sect. 4 shows the evaluation of the study, Sect. 5 contains the discussion and finally Sect. 6 is the conclusion and future scope.

2 Related Work

There are two closely related keywords involved in this research namely: Software Effort Estimation and Function Point Analysis.

2.1 Software Effort Estimation

Software effort estimation is the method of predicting how much work and how many hours of work are needed for the completion of a software project. Software effort estimation results can be used in project plans, budgets, iteration plans, investment analysis, bidding rounds and risk management.

In the literature different categories of software effort estimation are discussed [14, 15]. while some of them are very famous and used widely i.e. Expert Judgement [16]; Estimation by Analogy [17, 18]; Function Point Analysis [19]; Regression Analysis [20]; and Model Based [21].

Expert judgement is a common method that is used till date. Most of the project managers select expert judgment effort estimation because of its flexibility and less complexity as compared to other formal methods. At present there is not a single effort estimation method that claims for 100% accurate results. Therefore expert judgement effort estimation is a good choice for software project managers [16].

Effort estimation through Analogy, uses the knowledge or information that is gained from previously developed projects of similar type. The idea behind analogy-based effort estimation is the prediction of required efforts for a specific project on the bases of the past information of similar projects. Perhaps due to simplicity and flexibility, analogy-based estimation is frequently used as hybrid model for combination with other approaches to increase its performance and accuracy such as, particle swarm optimization (PSO), grey relational analysis (GRA), outlier elimination technique, principle component analysis (PCA), regression and rough set theory [22].

In the early days, Source Lines of Code (SLOC) was used for the calculation of software size and efforts estimation in software projects. In this method the estimation can be performed by counting the source lines of code. Furthermore, it is only possible once the task of coding is completed. In addition, studies indicate that the significance of SLOC is reduced for larger scale of development projects and using of different programming languages create different values of estimation. Therefore using SLOC for getting accurate estimation results in software projects could be a challenge [18, 19]. Later on Allan Albrecht introduced Function Point Analysis (FPA) to solved the estimation problems faced during estimation by SLOC [23].

2.2 Function Point Analysis

Function Point Analysis FPA approach is developed by Allan Albrecht in 1979. FPA is the method of measuring size and complexity of software by calculating the functionality, that the system provides to its end user [23]. The main goals of FPA are: (1) To calculate the functionality that is provided to the end user. (2) To perform estimation that is independent of technology.

In FPA approach Function Points (FPs) of a software project are calculated by the number of transactions, file types, general system characteristics and their complexity. However several steps are required for the calculation of FPs [10, 24].

First, calculating Unadjusted Function Points (UFP) by adding Internal Logical Files ILF, External Interface Files EIF, External Output EO, External Input EI and External inquiries EQ with their complexity (low, medium, or high) [24].

Secondly, calculating Value Adjustment Factor VAF from fourteen General System Characteristics (GSC) [24]. A scale is used from 0 to 5 to rate the degree of influence for each GSC. Whereas, 0 = Not present or no Influence, 1 = Incidental influence, 2 = Moderate influence, 3 = Average influence, 4 = Significant influence and 5 = Strong influence throughout. Once the 14 GSCs have assigned values regarding to their degree of influence. The next step is the calculation of VAF shown in the Eq. 1 [24].

$$ {\text{VAF}}\text{ = }0.65 + \left[ {\left( {\sum\nolimits_{{{\text{i}} = 1}}^{\text{n}} {\text{Ci}} } \right)\text{ * }0.1} \right] $$
(1)

So after getting the VAF the final value of FPs can be calculated from the Eq. 2 [24].

$$ {\text{FPs}} = {\text{UFP}} * {\text{VAF}} $$
(2)

3 Evaluation

This section describes the method of evaluating our case study. During this process four main evaluation factors are considered. These factors are; (1) Case selection, (2) Evaluation metrics, (3) Data collection and analysis, and (4) Evaluation results.

3.1 Case Study

To verify FPA method for software requirement changes during software development phase. We have applied the method in one case study i.e. Payroll System (PS). PS is a software development project assigned to the postgraduate students of software engineering at Advance Informatics School (AIS), at University Teknologi Malaysia (UTM). We have used FPA method in four phases, whereas each phase is representing a different development progress state in software development life cycle as shown in the Table 1.

Table 1. Case studies
Full size table

3.2 Evaluation Metric

An evaluation metric has been used for evaluating the change effort prediction results produced by the software change effort estimation which is the Magnitude of Relative Error (MRE). It has calculated a rate of the relative errors in both cases of over-estimation or under-estimation as shown in equation.

$$ {\text{MRE}} = \frac{{\left[ {{\text{Actual Results}} - {\text{Estimated Results}}} \right]}}{\text{Actual Results}} $$

3.3 Data Collection and Analysis

During data collection the following items such as; (1) Change Request Form (2) System Integration Test Report (3) User Acceptance Test Report (4) Software Requirements and Software Design Document, (5) Source Code, and (6) Progress Report have been collected from case selection.

The data collection from the experiment have been analyzed based on the project ID, change request ID, change request type, estimated effort result, actual effort and the magnitude of the relative error (MRE) between the estimation effort and the actual effort for each change request.

In our case study i.e. Payroll System (PS). We have selected fifteen change requests (CR) in four phases with three Change Types (CTs) i.e. Addition, Modification, and Deletion during software development phase as shown in Table 2.

Table 2. Change requests
Full size table

4 Evaluation Results

Table 3 shows the experiment result of the selected case software project. The table indicates the effort estimation produced by the actual implementation effort and MRE value (percentage of discrepancy between estimated effort and actual implementation effort) sorted by the Project ID and Change Request ID. These all 15 change requests were introduced to the case selection software project during the software development phase.

Table 3. Experiment results
Full size table

5 Discussion

To review the results of our study we have come up with some issues while using FPA approach for estimating software size for change requests during software development phase. The main issues are: (1) tracking of change request in software artifacts and (2) the impact of change request on software artifacts.

5.1 Tracking of Change Request in Software Artifacts

In FPA approach there is no formal way of tracking the change requests in software artifacts. While during the implementation of change requests in the following case studies i.e. CS2, CS3 and CS4. We faced the issue of tracking the change request in software artifacts. We performed the traceability of change requests in software artifacts manually. The process of traceability in software artifacts was repeated for every change request and it was a time taking process. As we used it for small project but it will be very difficult if FPA approach uses for big software projects for requirements change during software development phase.

5.2 Impact of Change Requests on Software Artifact

The second issue faced during this study was the impact of change requests on software artifacts. While accepting or rejecting a change request it is necessary for software project manager to know the impact of that change request on software artifacts. Whereas FPA approach cannot predict the impact of change requests on software artifacts. So, it becomes critical for software mangers to accept or reject a change request while using FPA approach for requirements change during software development phase.

6 Conclusion and Future Work

This paper has presented a case study for software requirements change during software development phase using FPA. Generally, FPA approach uses in early stages of SDLC for the measurement of the functionalities that the system provides to its end users. While in this paper we used FPA approach during the software development phase when the software artifacts were in inconsistent states. As we used FPA during software development phase hence we have faced some issues during FPs count. The main issues were: (1) Tracking of a change request in software artifacts and (2) Impact of a change request on software artifacts. However, we used FPA approach during software development phase in the case study and it was only possible because the software we used as a case study was a small software and we tracked the change requests manually. While it is challenging to use FPA approach for requirement changes during software development phase. On the other hand, FPA approach can be applied if it is integrated with change impact analysis. So as a future work we recommend that the integration of FPA approach with change impact analysis can be useful for effort estimation during software development phase.