Particularly for the COSMIC, the automation of the software functional size measurement is one of the top priorities. The automation will reduce the time and cost consuming and increase acceptance in the industry. Currently, most of the knowledge related to the automation using COSMIC is limited to academic research, and there are few commercial or semi-commercial tools. The automation in the new outline requirements could be very valuable; however, is the less explored. This paper presents an approach of the automation of the software functional size measurement through a facilitation tool that could be used in two moments: from the new outline requirements and once the requirements have been specified. The measurement results obtained using the facilitation tool, and the measurement realized manually by the experts were identical.
The paper considers the next structure; Section 2 summarizes the related work about software functional size measurement automation and validation. Section 3 presents the MENSURA tool in a brief mode. Section 4 describes the application of MENSURA in the reference case study, a subsection with the validity threat was include. In Section 5, a summary and the future work identified is describe.
In [3] the Functional user Requirements are defined as “A subset of the user requirements. Requirements that describe what the software shall do, in terms of tasks and services.”
Software functional size measurement methods work best when the information to be measured – the functional user requirements – is fully known. [4]
The SWEBOK [5] describes the Software Requirements Knowledge Area (KA), where the requirements process is defined. Fig. 1.
Considering the requirements process (Fig. 1), it is easy to note that there are several critical steps before the requirements specification stage is complete, impacting all phases of the software life-cycle as mention by Trudel et al. [6]
Even with the advance in research related to software requirements, in practice is still one of the significant problems, this is reflected in [7] where survey revealed that a third of the projects started were never completed, and one half of them succeeded only partially. Tiwari et al. [8] mention that "the reason behind such failure is poor requirement elicitation more precisely."
In the COSMIC Measurement Manual [9], the COSMIC concepts, principles, and rules to be applied for the measurement software functional size are defined. Like other FSMM, COSMIC [9] requires the functional requirements to be specified in a certain level of detail and quality, to be able to apply in a proper way.
Having several problems to solve in the requirements area, currently, no methodology of requirements is focusing in facilitating the measurement with some FSMM, generating a gap to be solved between requirements specification and the input required to apply an FSMM. 2.2
Because the automation of the software functional size measurement is one of the
top priorities for COSMIC, several measurement procedures and automation
approaches have been developed in the last years. [
There are several proposals of tools aiming to automate the software functional size measurement, a classification defined by Ungan et al. [1] group the tools based on the primary functionality they provide: data collection and calculation, expert systems for measuring (measurement facilitation), automated measurement (based on structured input or based on unstructured input). Most of the literature review about automation has been considered in the category “Automated Measurement”.
Another classification is proposed in this paper, based at the moment where the automation of the software functional size measurement is developed: 1. From early outline requirements, while requirements are eliciting and specified. It has not been deep researched yet and could be one of the most valuable moment. 2. From textual requirements, while the requirements are specified in free textual form. 3. From engineering artifacts, when the analysis of the requirements was made and a model with a specific notation is generated. There is little empirical evidence to support claims for the superiority of one notation over another [5]. 4. From the code, when the application is completed, after the software is finished.
From this classification, most of the literature review could be consider in the last three categories: “From text requirements”, “From engineering artifacts” and “From the code”, for all of them the assumption is that the requirements are fully defined in order to be measured as mention by [4].
This paper focuses on presenting some features of measurement facilitation from the tool called MENSURA®, that implements the automation of the software functional size measurement, comparing the results against a reference application [2]. 3 3.1
The use of software functional size in standard units like COSMIC, could be considered equivalent to the "specification" of requirements such as the assignment of numerical values usually standard measures in most engineering professions [8], but only for one part of the software requirements, the FUR’s.
The MENSURA Tool is a web-based application that includes several functionalities related to software like functional size measurement and approximation, software estimation, software project performance evaluation, and benchmarking. Most of the functionality is based on the COSMIC method, the tool also has a database for the Mexican industry, but any database could be loaded, the tool is currently in Spanish, in the MENSURA tool there is a module developed to perform the automation of the functional measurement based in the concepts depicted in Fig. 2.
The goal of the module for automation of software functional size in MENSURA is to find the way to include the concepts of the COSMIC since the beginning of the requirements process to the end of the project.
A distinction between what users and what user's needs are relevant, what users'
needs are related to the idea of specifying a system based on its interaction with the
environment, it was observe in [
The block of COSMIC Software Context Model is part inside the tool and part outside the tool, that represent the need for the people to use the MENSURA to know concepts about COSMIC with the idea described above, to translate the user need in COSMIC elements to allow to consider them in a transversal way. It also applies for the Generic Software Model (GSM), but this model is generated inside the tool.
Once the FUR’s are in terms of the GSM and represent what user's needs, the Measurement Engine executes the COSMIC measurement of the functionality, applying and validating the COSMIC rules [9], recording the software measurement in a database, the Report Engine works with the data recorded.
The output of the system are a formal Measurement Report, that is not only the software functional size, the report includes the purpose of the measurement, the Context Diagram, the list of Functional Process, Functional Users and the general software functional size with using a perspective of Data Movement type, and the detailed software functional size by Functional Process.
The FUR Report is also an output and is a FUR description at Functional Process level, using an interactive form, that defines how the software works in terms of tasks and services, that means, how the interaction between the system and the Functional User is realized. The specification of all the Functional Process is created identically for all the FUR’s, it solves the inconsistency about FUR’s specification.
To test the MENSURA tool, the FUR’s from a reference software was used, C-REG case study [2], the C-REG has nineteen 19 Functional Process with a 102 CFP. 4.1
The first catalog defined was the Actions catalog; this catalog stores the actions available to the Functional Users and for the System, the actions are verbs (usually a word) that the users very often uses to specify the FUR’s.
The actions defining the functionality of the software in terms of what users must do related to a specific Data Movement in COSMIC (E, X, W, R).
For a specific company, or area in a company, the business model is the same, so, the general Data Groups (very often used) could be defined in order to be available for all in a Data Group catalog, that helps to avoid inconsistency, and improve the understanding between technical areas and business areas. For the C-REG, for example, the student and other Data Groups were defined.
The Functional User catalog includes the functional users that send or receive information from the system, i.e. Payroll System, Mail System, Register, etc.
The Functional Process catalog registers the 19 Functional Process identified in CREG, in the context of the MENSURA tool, this catalog is also used to make approximations of the software functional size. 4.2
Once the data is stored in the catalogs, the description of the Functional Process could be made.
After selecting a specific Functional Process, the window to describe the interaction between Functional User and the software to be measured (Functional Process) is launched, the window is shown in Fig. 3.
In the window there are required fields that were related to the catalogs, the first field required is the Functional User/System, in this field is necessary to select from the catalog, who will make something, the next field is the Action that is selected from the catalog where is related to a specific Data Movement. The following field is the Data Group; the chosen data in the field is the entity (Data Group) which the Action will affect; there is a possibility to describe more than one (1) Data Group by action.
The field of description is optional and could be used to describe more the action, constraints or in general NFR. The next column is the option to eliminate each row for replacement.
After the Functional Process for the C-REG was captured in the tool, as is described below, the generation of the functional measurement was launched. The software functional size gathers with the MENSURA tool was equal to the reference C-REG case study (102 CFP), even the functional size by functional process is the same. However, the use of the tool, make the measurement faster, contributes avoiding mistakes because the use of catalogs, and helps to homologate the business concepts for a company. An additional benefit is avoiding inconsistency in requirements that increase software quality [6].
Also, the tool generates a comprehensive report about the measurement and a full formal measurement report including the purpose, and the scope, context diagram, and the features of the software to be measured. Additionally, a requirements specification report from all the Functional Process measured is generated.
The software functional measurement with the tool contributes to establishing a well-defined interaction between what users' needs and how the software will solve those tasks. This situation improves the definition of the functions that the software will execute, defining from the beginning the entities which will process or store information in the software and aligned to the COSMIC concepts, also homologating the way to specify the FURs. 4.3.1
From the application of the three-phase protocol [17], it is possible to observe that there is no difference in the final measurement results between manual and automated measurement procedure 4.4
This case study reflects the use of the MENSURA tool to measure a reference software (C-REG) that was measurement manually, to evaluate the application during elicitation of the requirements, several experimentations is currently developing.
To use the tool is recommended to have a little bit of knowledge of COSMIC concepts to introduce the data required, but there is no need to be an expert.
The tool only works for the FUR measurement and specification, the NFR could be stated, but could not be measured. 5
In this paper, the C-REG case study is used to evaluate the automation capabilities of the module of software measurement automation for the MENSURA tool, this tool integrates the COSMIC concepts and utilizes them for communicating what users need in terms that the developers could understand and allow to define specific units of size.
From the use of C-REG reference software, when the automation tool was applied, the results were the same as the manual measurement. Additional advantages like fast measurement, natural understanding of the FUR's for the users, the generation of a formal measurement report, and a requirements specification report, aiming to homologate this document in an organization, improving the requirements process.
Is pending for further work, the test with other case studies release by COSMIC, also the test with a real project in early phases, to really evaluate the possible contribution to the improvement of the requirements. A big scale test could be desirable to assess how the homologation is helping to define requirements.