9.30 Proposals for increasing benchmarking data quality of projects measured in COSMIC Luca Santillo (Agile Metrics, Italia), Harold van Heeringen (Sogeti Nederland B.V. Olanda)
- Introduction to benchmarking databases and institutions - Discussion of the COSMIC method framework - Introduction of the COSMIC Benchmarking Committee - Discussion of project attributes in benchmarking collection, especially regarding recent advances in the so-called measurement strategy
With the release of the COSMIC (Common Software Measurement International Consortium) measurement method version 3.0 in September 2007, the COSMIC FSM (Functional Size Measurement) method has reached a stable and mature status. Almost 10 years after its inception, COSMIC has proved itself to be a valuable functional sizing method for a broad range of different software types and domains, including business applications, telecommunication software, real-time systems, and hybrid of these, with any kind of logical architectural structure. Many organizations worldwide have already adopted the method, now known briefly as COSMIC Function Points, in their operations; still a significant lack of external benchmarking data is perceived in the industry. For instance, organizations that are measuring in COSMIC have less projects to benchmark themselves to, within the well-known ISBGS (International Software Benchmarking Standard Group) benchmarking database (currently at version 10), with respect to older generation measurement methods and measures, as IFPUG or NESMA Function Points. In this paper the COSMIC Benchmarking Committee, lead by the authors, will be introduced to the public and its goals and intents will be outlined. Topics covered in the paper are, among others, suggestions to improve the current ISBSG data collection questionnaire(s) for better usage, possibly higher data collection accuracy, and/or for compliance to the recently-issued topics of levels of decomposition and levels of granularity, and the possibilities to convert old generation measures (as IFPUG and COSMIC) to COSMIC measures for practical project benchmarking and estimation purposes.
10.00 Results from a Cocomo II-based productivity measurement. Lotte De Rore, Monique Snoeck (Leuven Institute for Research on Information Systems LIRIS, Department of Decision Sciences and Information Management, Faculty of Business and Economics, Belgio)
In this paper, we present the report we extracted from a year of measurements with the Cocomo II-model. Although only a limited amount of data was collected (22 projects), with this report we were able to provide useful information to management with respect to productivity improvement possibilities..
At the SMEF2006 conference, we presented our experiences with the set-up of a measurement environment using the Cocomo-II model for software development projects in a company in the banking and insurance area. The set-up was part of a larger research project on managing efficiency aspects of software factory systems. One year of measurements later, a database of 22 projects is obtained. In this paper we will present our conclusions and findings after these first measurement results. Despite of the small amount of data, a lot of useful information can be obtained. The effort multipliers in the Cocomo-II model represent the factors that have a linear influence on the amount of effort needed for a project. As such, they are a management instrument that gives an indication which parameters need attention within the company in order to improve the productivity. However, with the report defined in our previous paper (which sets out the different values of the effort multiplier against the productivity), no useful interpretations could be given in order to advice management. Therefore, a new report needed to be constructed. In the paper, we will discuss this new report in which the values of the effort multipliers can be identified as the slopes of the regression lines. The goal of the report is two folded. Firstly, one can check whether the factors identified by the Cocomo-II model as effort multipliers also have an influence on the effort and therefore on the productivity of a project in this company. And secondly, one can check whether the amount of influence identified by the Cocomo II model is comparable with the influence we detect in the company. In the paper we will elaborate on the reports obtained with our dataset after the first period of measurement. As we will show, even though there was only data available of one year of measurement, useful interpretations could already be given to the results as well as indications about which actions need to be taken in the company in order to improve the efficiency.
10.30 Performance calculation and estimation with QEST/LIME using ISBSG r10 data Luigi Buglione (Engineering.it, Italia), Alain Abran (ETS , Canada)
• To analyze with numbers why 'performance' is a wider concept than 'productivity' using your own historical data or - at the start of the process - external, well-referenced sources as the ISBSG repository • To stress the relevance in including more stakeholders' viewpoints than actual when taking decisions • To use multi-dimensional techniques for visualizing data for monitoring & control purposes
Traditional benchmarking models in Software Engineering are typically based on the concept of productivity, first defined as a single ratio of output to input, combined next to various cost factors leading to a single value. By contrast, the concept of performance is more comprehensive than productivity and can handle other dimensions such as quality. Multidimensional models, such as the QEST/LIME family of models, are therefore necessary to represents adequately performance. In software engineering, software process improvement models typically treat productivity and performance as two distinct concepts and at two distinct maturity levels and distinct process areas. This paper explores how information from a comprehensive measurement program can be used to analyze performance. The projects repository of the International Software Benchmarking Standards Group - ISBSG - is used as a case study to illustrate various aspects of the multi-dimensional QEST-LIME performance model.
This paper will explore how information from a comprehensive measurement program can be used to analyze performance. The information from the projects repository of the International Software Benchmarking Standards Group - ISBSG - will be used as a case study to illustrate various aspects of a performance model using industrial data. The Release 10 of the ISBSG which contains data more than 4,000 software projects will be used.
11.00 Coffee break 11.30 Un A model for Function Points measurement and productivity estimation of GIS systems. (D.P.O. - Data Processing Organization, Italia)
• To learn an approach for FP measurement in the context of a GIS application • To understand what elements to use in a method for estimating the productivity in the realization of GIS systems.
A geographic information system (GIS), also known as geographical information system or geospatial information system, is an information system for capturing, storing, analyzing and managing spatial data and associating to every geographic element one or more alphanumeric description (wikipedia). This kind of systems are used for studying and monitoring natural and anthropoid phenomena (overpopulation, pollution, air traffic and marine , etc...) taking into account the spatial component; the geographical information is used in order to take decisions and to execute simulations. In every field it is becoming more and more clear what are the benefits of managing geographical data in order to find solutions to several problems. For example, those data could be used for the management of events like the entrance of a ship in harbour, or the search of the path to catch up a mountain shelter. The GIS systems are meaningfully different from the traditional business software application (MIS), focused on the management of structured data that are collected and distributed mostly by mean of texts interfaces. The IFPUG functional sizing method (Function Point Analysis) doesn't find, therefore, an immediate application although it is capable to represent a consistent part of the size of a GIS software. It is essential, therefore, to carry out a mapping between IFPUG terminology and GIS terminology to the aim of characterizing and measuring appropriately the Base Functional Component (BFC) at the base of the functional measurement. This paper proposes criteria for being able to assign a functional value to GIS systems depending on its various elements and exploits real suggestions for being able to estimate productivity in the realization of GIS systems.
12.00 A real case of Function Points usage in the software asset evaluation for a company's branch acquisition Luciano Lucani, Franco Perna, Roberto Meli (D.P.O. - Data Processing Organization, Italia)
Participants will be faced with actual solutions to the following problems: • How to use Function Points in a software asset evaluation ? • How to derive an economical value for an already existing software application ? • How to use previous information in a formal negotiation ?
Software is essentially an immaterial asset and its evaluation is not a simple task, at all. Many approaches could be used for this and any one of them has its advantages and disadvantages.
This paper is intended to illustrate the activity of software asset evaluation for a real case of company's branch acquisition based on a "On Line Tribute system" in a public administration context, using the approach of the "replacement cost". The process of evaluation, according with this principle, responds basically to the question: "what would the cost of remaking the existing software as it is currently configured be if we restart from scratch and how long should we wait until it is available in operation?" The consulting activity was configured as an estimate of FP using the Early & Quick approach and deriving costs and time for a development project from scratch hypothetically run to yield a system "as it was" at the moment of evaluation without considering the costs "layered" related to maintenance that have occurred in time to set the asset as it currently was from a different starting point. Many development options were explored in order to simulate different scenarios and finally three of them were chosen to compare one to each other: internal development, external development and a mixed one. Quality and technical factors were considered in the model and a concept of "fitness for use" was adopted in order to guarantee the adequacy of the architectural characteristics to the customer requirements. Immediate availability was considered as an important value factor since the services couldn't be stopped to wait for a new system to be delivered. Development duration was transformed into economical value. The consultancy results were used in a negotiation process to establish a final value for the software asset and to conclude a deed of assignment.
12.30 13,00 Keynote Ton Dekkers - To be announced later
13.00 Closing |