Many universities have experienced an increase in the intake of students and at the same time cuts in the budgets for teaching. Many teachers have discovered, for a number of reasons, that they have to adjust their teaching or even a course with short notice. These facts pose a challenge to the teachers' agility in adapting to changes-and in doing it in a cost-efficient way.We propose eXtreme Teaching as a framework that allows teachers to focus on experimenting with and improving their teaching techniques without compromising quality. The framework and the associated practices provide quick, accurate feedback that teachers can act on. eXtreme Teaching will allow better student learning, stronger relationships with the students, increased interaction and development of the staff involved, less risk-and probably happier staff members.In this paper, we will describe the eXtreme Teaching framework and discuss and motivate its background.

Projects where developers are geographically distributed and with high personnel turnover are usually considered to be hard to manage. Any organisation that successfully handles such projects merits closer analysis so that lessons can be learned and good practice disseminated. Open Source Software projects represent such a case. One important factor is good configuration management practices. In this paper, the authors examine the configuration management process for some Open Source Software projects and analyse how process, tool support, and people aspects of configuration management contribute to this success. Finally, we discuss best practices and how lessons learned from Open Source Software can be transferred to more traditional ways of developing software. How do they do it-can we make their implicit configuration management process explicit so that it can be repeated? If a (commercial) company wants to start an OSS project, what should they then look out for and how should they handle the configuration management task? Research question #2: Why are they successful? What are the factors that contribute to their success? What configuration management tasks are they doing better than traditional projects? Are they putting restrictions on the project and thus obtaining a simpler process? Research question #3: What can CS projects learn from it? What configuration management lessons can and cannot be transferred from OSS projects to CS projects-and vice versa. Version Control: The possibility to store different versions and variants of a document and to subsequently be able to retrieve and compare them. Build Management: Mechanisms for collecting all the source modules of a system and generating the system, and for keeping the generated files up to date, preferably without doing any unnecessary work. Configuration Selection: Functionality to choose the versions of different documents or modules that constitutes a complete and consistent system. Workspace Management: Developers often want to work transparently with the configurations without being bothered with versioning or seeing the changes of others working on the same configuration. Concurrency Control: Manages the simultaneous access by several users (i.e. concurrent development), either by preventing it or by supporting it. Helps in synchronising the work of the developers. Change Management: A system supporting the management of the collection of change requests, the generation of error reports, firm change requests, implementation of those changes, documentation of the problem and the solution, and when it is available. Release Management: The identification and organisation of all documents and assets incorporated in a release. The build manager is responsible for providing the packaged product with the correct configuration and features.

Abstract. Versioning of components in a system is a well-researched field where various adequate techniques have already been established. In this paper, we look at how versioning can be extended to cover also the structural aspects of a system. There exist two basic techniques for versioning -intentional and extensional -and we propose a unified extensional versioning model for versioning of both components and structure in the same way. The unified model is described in detail and three different policies that can be implemented on top of the general model are exemplified/illustrated by three prototype tools constructed by the authors. The model is analysed with respect to the number of versions and configurations it generates and has to manage. Finally, the unified extensional model is compared to more traditional intentional models on some important parameters. The conclusions are that the unified model is indeed viable. It not only provides the functionality offered by the intentional model with respect to flexibility during development and management of combinatoric complexity, but also offers a framework for management of configurations that enables systems to provide much more advanced support than is commonly available.

This paper reports on experience from teaching basic software engineering concepts by using Extreme Programming in a second year undergraduate course taken by 107 students. We describe how this course fits into a wider programme on software engineering and technology and report our experience from running and improving the course. Particularly important aspects of our setup includes team coaching (by older students) and "teamin-one-room". Our experience so far is very positive and we see that students get a good basic understanding of the important concepts in software engineering, rooted in their own practical experience.

No abstract