papers

PP01 Paper Presentation: Experience Reports

Session Chair: David Hussman

Lean Software Management Case Study: Timberline Inc. by Peter Middleton, Amy Flaxel, Ammon Cookson
This paper is believed to be the first documented account of a full adoption of lean by a software company. Lean techniques were devised by Toyota and other manufacturers over the last 50 years. The techniques are termed lean because they require less resource to produce more product and exceptional quality. Lean ideas have also been successful in service industries and product development. Applying lean to software has been advocated for over 10 years. Timberline, Inc started their lean initiative in Spring 2001 and this paper records their journey, results and lessons learned up to Fall 2003. This case study demonstrates that lean thinking can work successfully for software developers. It also indicates that the extensive lean literature is a valuable source of new ideas for software engineering.

XP South of the Equator: An Experience Implementing XP in Brazil by Alexandre Freire, Fabio Kon, Cicero Torteli
Many have reported successful experiences using XP, but we have not yet seen many experiences adapting agile methodologies in developing countries such as Brazil. In a developing economy, embracing change is extremely necessary. This paper relates our experience successfully introducing XP in a start-up company in Brazil. We will cover our adaptations of XP practices and how cultural and economical aspects of the Brazilian society affected our adoption of the methodology. We will discuss how we managed to effectively coach a team that had little or no previous skill of the technologies and practices adopted. We will also cover some new practices that we introduced mid-project and some practices we believe emerged mostly because of Brazilian culture. The lessons we learned may be applicable in other developing countries.

Introducing Extreme Programming into a Software Project at the Israeli Air Force by Yael Dubinsky, Orit Hazzan, Arie Keren
Introducing Extreme Programming (XP) to an industrial software development team usually involves technical and professional aspects as well as social and organizational ones. The introducing of a new software development method in general and XP in particular into a software project team that operates in the army emphasizes and extends these issues. In this paper we present a process through which XP has been introduced into a 60-members software development project at the Israeli Air Force. Focus is placed on an XP workshop conducted with ten officers who worked at different teams of the project. Specifically, we present the principles according to which we facilitated the workshop, the workshop agenda and data regarding the way the participants perceive some of the XP practices. Recently, the first XP team in this project has started to work the XP way.

The Agile Journey: Adopting XP in a Large Financial Services Organization by Jeff Nielsen, Dave McMunn
On January 14, 2004, two vice presidents met with a group of directors, project managers, and developers, and indicated their desire to embrace agile software development as “the way forward” in their organization. This was not the beginning of this company’s adoption of XP and Agile Methodologies, but rather the culmination of almost two and a half years of learning, experimentation, prototyping, and promotion. Making change “stick” in any large organization is problematic, and dramatically changing the way a risk-averse, highly-regulated company develops software requires more than just a successful pilot and a couple of months of coaching. This experience report documents the “agile journey” undertaken by one such corporation between 2001 and 2004. They began by outsourcing a small effort to an XP-proficient consulting firm, and proceeded to use agile techniques on a series of increasingly-significant efforts, allowing sufficient time for the new approach to gain acceptance. In retrospect, all parties involved now believe that the slow, gradual approach to XP adoption–building on incremental successes project by project–was the key to its success.

PP02 Paper Presentation: New Insights

Session Chair: Sandro Pinna

From User Stories to Code in One Day? by Michal Smialek
User stories in software engineering serve the purpose of discovering requirements and are used as units of system development. When applying stories in a project, two elements seem to be crucial: the ability to write coherent sequences of events and the ability to transform these sequences into code quickly and resourcefully. In this paper, these qualities are reflected in a notation that can be described as “stories with notions”. This notation separates the story’s sequence of events from the description of terms used in this sequence. Such a formal separation does not limit and rather enhances invention, at the same time rising the level of consistence, and facilitating translation into models of code. This translation maps domain notions into static code constructs (classes, interfaces) and also maps stories into dynamic sequences of messages. With such a mapping, programming becomes equivalent to skilled transformation of user stories, thus giving shorter development cycles.

Evaluate XP Effectiveness using Simulation Modeling by Alessandra Cau, Giulio Concas, Marco Melis, Ivana Turnu
Effectively evaluating the capability of a software development methodology has always been very difficult, owing to the number and variability of factors to control. Evaluating XP is by no way different under this respect. In this paper we present a simulation approach to evaluate the applicability and effectiveness of XP process, and the effects of some of its individual practices. Such approaches using simulation are increasing popular because they are inexpensive and flexible. Of course, they need to be calibrated with real data and complemented with empirical research. The XP process has been modelled and a simulation executive has been written, enabling to simulate XP software development activities. The model follows an object-oriented approach, and has been implemented in Smalltalk language, following XP process itself. It is able to vary the usage level of some XP practices and to simulate how all the project entities evolve consequently.

Agile Security using an Incremental Security Architecture by Howard Chivers, Richard Paige, Xiaocheng Ge
The effective provision of security in an agile development requires a new approach: traditional security practices are bound to equally traditional development methods. However, there are concerns that security is difficult to build incrementally, and can prove prohibitively expensive to refactor. This paper describes how to grow security, organically, within an agile project, by using an incremental security architecture which evolves with the code. The architecture provides an essential bridge between system-wide security properties and implementation mechanisms, a focus for understanding security in the project, and a trigger for security refactoring. The paper also describes criteria that allow implementers to recognize when refactoring is needed, and a concrete example that contrasts incremental and ‘top-down’ architectures.

Quantifying Requirements Risk by Fred Tingey
It is possible to apply Information Theory to the Software Development process – an approach I have dubbed ‘Iterative Theory’. Focusing on the user requirements Iterative Theory is introduced and then used to quantify how the choice of development methodology affects the ‘value at risk’ on a software project. The central theme is that end-user requirements cannot be described exactly resulting in an inherent uncertainty in the correctness of any specification. This uncertainty can only be removed by receiving feedback on working software. Iterative Theory assumes that every requirement is expressed in terms of empirical tests thus it is possible to speak of working software as an implementation that passes all of its tests – although it may still fail end user acceptance testing. The implication of changing requirements is touched upon; this simply bolsters the argument for Iterative Development as a way of reducing risk. Iterative Theory, the application of Information Theory to the software development process, is certainly an area requiring further study.

PP03 Paper Presentation: Testing

Session Chair: Charlie Poole

A Survey of Test Notations and Tools for Customer Testing by Adam Geras, James Miller, Michael Smith, James Love
The term ‘customer testing’ typically refers to the functional, or correctness testing of software-intensive systems. The tests are typically described and automated in a test-first manner, that is, they exist before the target system is built. This is generally believed to have improved the testability, and perhaps the overall quality, of the systems under test. With the increasing utility and functionality of mobile and pervasive computing systems, we speculate that the need to include non-functional test cases (performance, security, usability, etc.) under the ‘test-first’ umbrella will increase. In this paper, we review the capability of existing test notations and tools to describe and execute, in a test-first style, non-functional test cases. This concept challenges the default agile position of delegating non-functional tests cases to traditional, test-last test techniques.

Testing with Guarantees and the Failure of Regression Testing in eXtreme Programming by Anthony Simons
The eXtreme Programming (XP) method eschews all formal design, but compensates for this by rigorous unit testing. Test-sets, which constitute the only enduring specification, are intuitively developed and so may not be complete. This paper presents a method for generating complete unit test-sets for objects, based on simple finite state machines. Using this method, it is possible to prove that saved regression test-sets do not provide the expected guarantees of correctness when applied to modified or extended objects. Such objects, which pass the saved tests, may yet contain introduced faults. This puts the whole practice of regression testing in XP into question. To obtain the same level of guarantee, tests must be regenerated from scratch for the extended object. A notion of guaranteed, repeatable quality after testing is defined.

Examining Usage Patterns of the FIT Acceptance Testing Framework by Kris Read, Grigori Melnik, Frank Maurer
Executable acceptance testing allows both to specify customers’ expectations in the form of the tests and to compare those to actual results that the software produces. The results of an observational study identifying patterns in the use of the FIT acceptance testing framework are presented and the data on acceptance-test driven design is discussed.

Agile Test Composition by Rick Mugridge, Ward Cunningham
Storytests in storytest driven development serve two interrelated goals. On the one hand, they are used to formulate and communicate business rules. On the other, they are used to verify that a story has been completed and that it hasn’t been subsequently broken. There is a small conflict between these views. For their communicative role, storytests are better to be concise and independent. For automated testing, speed is important in providing fast feedback, and so it makes sense to combine storytests. We show how this conflict can be avoided by automatically combining storytests. Hence the value of storytests for defining the needs of the system is not diminished when it comes to automated testing.

PP04 Paper Presentation: Social Issues

Session Chair: Michael Hill

Social Perspective of Software Development Methods: The Case of the Prisoner Dilemma and Extreme Programming by Orit Hazzan, Yael Dubinsky
One of the main dilemmas with which software development teams face is how to choose a software development method that suits the team as well as the organization. This article suggests a theory that may help in this process. Specifically, Extreme Programming (XP) is analyzed within the well known framework of the prisoner dilemma. We suggest that such an analysis may explain in what situations XP may fit for implementation and, when it is used, the way it may support software development processes.

A Framework for Understanding the Factors Influencing Pair Programming Success by Mustafa Ally, Fiona Darroch, Mark Toleman
Pair programming is one of the more controversial aspects of several Agile system development methods, in particular eXtreme Programming (XP). Various studies have assessed factors that either drive the success or suggest advantages (and disadvantages) of pair programming. In this exploratory study the literature on pair programming is examined and factors distilled. These factors are then compared and contrasted with those discovered in our recent Delphi study of pair programming. Gallis et al. (2003) have proposed an initial framework aimed at providing a comprehensive identification of the major factors impacting team programming situations including pair programming. However, this study demonstrates that the framework should be extended to include an additional category of factors that relate to organizational matters. These factors will be further refined, and used to develop and empirically evaluate a conceptual model of pair programming (success).

Empirical Study on the Productivity of the Pair Programming by Gerardo Canfora, Aniello Cimitile, Corrado Aaron Visaggio
Many authors complain the lack of empirical studies which assess the benefits and the drawbacks of agile practices. Particularly, pair programming rises an interesting question for managers: does pair programming mean to pay two developers in the place of one? We realized an experiment to compare the productivity of a developer when performing pair programming and when working as solo programmer. We obtained empirical evidence that pair programming decreases the effort of the single programmer.

The social side of technical practices by Hugh Robinson, Helen Sharp
XP is a social activity as well as a technical activity. The social side of XP is emphasized typically in the values and principles which underlie the technical practices. However, the fieldwork studies we have carried out with mature XP teams have shown that the technical practices themselves are also intensely social: they have social dimensions that arise from and have consequences for the XP approach. In this paper, we report on elements of XP practice that show the social side of several XP practices, including test-first development, simple design, refactoring and on-site customer. We also illustrate the social side of the practices in combination through a thematic view of progress.

PP05 Paper Presentation: Tools

Session Chair: Yael Dubinsky

E-TDD — Embedded Test Driven Development: A Tool for Hardware-Software Co-design Projects by Michael Smith, Andrew Kwan, Alan Martin, James Miller
Test driven development (TDD) is one of the key Agile practices. A version of CppUnitLite was modified to meet the memory and speed constraints present on self-contained, high performance, digital signal processing (DSP) systems. The specific characteristics of DSP systems required that the concept of refactoring be extended to include concepts such as ‘refactoring for speed’. We provide an experience report describing the instructor-related advantages of introducing an embedded test driven development tool E-TDD into third and fourth year undergraduate Computer Engineering Hardware-Software Co-design Laboratories. The TDD format permitted customer (instructor) hardware and software tests to be specified as ‘targets’ so that the requirements for the components and full project were known ‘up-front’. Details of CppUnitLit extensions necessary to permit tests specific for a small hardware-software co-design project, and lessons learnt when using the current E-TDD tool, are given. The next stage is to explore the use of the tool in an industrial context of a video project using the hybrid communication-media (HCM) dual core Analog Devices ADSP-BF561 Blackfin processor.

Multi-criteria detection of bad smells in code using UTA method by Bartosz Walter, Blazej Pietrzak
Bad smells are indicators of inappropriate code design and implementation. They suggest a need for refactoring, i.e. restructuring the program towards better readability, understandability and eligibility for changes. Smells are defined only in terms of general, subjective criteria, which makes them difficult for automatic identification. Existing approaches to smell detection base mainly on human intuition, usually supported by code metrics. Unfortunately, these models do not comprise the full spectrum of possible smell symptoms and still are uncertain. In the paper we propose a multi-criteria approach for detecting smells adopted from UTA method. It learns from programmer’s preferences, and then combines the signals coming from different sensors in the code and computes their utility functions. The final result reflects the intensity of an examined smell, which allows the programmer to make a ranking of most onerous odors.

An Eclipse Plugin to Support Agile Reuse by Frank McCarey, Mel O Cinneide, Nicholas Kushmerick
Reuse in an Agile context is largely an unexplored research topic. On the surface, these two software engineering techniques would appear to be incompatible due to contradictory principles. For example, Agile components are usually accompanied with little or no support materials, which is likely to hamper their reuse. However we propose that Agile Reuse is possible and indeed advantageous. We have developed an Eclipse plug-in, named RASCAL, to support Agile Reuse. RASCAL is a recommender agent that infers the need for a reusable component and proactively recommends that component to the developer using a technique consistent with Agile principles. We present the benefits and the challenges encountered when implementing an Agile Reuse tool, paying particular to attention to the XP methodology, and detail our recommendation technique. Our overall results suggest RASCAL is a promising approach for enabling reuse in an Agile environment.

Automated Acceptance Testing: Expressing Requirements as Tests by Robert Martin
One of the keystones of the Agile Methods is automated acceptance testing. In Agile Projects requirements are expressed as executable tests. These tests are written in a high level language that is easily understood by business analysts and stakeholders. The tests are written by collaboration between the business analysts, QA, and the developers. These tests are accumulated on an intranet site and can be run by any project stakeholder at any time. The number of tests passing gives a clear indication of what is working, what isn’t working, and how much progress the team is making on a day to day basis. In this talk the speaker demonstrates FitNesse, an open source tool for organizing, expressing and executing acceptance tests. He describes the process for writing and executing these tests, and discusses the experiences of teams that are using this approach.

PP06 Paper Presentation: Case Studies

Session Chair: Daniel Karlström

An Approach for Assessing Suitability of Agile Solutions: A Case Study by Minna Pikkarainen, Ulla Passoja
Dynamic market situation and changing customer requirements generate more demands for the product development. Product releases should be developed and managed in short iterations answering to the rapid external changes and keeping up a high quality level. Agile practices (such as the best practices in Extreme Programming and Scrum) offer a great way of monitoring and controlling rapid product development cycles and release development. One problem in product development projects, however, is how to apply agile methods and principles as a part of the complex product development. The purpose of this paper is to describe, how Agile Assessment was conducted in a case company in order to support product development and customer support improvement. During the experiment it was found that Agile Assessment is an efficient method to clarify what agile practices are suitable for the organization’s product development and customer co-operation. Another finding was that the use of the best suitable agile practices would improve incremental development monitoring and traceability of requirements.

XP Expanded: Distributed Extreme Programming by Keith Braithwaite, Tim Joyce
Colocation has come to be seen as a necessary precondition for obtaining the majority of the benefits of XP. Without colocation teams expect to struggle, to compromise and to trade off the benefits of XP vs the benefits of distributed development. We have found that you can stay true to the principles and not compromise the practices of XP in a distributed environment. Thus, business can realize both the benefits of distributed and of truly agile development.

A Case Study on Naked Objects in Agile Software Development by Heikki Kernen, Pekka Abrahamsson
Naked Objects and agile software development have been suggested to complement each other. Very few empirical studies to date exist where a product has been developed using the Naked Objects technologies in an agile development environment. This study reports results of a case study where a mobile application was developed using the Naked Objects Framework. Qualitative and quantitative data was collected systematically throughout the project. The empirical results offer support for the argument that the Naked Objects approach is suitable for agile software development. The results also reveal weak-nesses in the current Naked Object Framework, namely, that it is not yet mature enough for applications that require intense database operations. The results also show that the development team was able to create an operational user interface just in five hours, which demonstrates the applicability of the Naked Object Framework in practical settings.