Cigdem Gencel

Functional size measurement revisited

There are various approaches to software size measurement. Among these, the metrics and methods based on measuring the functionality attribute have become widely used since the original method was introduced in 1979. Although functional size measurement methods have gone a long way, they still provide challenges for software managers. This article identifies improvement opportunities based on empirical studies we performed on ongoing projects. We also compare our findings with the extended dataset provided by the International Software Benchmarking Standards Group (ISBSG).

Impact of Base Functional Component Types on Software Functional Size Based Effort Estimation

Software effort estimation is still a significant challenge for software management. Although Functional Size Measurement (FSM) methods have been standardized and have become widely used by the software organizations, the relationship between functional size and development effort still needs further investigation. Most of the studies focus on the project cost drivers and consider total software functional size as the primary input to estimation models. In this study, we investigate whether using the functional sizes of different functionality types, represented by the Base Functional Component (BFC) types; instead of using the total single size figure have a significant impact on estimation reliability. For the empirical study, we used the projects data in the International Software Benchmarking Standards Group (ISBSG) Release 10 dataset, which were sized by the COSMIC FSM method.

Conceptual Differences Among Functional Size Measurement Methods

Although functional size measurement (FSM) methods have gone a long way, they still provide challenges for software managers. A major challenge is related to the comparison of the well established FSM methods. This paper identifies the conceptual similarities and differences among Mkll FPA, COSMIC FFP and IFPUG FPA methods based on a case study, which involves implementation of the methods to measure the functional size of a military inventory management project integrated with a document management system.

Conceptual Association of Functional Size Measurement Methods

Functional size determines how much functionality software provides by measuring the aggregate amount of its cohesive execution sequences. Alan Albrecht first introduced the concept in 1979. Since he originally described the function point analysis (FPA) method, researchers and practitioners have developed variations of functional size metrics and methods. The authors discuss the conceptual similarities and differences between functional size measurement methods and introduce a model for unification.

On the Relationship between Different Size Measures in the Software Life Cycle

Various measures and methods have been developed to measure the sizes of different software entities produced throughout the software life cycle. Understanding the nature of the relationship between the sizes of these products has become significant due to various reasons. One major reason is the ability to predict the size of the later phase products by using the sizes of early life cycle products. For example, we need to predict the Source Lines of Code (SLOC) from Function Points (FP) since SLOC is being used as the main input for most of the estimation models when this measure is not available yet. SLOC/FP ratios have been used by the industry for such purposes even though the assumed linear relationship has not been validated yet. Similarly, FP has recently started to be used to predict the Bytes of code for estimating the amount of spare memory needed in systems. In this paper, we aim to investigate further the nature of the relationship between the software functional size and the code size by conducting a series of empirical studies.

Trust dynamics in global software engineering

Trust is one of the key factors that determines success or failure of any software project. However, achieving and maintaining trust in distributed software projects, when team members are geographically, temporally and culturally distant from each other, is a remarkable challenge. This paper explores the dynamics of trust and best practices performed in software organizations to address trust-related issues in global software engineering. Semi-structured interviews were conducted in six different distributed software development organizations and a resulting trust dynamics model is presented. Based on the findings, the paper also provides suggestions for the industry to achieve trust in distributed collaborations.

A Comparison of Size Estimation Techniques Applied Early in the Life Cycle

Timing is one of the most critical factors of software size estimation. We need to know quite a bit about the software project to make a meaningful size estimate. However, most of the software estimates should be performed at the beginning of the life cycle, when we do not yet know the problem we are going to solve. In the literature, there are few early size estimation methods. This study demonstrates the results of size estimation methods utilized on a large software intensive military application within the boundary of a project for Request for Proposal (RFP) preparation.

Do Base Functional Component Types Affect the Relationship between Software Functional Size and Effort

One of the most debated issues in Software Engineering is effort estimation and one of the main points is about which could be (and how many) the right data from an historical database to use in order to obtain reliable estimates. In many of these studies, software size (measured in either lines of code or functional size units) is the primary input. However, the relationship between effort and the components of functional size (BFC --- Base Functional Components) has not yet been fully analyzed. This study explores whether effort estimation models based on BFCs types, rather than those based on a single total value, would improve estimation models. For this empirical study, the project data in the International Software Benchmarking Standards Group (ISBSG) Release 10 dataset, which were functionally sized by the COSMIC FFP method, are used.

Improvement Opportunities and Suggestions for Benchmarking

During the past 10 years, the amount of effort put on setting up benchmarking repositories has considerably increased at the organizational, national and even at international levels to help software managers to determine the performance of software activities and to make better software estimates. This has enabled a number of studies with an emphasis on the relationship between software product size, effort and cost drivers in order to either measure the average performance for similar software projects or to develop estimation models and then refine them using the collected data. However, despite these efforts, none of those methods are yet deemed to be universally applicable and there is still no agreement on which cost drivers are significant in the estimation process. This study discusses some of the possible reasons why in software engineering, practitioners and researchers have not yet been able to come up with reasonable and well quantified relationships between effort and cost drivers although considerable amounts of data on software projects have been collected. An improved classification of application types in benchmarking repositories is also proposed.

Why a CMMI Level 5 Company Fails to Meet the Deadlines

Reliable effort and cost estimation remains to be a challenging issue even for mature software organizations. Although, these organizations collect historical data to base their future estimates, changes in circumstances (such as application type, development platform, etc.) prevent their successful utilization. As a result, companies often suffer from underestimated and unrealistic schedules. Managing software projects that involve a large number of globally distributed stakeholders makes estimation and planning even more challenging. Related studies show that even knowledgeable project managers often underestimate hidden costs and sources of delay associated with distributed development. Therefore, management activities such as estimation of development effort, planning and control require special attention. In this paper we discuss experiences gained from a highly distributed software project, which aimed at development of a product based on a new platform and architectural solution. The project was conducted in a CMMI Level 5 company and still failed to meet initial plan constraints. We thus provide an overview of management decisions in the light of their consequences, and discuss potential areas of improvement.