H.-Christian Estler

Agile vs. Structured Distributed Software Development: A Case Study

This paper presents a case study on the impact of development processes on the success of globally distributed software projects. The study compares agile (Scrum, XP, etc.) vs.\ structured (RUP, waterfall) processes to determine if the choice of process impacts: the overall success and economic savings of distributed projects; the importance customers attribute to projects; the motivation of the development teams; and the amount of real-time or asynchronous communication required during project development. The case study includes data from 66 projects developed in Europe, Asia, and the Americas. The results show no significant difference between the outcome of projects following agile processes and structured processes, suggesting that agile and structured processes can be equally effective for globally distributed development. The paper also discusses several qualitative aspects of distributed software development such as the advantages of near shore vs. offshore, the preferred communication patterns, and some common critical aspects.

How Do Distribution and Time Zones Affect Software Development? A Case Study on Communication

Software projects have crossed seas and continents looking for talented developers, moving from local developments to geographically distributed projects. This paper presents a case study analyzing the effect of distribution and time zones on communication in distributed projects. The study was performed in a university course during two semesters, where students developed projects jointly with teams located in ten different countries in South America, Europe, and Asia. The study compares the results of the projects distributed in two locations with projects distributed in three locations. It also analyzes projects in different time zone ranges. The initial results show that the amount of communication in projects distributed in two locations is bigger than the communication in projects distributed in three locations. We also found that projects in closer time zones have more communication than projects in farther time zones. Furthermore, we analyze the reply time for e-mails of projects distributed in different time zones, and discuss the challenges faced by the students during these projects.

Contracts in Practice

Contracts are a form of lightweight formal specification embedded in the program text. Being executable parts of the code, they encourage programmers to devote proper attention to specifications, and help maintain consistency between specification and implementation as the program evolves. The present study investigates how contracts are used in the practice of software development. Based on an extensive empirical analysis of 21 contract-equipped Eiffel, C#, and Java projects totaling more than 260 million lines of code over 7700 revisions, it explores, among other questions: 1 which kinds of contract elements preconditions, postconditions, class invariants are used more often; 2 how contracts evolve over time; 3 the relationship between implementation changes and contract changes; and 4 the role of inheritance in the process. It has found, among other results, that: the percentage of program elements that include contracts is above 33% for most projects and tends to be stable over time; there is no strong preference for a certain type of contract element; contracts are quite stable compared to implementations; and inheritance does not significantly affect qualitative trends of contract usage.

An experiment on teaching coordination in a globally distributed software engineering class

The importance of planning and management skills in software development is very difficult to convey in software engineering courses. We present the synopsis of an assignment whose purpose is to demonstrate the significance of such skills, including effective communication, team coordination and collaboration, and overall project planning. The assignment is organized in the context of a distributed software engineering course carried out in collaboration with 12 universities in South America, Europe and Africa. The assignment is a globally distributed contest issued before most development activities related to the courses software project are performed, aiming at favoring the collaboration between students prior to project development. The contest does not involve any programming, and is not related to the project development activities. Instead, it consists of making teams in different countries compete in collaboratively solving a set of very simple tasks. The complexity of the activity is in team collaboration and coordination, and their lack is evident when the tasks are not correctly solved, or not solved in time. Despite the simplicity of the as-signment, students have found it useful in helping them understand the significance of management and planning challenges in distributed software development. Moreover, the assignment helped in team building, by creating a better team atmosphere and contributing in identifying team members better suited for management.

Collaborative Debugging

Debugging - the process of finding and correcting programming mistakes - faces too the challenges of distributed and collaborative development. The debugging tools commonly used by programmers are integrated into traditional development environments such as Eclipse or Visual Studio, and hence do not offer specific features for collaboration or remote shared usage. In this paper, we describe CDB, a debugging technique and integrated tool specifically designed to support effective collaboration among developers during shared debugging sessions. We also discuss the design and results of an empirical study aimed at identifying features that can ameliorate the effectiveness of collaborative debugging processes, and at evaluating the usefulness of our CDB collaborative debugging approach. The study suggests that CDBs collaboration features are often perceived as important for effective debugging, and can improve the overall debugging experience in collaborative settings.

Alloy as a Refactoring Checker

Refactorings are systematic changes made to programs, models or specifications in order to improve their structure without changing the externally observable behaviour. We will examine how a constraint solver (the Alloy Analyzer) can be used to automatically check if refactorings, applied to a formal specification (written in Z), meet this requirement. Furthermore, we identify a class of refactorings for which the use of this tool is reasonable in general.

Modelchecking Correctness of Refactorings - Some Experiments

Refactorings are changes made to programs, models or specifications with the intention of improving their structure and thus making them clearer, more readable and re-usable. Refactorings are required to be behaviour-preserving in that the external behaviour of the program/model/specification remains unchanged. In this paper we show how a simple type of refactorings on object-oriented specifications (written in Object-Z) can be formally shown to be behaviour-preserving using a modelchecker (SAL). The class of refactorings treated covers those operating on a single method only.

A spreadsheet-like user interface for combinatorial multi-objective optimization

We present Moolloy, a general purpose, spreadsheet-like user interface for combinatorial multi-objective optimization. Current user interfaces for multi-objective optimization tend to either require some programming experience to use, or are narrowly focused on specific problems. Consequently, multi-objective optimization is usually only used by sophisticated technical workers, such as aerospace engineers. Moolloy makes multi-objective optimization accessible to a larger set of potential users.