Klaas Sikkel

Basic support for cooperative work on the World Wide Web

The emergence and widespread adoption of the World Wide Web offers a great deal of potential in supporting cross-platform cooperative work within widely dispersed working groups. The Basic Support for Cooperative Work (BSCW) project at GMD is attempting to realize this potential through development of web-based tools which provide cross-platform collaboration services to groups using existing web technologies. This paper describes one of these tools, theBSCW Shared Workspace system?a centralized cooperative application integrated with an unmodified web server and accessible from standard web browsers. The BSCW system supports cooperation through “shared workspaces”; small repositories in which users can upload documents, hold threaded discussions and obtain information on the previous activities of other users to coordinate their own work. The current version of the system is described in detail, including design choices resulting from use of the web as a cooperation platform and feedback from users following the release of a previous version of BSCW to the public domain.

A systematic mapping study on empirical evaluation of software requirements specifications techniques

This paper describes an empirical mapping study, which was designed to identify what aspects of Software Requirement Specifications (SRS) are empirically evaluated, in which context, and by using which research method. On the basis of 46 identified and categorized primary studies, we found that understandability is the most commonly evaluated aspect of SRS, experiments are the most commonly used research method, and the academic environment is where most empirical evaluation takes place.

Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study

Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations. We found that some explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. These are (i) the driving role of the client in the value creation process, (ii) the prevailing position of business value as a main prioritization criterion, (iii) the role of the prioritization process for project goal achievement. This implies that these assumptions have to be reframed and that the approaches to requirements prioritization for value creation need to be extended.

Value Creation by Agile Projects: Methodology or Mystery?

Business value is a key concept in agile software development approaches. This paper presents results of a systematic review of literature on how business value is created by agile projects. We found that with very few exceptions, most published studies take the concept of business value for granted and do not state what it means in general as well as in the specific study context. We could find no study which clearly indicates how exactly individual agile practices or groups of those create value and keep accumulating it over time. The key implication for research is that we have an incentive to pursue the study of value creation in agile project by deploying empirical research methods.

A group-based authorization model for cooperative systems

Requirements for access control in CSCW systems have often been stated, but groupware in use today does not meet most of these requirements. There are practical reasons for this, but one of the problems is the inherent complexity of sophisticated access control models. We propose a general authorization model that emphasizes conceptual simplicity and show that several issues-in particular negative access rights and delegation of rights-can be solved elegantly in this model.

Deciding to adopt requirements traceability in practice

The use of requirements traceability for information systems development (ISD) projects is not very common in practice despite its often mentioned advantages in the literature. We conducted a case study in a large IT company to identify the factors that are relevant for the decision whether or not to adopt traceability in an ISD project. Five dominant factors emerged: development organization awareness, customer awareness, return on investment, stakeholder preferences, and process flow. It turned out that the majority of the software development project leaders we interviewed were not aware of the concept of traceability - with the obvious result that using traceability in software project is not even considered. This fact has possibly been underestimated in the present literature of requirements engineering.

Using Shared Workspaces in Higher Education

The use of BSCW shared workspaces in higher education is evaluated by means of a comparison of seven courses in which this environment was used. A number of different functions for which the BSCW environment has been used are identified and the relative success of these functions across the cases is discussed. In addition, the cases are evaluated by means of a model that predicts the chances of acceptance of ICT in an educational setting. Effectiveness for a given task appears to be a prime success factor for using ICT, but an effective tool may fail due to other factors such as ease of use and organizational, socio-cultural or technological obstacles. The particular strength of a shared workspace, for which BSCW is most effective and efficient, is providing a repository for objects of collaborative work. Other types of usage showed mixed results.

Generalizing by similarity: lessons learnt from industrial case studies

Large IT vendors execute thousands of projects in a variety of business domains and environments. Over the years, they end up repeatedly developing and deploying systems for a given domain in the same country, sometimes even for the same company. It would save them a lot of cost and effort if they could reliably depend on their past experience and draw insights from lessons learnt in the past. However, this requires them to generalize from past projects to a similar current project. In this paper we draw lessons learnt from three industrial case studies on how to generalize by similarity.

Business value is not only dollars – results from case study research on agile software projects

Business value is a key concept in agile software development. This paper presents results of a case study on how business value and its creation is perceived in the context of agile projects. Our overall conclusion is that the project participants almost never use an explicit and structured approach to guide the value creation throughout the project. Still, the application of agile methods in the studied cases leads to satisfied clients. An interesting result of the study represents the fact that the agile process of many projects differs significantly from what is described in the agile practitioners’ books as best practices. The key implication for research and practice is that we have an incentive to pursue the study of value creation in agile projects and to complement it by providing guidelines for better client’s involvement, as well as by developing structured methods that will enhance the value-creation in a project.

Explaining IT Implementation Through Group Learning

Implementation of an information technology IT system in an organization takes a certain amount of time. System usage becomes stable when users have appropriated the system and new work practices have been established. We propose a concept of group learning as a framework to highlight relevant aspects of such a process. A longitudinal case study with two opposite research results has provided a preliminary validation of the proposed model. A human resource information system HRIS was introduced in a hospital in two different settings. With one user group it was successfully implemented, and it failed in the other group. Analysis of the qualitative data shows a marked difference in the group learning processes between the two groups, which significantly contribute to the differences in success. These results confirm our assumption about the importance of learning processes in groupware implementation.