Catálogo de publicaciones - libros

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.

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.

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.

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.

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.

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.

Test driven development (TDD) is one of the key Agile practices. A version of 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 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.

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.

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.

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.