Estimating the cost and schedule of agile software projects is critical at an early phase to establish baseline budgets and schedules for the selection of competitive bidders. The challenge is that common agile sizing measures such as story points and user stories are not practical for early estimation as these are often reported after contract award in DoD. This study provides a set of effort and schedule estimation models for agile projects using a sizing measure that is available before proposal evaluation based on data from 36 DoD agile projects. The results suggest that initial software requirements, defined as the sum of functions and external interfaces, is an effective sizing measure for early estimation of effort and schedule of agile projects. The models’ accuracy improves when application domain groups and peak staff are added as inputs.

This paper presents a preliminary and exploratory study of the relationship of software security-related size, in lines of code, and the software security level, expressed as the vulnerability density. We developed a classifier and employed source code analyzers to determine the proportion of security-related code and the security level of a sample of 162 open source software (OSS) projects, developed in five different programming languages. Based on the information collected, we analyzed the proportion of security-related code and investigated its correlation with the static analysis vulnerability density of the selected projects. We found that the proportion of security size in OSS can vary depending on its type. Enterprise OSS present a median of 22 % of its code related to security, whereas volunteer-based OSS have a 9% median. We did not find a correlation between security-related size and vulnerability density. However, by filtering only volunteer-based OSS projects in the sample, we found a moderate positive correlation between vulnerability density and the proportion of security-related size. Our study results do not support the idea that a larger proportion of security-related code is associated with more security in terms of a lower vulnerability density. Nonetheless, the type of OSS, namely volunteer-based or enterprise, seems to have a significant impact on software security. Volunteer-based OSS presented a smaller proportion of security-related code, but as this proportion increases, so does the vulnerabilities, indicating a worsening on the security level. The phenomenon was not identified in enterprise OSS.

Background: Software effort estimates are necessary and critical at an early phase for decision makers to establish initial budgets, and in a government context to select the most competitive bidder for a contract. The challenge is that estimated software requirements is the only size information available at this stage, compounded with the newly increasing adoption of agile processes in the US DoD. Aims: The objectives are to improve cost estimation by investigating available sizing measures, and providing practical effort estimation models for agile software development projects during the contract bidding phase or earlier. Method: The analysis explores the effects of independent variables for product size, peak staff, and domain on effort. The empirical data for model calibration is from 20 industrial projects completed recently for the US DoD, among a larger dataset of recent projects using other lifecycle processes. Results: Statistical results showed that initial software requirements is a valid size metric for estimating agile software development effort. Prediction accuracy improves when peak staff and domain are added as inputs to the cost models. Conclusion: These models may be used for estimates of agile projects, and evaluating software development contract cost proposals with inputs available during the bidding phase or earlier.

Context: An effort estimation model with more than 20 parameters is not very useful at early conceptual phase if you don't have a logical approach for specifying the input values.

The article of record as published may be found at http://dx.doi.org/10.1109/ESEM.2011.56

The COCOMO II model was created to meet the need for a cost model that accounted for future software development practices. This paper describes some of the experiences learned in calibrating COCOMO II Post-Architecture model from eighty-three observations. The results of the multiple regression analysis, their implications, and a future calibration strategy are discussed.