Yvonne Dittrich

Component-based technologies for end-user development

Component-based software development (CBSD) involves multiple roles. Framework builders create the infrastructure for components to interact; developers identify suitable domains and develop new components for them; application assemblers select domain-specific components and assemble them into applications; and end users employ component-based applications to perform daily tasks [7].

The Success Factors Powering Industry-Academia Collaboration

Collaboration between industry and academia supports improvement and innovation in industry and helps to ensure industrial relevance in academic research. This article presents an exploratory study of the factors for successful collaboration between industry and academia in software research.

ERP Customization as Software Engineering: Knowledge Sharing and Cooperation

Enterprise resource planning (ERP) vendors provide multiple configuration possibilities ranging from module selection to master data provision to steer access rights for different users. These configuration possibilities cover anticipated variability. If the customer requires adaptation beyond whats anticipated, the source code of the product must be adapted. Customizations in this articles context are source code based adaptations of software products. The size and complexity of customizations range from simple report generation to developing independent add-ons that support specific businesses, for example, solutions for flight carriers. The size and lead time of such projects can compare to a full-size software development project. Enterprise resource planning (ERP) systems must be configured and customized to fit a specific company. The authors discuss cooperation with regard to ERP systems customization.

How agile are industrial software development practices

Representatives from the agile development movement claim that agile ways of developing software are more fitting to what is actually needed in industrial software development. If this is so, successful industrial software development should already exhibit agile characteristics. This article therefore aims to examine whether that is the case. It presents an analysis of interviews with software developers from five different companies. We asked about concrete projects, both about the project models and the methods used, but also about the real situation in their daily work. Based on the interviews, we describe and then analyze their development practices. The analysis shows that the software providers we interviewed have more agile practices than they might themselves be aware of. However, plans and more formal development models also are well established. The conclusions answer the question posed in the title: It all depends! It depends on which of the different principles you take to judge agility. And it depends on the characteristics not only of the company but also of the individual project.

When Plans do not Work Out: How Plans are Used in Software Development Projects

Based on empirical material from the area of software engineering, this article discusses the issue of plans and planning as an integral part of and prerequisite for software development work. It relates observed practices to literature produced by the Computer Supported Cooperative Work community. Empirical studies of software development practice seldom address re-planning. By analyzing the empirical material from one project we are able to show how certain kinds of co-ordination problems arise and how they may be dealt with. The empirical research does not focus primarily on the character of plans; instead, it raises the question ‘what means are necessary and should be provided in order to cope with situations when plans do not work out? In relation to plans, especial emphasis is on “due process”, i.e. how the project plan and the company wide project model are maintained to enable the identification and articulation of deviations from it. On the basis of our empirical analysis we propose to support the articulation and coordination work necessary in situations where plans do not adequately work out.

Empirical studies on the use of social software in global software development : A systematic mapping study

Abstract Background In Global Software Development (GSD), informal communication and knowledge sharing play an important role. Social Software (SoSo) has the potential to support and foster this key responsibility. Research on the use of SoSo in GSD is still at an early stage: although a number of empirical studies on the usage of SoSo are available in related fields, there exists no comprehensive overview of what has been investigated to date across them. Objective The aim of this review is to map empirical studies on the usage of SoSo in Software Engineering projects and in distributed teams, and to highlight the findings of research works which could prove to be beneficial for GSD researchers and practitioners. Method A Systematic Mapping Study is conducted using a broad search string that allows identifying a variety of studies which can be beneficial for GSD. Papers have been retrieved through a combination of automatic search and snowballing , hence a wide quantitative map of the research area is provided. Additionally, text extracts from the studies are qualitatively synthesised to investigate benefits and challenges of the use of SoSo. Results SoSo is reported as being chiefly used as a support for collaborative work, fostering awareness, knowledge management and coordination among team members. Contrary to the evident high importance of the social aspects offered by SoSo, socialisation is not the most important usage reported. Conclusions This review reports how SoSo is used in GSD and how it is capable of supporting GSD teams. Four emerging themes in global software engineering were identified: the appropriation and development of usage structures; understanding how an ecology of communication channels and tools are used by teams; the role played by SoSo either as a subtext or as an explicit goal; and finally, the surprising low percentage of observational studies.

Making e-government happen everyday co-development of services, citizenship and technology

In a joint research project concerning the use and design of IT in public services, we are using a simple figure of on-going design-oriented interactions to highlight shifting foci on relationships of co-development of services, citizenship and technology. We bring together a number of concrete examples of this on-going everyday co-development, presented from the different perspectives that we, as researchers from different disciplines and traditions, represent in the project. The article explores and discusses working relations of technology production and use that we see as central to what is actually making e-government happen - or not happen. The main challenge in this area, as we see it, concerns making visible, and developing supportive infrastructures for, the continuing local adaptation, development and design in use of integrated IT and public services.

Exploring the Role of Instant Messaging in a Global Software Development Project

Communication plays a vital role in software development projects. Globally distributed teams use a mix of different communication channels to get the work done. In this paper, we report on an empirical study of a team distributed across Denmark and India. This paper explores the integration of formal documentation, bug-tracking systems and email with informal communication on Instant Messaging (IM), screen sharing, and audio conversations. Whenever overlap times occur, informal communication can take place at the same time in different sites, and it can effectively complement formal documentation. Our analysis provides an indication that IM can play a special role in such socio-technical communication systems: IM acts as a real time glue between different channels. The communication through IM also provides a means to build trust and social relationships with co-workers.

Software engineering beyond the project - Sustaining software ecosystems

Abstract Context The main part of software engineering methods, tools and technologies has developed around projects as the central organisational form of software development. A project organisation depends on clear bounds regarding scope, participants, development effort and lead-time. What happens when these conditions are not given? The article claims that this is the case for software product specific ecosystems. As software is increasingly developed, adopted and deployed in the form of customisable and configurable products, software engineering as a discipline needs to take on the challenge to support software ecosystems. Objective The article provides a holistic understanding of the observed and reported practices as a starting point to device specific support for the development in software ecosystems. Method A qualitative interview study was designed based on previous long-term ethnographical inspired research. Results The analysis results in a set of common features of product development and evolution despite differences in size, kind of software and business models. Design is distributed and needs to be coordinated across heterogeneous design constituencies that, together with the software, build a product specific socio-technical ecosystem. The technical design has to support the deference of part of the development not only to 3rd-party developers but also to local designers tailoring the software in the use organisation. The technical interfaces that separate the work of different design constituencies are contested and need to be maintained permanently. Development takes place as cycles within cycles – overlaying development cycles with different rhythms to accommodate different evolution drivers. Conclusion The reported practices challenge some of the very core assumptions of traditional software engineering, but makes perfect sense, considering that the frame of reference for product development is not a project but continuous innovation across the respective ecosystem. The article provides a number of concrete points for further research.

How use¿oriented development can take place

Abstract Usability is still a problem for software development. As the introduced software changes the use context, use qualities cannot be fully anticipated. Close co-operation between users and developers during development has been proposed as a remedy. Others fear such involvement of users as it might jeopardize planning and control. Based on the observation of an industrial project, we show how user participation and control can be achieved at the same time. The present article discusses the specific measures that allowed for co-operation between users and developers in an industrial context. It indicates measures to improve software development by focusing on use-orientation, i.e. allowing for user–developer co-operation.