Kenneth Lind

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.

Estimation of Real-Time Software Code Size using COSMIC FSM

For distributed networks which will be mass produced, such as computer systems in modern vehicles, it is crucial to find cost efficient hardware. A distributed network in a vehicle consists of several ECUs (Electronic Control Unit). In this paper we consider the amount of memory needed for these ECUs. They should contain enough memory to survive several software generations, without inducing unnecessary cost of too much memory. Our earlier work shows that UML Component Diagrams can be used to collect enough information for estimating memory size using a Functional Size Measurement method. This paper replicates our earlier experiment with more software components of a different type. We compare the results from the two experiments.

A model-based and automated approach to size estimation of embedded software components

Accurate estimation of Software Code Size is important for developing cost-efficient embedded systems. The Code Size affects the amount of system resources needed, like ROM and RAM memory, and processing capacity. In our previous work, we have estimated the Code Size based on CFP (COSMIC Function Points) within 15% accuracy, with the purpose of deciding how much ROM memory to fit into products with high cost pressure. Our manual CFP measurement process would require 2,5 man years to estimate the ROM size required in a typical car. In this paper, we want to investigate how the manual effort involved in estimation of Code Size can be minimized. We define a UML Profile capturing all information needed for estimation of Code Size, and develop a tool for automated estimation of Code Size based on CFP. A case study will show how UML models save manual effort in a realistic case.

A Practical Approach to Size Estimation of Embedded Software Components

To estimate software code size early in the development process is important for developing cost-efficient embedded systems. We have applied the COSMIC Functional Size Measurement (FSM) method for size estimation of embedded software components in the automotive industry. Correlational studies were conducted using data from two automotive companies. The studies show strong correlation between functional size and software code size, which is important for obtaining accurate estimation results. This paper presents the characteristics and results of our work, and aims to provide a practical framework for how to use COSMIC FSM for size estimation purposes. We investigate the results from our earlier correlational studies, and conduct further studies to identify such a framework. Based on these activities, we conclude that a clear purpose of the estimation process, a well-defined domain allowing categorization of software, consistent content and quality of requirements, and historical data from implemented software are key factors for size estimation of embedded software components.

On the relationship between functional size and software code size

SLOC (Source Lines-Of-Code) has been used extensively as a Code Size Measure, and as input to parametric software cost and effort estimation tools. SLOC is obtained by measuring FP (Function Points) on the requirements and multiplying by the SLOC/FP ratio from similar projects. This is done even though several studies show large variations in this ratio, due to weak correlation between FP and SLOC. However, in our previous experiments we have obtained strong correlation between CFP (COSMIC Function Points) and Bytes compiled code as Code Size Measure. The experiments were conducted in the automotive industry using software components developed by GM (General Motors). In this paper we explain the reasons behind the strong correlation. The main reasons are that we apply the COSMIC method on software components of similar type, with a 1-to-1 mapping to COSMIC. A strong correlation between the Functional Size Measure and the Code Size Measure is required to obtain accurate Code Size estimation results. To estimate the Code Size before the software is available, is important both for Cost/Effort estimation and design of electronic hardware.

Categorization of real-time software components for code size estimation

Background: To estimate Software Code Size early in the development process is important both for Cost/Effort estimation and electronic hardware design reasons. The COSMIC FSM (Functional Size Measurement) method treats the intended software to be measured as a black box, and measures CFP (COSMIC Function Points) based only on data movement in and out of the software. Therefore, CFP can be measured on requirements defined early, and be used to estimate Code Size if there exists a strong correlation between CFP and Code Size. We have conducted four experiments in the automotive industry showing strong correlation between CFP and implemented Code Size in Bytes. All four experiments, of which two have not been published before, show equally strong correlation but the linear relationship is different between the experiments. Goal: This paper aims to identify the factors affecting the linear relationship. With these factors, we can categorize new requirements to be measured and select the proper linear relationship to convert CFP into Bytes, i.e. estimate Code Size. Method: We replicate our earlier experiments with software components of new types, and review the results from all our experiments. Potential factors affecting implemented Code Size are identified by performing open-ended interviews with domain experts. Results: We have in the automotive industry identified a set of factors that can be used to categorize the software components we want to measure; functionality type, quality constraints, and development methods and tools. Conclusions: COSMIC can produce accurate Code Size Estimates provided that sub-sets of cohesive and uniform requirements can be identified. Moreover, similar requirements must have been measured before to establish the linear relationship between CFP and Bytes. Finally, the sub-sets of requirements need to be able to categorize based on factors that affect the linear relationship. With this approach, even complex calculations can be measured, provided that they are proportional to the number of data movements.

Quality-driven optimization of system architecture: Industrial case study on an automotive sub-system

Due to the complexity of todays embedded systems and time-to-market competition between companies developing embedded systems, system architects have to perform a complex task. To design a system which meets all its quality requirements becomes increasingly difficult because of customer demand for new innovative user functions. Methods and tools are needed to assist the architect during system design. The goal of this paper is to show how metaheuristic optimization approaches can improve the process of designing efficient architectures for a set of given quality attributes. A case study is conducted in which an architecture optimization framework is applied to an existing sub-system in the automotive industry. The case study shows that metaheuristic optimization approaches can find efficient solutions for all quality attributes while fulfilling given constraints. By optimizing multiple quality attributes the framework proposes revolutionary architecture solutions in contrast to human architects, who tend to propose solutions based on previous architectures. Although the case study shows savings in manual effort, it also shows that the proposed architecture solutions should be assessed by the human architect. So, the paper demonstrates how an architecture optimization framework complements the domain knowledge and experience of the architect.

Impact of Introducing Domain-Specific Modelling in Software Maintenance: An Industrial Case Study

Domain-specific modelling (DSM) is a modern software development technology that aims at enhancing productivity. One of the claimed advantages of DSM is increased maintainability of software. However, current empirical evidence supporting this claim is lacking. In this paper, we contribute evidence from a case study conducted at a software development company. We study how the introduction of DSM affected the maintenance of a legacy system. We collected data about the maintenance phase of a system that was initially developed using manual programming, but which was gradually replaced by DSM development. We performed statistical analyses of the relation between the use of DSM and the time needed to resolve defects, the defect density, and the phase in which defects were detected. The results show that after introducing DSM the defect density is lower, that defects are found earlier, but resolving defects takes longer. Other observed benefits are that the number of developers and the number of person-hours needed for maintaining the system decreased, and the portability to new platforms increased. Our findings are useful for organizations that consider introducing DSM and would like to know which benefits can be realized in software maintenance.