Source Lines Of Code Research Articles

Interactive churn metrics

A central part of software quality is finding bugs. One method of finding bugs is by measuring important aspects of the software product and the development process. In recent history, researchers have discovered evidence of a "code churn" effect whereby the degree to which a given source code file has changed over time is correlated with faults and vulnerabilities. Computing the code churn metric comes from counting source code differences in version control repositories. However, code churn does not take into account a critical factor of any software development team: the human factor, specifically who is making the changes. In this paper, we introduce a new class of human-centered metrics, "interactive churn metrics" as variants of code churn. Using the git blame tool, we identify the most recent developer who changed a given line of code in a file prior to a given revision. Then, for each line changed in a given revision, determined if the revision author was changing his or her own code ("self churn"), or the author was changing code last modified by somebody else ("interactive churn"). We derive and present several metrics from this concept. Finally, we conducted an empirical analysis of these metrics on the PHP programming language and its post-release vulnerabilities. We found that our interactive churn metrics are statistically correlated with post-release vulnerabilities and only weakly correlated with code churn metrics and source lines of code. The results indicate that interactive churn metrics are associated with software quality and are different from the code churn and source lines of code.

Measuring productivity of software development teams

This paper gives an exhaustive literature review of the techniques and models available to measure the productivity of software development teams. Definition of productivity, measuring individual programmer's productivity, and measuring software development team productivity are discussed. Based on the literature review it was found that software productivity measurement can be done using SLOC (Source Lines of Code), function points, use case points, object points, and feature points. Secondary research findings indicate that the team size, response time, task complexity, team climate and team cohesion have an impact on software development team productivity. List of factors affecting the software development team productivity are studied and reviewed.

An Environmentally Oriented Constructive Cost Model In Information and Communication Software Development Environment: Nigeria as A Case Study

A model was designed to assist software developers in Nigeria to estimate software effort, duration and cost as a result of the difficulties in understanding the parameters of the traditional Constructive Cost Model II (COCOMO II) , which was designed for a specif ic environment, using Source Lines of Code (SLOC) . Results revealed that t he model guarantee 70% effort and 60% cost estimates accuracy to suite Nigeria information and communication software development environment.Key words: Environment, Constructive Cost Model , Software , Estimate, Effort , Duration, Information , Communication, development.

A Probabilistic Method for Predicting Software Code Growth

A significant challenge that many cost analysts and project managers face is predicting by how much their initial estimates of software development cost and schedule will change over the lifecycle of the project. Examination of currently-accepted software cost, schedule, and defect estimation algorithms reveals a common acknowledgment that estimated software size is the single most influential independent variable. Unfortunately, the most important business decisions about a software project are made at its beginning, the time when most estimating is done, and coincidently the time of minimum knowledge, maximum uncertainty, and hysterical optimism. This article describes a model and methodology that provides probabilistic growth adjustment to single-point Technical Baseline Estimates of Delivered Source Lines of Code, for both new software and pre-existing reused software that is sensitive to the maturity of their single-point estimates. The model is based on Software Resources Data Report data collected ...

A historical compilation of software metrics with applicability to NASA’s Orion spacecraft flight software sizing

Estimating the size of a large and complex software system is a challenging task. Early in a project's life cycle, when requirements for the system may be immature and functionality defined only at a high level, resource profiles are necessary for appropriate funding, staffing, and development of a viable project plan. Similar project historical software size data and trends provide a tool to predict software size, creating a feasible estimation approach. To confidently estimate the flight software required for the Orion Spacecraft, NASA conducted an analysis of similar space and aircraft software systems. This paper presents the results of a study that compiled data from over 400 spacecraft, aircraft, and submarine software projects, which were functionally similar in nature to the Orion spacecraft flight software. The study includes the analysis and summary of overall trends in software size, development strategies, and processes. The results indicate a well-correlated upward trend in software size over time for both crewed and uncrewed space and aircraft. This trend was used to predict the estimated completed size of the Orion flight software at approximately 2.3 million Source Lines of Code (SLOC).

Analysis of Productivity Gain in Incremental Effort Estimation

This paper presents the framework for incremental Effort based development in order to analysis the productivity gain in Effort based development. Effort estimation is a challenge in every software project. The estimates will impact costs and expectations on schedule, functionality and quality. While expert estimates are widely used, they are difficult to analyze and the estimation quality depends on the experience of experts from similar projects. Alternatively, more formal estimation models can be used. Traditionally, software size estimated in the number of Source Lines of Code (SLOC), Function Points (FP) and Object Points (OP) are used as input to these models. Models that predict product size as an exponential function of the development effort are used in the paper to explore the relationships between effort and the number of increments. The author mainly focus what will be effect on productivity rate on incremental development and how duration for incremental software development vary .For incremental development the author estimate the cumulative effort gain against effort estimation . This research paper will be helpful to get productivity rate against incremental effort estimation. General Terms Effort estimation, Productivity, Time duration.

Examining Requirements Change Rework Effort: A Study

Although software managers are generally good at new project estimation, their experience of scheduling rework tends to be poor. Inconsistent or incorrect effort estimation can increase the risk that the completion time for a project will be problematic. To continually alter software maintenance schedules during software maintenance is a daunting task. Our proposed framework, validated in a case study confirms that the variables resulting from requirements changes suffer from a number of problems, e.g., the coding used, end user involvement and user documentation. Our results clearly show a significant impact on rework effort as a result of unexpected errors that correlate with 1) weak characteristics and attributes as described in the program's source lines of code, especially in data declarations and data statements, 2) lack of communication between developers and users on a change effects, and 3) unavailability of user documentation. To keep rework effort under control, new criteria in change request forms are proposed. These criteria are shown in a proposed framework; the more case studies that are validated, the more reliable the result will be in determining the outcome of effort rework estimation.

Organization, management, and documentation of ATLAS offline software releases

We update our CHEP06 [2] presentation on the ATLAS experiment software infrastructure used to build, validate, distribute, and document the ATLAS offline software. The ATLAS collaboration's computational resources and software developers are distributed around the globe in about 35 counties. The ATLAS offline code base is currently over 7 million source lines of code in 10,000+ C++ classes organized into about 2,000 packages. More than 400 developers contribute code each month. Since our last report, we have developed a powerful, flexible system to request code versions to be included in software builds, made changes to our software building tools, increased the number of daily builds used to validate significant code changes, improved the tools for distributing the code to our computational sites around the world, and made many advancements in the tools to document the code.

Understanding developer and manager perceptions of function points and source lines of code

Although function points (FP) are considered superior to source lines of code (SLOC) for estimating software size and monitoring developer productivity, practitioners still commonly use SLOC. One reason for this is that individuals who fill different roles on a development team, such as managers and developers, may perceive the benefits of FP differently. We conducted a survey to determine whether a perception gap exists between managers and developers for FP and SLOC across several desirable properties of software measures. Results suggest managers and developers perceive the benefits of FP differently and indicate that developers better understand the benefits of using FP than managers.

Abstracting access patterns of dynamic memory using regular expressions

Unless the speed gap between CPU and memory disappears, efficient memory usage remains a decisive factor for performance. To optimize data usage of programs in the presence of the memory hierarchy, we are particularly interested in two compiler techniques: pool allocation and field layout restructuring . Since foreseeing runtime behaviors of programs at compile time is difficult, most of the previous work relied on profiling. On the contrary, our goal is to develop a fully automatic compiler that statically transforms input codes to use memory efficiently. Noticing that regular expressions , which denote repetition explicitly, are sufficient for memory access patterns, we describe how to extract memory access patterns as regular expressions in detail. Based on static patterns presented in regular expressions, we apply pool allocation to repeatedly accessed structures and exploit field layout restructuring according to field affinity relations of chosen structures. To make a scalable framework, we devise and apply new abstraction techniques, which build and interpret access patterns for the whole programs in a bottom-up fashion. We implement our analyses and transformations with the CIL compiler. To verify the effect and scalability of our scheme, we examine 17 benchmarks including 2 SPECINT 2000 benchmarks whose source lines of code are larger than 10,000. Our experiments demonstrate that the static layout transformations for dynamic memory can reduce L1D cache misses by 16% and execution times by 14% on average.

Object-Oriented Software Cost Estimation Methodologies Compared

Executive Summary Most commonly available software cost estimation methodologies and tools use either source lines of code (SLOC) or function point (FP) measures as the basis for the estimate. While these methodologies and tools may suffice for software projects that use structured software development techniques, when object-oriented (OO) techniques such as use-case modeling are employed, it is more effective to use a methodology that takes advantage of the information provided by the use cases, scenarios, and more in-depth object-oriented metrics. Furthermore, as an organization becomes proficient in developing object-oriented system software, the traditional metrics of SLOC and FPs become less useful because each individual line of code becomes less likely to be like the others. Using use cases as the basis for effort estimation is a valuable addition to the tools available to a project manager, particularly for those projects where use cases are produced as part of the life-cycle process. Though use c...

Organization and management of ATLAS offline software releases

ATLAS is one of the largest collaborations ever undertaken in the physical sciences. This paper explains how the software infrastructure is organized to manage collaborative code development by around 300 developers with varying degrees of expertise and situated in 30 different countries. ATLAS offline software currently consists of about 2 million source lines of code contained in 6800 C++ classes, organized in more than 1000 packages. We will describe how releases of the offline ATLAS software are built, validated and subsequently deployed to remote sites. Several software management tools have been used, the majority of which are not ATLAS specific; we will show how they have been integrated.

Software Cost and Productivity Model

Abstract A software cost and productivity model is summarized. The model is based on 452 software development activities that commenced or completed after January 1, 1996, and are drawn from air, sea, land, and space programs. Software complexity is considered by assigning each data record to one of 32 combinations of operational environment and application domains. In addition, the model captures productivity information based on programming language. The following areas are examined, with comparisons to an earlier (1996) Aerospace Corporation model whenever possible: (1) software development productivity, (2) code growth, (3) apparent minimum and maximum software development schedules as a function of the number of source lines of code, (4) relationships for estimating the number of developer-months needed to produce a given number of lines of code, and (5) approximate data distributions. A key finding is that an apparent increase in software productivity has occurred, with median levels of productivity...

Determinants of software volatility: a field study

AbstractAlthough technology advances have provided new tools for maintaining software, maintenance costs remain the largest component of software life cycle cost. A basic factor claimed to be one of the driving factors in the cost of maintenance is software volatility. The objective of this research is to investigate the relationship between certain software attributes and software volatility. In this study, software volatility refers to the frequency or number of enhancements per unit of application over a specified time normalized. However, this metric is divided by the number of source lines of code (SLOC) to obtain a measure that takes into account the size of the software application. The research model is built on previous research concerning software volatility. Three factors are examined to determine their influence on software volatility normalized for SLOC: age, software complexity, and software complexity normalized for SLOC. In addition, we introduce the notion that mean time between software enhancements moderates the relationship of age, complexity, and complexity normalized for SLOC with software volatility. A field study at a major corporation allowed for the collection of data from a 13‐year‐time period. These data are used to empirically test the hypotheses presented in this study. As a moderator variable, mean time between enhancements significantly contributes to the explanatory power of a prediction model for software volatility adjusted for SLOC. Software administrators may wish to use the proposed model in their decision‐making plans to control for software costs. Copyright © 2003 John Wiley & Sons, Ltd.

Statistical modeling applied to managing global 5ESS®-2000 switch software development

In the development of new releases of large software systems, the software is evaluated by various development and testing organizations. To ensure that software faults causing customer-affecting failures are minimized at each stage of the development cycle, we use developer-oriented and customer-oriented metrics to measure software quality. Developer-oriented metrics focus on faults and fault densities during testing to monitor development process capabilities and software quality. These metrics are expressed as the number of faults per thousand of non-commentary source lines of code (KNCSL). Customer-oriented metrics focus on failure intensity during software execution, thus providing a user's view of the software quality. These metrics are expressed as the number of failures per unit of time. This paper describes the use of empirical software tracking models and software reliability models, as well as reports derived from these models, in managing the 5ESS®-2000 switch development resources and product quality.

Software benchmarks using function point analysis

The alternative to using source lines of code (SLOC) for costing software projects is to use function points. Functional point analysis (FPA), which was first introduced in 1979, has now been widely accepted as the industry standard for estimating software size and costs. International standard bodies like the International Function Point Users’ Group (IFPUG) has been maintaining a repository of data based on projects that were drawn from 14 countries in North America, Europe and Asia/Australasia. This paper presents the results of the analysis that was performed on these data together with recommendations such as benchmarks for software projects. Project measures such as functional size, work effort, project delivery rate, speed of delivery and project duration were analysed using the statistical package, Systat. Apart from project duration, all distributions were log‐normal, thus suggesting that the results can be used for software benchmarking. Regression analysis on the data further identified correlation of functional size with other project measures that can be used as a basis for planning and estimating software projects. Further work on the repository involves other project measures such as team size and software defects.

Some misconceptions about lines of code

Source lines of code (SLOC) is perhaps the oldest of software metrics, and still a benchmark for evaluating new ones. Despite the extensive experience with the SLOC metric, there are still a number of misconceptions about it. The paper addresses three of them: (1) that the format of SLOC is relevant to how to properly count it (a simple experiment shows that, in fact, it does not matter), (2) that SLOC is most useful as a predictor of software quality (in fact it is most useful as a covariate of other predictors), and (3) that there is an important inverse relationship between defect density and code size (in fact, this is an arithmetic artifact of plotting bugs-per-SLOC against SLOC).

Poisson analyses of defects for small software components

Poisson analyses are proposed for the identification of the determinants of defects in small software components such as subprograms, modules, or functional units. Software complexity (which can be measured during design or implementation) and software development environment characteristics influence the numbers of defects emerging in the testing phase. Poisson models are calibrated using software complexity measures from several Ada projects along with their associated software change report data. One of the models is used to estimate defects at the subprogram, subsystem, and project levels for the calibration data, and these estimates are then compared to the actual defects. Notable results from this analysis are that extensively modified reused subprograms (> 25% changed) have substantially more defects than new code of otherwise comparable characteristics and that software development environment volatility (as measured by non-defect changes per thousand source lines of code) is a strong determinant of subprogram defects. To demonstrate cross-language applicability, defect predictions are made at the subsystem level for a project coded in the C programming language and compared to the actual subsystem defects. Finally, for software projects developed through multiple builds, we show that a Poisson model that incorporates a measure of testing effort is applicable.

Software-effort estimation with a case-based reasoner

Software effort estimation is an important but difficult task. Existing algorithmic models often fail to predict effort accurately and consistently. To address this, we developed a computational approach to software effort estimation. cEstor is a case-based reasoning engine developed from an analysis of expert reasoning. cEstor's architecture explicitly separates case-independent productivity adaptation knowledge (rules) from case-specific representations of prior projects encountered (cases). Using new data from actual projects, uncalibrated cEstor generated estimates which compare favorably to those of the referent expert, calibrated Function Points and calibrated COCOMO. The estimates were better than those produced by uncalibrated Basic COCOMO and Intermediate COCOMO. The roles of specific knowledge components in cEstor (cases, adaptation rules, and retrieval heuristics) were also examined. The results indicate that case-independent productivity adaptation rules affect the consistency of estimates and appropriate case selection affects the accuracy of estimates, but the combination of an adaptation rule set and unrestricted case base can yield the best estimates. Retrieval heuristics based on source lines of code and a Function Count heuristic based on summing over differences in parameter values, were found to be equivalent in accuracy and consistency, and both performed better than a heuristic based on Function Count totals.

Cost models for future software life cycle processes: COCOMO 2.0

Current software cost estimation models, such as the 1981 Constructive Cost Model (COCOMO) for software cost estimation and its 1987 Ada COCOMO update, have been experiencing increasing difficulties in estimating the costs of software developed to new life cycle processes and capabilities. These include non-sequential and rapid-development process models; reuse-driven approaches involving commercial off-the-shelf (COTS) packages, re-engineering, applications composition, and applications generation capabilities; object-oriented approaches supported by distributed middleware; and software process maturity initiatives. This paper summarizes research in deriving a baseline COCOMO 2.0 model tailored to these new forms of software development, including rationale for the model decisions. The major new modeling capabilities of COCOMO 2.0 are a tailorable family of software sizing models, involving Object Points, Function Points, and Source Lines of Code; nonlinear models for software reuse and re-engineering; an exponentdriver approach for modeling relative software diseconomies of scale; and several additions, deletions and updates to previous COCOMO effort-multiplier cost drivers. This model is serving as a framework for an extensive current data collection and analysis effort to further refine and calibrate the model's estimation capabilities.