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.

The E/E (Electrical/Electronic) Architecture is the key enabler for new innovative user functions in the automotive domain. The E/E Architecture needs to manage the complexity of the E/E System in a cost-efficient manner. This is a fact for all domains developing mass-produced distributed systems containing embedded software. However, many companies in these domains are missing a clear description of the development process for E/E Architectures. In addition, the relation between development of E/E Architectures and the development of E/E Systems is not clear. This paper proposes a development process for E/E Architectures in the automotive domain. Furthermore, it shows the relation between development of E/E Architectures and development of E/E Systems. The development process is based on post mortem analysis of E/E System development projects conducted at an automotive company during the period 1998-2009, and it was validated in an E/E Architecture development project conducted during the period 2010-2011. The contribution of this paper is a detailed E/E System development process describing how to create and maintain an E/E Architecture and how to refine this into a Product-specific Architecture in Product development projects. Furthermore, the paper reports on experiences from working with RA development both as a small stand-alone company with few different products, and as part of a large global company with several different products.

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.

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. Central in that work is the mapping between CFP and the information available early in the development process. We have previously defined a UML Profile capturing the information needed for CFP measurement and estimation of Code Size. The key idea was to extend UML components to contain all the necessary information. In this paper, we show how we developed a tool for automated estimation of Code Size based on our UML Profile. The tool is designed to permit Code Size estimation based on other UML diagrams than components. A case study evaluates the UML Profile and the tool in a realistic case.

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.

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.

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.