Catálogo de publicaciones - libros

Many authors have presented techniques for using business value to measure and prioritise requirements. Unfortunately, although there is much written about using value in this way, there is very little written about how to measure value itself. This workshop is intended to help the participants answer questions such as: Where does value come from? How do we know what is valuable and what is not? Who determines value? Are there different types of value and, if so, how can we compare them?

The participants will how a pair programming team works. Working in a single pair is different from working on your own: You have to articulate what you want to do, the other person (probably) has some different insights, and the result will be different from what you would have done on your own. But.. this is only half of the story: working in a Pair Programming Team has many more advantages: knowledge is spread, the team creates an own style, parallel development becomes easy, truck factor (http://c2.com/cgi/wiki?TruckNumber) is reduced. The team creates the product (instead of individual programmers creating the parts), the product is a whole, not a mixture of individual results. You will learn about the necessity of agile tools like daily standup meetings, pair rotation, coding standards and collective code ownership, how they work, and what their effects are. You will experience improvements for the quality of you product, and for the productivity of the team.

This workshop will investigate the application of Domain Specific Languages within Agile development. A Domain Specific Language (DSL) is designed to express the requirements and solutions of a particular business or architectural domain. SQL, GUI designers, workflow languages and regular expressions are familiar examples. In recent years, Domain-Specific Modeling has yielded spectacular productivity improvements in domains such as telephony and embedded systems. By creating graphical or textual languages specific to the needs of an individual project or product line within one company, DSM offers maximum agility. With current tools, creating a language and related tool support is fast enough to make DSM a realistic possibility for projects of all sizes.

Methodology adoption issues in the agile world are faced with challenges such as the growing trend towards the use of a group of relevant cross-methodology practices from the agile family as opposed to the adoption of individual methodologies. While this may see agile processes precipitating towards more mature software engineering processes, the challenge is that some of the specific agile methodologies may become extinct over time. This research therefore contributes a key addition to knowledge by developing a thinking tool that will guide system developers to informatively select agile practices from the entire agile methodologies family that are relevant to the project at hand. This paper proposes a novel modeling technique for tailoring methodologies to a particular environment using the family of methodologies approach. The Agile Methodologies Generic (AMG) model considers agile methodologies as a group of methodologies with common parameters that can be used to model the entire group. Based on this model, methodology parameters can be identified that are common among the different agile methodologies making it possible to create a set of relevant agile practices that can be used in an organization. The original concepts of the model are based on two foundations: 1) the philosophy of Jim Highsmith’s Adaptive Software Development (ASD) methodology. ASD focuses on the speculate, collaborate and learn cycle iteratively which is fundamental to agile development, and 2) the concept of organizational maturity levels which says that mature organizations families of repeatable and automated processes. It is from such a perspective that AMG was born. AMG considers agile methodologies at an abstract level where the four values of the Agile Manifesto are assumed to collectively constitute basic philosophy of all agile methodologies. The phases of AMG (mechanistic, organic, and synergistic adaptation) are therefore analyzed in light of the values of the project at hand. The benefits of such a technology is the provision of a thinking tool that assists software development teams to effectively tailor agile methodologies to their project environments. The tool has been applied by two software development organisations and the results are being analysed.

Since the first edition of Beck’s book [1], the Extreme Programming (XP) has attracted attention from academia and industry, and its values, principles and practices are becoming increasingly popular. Strong interest in the software engineering community has generated substantial literature and debate over Extreme Programming. However, current research on the applicability and effectiveness of Extreme Programming is still very scarce and researchers and practitioners need to assess concretely XP’s advantages and drawbacks. One disadvantage, which has been noted, is that Extreme Programming is more effective for small to medium size projects with co-located team. Despite such observation, Beck asserts that XP can work with teams of any size and also multi-site [2]. The main goal of this research is to evaluate the effectiveness of Extreme Programming, when the size of development team is large and distributed.

There are two different approaches to investigate the applicability and effectiveness of a software method: empirical studies and simulation process modeling. These approaches are usually applied separately, but there are many interdependencies between simulation and empirical research. On the one hand simulation model generalizes empirical studies and provides a framework for the evaluation of empirical models. On the other hand, empirical studies provide the necessary fundament for simulation models because through empirical studies it is possible to collect real data to validate the simulation model. In the present research these two approaches are combined.

My research is grounded on the following steps:

The main goal to be answered by this Ph.D. thesis is whether there is a potential for a successful and powerful application of agile methods and related techniques to embedded systems development or not (cf. [2]). Regarding the special context of embedded system, there are some aspects to be mentioned as stated in [3]. These include the function oriented development which lead to early testing of the system, the use of target-processor simulation and the problem of hardware software co-design.

The first problem being addressed is the evaluation of well known sub-techniques like refactoring, TDD, fast development cycles, short design horizon, or similar methods in the context of embedded systems. A complementary approach consists of the elaboration of underlying root causes which make agile methods appear as a sound alternative to classic techniques. For example assumptions like source code degrading over time, non-costumer oriented development, overly complex systems, and wrong development focus could be checked. A possible subdivision of the causes can be done by distinguishing effects that are generated by agile methods and effects that typically exist in embedded system engineering. This can be regarded as an alternative upside down procedure which will more likely yield a justification for agile methods in embedded system development. Finding a causation with an appropriate prioritization appears more challenging and thus will be used only to verify techniques which have a strong effect. The first step toward an assessment of agile methods has been started by executing a study during a lab course which is guided by the ideas described in [1]. Here, the students are divided into a planning group and an agile group, each developing a pre-crash system based on ultrasonic sensors. The two data collection mechanisms are a biweekly survey and a time recording log. The underlying aim is to show the influence of the planning horizon on embedded system development. This approach already sketches the main validation technique, which will be quantitative and composed of case studies and experiments. In addition, a case study with a high degree of variable control as proposed by [4] will be executed in order to guide the evaluation process to the most promising aspects of agile methods for embedded system development.

Agile methods are quickly gaining notoriety amongst software engineers. Having been developed over the past decade, they now present a mature, lightweight alternative to the “classic” approaches to software engineering. Although agile methods have solved some of the problems of established software engineering practice, they have created some problems of their own. Most importantly, we can infer a, potentially problematic, requirement of collocation.

The usefulness of the agile methods is restricted by this requirement of collocation and by the requirement of small development teams. If these requirements can be loosened then it would be possible to apply agile methods to a larger arena of software development. This research intends to extend the usefulness of agile methods by defining a new paradigm for software engineering practice, the “Liberal” paradigm and providing tool support for processes within this paradigm.

The University of Sheffield provides undergraduate students with a real experience of software engineering through a module entitled the Software Hut. Here, 2 year students work in teams competing to build a real business solution for a real commercial client. In this exercise, eXtreme Programming is used. This article provides a few details of this innovative educational programme.

Extreme programming (XP) emphasises the test-first strategy of developing software where if code passes unit tests developers gain more confidence in their software. Jester is a test tester for JUnit tests and thus allows developers to confirm their confidence in their tests and consequently in their code. Jester finds code that is not covered by JUnit tests and thus indicates either missing test cases or the redundancy of code that currently exists. The Eclipse IDE enables developers in any language to independently build tools that when combined together work as if they are part of a single integrated tool set. The implications of this open source IDE as an aid to software engineering are infinite and thus provide an ideal platform to nurture XP practices on.

This paper attempts to describe the author’s experience of working in an XP company, namely Genesys Solutions® and its use of the XP principles. Before understanding how XP is being used in Genesys, the process and the people of the organization must be taken into account. The process used is a formalized XP approach and the people considered are students, since the company is entirely run by students, which is unique to Sheffield. The paper also highlights some of the problems and challenges faced by the practitioners at Genesys Solutions® and also some of the real world advantages of using the XP approach in an academic and industrial background.