A longitudinal case study evaluating the effects of adopting the Extreme Programming (XP) methodology was performed at Sabre Airline Solutions™. The Sabre team was a characteristically agile team in that they had no need to scale or re-scope XP for their project parameters and organizational environment. The case study compares two releases of the same product. One release was completed just prior to the team’s adoption of the XP methodology, and the other was completed after approximately two years of XP use. Comparisons of the new release project results to the old release project results show a 50 % increase in productivity, a 65 % improvement in pre-release quality, and a 35 % improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result in increased productivity and quality. 1.

Abstract not found

In any software project, developers need to be aware of existing dependencies and how they affect their system. We investigated the architecture and dependencies of Windows Server 2003 to show how to use the complexity of a subsystem’s dependency graph to predict the number of failures at statistically significant levels. Such estimations can help to allocate software quality resources to the parts of a product that need it most, and as early as possible. 1.

Abstract. Constructing comprehensive operational models of intended system behaviour is a complex and costly task. Consequently, practitioners adopt techniques that support partial behaviour decription such as scenario-based specifications, and focus on elaborating these descriptions iteratively. In previous work, we show how this process can be formally supported by Modal Transition Systems (MTSs), observational refinement, and model merging. In this paper, we study a number of properties of merging MTSs and give insights on the implications these results have on engineering and reasoning about behaviour models. We illustrate the utility of our results on a case study. 1

Constructing comprehensive operational models of intended system behavior is a complex and costly task, which can be mitigated by the construction of partial behavior models, providing early feedback and subsequently elaborating them iteratively. However, how should partial behavior models with different viewpoints covering different aspects of behavior be composed? How should partial models of component instances of the same type be put together? In this article, we propose model merging of modal transition systems (MTSs) as a solution to these questions. MTS models are a natural extension of labelled transition systems that support explicit modeling of what is currently unknown about system behavior. We formally define model merging based on weak alphabet refinement, which guarantees property preservation, and show that merging consistent models is a process that should result in a minimal common weak alphabet refinement (MCR). In this article, we provide theoretical results and algorithms that support such a process. Finally, because in practice MTS merging is likely to be combined with other operations over MTSs such as parallel composition, we also study the algebraic properties of merging and apply these, together with the algorithms that support MTS merging, in a case study.

Abstract: This article provides software cost, quality and productivity benchmarks in twelve application-oriented domains that readers can use to determine how well their organizations are performing relative to industry averages. In addition to answering common questions raised relative to these benchmarks, the article summarizes the return on investments firms are realizing as they try to harness new technology for a variety of reasons.

Abstract. Extreme programming (XP), similar to other agile software development methods, values close collaboration with customers. One of the XP's practices suggests that customer should be 100 % available for the development team. Anecdotal evidence suggests that the XP customer role is costly, difficult and demanding. However, very few empirical studies have been published on the customer’s role in an XP project. This paper reports empirical results from a controlled XP case study where the customer was present close to 100 % of the development time. Both quantitative and qualitative data will be presented. Results are in line with the common belief that the on-site customer’s role is demanding and requires a strong ability to resolve issues rapidly but offer contrasting findings in terms of required actual customer involvement in the development project. The empirical case demonstrates that while customer was present close to 100 % with the development team, only 21 % of his work effort was required to assist the team in the development. However, it is also shown that an on-site customer may create a false sense of confidence in to the system under development. The implications of these findings are discussed.

This paper examines practices of eXtreme Programming (XP) on the subject of their application to the development of security solutions. We introduce eXtreme Security Engineering (XSE), an application of XP practices to security engineering, and discuss its potential benefits and the scope of its applicability. We argue that XSE could help achieve "good enough security" while avoiding defining a priori what it is.

In this article, we gather results from several projects we conducted recently that use some kind of agile method. We analyze both academic and governmental software development projects, some of them using agile methods since the beginning and others in which agile methods were introduced afterwards. Our main goals are to classify the different projects, and to analyze the collected data and discover which metrics are best suited to support tracking an agile project. We use both quantitative and qualitative methods, obtaining data from the source code, from the code repository, and from the feedback received from surveys and interviews held with the team members. We use various kinds of metrics such as lines of code, number of tests, cyclomatic complexity, number of commits, as well as combinations of these. In this article, we describe in detail the projects, the metrics, the obtained results, and their analysis from our main goals standpoint, providing guidelines for the use of metrics to track an agile software development project.

Abstract. This paper presents SADAAM, an agent development methodology that utilises agile techniques to facilitate the development and implementation of multi-agent systems. We illustrate SADAAM through a worked example from the Supply Chain Management domain, and implement a partial system using the Agent Factory Framework. 1