Automated COSMIC Function Point measurement using a requirements engineering ontology

Highlights

• A requirements engineering ontology was designed in a telecommunications company setting.

• COSMIC Function Point concepts were also designed as a part of proposed ontology.

• A mapping was proposed between the concepts of requirements ontology and COSMIC Function Point.

• An automatic functional size measurement method and tool was designed and implemented.

• Experimental results show that method works correctly and eliminates effort and subjectivity coming from manual measurement.

Abstract

Context

There are two interrelated difficulties in requirements engineering processes. First, free-format modelling practices in requirements engineering activities may lead to low quality artefacts and productivity problems. Second, the COSMIC Function Point Method is not yet widespread in the software industry because applying measurement rules to imprecise and ambiguous textual requirements is difficult and requires additional human measurement effort. This challenge is common to all functional size measurement methods.

Objective

In this study, alternative solutions have been investigated to address these two difficulties. Information created during the requirements engineering process is formalized as an ontology that also becomes a convenient model for transforming requirements into COSMIC Function Point Method concepts.

Method

A method is proposed to automatically measure the functional size of software by using the designed ontology. The proposed method has been implemented as a software application and verified with real projects conducted within the ICT department of a leading telecommunications provider in Turkey.

Results

We demonstrated a novel method to measure the functional size of software in COSMIC FP automatically. It is based on a newly developed requirements engineering ontology. Our proposed method has several advantages over other methods explored in previous research.

Conclusion

Manual and automated measurement results are in agreement, and the tool is promising for the company under study and for the industry at large.

Introduction

In requirements engineering, elicitation, requirements analysis and solution analysis are the phases in which ambiguity is experienced intensively [1], [2]. In addition, through requirements engineering, project scope is widely determined, and all project stakeholders’ expectations are optimized [3].

In this study, two important dimensions of this uncertainty are addressed. One dimension of uncertainty involves the specification of requirements for the problem domain, and another involves measuring the functional size of project scope in the early phases of a project. Measurement should be performed in an unobtrusive, automated way as a side effect of the requirements analysis activity. A well-defined project scope is a good input for measurement, and a good evaluation of the scope to be measured reveals gaps in the requirements. These two issues are interdependent and affect each other positively [4]. In this manner, a project with the correct scope and a precise budget produces high quality results, on time [5].

Software is a complete formal specification of the solution for a requirement in the problem domain. Requirements engineering activities are expected to close the gap between stakeholders’ expectations and the formal software world. Therefore, formalization is essential for requirements engineering [3]. However, Carrillo De Gea et al. [6] have found that formal techniques have not been good enough to use in requirements engineering tools due to their natural language and text-oriented interfaces. Matulevicius [7] reports that industry still relies on office tools (text editors, drawing and modelling tools) in requirements engineering practices. Recently, in other research performed in the same telecommunications company as the one used in this study, similar results have been obtained. The results indicate that requirements engineers and developers expect more requirements formalization capabilities from requirements engineering tools [8]. As a result of this study, formalization is considered to be helpful by requirements engineers for improving quality validation, the reusability of information and impact analysis. Additionally, measuring functional size from structured requirements analysis documents is easier than measuring the functional size of free format or text requirements.

A Source Line of Code (SLOC) metric has two important disadvantages compared to Function Point based functional size measurement metrics. First, SLOC cannot be used in early software effort estimation because SLOC cannot be measured until implementation is completed. Second, SLOC depends on the actual design, programming practice and programming language used in the implementation. Thus, for the same functionality, different SLOC results can be obtained for different implementation preferences. Therefore, SLOC cannot be used as an economic productivity metric [9]. Contrastingly, a Function Point metric does not suffer from these drawbacks. Function Point metrics can be measured early in the requirements phase of a project, and they are independent of implementation. Although Function Point metrics provide a superior measure for size estimation and productivity, SLOC is still in wide use today [10]. This study reveals several reasons for the lack of adoption of Function Points within industry. SLOC metrics have the advantage of being easy to understand and to automate. Function Point based methods have some important disadvantages such as the cost of measurement and the difficulty of selecting a specific Function Point method among many variants [9], [11]. Thus, Function Point measurement methods will need to be automated if they are to become widespread within the software industry. Additionally, functional size measurement results are dependent on the measurers’ subjective interpretations and assumptions regarding the project scope and measurement methods used [12]. The automation of measurement processes will eliminate this important disadvantage as well. Currently, the functional size of a project's scope within the company under study is measured manually using the COSMIC Function Point methodology [13]. Bağrıyanık et al. [14] have found that 0.4% of overall project effort is consumed during manual measurement. Although measurement effort is relatively small, eliminating this effort and decreasing training needs surrounding such measurement would yield remarkable savings. Efforts to automate the functional size measurement of a project with tools, such as the one we propose, would also catalyse the widespread use of the COSMIC Function Point method and the roll out of software measurement programs within industry.

The contributions of this study are focused on the formalization of requirements using an ontology and on the automated measurement of the functional size of a project based on this model/ontology. Motivations for and issues addressed by this study are summarized as follows:

Motivations:

• There is a need to formalize requirements as described in the first paragraph of this section.

• Manual CFP measurement has some other important disadvantages such as the cost and accuracy of measurements as described in the previous paragraph.

Issues:

• Current requirements engineering ontologies are insufficient for our purposes because they do not satisfy some basic requirements such as covering telecommunications domain concepts and providing seamless CFP measurement. Detailed requirements will be given in Section 2.1.

• The current CFP measurement literature has some inadequacies regarding the measurement of software maintenance and levels of abstraction. These shortcomings are described in detail in Section 2.2.

The rest of the paper is organized as follows: background is given in the second section. The second section introduces previous studies that explore the use of requirements engineering ontologies and automation in functional size measurement. In the third section, our proposed requirements engineering ontology is explained. In the fourth section, the COSMIC Function Point transformation of this ontology and measurement procedure is detailed. The fifth section presents details with respect to automating the measurement procedure for the proposed ontology, and a validation method is presented. The sixth section discusses the research contributions and limitations of the study and is followed by conclusions and proposed future work.