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

Gencel, Çiğdem; Heldal, Rogardt; Lind, Kenneth

doi:10.1109/apsec.2009.51

Cited by 17 publications

(8 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The data sets in Series 1, 2, 3, and 4, show very strong correlation, whereas all data show weak correlation. This is in line with what we expect, but the R 2 value is not worse than typical values on the correlation between CFP and SLOC [10], [14], [15], [31]. This encourages us to perform linear regression analysis on all data.…”

Section: Analysis Of All Collected Datasupporting

confidence: 78%

“…Other FSM methods (like IFPUG [17]) require more details of the intended software, details that are specified later during the development process. The downside is that COSMIC does not directly capture complex calculations [10], [14], [15], [31]. This paper shows that it is possible to obtain accurate Code Size estimates even for software components containing complex calculations, as long as the components contain similar complexity proportional to the number of data movements.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Categorization of real-time software components for code size estimation

Lind¹,

Heldal

2010

Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Section: Analysis Of All Collected Datasupporting

confidence: 78%

Section: Introductionmentioning

confidence: 99%

Categorization of real-time software components for code size estimation

Lind¹,

Heldal

2010

Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

show abstract

“…Gencel et al investigated the nature of the relationship between software functional size and the code size via a series of empirical studies . They found that the size in LOCs/functional size ratio tends to vary widely through software applications.…”

Section: Related Workmentioning

confidence: 99%

Evolution of functional size measures through ICONIX process phases

Lavazza

Tosi

2019

J Software Evolu Process

View full text Add to dashboard Cite

Functional size measures are used in several software development processes, because they can be applied as soon as the functional user requirements of a software application have been specified. Quite often, functional user requirements are used as the main input of effort and cost estimation. Since effort and cost estimates are fundamental for decision making, project managers would like to get reasonably accurate estimates even before user requirements have been specified completely and at the proper level of detail. To this end, early size estimation methods have been proposed. In this paper, we consider a specific situation; namely, we consider processes in which the requirements elicitation and modeling phases are carried out according to the ICONIX process. The ICONIX process involves a few stages, each one tackling an aspect of requirements and delivering a specific artifact, in the form of a UML model. We explore the possibility of deriving from ICONIX artifacts the information needed to estimate the final size of the application. To this end, we analyzed the requirements of 21 software applications and derived statistical models that correlate the information extracted from ICONIX artifacts to the size, expressed in function points, of the application. The analysis of the achieved estimates shows that the approach is viable, in that it provides early estimates with good accuracy. KEYWORDS early size measurement, function points, functional size measurement 1 INTRODUCTION Functional size measurement (FSM) was proposed by Albrecht 1 around 40 years ago, to provide an alternative to ''physical'' measures of software, like lines of code (LoCs). Albrecht's function point analysis (FPA) was received with great favor by practitioners, because it provides the means to get a proper measure of the size of software based on functional user requirements (FURs). Before the introduction of FPA, when an estimate of software development cost was needed at the beginning of the development process, one had to estimate the size in LoCs, which was quite difficult, since the size in LoC depends on several factors (including the experience of developers and the programming language, for instance)that may be unknown at estimation time.Function point analysis was a breakthrough, in that it provided a measure that could support cost estimation in the early phases of development, when it was most needed. The success of FPA induced the creation of the International Function Points User Group (IFPUG), which took charge of maintaining the FPA method and the official measurement manual. 2 Function points (FPs) were also recognized as a standard by International Standards Organization (ISO), 3 in their unadjusted form. Throughout this paper, we always make reference to unadjusted FP (UFP).Functional size measure requires that FURs are known completely and in detail. However, quite often, functional size measures are needed before the requirements elicitation and specification phase is complete, i.e., when FUR are still incomplete and...

show abstract

“…These attributes reflect the data quality of a project in this dataset. In most studies on software effort prediction involving the ISBSG dataset, the authors follow the ISBSG guidelines [9] and filter the data by only including projects with Data Quality Rating and UFP Rating classified as A or B, denoting at least good quality [7,[10][11][12][13][14][15][16][17]. Generally, performing analyses on the best possible data seems reasonable.…”

Section: Introductionmentioning

confidence: 99%

The Impact of Data Quality on Software Testing Effort Prediction

Radliński

2023

Electronics

View full text Add to dashboard Cite

Background: This paper investigates the impact of data quality on the performance of models predicting effort on software testing. Data quality was reflected by training data filtering strategies (data variants) covering combinations of Data Quality Rating, UFP Rating, and a threshold of valid cases. Methods: The experiment used the ISBSG dataset and 16 machine learning models. A process of three-fold cross-validation repeated 20 times was used to train and evaluate each model with each data variant. Model performance was assessed using absolute errors of prediction. A ‘win–tie–loss’ procedure, based on the Wilcoxon signed-rank test, was applied to identify the best models and data variants. Results: Most models, especially the most accurate, performed the best on a complete dataset, even though it contained cases with low data ratings. The detailed results include the rankings of the following: (1) models for particular data variants, (2) data variants for particular models, and (3) the best-performing combinations of models and data variants. Conclusions: Arbitrary and restrictive data selection to only projects with Data Quality Rating and UFP Rating of ‘A’ or ‘B’, commonly used in the literature, does not seem justified. It is recommended not to exclude cases with low data ratings to achieve better accuracy of most predictive models for testing effort prediction.

show abstract

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

Cited by 17 publications

References 8 publications

Categorization of real-time software components for code size estimation

Categorization of real-time software components for code size estimation

Evolution of functional size measures through ICONIX process phases

The Impact of Data Quality on Software Testing Effort Prediction

Contact Info

Product

Resources

About