9.15 Why use Function point in a contract?Why to use Function Point in a contract? Simple: for reducing litigations but…not only!
Gianfranco Lanza (Csi Piemonte, Italy)
Since from the antiquity, in a relationship Customer-Supplier, there has been a negotiation to establish the value of goods. The negotiation is, in many countries (for example the arabian countries), a matter of culture. In the ICT world the negotiation between a customer and his suppliers is, very often, cause of litigations: the result is that the customer has not the good he desires and the supplier has not the profit he desires.
One reason is, undoubtedly, the difficulty to evaluate the amount of software that the supplier has to develop according to the customer requirements.
So, how can the software metrics help us? Can the use of function point resolve any problems?
Which are the steps that a customer and a supplier have to do for a proper use of the software metrics?
This presentation will try to answer these questions trough real experiences done in CSI Piemonte.
In the ICT World, especially in supplies of services for the Public Administration, there is the need of transparency and objectivity in order to know how to improve effectiveness and efficiency; the use of software metrics can be the key to reach these goals.
The main requirement is that both the customer and the supplier have to know what exactly the function point measures, which type of function point to choose, the significance of price for function point, how to apply dimensional metrics in different contests and moments, etc.: in other words they must have the same level of culture.
That’s not an easy task: this presentation highlights which are the things to do to obtain a valid use of function point in a contract to better regulate the relationship between customer and supplier.
9.50 Rational pricing of business sw systems on the basis of FSM
Beata Czarnacka-Chrobot (Warsaw School of Economics, Poland)
In the practice of Business Software Systems (BSS) Development and Enhancement Projects (D&EP) execution in Poland there are two types of client-provider contracts that decidedly dominate at the moment, namely: fixed price contract and time and material contract. Both approaches promote exceeding of the costs designed for purchasing product meeting client’s requirements. Thus ex ante as well as ex post pricing of the BSS dedicated to the client’s needs should be based on its size: required size in the case of ex ante pricing and actually delivered size in the case of ex post pricing. Consequently, work costs per unit should be related to the product size unit and not to the time unit – this is what makes pricing have objective and reliable character. It requires the appropriate measure of software size to be implemented, which may be acquired on the basis of the software Functional Size Measurement (FSM) concept, having been recently normalized by the ISO/IEC. This paper presents the simplified case study proving the possibility of rational ex ante and ex post BSS pricing carried out on the basis of FSM for a dedicated system being developed for the needs of Polish affiliated sales department of international motor concern, as well as the main conclusions coming from this study. The paper aims at presenting general connections between the FSM and economic aspects by using the example showing BSS development project cost savings, which may contribute to better understanding of the FSM importance by business managers and thus to the reduction of the gap between BSS providers and clients.
10.25 Request For Proposal Management
H.S. van Heeringen (Sogeti, Netherland)
Worldwide, many Requests for proposals (RFP’s) are send out every day to even more potential suppliers. In modern RFP’s, clients are trying to gather objective criteria, with which they can analyze and evaluate bids from different suppliers. However, the questions asked in these RFP’s are often hard to answer for immature organizations, but sometimes even harder to answer by more mature organizations.
Sogeti Nederland B.V., a large IT software supplier in the Netherlands, is often struggling to answer RFP questions like:
- What is your productivity rate for .Net projects?
- What is your standard duration for a project of 1.000 function points?
- What is your price per function point for a Java project?
Of course, these questions seem like good questions, but in fact these questions are ‘un-answerable’. We believe that there is no such thing as a standard productivity rate, but that there are a number of factors, like duration, size and complexity, that together lead to a realistic productivity rate. We could answer a question like: ‘What is your productivity rate for a moderately complex java project of 500 function points and a duration (low-level design – acceptance test) of 20 weeks?”. However, these are not the questions that are asked in RFP’s, so we have to improvise.
This also means that in the software industry, quotations of suppliers are often not realistic. Client organizations should become aware of the questions they should ask in RFP’s and they should learn how to evaluate the quotations from the suppliers. In this paper, both topics will be discussed. Participants on the demand side will learn which questions they should ask in RFP’s and how to identify the quotations from suppliers that are not realistic. Participants on the supply side will learn about the future in RFP management and the questions that they should be able to respond to in the (hopefully) near future.
11.00 Coffee
11.30 The Definition of Metrics Integration in SCRUM
Christian Facchi (University of Appiled Sciences Ingolstadt, Germany)
Jochen Wessel (Nokia Siemens Networks, Germany
SCRUM as an Agile Method for software development has been widely spread. A key success factor of SCRUM is a permanent integration, which will be achieved by the method of Continuous Integration. At Nokia Siemens Networks we are in doubt whether our Continuous Integration is as steady as it should be. Metrics have been used for a well founded evaluation of the steadiness. In this paper we introduce these metrics, their implementation and validate these metrics in a real life case study.
12,05 Utilising Measurement in the context of SW Maturity Models
Jari Soini (Tampere University of Technology, Finland)
In the software business, software process improvement (SPI) is one of the most important focus areas if a company wants to be successful in the long term. In practice, this means that the software engineering process must be improved continuously and existing processes must be constantly scrutinized for areas to develop. Continuous process improvement cannot exist without a continuous and systematic monitoring and measuring of the company’s own processes. Measurement can be utilized for defining the status of the software process, monitoring the progress of improvement actions as well as analyzing the effect of consciously made changes or observing deviant behavior in the software process. It can be said that the prevailing state of the process, or product, can be based only on measurement and therefore it tends to be one of the most important aspects when a company wishes to assess the SPI results reliably. However, the link between software measurement and SPI is not explicit. Therefore, during the completed research project, an information system was developed as a tool, in order to connect and link the software process phases and software process metrics. The information system presented offers a bidirectional link between processes (classified by the CMMI and SPICE maturity models) and common software metrics. This feature helps the users to identify the relevant metrics for controlling a particular process. The system guide advises the user on how to use measurement as an instrument for SPI. This tool is primarily meant for assisting software companies to enhance their understanding of how to utilize measurement in connection with SPI.
12.40 Software Quality Standards and Approaches from a Ontological Point of View
Konstantina Georgieva, Robert Neumann, Reiner R. Dumke (Institute for Distributed Systems, University of Magdeburg,Germany)
This paper is dedicated to some of the international standards used for assessment and assurance of software quality. An ontology expressing the common processes in the standards is introduced, so that it is easy to observe the common basis of all of them. Furthermore, the connections among the models are discussed, which provides a basis for comparison of their structure, related processes and assessment methods.
13.15 Lunch
14.30 Estimating Web Application Development Effort using COSMIC
Filomena Ferrucci, Carmine Gravino (Università di Salerno, Italy)
Luigi Buglione (ETS/Engineering.it)
Due to its composite and particular nature, Web projects (and related applications) are quite difficult to be defined (and measured) by a single size unit, and the subsequent effort estimation process for a Web project still remains nowadays a critical activity for a project manager, that’s in charge to deliver the final application on time, on quality, and within budget. COSMIC, a 2nd generation Functional Size Measurement Method (FSMM), seems to better capture and size also those kinds of projects than 1st generation FSMM such as IFPUG FPA and several studies have been carried out during last years, with results that would confirm such hypothesis. But a Web project can refer to different application types and/or organizational environments or, more trivially, refer to a static or a dynamic environment, with relevant impacts on functional sizes and therefore on related productivities and consequently on the estimation process.
Recently some experiments have been carried out on improving estimations using combinations of Base Functional Components (BFC) for a certain FSM method as the independent proxies in multiple linear regression analysis, showing higher prediction values than using the single fsu value (e.g. UFP for IFPUG or CFP for COSMIC).
This paper will present a further case study in such direction, presenting and discussing results from an empirical study carried out using data from 15 projects from an Italian company, analyzed at the light of Multiple Linear Regression (MLR) and Manual Stepwise Regression (MSWR) estimation techniques.
15.05 Applying the maintabilty index to object-oriented code
Rob Kusters, Jos Trienekens, Andy van Langendock (Eindhoven University of Technology, Netherland)
Software maintenance costs are difficult to estimate, but usually high. Figures of 40 (Brooks, 2001, p.242) to 60-80 (Jones 1998, Boehm 1981) percent of the life cycle costs are quoted regularly. So it is understandable, that a maintenance department would like to know the level of maintainability of software that is being relegated to their care.
The Maintainability Index (MI) is a compound metric consisting of a number of metrics that claims an easy and fast prediction of the maintainability of software code (Oman, 1994). Over the last decades different attempts have been made to improve the MI, e.g. (Pearse, 1995), (Welker, 2001), (Liso, 2001), (Sei, 2002). The MI was originally aimed at imperative software code, but Welker (Welker, 1997) suggested how to use it also for object oriented code.
This paper investigates the validity of the claims made for the MI in the context of object oriented code in a large governmental software maintenance organisation. For this purpose, maintenance of code was measured in three different ways:
- First the MI was calculated automatically for the code produced in the IT-department.
- Secondly the maintainability has been investigated, as it was estimated in practice by the software developers. For this we developed a (qualitative) questionnaire, with measurement scales high, average and low (Oman, 1994).
- Finally the actual maintenance effort has been calculated, which was spend on the code in the past year. For this we collected both the total effort and the average effort per maintenance activity in the IT-department.
The first assumption to test is the correlation between maintainability, as calculated with the MI, and the actual maintenance effort. If MI is a valid measure of maintainability, a positive correlation should be expected between the MI and the actual maintenance effort.
A second assumption tests the statement of the maintenance engineers that they are quite capable of estimating the level of maintainability themselves. If this is true, a positive correlation could be expected between these qualitative (inter-subjective) estimations and the calculated actual maintenance effort.
Data were gathered about 27 software code applications. These together contained 1.036.798 lines of code. In total 24852 maintenance tickets (for a particular period of maintenance) were associated with these applications. Surprisingly the overall result, of the software code as a whole, was negative. No significant correlations were found in the total set of data, casting doubt on the claims.
However, feed-back to the software maintenance groups on the more detailed results, has lead to fruitful discussions on maintainability. E.g the discussions on the application level showed that for particular software applications a calculated MI had indeed strong correlations with the estimations of maintenance engineers.
Further it was concluded that regarding the validation of the MI, a refinement should be made, and that the MI should be calculated for particular clusters of software applications and should be estimated for particular types of maintenance activities.
15.40 Coffee
16.05 Cloud services security, performance and reliability measurement
Stefano Fabrizi, Marina La Fratta, Dario Russo (Banca d’Italia, Italy)
Cloud Computing represents a novel and promising approach for implementing scalable ICT systems for individual, communities, and business use. However compliance with security, performance, and reliability in Cloud Computing is currently pursued with partial and ad hoc solutions. The Compliant Cloud Computing (C3) project provides a framework to define and measure cloud services by means of Compliance Level Agreements (CLAs). The CLAs are a special type of Service Level Agreements (SLAs) containing extensions necessary to express security, performance, and reliability related constraints of a cloud service.
16.40 Alignment of Open Source Tools with ISO Norms
Emanuel Irrazabal, Juan Manuel Vara, Javier Garzás, Esperanza Marcos
Kybele Consulting, Kybele Research Group Universidad Rey Juan Carlos Madrid, SPAIN.
During the last years, quality is becoming a hot topic in the context of Software Engineering. The quality control should be done from a quantitative point of view, for what it is necessary to establish measurement systems throughout the product lifecycle. Measures
provide the basis for the improvement and, in particular, code measures provide direct visibility of product quality. Nevertheless, small organizations can not cope with the development of tools to check the quality of their products plus the development of the software that constitutes their main business. In this context, open-source tools emerge as the answer to provide with the technical support to collect the information needed to assess the quality of software assets. In this work, we review how existing open-source tools fulfill the needs for quality measures raised when you want to assess product quality according to the ISO/IEC-9126 standard. To that end, we review the main features of those tools as well as the criteria used to select them, pointing out the degree of alignment of the measures provided by each tool with regards to the needs of information of the standard. Finally, we put forward a set of directions for future work in order to reach a complete framework that can be used to assess product quality according to the ISO/IEC-9126 standard.
17.15 No assessment, no glory
Keynote speaker Ton Dekkers
17.45 Closing |
TOP
Go!