Skip to main content

Roberto Meli

Followers

143

Following

21

Co-authors

5

Mentions

110

Public Views

Roberto Meli graduated with honors in Information Science in 1984. In 1996, he became the CEO of the company DPO. For 35 years, he has developed targeted skills in project management, software measurement, and cost estimation, and has written more than 100 papers in international contexts, participating in the technical tables of italian Public Administration for software measurement. He developed the Early & Quick FP approximation method, the Simple Function Point measurement method, and the VAMOS-R3 cost estimation method. In the last 30 years, he has been: coordinator of the board of directors of GUFPI-ISMA, coordinator of the COSMIC Measurement Practices Committee, and for 10 years chairman of the SMEF conferences (Software Measurement European Forum). He is currently a member of the board of IFPUG and GUFPI-ISMA. Since 2023, he has been the Director of Functional Measurement Standards at IFPUG.
Address: Roma

less

Interests

Uploads

Papers by Roberto Meli

On the applicability of COSMIC-FFP for measuring software throughout its life cycle

Software measurement plays a key role in software engineering and, to improve its performance, an... more Software measurement plays a key role in software engineering and, to improve its performance, an organisation needs to measure software at each stage of the development life cycle. Recently, the COSMIC-FFP measurement method has been developed to improve the measurement of the functional size of a large array of software types. By quantifying software's functional user requirements, the method makes it possible to measure software from the user's viewpoint. The COSMIC-FFP measurement method has been designed based on a software functional model that can represent the functional user requirements at many levels of functional abstraction, such as software layers, functional processes and data movement sub-processes. Developers in general, however, need to know the size of the software early in the development process to support the estimation and project planning process. While the measurement rules of the COSMIIC-FFP method have been designed to be applied when the details of the software functions are known, the method has the required flexibility to capture an estimate of the functional size of software early in the life cycle and to offer added value to the software engineers preparing the development plans. This paper investigates the applicability of COSMIC-FFP for measuring the size of software at early stages of the development life cycle.

Using Extremely Simplified Functional Size Measures for Effort Estimation

Background: Functional size measures of software are widely used for effort estimation, because t... more Background: Functional size measures of software are widely used for effort estimation, because they provide a fairly objective quantification of software size, which is one of the main factors affecting software development effort. Unfortunately, in some conditions, performing the standard Function Point Analysis process may be too long and expensive. Moreover, functional measures could be needed before functional requirements have been elicited completely and at the required detail level. Aim: Basing effort estimation on measures that are simpler than Function Points---hence, faster and cheaper to obtain---could be beneficial, if good estimation accuracy is possible. In this paper, the level of accuracy that can be obtained using simple measures instead of Function Points---as defined by IFPUG, the International Function Point User Group---is evaluated, based on an empirical study. Method: An analysis of the data provided in the ISBSG dataset was performed. Effort models based on standard IFPUG Function Points and on the number of transactions were derived. The accuracy of the effort estimates delivered by the two models were then compared. Results: Effort models based on the number of transactions appear marginally less accurate than models based on standard IFPUG Function Points for new development projects, and marginally more accurate for projects extending previously developed software. Conclusions: Based on the results of the empirical study, it seems that using the number of transactions instead of the standard IFPUG Function Points measures does not cause estimate accuracy to change to a practically appreciable extent. This conclusion applies to effort models using size measure as the only independent variable. Additional research is necessary to evaluate the performance of effort models based on the number of transactions in combination with other factors.

A study on the statistical convertibility of IFPUG Function Point, COSMIC Function Point and Simple Function Point

Information & Software Technology, Jun 1, 2017

Background Several functional size measurement methods have been proposed. A few ones-like IFPUG ... more Background Several functional size measurement methods have been proposed. A few ones-like IFPUG and COSMIC methods-are widely used, while others-like Simple Function Points method-are interesting new proposals, which promise to deliver functional size measures via a faster and cheaper measurement process. Objectives Since all functional size measurement methods address the measurement of the same property of software (namely, the size of functional specifications), it is expected that measures provided in a given measurement unit

How functional size measurement supports the balanced scorecard framework for ICT

Index-1. Introduction-2. The Balanced Scorecard (BSC)-2.1. The original method-2.2. ICT-tailored ... more Index-1. Introduction-2. The Balanced Scorecard (BSC)-2.1. The original method-2.2. ICT-tailored BSC-2.3. ICT BSC: an operationalisation issue-3. Functional Size Measurement (FSM)-3.1. Evolution of FSM-3.2. FSM and Technical Size Measurement (TSM)-3.3 Multiple uses of FSM in SI Os-4. Definition of FSM-based measures for ICT BSCs-5. Concluding remarks-References-Appendices

Productivity of Software Enhancement Projects: an Empirical Study

Background. Having a correct, although approximate, knowledge of software development productivit... more Background. Having a correct, although approximate, knowledge of software development productivity is clearly important. In some environments, the belief that software enhancement projects are characterized by higher productivity than new software development has emerged. Aim. We want to understand whether the mentioned belief is rooted on solid bases or is due to some cognitive biases. Method. An empirical study was performed, analyzing the data from a large dataset that collects data from real-life projects. Several statistical methods were used to evaluate the unitary cost (i.e., the cost per Function Point) of enhancement projects and new developments. Results. Our analyses show that-contrary to some popular beliefs-software enhancement costs more than new software development, at least for projects greater than 300 Function Points. Conclusions. Project managers and other stakeholders interested in the actual cost of software should reject ill-based evaluations that the productivity of software enhancement is greater than new software development. More generally, objective evaluations based on the analysis of representative data should be preferred to evaluations affected by cognitive biases.

Estimating Software Functional Size via Machine Learning

ACM Transactions on Software Engineering and Methodology

Measuring software functional size via standard Function Points Analysis (FPA) requires the avail... more Measuring software functional size via standard Function Points Analysis (FPA) requires the availability of fully specified requirements and specific competencies. Most of the time, the need to measure software functional size occurs well in advance with respect to these ideal conditions, under the lack of complete information or skilled experts. To work around the constraints of the official measurement process, several estimation methods for FPA have been proposed and are commonly used. Among these, the International Function Points User Group (IFPUG) has adopted the “High-level FPA” method (also known as the NESMA method). This method avoids weighting each data and transaction function by using fixed weights instead. Applying High-level FPA, or similar estimation methods, is faster and easier than carrying out the official measurement process but inevitably yields an approximation in the measures. In this article, we contribute to the problem of estimating software functional siz...

COSMIC FFP field trials aims, progress and interim findings

COSMIC must also recognise the size of COSMIC must also recognise the size of requirements for 'p... more

Developing Software for Mobile Devices: How to Do That Best

Including computers and applications into mobile devices creates a major break-through in the app... more Including computers and applications into mobile devices creates a major break-through in the applicability of computing systems and in the impact this had on users and even the society. While software development has always been costly and challenging, it is even more challenging for mobile devices. This raises the important question of how to best develop software for mobile devices. Keywords-mobile device; software development; user interface; Apps; testing.

COSMIC full function point method : 2004 - State of the Art

Jolijn Onvlee, Risto Nevalainen, Grant Rule, Denis St Pierre, Charles Symons

Measuring the functional size of software was proposed by Albrecht, more than 20 years ago, as a ... more Measuring the functional size of software was proposed by Albrecht, more than 20 years ago, as a solution to the limitations of lines of code (SLOC) when quantifying the output of the software engineering process. While this approach has been, and still is, successful when applied to MIS type of software, it has not enjoyed the same success for measuring the size of non MIS software, as demonstrated in publications from a number of authors in the past 15 years. Three types of approach have been proposed in the literature to apply Albrecht's concepts to non MIS types of software. Although some of these approaches offered interesting insights, none has gained sufficiently wide usage to be recognized as a de facto standard.

Abstract 1 Functional Metrics: Problems and Possible Solutions

gaining dominance over "technological " type metrics (Lines of Code). Although this tak... more gaining dominance over "technological " type metrics (Lines of Code). Although this takes place quite rapidly from the "cultural " standpoint, on a practical level the process is much slower due to the large quantity of code measurements already present in any company, and given the scepticism with which functional metrics are received in some technical environments. The advantages of the first approach over the second one are, by now, well known. There are, indeed, some problems regarding functional metrics that need to be addressed by the technical community. This paper aims to highlight the major drawbacks of IFPUG Function Point metrics and discuss some possible solutions.

Early & Quick Function Point Method An empirical validation experiment

The "Early & Quick Function Points Approach (E&QFPA)" is a mean to approximate the resu... more The "Early & Quick Function Points Approach (E&QFPA)" is a mean to approximate the results of some standard Functional Size Measurement Methods like IFPUG, SiFP or COSMIC. E&QFPA is a set of concepts and procedures that, even when applied to non-detailed functional specifications of a software system, maintains the overall structure and the essential principles of standard functional size measurement methods. The E&QFPA combines different estimation approaches in order to provide better approximations of a software system functional size: it makes use of both analogical and analytical classification of function types (transactions and data). Moreover, it allows the use of different levels of detail for different branches of the system (multilevel approach). This paper illustrates the basic concepts of the method which is mature and well established in the Italian market, as well as the results of an empirical validation experiment conducted on a real business data set of I...

The ICT Measurement System Definition, components and a maturity evaluation approach

The measurement of ICT (Information & Communication Technologies) processes and related products ... more The measurement of ICT (Information & Communication Technologies) processes and related products / services is often experienced, by the organizations which make them for themselves or for the market, as a too expensive activity that slows down the primary production activities. Nevertheless, the "measurement of ICT" can give a strong support to its governance. Rarely measurement is perceived as an opportunity, most often as a threat. Many measurement initiatives, in the past, were not successful in becoming stable frameworks for supporting software processes. A formalized ICT-Measurement System (ICT-MS) can facilitate to position the "seemingly expensive" measurement activities in the context of corporate governance which, at least, makes them more justified, productive and interesting for the management and for the other involved stakeholders. An ICT-MS is a governance tool for both the contractual relations between customers and suppliers and the internal prod...

Function Point Estimation Methods: A Comparative Overview

The appearance of the Function Point technique has allowed the ICT community to increase signific... more The appearance of the Function Point technique has allowed the ICT community to increase significantly the practice of software measurement, with respect to the use of the traditional "Lines of Code approach". A FP count, however, requires a complete and detailed level of descriptive documentation, like the Functional Specifications of the software system under measurement, to be performed. There are at least two situations in which having an estimation method, compatible but alternative to the standard rules for FP, could be decisive. The first case occurs when the development or enhancement project is in such an early phase that it is simply not possible to perform a FP count according to the IFPUG standards (i.e. in the Feasibility Study). The second case occurs when an evaluation of the existing software asset is needed, but the necessary documentation or the required time and resources to perform a detailed FP calculation are not available. Based on these and other an...

Early and Extended Function Point: a new method for Function Points estimation

As a consequence of the wider use of the Function Point metrics in the software management field ... more As a consequence of the wider use of the Function Point metrics in the software management field there is an increasing need for methods to estimate in an early stage of the software life cycle the number of Function Points related to a software application. The present paper describes a new technique to estimate Function Points (Early and Extended Function Points Method) and some experiences of its utilization. The application of the method allows to obtain two different measurements: Early Function Points (EFP) and Extended Function Points (XFP). Early Function Points are not a measurement alternative to IFPUG 4.0 Function Points, but only a fast estimate of the same. Therefore, no conversion factors are required between the two measures. The number of EFP should approximate the number of IFPUG 4.0 FP when both are calculated on the same user requirements. Extended Function Points derive from EFP after the application of two corrective factors relative to software reuse and algori...

Rischi, requisiti e stima di un progetto software

Lo scopo di questo lavoro e quello di fornire un contributo pratico a coloro che sono interessati... more Lo scopo di questo lavoro e quello di fornire un contributo pratico a coloro che sono interessati a perseguire il successo di un progetto software, attraverso la riduzione consapevole e metodica dei principali rischi ad esso associati. Un rischio, per un progetto, puo essere immaginato come la eventualita di non riuscire a raggiungere uno o piu degli obiettivi specificati e concordati per esso, con i conseguenti danni che ne derivano. Tipiche aree di risultati attesi sono quelle dei requisiti funzionali, della qualita del prodotto, dell'impegno lavorativo, della durata e costo del progetto di sviluppo o manutenzione evolutiva. Una sistematica revisione delle reali motivazioni di fallimento dei progetti, mostra che la scarsa definizione degli obiettivi e la inadeguata allocazione delle risorse sono due tra i fattori piu significativi in grado di influenzare negativamente il risultato progettuale. Per questo motivo, gestire i requisiti utente e stimare le risorse necessarie al pro...

Productivity of Software Enhancement Projects: an Empirical Study

Background. Having a correct, although approximate, knowledge of software development productivit... more Background. Having a correct, although approximate, knowledge of software development productivity is clearly important. In some environments, the belief that software enhancement projects are characterized by higher productivity than new software development has emerged. Aim. We want to understand whether the mentioned belief is rooted on solid bases or is due to some cognitive biases. Method. An empirical study was performed, analyzing the data from a large dataset that collects data from real-life projects. Several statistical methods were used to evaluate the unitary cost (i.e., the cost per Function Point) of enhancement projects and new developments. Results. Our analyses show that–contrary to some popular beliefs–software enhancement costs more than new software development, at least for projects greater than 300 Function Points. Conclusions. Project managers and other stakeholders interested in the actual cost of software should reject ill-based evaluations that the producti...

How functional size measurement supports the balanced scorecard framework for ICT

The Balanced Scorecard (BSC) represents one of the performance management frameworks adopted with... more The Balanced Scorecard (BSC) represents one of the performance management frameworks adopted with great success in business circles in recent years. One of its most valuable strengths is its linkage of the strategic and operational levels, through a quantitative and qualitative management using a series of indicators from four different perspectives: Financial, Customer, Internal Process, Learning & Growth. The success of this framework in the business world has led to some tailored extensions in the ICT world, with a few examples developed in the second half of the '90s. A key issue that needs to be addressed in the design and implementation of a BSC for ICT companies is measurement of the software itself. To build a BSC, once the overall strategic direction has been identified, Goals, Drivers and Indicators (GDI elements) must be selected for each perspective. Even though significant attention has already been paid to the first two elements (Goals and Drivers), the last (Indic...

Functional Metrics: Problems and Possible Solutions

Functional metrics (especially IFPUG Function Point and Mark II Function Point) are gaining domin... more Functional metrics (especially IFPUG Function Point and Mark II Function Point) are gaining dominance over "technological" type metrics (Lines of Code). Although this takes place quite rapidly from the "cultural" standpoint, on a practical level the process is much slower due to the large quantity of code measurements already present in any company, and given the scepticism with which functional metrics are received in some technical environments. The advantages of the first approach over the second one are, by now, well known. There are, indeed, some problems regarding functional metrics that need to be addressed by the technical community. This paper aims to highlight the major drawbacks of IFPUG Function Point metrics and discuss some possible solutions.

On the applicability of COSMIC-FFP for measuring software throughout its life cycle

Software measurement plays a key role in software engineering and, to improve its performance, an... more Software measurement plays a key role in software engineering and, to improve its performance, an organisation needs to measure software at each stage of the development life cycle. Recently, the COSMIC-FFP measurement method has been developed to improve the measurement of the functional size of a large array of software types. By quantifying software’s functional user requirements, the method makes it possible to measure software from the user’s viewpoint. The COSMIC-FFP measurement method has been designed based on a software functional model that can represent the functional user requirements at many levels of functional abstraction, such as software layers, functional processes and data movement sub-processes. Developers in general, however, need to know the size of the software early in the development process to support the estimation and project planning process. While the measurement rules of the COSMIIC-FFP method have been designed to be applied when the details of the so...

On the applicability of COSMIC-FFP for measuring software throughout its life cycle

Software measurement plays a key role in software engineering and, to improve its performance, an... more Software measurement plays a key role in software engineering and, to improve its performance, an organisation needs to measure software at each stage of the development life cycle. Recently, the COSMIC-FFP measurement method has been developed to improve the measurement of the functional size of a large array of software types. By quantifying software's functional user requirements, the method makes it possible to measure software from the user's viewpoint. The COSMIC-FFP measurement method has been designed based on a software functional model that can represent the functional user requirements at many levels of functional abstraction, such as software layers, functional processes and data movement sub-processes. Developers in general, however, need to know the size of the software early in the development process to support the estimation and project planning process. While the measurement rules of the COSMIIC-FFP method have been designed to be applied when the details of the software functions are known, the method has the required flexibility to capture an estimate of the functional size of software early in the life cycle and to offer added value to the software engineers preparing the development plans. This paper investigates the applicability of COSMIC-FFP for measuring the size of software at early stages of the development life cycle.

Using Extremely Simplified Functional Size Measures for Effort Estimation

Background: Functional size measures of software are widely used for effort estimation, because t... more Background: Functional size measures of software are widely used for effort estimation, because they provide a fairly objective quantification of software size, which is one of the main factors affecting software development effort. Unfortunately, in some conditions, performing the standard Function Point Analysis process may be too long and expensive. Moreover, functional measures could be needed before functional requirements have been elicited completely and at the required detail level. Aim: Basing effort estimation on measures that are simpler than Function Points---hence, faster and cheaper to obtain---could be beneficial, if good estimation accuracy is possible. In this paper, the level of accuracy that can be obtained using simple measures instead of Function Points---as defined by IFPUG, the International Function Point User Group---is evaluated, based on an empirical study. Method: An analysis of the data provided in the ISBSG dataset was performed. Effort models based on standard IFPUG Function Points and on the number of transactions were derived. The accuracy of the effort estimates delivered by the two models were then compared. Results: Effort models based on the number of transactions appear marginally less accurate than models based on standard IFPUG Function Points for new development projects, and marginally more accurate for projects extending previously developed software. Conclusions: Based on the results of the empirical study, it seems that using the number of transactions instead of the standard IFPUG Function Points measures does not cause estimate accuracy to change to a practically appreciable extent. This conclusion applies to effort models using size measure as the only independent variable. Additional research is necessary to evaluate the performance of effort models based on the number of transactions in combination with other factors.

A study on the statistical convertibility of IFPUG Function Point, COSMIC Function Point and Simple Function Point

Information & Software Technology, Jun 1, 2017

Background Several functional size measurement methods have been proposed. A few ones-like IFPUG ... more Background Several functional size measurement methods have been proposed. A few ones-like IFPUG and COSMIC methods-are widely used, while others-like Simple Function Points method-are interesting new proposals, which promise to deliver functional size measures via a faster and cheaper measurement process. Objectives Since all functional size measurement methods address the measurement of the same property of software (namely, the size of functional specifications), it is expected that measures provided in a given measurement unit

How functional size measurement supports the balanced scorecard framework for ICT

Index-1. Introduction-2. The Balanced Scorecard (BSC)-2.1. The original method-2.2. ICT-tailored ... more Index-1. Introduction-2. The Balanced Scorecard (BSC)-2.1. The original method-2.2. ICT-tailored BSC-2.3. ICT BSC: an operationalisation issue-3. Functional Size Measurement (FSM)-3.1. Evolution of FSM-3.2. FSM and Technical Size Measurement (TSM)-3.3 Multiple uses of FSM in SI Os-4. Definition of FSM-based measures for ICT BSCs-5. Concluding remarks-References-Appendices

Productivity of Software Enhancement Projects: an Empirical Study

Background. Having a correct, although approximate, knowledge of software development productivit... more Background. Having a correct, although approximate, knowledge of software development productivity is clearly important. In some environments, the belief that software enhancement projects are characterized by higher productivity than new software development has emerged. Aim. We want to understand whether the mentioned belief is rooted on solid bases or is due to some cognitive biases. Method. An empirical study was performed, analyzing the data from a large dataset that collects data from real-life projects. Several statistical methods were used to evaluate the unitary cost (i.e., the cost per Function Point) of enhancement projects and new developments. Results. Our analyses show that-contrary to some popular beliefs-software enhancement costs more than new software development, at least for projects greater than 300 Function Points. Conclusions. Project managers and other stakeholders interested in the actual cost of software should reject ill-based evaluations that the productivity of software enhancement is greater than new software development. More generally, objective evaluations based on the analysis of representative data should be preferred to evaluations affected by cognitive biases.

Estimating Software Functional Size via Machine Learning

ACM Transactions on Software Engineering and Methodology

Measuring software functional size via standard Function Points Analysis (FPA) requires the avail... more Measuring software functional size via standard Function Points Analysis (FPA) requires the availability of fully specified requirements and specific competencies. Most of the time, the need to measure software functional size occurs well in advance with respect to these ideal conditions, under the lack of complete information or skilled experts. To work around the constraints of the official measurement process, several estimation methods for FPA have been proposed and are commonly used. Among these, the International Function Points User Group (IFPUG) has adopted the “High-level FPA” method (also known as the NESMA method). This method avoids weighting each data and transaction function by using fixed weights instead. Applying High-level FPA, or similar estimation methods, is faster and easier than carrying out the official measurement process but inevitably yields an approximation in the measures. In this article, we contribute to the problem of estimating software functional siz...

COSMIC FFP field trials aims, progress and interim findings

COSMIC must also recognise the size of COSMIC must also recognise the size of requirements for 'p... more

Developing Software for Mobile Devices: How to Do That Best

Including computers and applications into mobile devices creates a major break-through in the app... more Including computers and applications into mobile devices creates a major break-through in the applicability of computing systems and in the impact this had on users and even the society. While software development has always been costly and challenging, it is even more challenging for mobile devices. This raises the important question of how to best develop software for mobile devices. Keywords-mobile device; software development; user interface; Apps; testing.

COSMIC full function point method : 2004 - State of the Art

Jolijn Onvlee, Risto Nevalainen, Grant Rule, Denis St Pierre, Charles Symons

Measuring the functional size of software was proposed by Albrecht, more than 20 years ago, as a ... more Measuring the functional size of software was proposed by Albrecht, more than 20 years ago, as a solution to the limitations of lines of code (SLOC) when quantifying the output of the software engineering process. While this approach has been, and still is, successful when applied to MIS type of software, it has not enjoyed the same success for measuring the size of non MIS software, as demonstrated in publications from a number of authors in the past 15 years. Three types of approach have been proposed in the literature to apply Albrecht's concepts to non MIS types of software. Although some of these approaches offered interesting insights, none has gained sufficiently wide usage to be recognized as a de facto standard.

Abstract 1 Functional Metrics: Problems and Possible Solutions

gaining dominance over "technological " type metrics (Lines of Code). Although this tak... more gaining dominance over "technological " type metrics (Lines of Code). Although this takes place quite rapidly from the "cultural " standpoint, on a practical level the process is much slower due to the large quantity of code measurements already present in any company, and given the scepticism with which functional metrics are received in some technical environments. The advantages of the first approach over the second one are, by now, well known. There are, indeed, some problems regarding functional metrics that need to be addressed by the technical community. This paper aims to highlight the major drawbacks of IFPUG Function Point metrics and discuss some possible solutions.

Early & Quick Function Point Method An empirical validation experiment

The "Early & Quick Function Points Approach (E&QFPA)" is a mean to approximate the resu... more The "Early & Quick Function Points Approach (E&QFPA)" is a mean to approximate the results of some standard Functional Size Measurement Methods like IFPUG, SiFP or COSMIC. E&QFPA is a set of concepts and procedures that, even when applied to non-detailed functional specifications of a software system, maintains the overall structure and the essential principles of standard functional size measurement methods. The E&QFPA combines different estimation approaches in order to provide better approximations of a software system functional size: it makes use of both analogical and analytical classification of function types (transactions and data). Moreover, it allows the use of different levels of detail for different branches of the system (multilevel approach). This paper illustrates the basic concepts of the method which is mature and well established in the Italian market, as well as the results of an empirical validation experiment conducted on a real business data set of I...

The ICT Measurement System Definition, components and a maturity evaluation approach

The measurement of ICT (Information & Communication Technologies) processes and related products ... more The measurement of ICT (Information & Communication Technologies) processes and related products / services is often experienced, by the organizations which make them for themselves or for the market, as a too expensive activity that slows down the primary production activities. Nevertheless, the "measurement of ICT" can give a strong support to its governance. Rarely measurement is perceived as an opportunity, most often as a threat. Many measurement initiatives, in the past, were not successful in becoming stable frameworks for supporting software processes. A formalized ICT-Measurement System (ICT-MS) can facilitate to position the "seemingly expensive" measurement activities in the context of corporate governance which, at least, makes them more justified, productive and interesting for the management and for the other involved stakeholders. An ICT-MS is a governance tool for both the contractual relations between customers and suppliers and the internal prod...

Function Point Estimation Methods: A Comparative Overview

The appearance of the Function Point technique has allowed the ICT community to increase signific... more The appearance of the Function Point technique has allowed the ICT community to increase significantly the practice of software measurement, with respect to the use of the traditional "Lines of Code approach". A FP count, however, requires a complete and detailed level of descriptive documentation, like the Functional Specifications of the software system under measurement, to be performed. There are at least two situations in which having an estimation method, compatible but alternative to the standard rules for FP, could be decisive. The first case occurs when the development or enhancement project is in such an early phase that it is simply not possible to perform a FP count according to the IFPUG standards (i.e. in the Feasibility Study). The second case occurs when an evaluation of the existing software asset is needed, but the necessary documentation or the required time and resources to perform a detailed FP calculation are not available. Based on these and other an...

Early and Extended Function Point: a new method for Function Points estimation

As a consequence of the wider use of the Function Point metrics in the software management field ... more As a consequence of the wider use of the Function Point metrics in the software management field there is an increasing need for methods to estimate in an early stage of the software life cycle the number of Function Points related to a software application. The present paper describes a new technique to estimate Function Points (Early and Extended Function Points Method) and some experiences of its utilization. The application of the method allows to obtain two different measurements: Early Function Points (EFP) and Extended Function Points (XFP). Early Function Points are not a measurement alternative to IFPUG 4.0 Function Points, but only a fast estimate of the same. Therefore, no conversion factors are required between the two measures. The number of EFP should approximate the number of IFPUG 4.0 FP when both are calculated on the same user requirements. Extended Function Points derive from EFP after the application of two corrective factors relative to software reuse and algori...

Rischi, requisiti e stima di un progetto software

Lo scopo di questo lavoro e quello di fornire un contributo pratico a coloro che sono interessati... more Lo scopo di questo lavoro e quello di fornire un contributo pratico a coloro che sono interessati a perseguire il successo di un progetto software, attraverso la riduzione consapevole e metodica dei principali rischi ad esso associati. Un rischio, per un progetto, puo essere immaginato come la eventualita di non riuscire a raggiungere uno o piu degli obiettivi specificati e concordati per esso, con i conseguenti danni che ne derivano. Tipiche aree di risultati attesi sono quelle dei requisiti funzionali, della qualita del prodotto, dell'impegno lavorativo, della durata e costo del progetto di sviluppo o manutenzione evolutiva. Una sistematica revisione delle reali motivazioni di fallimento dei progetti, mostra che la scarsa definizione degli obiettivi e la inadeguata allocazione delle risorse sono due tra i fattori piu significativi in grado di influenzare negativamente il risultato progettuale. Per questo motivo, gestire i requisiti utente e stimare le risorse necessarie al pro...

Productivity of Software Enhancement Projects: an Empirical Study

Background. Having a correct, although approximate, knowledge of software development productivit... more Background. Having a correct, although approximate, knowledge of software development productivity is clearly important. In some environments, the belief that software enhancement projects are characterized by higher productivity than new software development has emerged. Aim. We want to understand whether the mentioned belief is rooted on solid bases or is due to some cognitive biases. Method. An empirical study was performed, analyzing the data from a large dataset that collects data from real-life projects. Several statistical methods were used to evaluate the unitary cost (i.e., the cost per Function Point) of enhancement projects and new developments. Results. Our analyses show that–contrary to some popular beliefs–software enhancement costs more than new software development, at least for projects greater than 300 Function Points. Conclusions. Project managers and other stakeholders interested in the actual cost of software should reject ill-based evaluations that the producti...

How functional size measurement supports the balanced scorecard framework for ICT

The Balanced Scorecard (BSC) represents one of the performance management frameworks adopted with... more The Balanced Scorecard (BSC) represents one of the performance management frameworks adopted with great success in business circles in recent years. One of its most valuable strengths is its linkage of the strategic and operational levels, through a quantitative and qualitative management using a series of indicators from four different perspectives: Financial, Customer, Internal Process, Learning & Growth. The success of this framework in the business world has led to some tailored extensions in the ICT world, with a few examples developed in the second half of the '90s. A key issue that needs to be addressed in the design and implementation of a BSC for ICT companies is measurement of the software itself. To build a BSC, once the overall strategic direction has been identified, Goals, Drivers and Indicators (GDI elements) must be selected for each perspective. Even though significant attention has already been paid to the first two elements (Goals and Drivers), the last (Indic...

Functional Metrics: Problems and Possible Solutions

Functional metrics (especially IFPUG Function Point and Mark II Function Point) are gaining domin... more Functional metrics (especially IFPUG Function Point and Mark II Function Point) are gaining dominance over "technological" type metrics (Lines of Code). Although this takes place quite rapidly from the "cultural" standpoint, on a practical level the process is much slower due to the large quantity of code measurements already present in any company, and given the scepticism with which functional metrics are received in some technical environments. The advantages of the first approach over the second one are, by now, well known. There are, indeed, some problems regarding functional metrics that need to be addressed by the technical community. This paper aims to highlight the major drawbacks of IFPUG Function Point metrics and discuss some possible solutions.

On the applicability of COSMIC-FFP for measuring software throughout its life cycle

Software measurement plays a key role in software engineering and, to improve its performance, an... more Software measurement plays a key role in software engineering and, to improve its performance, an organisation needs to measure software at each stage of the development life cycle. Recently, the COSMIC-FFP measurement method has been developed to improve the measurement of the functional size of a large array of software types. By quantifying software’s functional user requirements, the method makes it possible to measure software from the user’s viewpoint. The COSMIC-FFP measurement method has been designed based on a software functional model that can represent the functional user requirements at many levels of functional abstraction, such as software layers, functional processes and data movement sub-processes. Developers in general, however, need to know the size of the software early in the development process to support the estimation and project planning process. While the measurement rules of the COSMIIC-FFP method have been designed to be applied when the details of the so...