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.

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.

Static representations of development processes provide a basis for communication and coordination of work, as well as for planning work. However, they do not provide any information about the actual behavior of a project, including the effects of staffing decisions, quality-inducing activities, delays, resource contentions, and so forth. Software process simulation (SPS) has demonstrated the capability for providing insight to the dynamics of software projects and supporting project management decisions. This tutorial is a SPS introduction that emphasizes practical approaches to modeling and simulation for both researchers and practitioners. We will discuss modeling and simulation, types of simulation, an historical overview of SPS, the disciplines that contribute to successful SPS work, modeling constructs commonly used to represent software development dynamics, and methods for conducting a SPS project.

ABSTRACT Software process simulation (SPS) has been evolving over the past two decades after being introduced to the software engineering community in the 1980s. At that time the SPS technology attracted a great deal of interest from both academics and practitioners in the software process community—even to the extent of being one of the recommended techniques for achieving multiple Key Process Areas of Level 4 of the Capability Maturity Model Integration. However, in recent years, the growth of SPS seems to have slowed along with the number of reported applications in industry. This article summarizes the special panel that was held during ICSSP 2012 whose goals were to assess whether this technology remains applicable to today's software engineering projects and challenges and to point out the most beneficial opportunities for future research and industry application. Copyright © 2014 John Wiley & Sons, Ltd.

Background: Do we always need complex methods for software effort estimation (SEE)? Aim: To characterize the essential content of SEE data, i.e., the least number of features and instances required to capture the information within SEE data. If the essential content is very small, then 1) the contained information must be very brief and 2) the value added of complex learning schemes must be minimal. Method: Our QUICK method computes the euclidean distance between rows (instances) and columns (features) of SEE data, then prunes synonyms (similar features) and outliers (distant instances), then assesses the reduced data by comparing predictions from 1) a simple learner using the reduced data and 2) a state-of-the-art learner (CART) using all data. Performance is measured using hold-out experiments and expressed in terms of mean and median MRE, MAR, PRED(25), MBRE, MIBRE, or MMER. Results: For 18 datasets, QUICK pruned 69 to 96 percent of the training data (median = 89 percent). K = 1 nearest neighbor predictions (in the reduced data) performed as well as CART's predictions (using all data). Conclusion: The essential content of some SEE datasets is very small. Complex estimation methods may be overelaborate for such datasets and can be simplified. We offer QUICK as an example of such a simpler SEE method.

A reason we may be at a crossroads in process simulation is that our view has been limited. Possibly we aren't simulating all the relevant aspects of importance to enterprises. For example, being overly focused in the weeds of development and not modeling the business or mission value of process options. To make greater impact we should involve other disciplines and considerations in broader, more holistic models. Software is critical and provides the edge for successful products and organizations, so we should take on a commensurate larger perspective and more informed role. This requires a pro-active approach within organizations.

Systems engineering processes using pull scheduling methods (kanban) are being evaluated with hybrid modeling and simulation. We are assessing integrated systems and software engineering at the enterprise level, where rapid response software development projects incrementally evolve capabilities of existing systems and/or systems of systems. A kanban-based scheduling system was defined and implemented with connected discrete, continuous and agent-based models. We are simulating the process performance vs. traditional methods of sharing systems engineering services across projects, and whether the overall value of the systems of systems over time is increased.

Systems engineering is often ineffective in development environments where large, complex, brownfield systems of systems are evolved through parallel development of new capabilities in response to external, time-sensitive requirements. This paper defines a conceptual framework to improve that effectiveness and better integrate the systems engineering and software engineering processes. The framework is based on a services approach to systems engineering and the use of kanban techniques to schedule scarce enterprise systems engineering resources across multiple related systems and software development projects. The framework also addresses the differing value of work items to multiple stakeholders in the scheduling and coordination processes. Models and simulations are being used to capture, refine and validate the framework prior to in vivo experimentation.

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

A systems engineering process model for the acquisition of large, complex systems for the U.S. Department of Defense (DoD) is being adapted for ongoing experiments in acquisition process policies. The discrete-event simulation model of the larger "enterprise of acquisition" for weapon systems has a broad scope from program beginning through development. It reveals some of the challenges and risks in weapon system acquisition.

Adoption of advanced automated SE (ASE) tools would be favored if a business case could be made that these tools are more valuable than alternate methods. In theory, software prediction models can be used to make that case. In practice, this is complicated by the "local tuning" problem. Normally, predictors for software effort and defects and threat use local data to tune their predictions. Such local tuning data is often unavailable.

As the founding Director of the Center for Software Engineering, Professor Barry W. Boehm developed courses that have greatly impacted the education of software engineering students. Through the use of the MBASE framework and complementary tools, students have been able to obtain real-life software development experience without leaving campus. Project team clients and the universities have also benefited. This paper provides evidence on the impact of Dr. Boehm's frameworks on courses at two universities, and identifies major contributions to software engineering education and practice