Functional Size Measurement methods -like the COSMIC methodare widely used but have two major shortcomings: they require a complete and detailed knowledge of user requirements and they are carried out via relatively expensive and lengthy processes. To tackle these issues, simplified measurement processes have been proposed that can be applied to requirements specifications even if they are incomplete or not very detailed. Since software requirements can be effectively modeled using languages like UML and the models increase their level of detail and completeness through the development lifecycle, our goal is to define the characteristics of progressively refined requirements models that support progressively more sophisticated and accurate measurement processes for functional software size. We consider the COSMIC method and three simplified measurement processes, and we show how they can be carried out, based on UML diagrams. Then, the accuracy of the measurement supported by each type of UML model is empirically tested, by analyzing the results obtained on a set of projects. Our analysis shows that it is possible to write progressively more detailed and complete user requirements UML models that provide the data required by simplified methods, which provide progressively more accurate values for functional size measures of the modeled software. Conclusions. Developers that use UML for requirements model can obtain an estimation of the application's functional size early on in the development process, when only a very simple UML model has been built for the application, and can get increasingly more accurate size estimates while the knowledge of the product increases and UML models are refined accordingly.
Functional Size Measurement (FSM) aims at providing a measure of functional user
requirements. User requirements can be expressed by using various notations,
including UML. It has been shown that the most popular FSM methods –namely, IFPUG
Function Points (FP) and COSMIC Function Points (CFP)– can be applied to
requirements written in UML, especially if the UML models have been written with
FSM in mind, so that all (and only) the information required by FSM methods is
suitably represented in the models [
UML models are collections of diagrams. While progressing in the development,
UML models become more and more complete and detailed and in general include an
increasing number of diagrams. This means that UML models convey an increasing
amount of information, which can be used for FSM [
The majority of simplified FSM methods address the simplification of Function Point Analysis, since the IFPUG process of measuring FP involves activities –such as the classification of transactions and data and the evaluation of the complexity of every transaction and logic data file– that require a relevant measurement effort, and can be carried out only when the specification of user requirements is fairly complete and detailed.
However, the process of measuring CFP (which is generally faster and less
expensive than FP measuring) may also need to be simplified so it can be carried out faster
and at a smaller cost than the official process required by the official counting manual
[
The availability of “simplified” measurement processes for CFP, which require descriptions of requirements at different levels of detail, and the fact that UML models evolve through the requirements elicitation phase by growing in completeness and details suggest the following research questions: RQ1.
RQ2.
RQ3.
During the requirements elicitation and specification phase, is it possible to write progressively more complete and detailed UML models that support progressively more accurate simplified CFP measurement methods? What is the accuracy of different simplified CFP measurement methods, i.e., how close are the estimated sizes they provide to the actual ones? Do simplified CFP measurement methods provide an accuracy level that increases with the amount of information required?
Note that we do not intend to address question RQ3 quantitatively. Rather, we look for a trade-off between the information elicitation effort required by a given size estimation method and the resulting estimate accuracy that can –subjectively– be considered reasonable.
To answer questions RQ1-RQ3, we measured a set of software applications via different simplified CFP measurement methods, using progressively more detailed and complete UML models; we obtained the values of the parameters on which the estimation methods are based and computed the estimated sizes and compared them with the sizes measured according to the COSMIC counting manual.
The remainder of the paper is organized as follows. Section 2 describes simplified measurement processes for COSMIC function points. Section 3 illustrates the UML models that support the simplified measurement processes. Section 4 illustrates the experimental analysis. Section 5 accounts for related work. Section 6 discusses the threats to the validity of the study, while Section 7 draws some conclusions and outlines future work. 2
The COSMIC FSM method requires that: 1. The functional processes of the application being measured be identified. 2. The data groups mentioned in the user requirements be identified. 3. For each functional process, the unique data movements involving each identified data group be counted. Data movements are classified into Entries and Exits (i.e., I/O movements) and Reads and Writes (to persistent storage). A data group is considered persistent if its value is stable between two consecutive functional process executions. 2.1
A first very rough simplification of the measurement process was proposed by
COSMIC [
It is reasonable to assume that the size in CFP increases with the number of data groups (#DG): the more data groups, the more opportunities for data movements. A simplified computation of CFP can thus be obtained via a model like the following: CFP = f(#FPr, #DG) (2) that is, a model that computes the estimated size by means of some formula (to be defined) applied to #FPr and #DG. This procedure is simpler than the “full” COSMIC counting process, as data movements do not need to be identified and classified. Besides, a conceptual model of the data involved in the application is usually built very early in the requirements modeling process; thus, its availability is generally an easily satisfied assumption.
Equation (2) could be derived via regression analysis, provided that historical data reporting both #FPr and #DG are available. 2.3
The two methods described above are based on measures (#FPr and #DG) that characterize the whole application. It is reasonable to expect that a more accurate estimate can be derived if information that characterizes each functional process individually – like the number of data groups involved in each functional process –is used. If the historical dataset includes such data, statistical analysis can yield models of type CFP = f( #FPr, AvDGperFPr) (3) where AvDGperFPr is the average number of data groups involved in each of the functional processes in the application to be measured. 3
In this section, we describe the UML models that are needed to support the simplified
approaches to CFP measurement described in Section 2. We also present the model
supporting the measure of CFP performed as described in the manual [
The UML models used for measurement are models of the functional user specifications. They do not contain any design element; on the contrary, only information that is relevant to the user and is directly related to user’s needs and requirements is allowed in models.
<<component>>
User <<component>>
System <<interface>>
User_interface +AddCustomer() +ChangeCustomerData() +DeleteCustomer() +Payment() +NewItem() +RetrieveItem() +NewPlace() +ChangePlaceData() +DeletePlace() +PrintCustomerItemList() +PrintBill() +PrintStoredItemList() +QueryCustomer() +QueryCustomerItems() +QueryPlace() +QueryStoredItems()
Fig. 3 illustrates a diagram providing the information needed to use equation (3). In the diagram, UML ports are used to precisely indicate which classes (i.e., data groups) are used in each functional process. To this end, sets of functional processes that use the same set of classes are grouped into a single interface. In Fig. 3, only the interfaces needed to add, change, and delete clients are shown. It can be noticed that grouping functional processes according to the used classes may lead to a rather large number of interfaces, which could decrease the readability of the diagram. This is true, but interfaces that are homogeneous with respect to the used classes not only allow for a quite precise estimation of size (see Section 4), but explicitly represent the logical relationship between interface elements and system data: this poses the basis for the identification of important traceability information when the design model is built.
An alternative to the model shown in Fig. 3 is a sequence diagram that shows only
the classes involved in the functional process (Fig. 4). In fact, the diagram represents a
specific functional process (AddCustomer) and the involved class instances. We can
see that AddCustomer uses two data groups: Customer and Message. This type of
diagram is convenient because it can be refined into the diagram described in Fig. 5,
which supports full-fledged COSMIC measurement.
To answer the questions defined in the Introduction, we modeled a set of software
applications and measured them. Then, we applied the simplified measurement
methods, obtaining size estimates that were finally compared with the measures obtained
via the standard COSMIC method [
The projects considered were sample projects provided by COSMIC to illustrate the counting process (5 projects), academic examples used in teaching (5 projects) and project management tools (one project).
The UML models were built by a PhD student following the methodology
described in [
In Table 1, “Avg#DGperFPr” is the average number of data groups involved in the project’s functional processes; “AvgDMperDGperFPr” is the average number of data movements per data group per functional process; “AvgFPrSize (DMperFPr) others” is the mean number of data movements per functional process, computed on all the other applications; “Avg#DGperFPr others” is the mean number of data groups per functional process, computed on all the other applications; “AvgCFP/#DG_others” is the mean number of data movements (i.e., size) per data group, computed on all other applications.
When estimating the size of an application using equation (1), we used the MDM of the other projects. The MDM is equivalent to the mean CFP/NumFPr, i.e., to the mean size of Functional processes. Using this model we got the estimates reported in Table 2. The obtained estimates are characterized by MMRE = 17.8%, Pred(25) = 72.7%, percentage error range = [-27.8%, 44.9%].
While analyzing the dataset, we discovered that the mean number of data movements per data group involved in a functional process, computed for each application, was fairly constant throughout the applications of our dataset: the mean is 1.88 and the standard deviation 0.29 (i.e., 15% of the mean). We exploit this fact to define the following model:
CFP = NumFPr × AvDGperFPr × AvDMperDGperFPr (4) where (AvDGperFPr × AvDMperDGperFPr) is an estimate of the number of data movements per functional process, i.e., an estimate of the mean size of functional P.Id 1 2 3 4 5 6 7 8 9 10 11 86 56 101 69 103 64 116 124 117 90 252 processes: multiplied by the number of functional processes it yields an estimate of the number of data movements, i.e., the size of the application.
By using this model, we obtained the estimates reported in Table 2 and
characterized by MMRE = 15.3%, Pred(25) = 81.8%, percentage error range [-15.3%, 33.9%].
Many techniques for early size estimation have been proposed for Function Points
(e.g., the Early and Quick Function Point by Conte et al. [
In [
Several authors studied the possibility of basing standard CFP measurement [
Hericko and Zivkovic address size estimation in iterative development [
A possible threat to internal validity is the limited number of projects in our sample.
The main threat to the external validity of the study may come from the projects chosen, which are a limited sample of a much larger population. However, this kind of threat is typical in most empirical software engineering studies. Also, the sample of projects is a “convenience” sample, i.e., it is made of projects that were selected because the data that we needed for our study were available. Note that, however, we are not interested here in specific models (e.g., we are not interested in the coefficients of the models), but, rather, in the performance of the techniques we propose. At any rate, it is not easy to assess the extent to which our results may apply in general.
There may be a threat to construct validity due to the use of MMRE, which has
been criticized in the past as an accuracy indicator [
One might also observe that only one of the projects used within this empirical study is a real implemented project, and that this fact could possibly decrease the reliability of the results or their generality. However, this is not actually a problem, for two reasons. One is that the requirements of all our projects were realistic: any of our projects could be implemented, thus requiring for size measurement, effort estimation, etc. The second is that we are interested in the comparison of measures obtained via simplified and full-fledged processes. Therefore, some characteristic requirements that affect the standard size measure are bound to affect in the same way the simplified measure, so that the results are hardly affected. 7
Simplified FSM methods are often used when a project manager needs an estimate of the functional size of the software application to be built before the requirement specification phase is completed, or when the cost or time allowed for measurement are limited. When UML is used in the early phases of development, it is convenient to apply simplified FSM methods to UML models. In this paper we showed that it is possible to build UML models that adequately support the application of simplified measurement methods and the standard COSMIC method. In particular, during the requirements specification phase, UML models grow in detail, thus providing the information required by progressively more accurate size estimation methods. In fact, it was possible to define quantitative size estimation models based on only the number of functional processes, or the number of functional processes and the number of data movements in each functional process.
To practitioners, our results provide an interesting hint: the information contained in the UML models illustrated in Section 3 is just the information required to document applications’ requirements properly; accordingly, in the requirements specification phase the analyst must indicate what data are involved in each functional process, and how they are used. Therefore, size estimates can be seen as ‘by products’ of the progressive refinement of UML requirements models.
The research presented in this paper has been partially funded by the project “Metodi, tecniche e strumenti per l’analisi, l’implementazione e la valutazione di sistemi software” funded by the Università degli Studi dell’Insubria and by “Progetto dote 2 programma UNIRE - accordo per lo sviluppo capitale umano nel sistema universitario lombardo”, co-funded by Regione Lombardia and Università degli Studi dell’Insubria.