Catálogo de publicaciones - libros

The traditional versus agile project debate is most often represented in terms of polar positions of the life cycle – the process is either traditional or agile, waterfall or highly iterative. This may be effective in intellectual discussions, but it is highly unlikely to be useful to practitioners, especially those practitioners that are facing traditional project pressures and trying to find the “home ground” for their situation that will increase the likelihood that they will succeed. In this paper, we discuss extensions to Boehm and Turner’s five dimensions for determining a project’s “home ground” – that is, the process configuration that might best fit the situation at hand. We have added dimensions to the basic framework provided by Boehm and Turner and have considered the process configuration question as a process itself and increased its scope to include both management and engineering key practice areas.

The DICE framework provides means for predicting the outcome of change management initiatives. The four factors: duration, integrity, commitment, and effort are evaluated and a score is calculated. The DICE^® score is used to classify projects into win, worry, or woe zones. In this paper, we apply the DICE^® framework to predict the outcome of a software project that is migrating from waterfall to agile practices. We propose fine-tuning of the four factors to improve the score and show how to use DICE^® for communication with the stakeholders. Finally, we make a claim that evaluation against the DICE^® framework confirms that agile projects have a higher chance of success than traditional waterfall projects.

This paper takes a look at how XP and other agile practices can improve a software process for the development of avionics software. Developers of mission critical airborne software are heavily constrained by the RTCA DO-178B regulations [8]. These regulations impose strict rules regarding traceability and documentation that make it extremely hard to employ an iterative software development process. In particular, the extra validation overhead increases the time spent on small iteration cycles (for example, a bug-fix) to several weeks. Currently, this sector is also pressed to switch to a more agile, customer driven approach. In this paper we investigate how to speed up development and cope with changing requirements using agile techniques. The research was carried out in cooperation with Barco, a major Belgian avionics equipment supplier. We explain why certain agile techniques have less effect as the project progresses. We point out the stadia in which each XP practice is beneficial and where XP practices might cause a slowdown.

This article introduces a new practice to eXtreme Programming (XP): Developer stories. The goal of these stories and their creation process is to incorporate architectural planning to XP thus ensuring a viable architecture. By conducting a small development project using XP, we find that establishing a viable architecture might be problematic. Arguing that architectural quality criteria in XP are traceable to traditional criteria, and by pointing to related work regarding incremental continous design, requirements management and large-scale refactorings, we find support for this claim. We proceed by describing the new practice ensuring that it embraces the values, and supports existing practices of XP.

Due to a number of similarities between user-centred design (UCD) and agile development, coupled with an appreciation that developers are rarely usability experts, it seems attractive to integrate these two approaches. However, although agile methods share some of the same aims as UCD, there are also distinct differences. These differences have made the use of these methods on development projects problematic. This paper reports a field study designed to investigate the use of agile methods alongside UCD in one particular organization. The aim of the study was to develop a framework for use by project teams wishing to integrate UCD practices with agile development. The study, its findings and five principles for integrating UCD and agile development arising from this work are discussed.

Security is a critical part of systems development, particularly for web-based systems. There is little known about how to effectively integrate security into incremental development processes such as Extreme Programming. This paper presents the results of a project that used Extreme Programming practices and deferred consideration of security until system functionality was complete. The findings suggest that refactorings within incremental development processes are capable of delivering high quality security solutions, and provide insights into how security requirements can be incorporated in the planning game.

Large software development projects are not agile by nature. Large projects are not easy to implement, they are even harder to implement using agile methodologies. Based on over 6 years of experience building software systems using agile methodologies we found that we can modify agile methodologies to be successfully applied to large projects. In this paper, we will introduce a development practice, which we call Divide After You Conquer to reduce some of the challenges during the development of large agile projects. By solving the base problem first with a smaller development team (Conquer phase) before expanding the team to its full size (Divide phase) we can solve many of the problems that occur with larger projects using agile methodologies.

Agile approaches including XP and Scrum grew out of one particular team’s practice, so its advice contains hidden assumptions we need to identify. If we do not, we risk seeing these techniques fail a team, or a team fail with these techniques. This report describes one team’s experience learning adaptive planning, and the steps it took to augment the out-of-the-box process that the agile literature suggests. It shows how the team’s environment has motivated these changes while allowing the team to continue to engage in an evidence-based continuous improvement program.

Very little has been written to date on how to prioritize and sequence the development of new features and capabilities on an agile software development project. Agile product managers have been advised to prioritize based on “business value.” While this seems an appropriate goal, it is vague and provides little specific guidance. Our approach to optimizing “business value” uses tactics to minimize costs and maximize benefits through strategic learning. In order to provide specific and actionable advice to agile product managers, we present two guidelines. These guidelines are meant to provide a set of considerations and a process by which an agile product manager can achieve the goal of optimizing “business value” while recognizing that different product managers will vary in their notions of what “business value” is.

This article presents the Automatic Changes Propagation tool, which is used in one of Polish software companies. This system tries to solve the problem of introducing changes in deployed system versions when an error in the head version is found. The tool was created to speed the process of changes propagation for the application used in more than 12 Polish financial institutions. Unfortunately, the customers have different system versions and therefore it is not enough to correct only the newest one. Because the manual changes are time-consuming, monotonous and error-prone the automatic way is very desired. Moreover, the Automatic Changes Propagation tool prepares the application patches which are ready for deployment.