An Experience Base with Rights Management for Global Software Engineering

Anna Averbakh
Leibniz Universitt Hannover Welfengarten 1 30167 Hannover

Eric Knauss
Leibniz Universitt Hannover Welfengarten 1 30167 Hannover

Olga Liskin
Leibniz Universitt Hannover Welfengarten 1 30167 Hannover

anna.averbakh@inf.unihannover.de

eric.knauss@inf.unihannover.de

olga.liskin@inf.unihannover.de

ABSTRACT
Software engineering projects result in experiences that are valuable for continuous improvement. Experience and Knowledge Management (EKM) deals with the proper presentation, engineering, and reuse of experiences, e.g. training new project members or supporting future projects. In globally distributed projects proper EKM is even more important: Communication between project partners is more dicult than in co-located projects and may impair the awareness of knowledge residing at a project partners location. Project members might hesitate to share experience because of security considerations. We propose a hierarchical experience base with rights management aiming to positively inuence their willingness to share. Our concept includes special support for experience engineers to rene local experiences into best practices in globally distributed software projects. In this paper we show how our approach can rise awareness of existing experiences by presenting relevant experiences according to roles. We also argue, how this improves the willingness to share experiences in a distributed environment.

Categories and Subject Descriptors

H.4 [Information Systems Applications]: Miscellaneous; D.2.9 [Software Engineering]: ManagementProductivity

strategic advantages [1]. However, globally distributed projects also hold challenges due to cultural, linguistic, temporal, and security policy dierences [17, 11, 7]. This often leads to problems in communication between project partners [4, 12, 13]. Possible lack of trust between partners is a major concern as well, especially if they have a competitive relationship outside of the project. This hinders EKM, since a healthy knowledge sharing culture needs an atmosphere in which organization members feel safe sharing their knowledge [19]. People may be afraid of sharing sensitive experiences for fear of negative consequences [8]. Critical and emotionally laden statements towards partner organizations or individuals may aggravate the relationship between the partners and should not be openly accessible as long as the global software engineering team is working in the same context. These statements may lead to conicts and an even less trustful atmosphere. Nevertheless, these experiences may be very valuable and should be stored in the experience base for further processing. The problem of awareness in a distributed project environment can be approached by adjusting the appropriateness of the retrieved experiences to the target audience. An occasional user, e.g., may be easily scared o, if she nds a stack of observation sheets and tries to transfer them to her current problem. She would rather like to nd ready-to-use guidelines. On the other hand, users like an experience engineer must be able to access raw experiences. Our contribution in this paper is a concept for an experience base for distributed software engineering projects with the following (two main) features: Our concept supports a method to rene raw observation sheets into best practices. These observation sheets exist in a distributed way among several sites of a globally distributed software engineering endeavor. We provide a concept to manage access rights for the various stages of experiences for certain user roles in the software engineering domain. We show the applicability of our concepts by presenting an example we observed during the usage of a rst version of our experience base for global software engineering. We do not intend to improve the state of the art in security engineering, but to give a conceptual overview of rights in a distributed experience base. We designed our concepts fot

General Terms
Experience Engineering, Global Software Engineering, Rights Management

Keywords
Knowledge Management, Global Software Engineering, Experience Engineering, Rights Management

1.

INTRODUCTION

Distributed software engineering projects have become more and more common due to economical, organizational, and

the software engineering domain. We do not rule out the possibility of our concepts to be applied to other domains. However, we have not evaluated them outside the software engineering domain. This paper is structured as follows. The next chapter describes related work. In Chapter 3 we present our concepts of an experience base for global software engineering: In Chapter 3.1 we describe its structure and the experience engineering process it supports; Chapter 3.2 presents the rights management concept. In Chapter 4 we describe how we implemented our ideas. This preliminary evaluation shows that our concepts can support EKM in globaly distributed students projects. After discussing the concepts and implementation in Chapter 5, we conclude this paper and present ideas for further research in Chapter 6.

the experience engineers, have access to the storage room. To distinguish from the related work, we present a concept and implementation of an experience base that supports experience engineering tasks with more dierentiated rights management based on Schneiders shopping metaphor, but applied to a distributed environment with multiple partner organizations.

3.

CONCEPTS

In these sections we describe the ideas of our experience base. Chapter 3.1 presents a methodology of creating best practices (without considering view restrictions) from observation sheets and Chapter 3.2 describes a rights management structure for this experience base concept.

2.

RELATED WORK

3.1

Experience Engineering. Experience bases have been implemented before. Conradi and Dingsyr give an overview on several company-wide software experience bases [6]. Jrgensen et al. report on experience reuse within an organization giving recommendations of how to collect, package, and distribute experience and on needed roles to support the reuse [16]. Schneider presents a similar overview of experience engineering tasks to transform raw experiences into best practices [21]. In this paper, we applied these tasks to a globally distributed context. Knowledge Management in Global Software Engineering. Nonaka et al. dene a fundamental model (SECI) of a knowledge life cycle in an inter-organizational context, including, among other things, a combination step, i.e. engineering explicit knowledge into more structured knowledge [19]. This model is a basis to our contribution. Clerc et al. report on implementing an architectural knowledge repository to improve knowledge sharing in global teams [5]. Our solution also classies and presents pieces of dierent types of experience, the experience artifacts. It oers support for experience engineering tasks and for setting access rights for these artifacts. Rights Management Concepts. There exists related work about knowledge management applications with a hierarchical access management and user classication [3, 2, 18, 10]. Bergmann [3] and Basili [2] mention dierent user roles and rights management approaches in knowledge bases. Their user categorizations are quite general and do not allow to distinguish between more and less motivated users. Our concept presents a more ne-grained dierentiation of users and their rights applied in a globally distributed context. The APOSDLE platform coordinates knowledge repositories and leaves the access management task to each platform [18]. In contrast, our approach is to build one collective repository for a joint venture. Happel mentions the need to retain privacy in knowledge management systems to avoid others to access premature or sensitive contents not going into more detail [10]. We present a concept with concrete suggestions on which content should be accessed by whom. Our approach is inuenced by Schneiders suggestion to organize experience bases based on a shopping metaphor [20]. In this metaphor a shopping window only shows the nished product, i.e. best practices, to customers. Only the shop workers, i.e.

The Experience Engineering Method for Global Software Engineering

In this chapter we describe the structure and methodology of our experience base, its artifacts, and the process of creating best practices out of observation sheets.

1 Collect
Observations Experience Packages Experience Engineering Recommendations &BestPractices

4 Activate

3 Dissemination
Feedback

Active

Figure 1: The experience life-cycle as a basis for the experience base (based on [21]) When constructing an experience base, it is important to consider the ow of experiences and the way they are engineered and reused. In Figure 1 we refer to this ow as the experience life-cycle [21]. The diagram depicts EKM-related activities (1 to 4) and experience artifacts next to them that are the source or result of each activity. The life-cycle revolves around an experience base (in the center). 1 Collect: The rst step is to collect experiences, i.e. to make people aware that they have valuable experiences as well as provide a way to externalize them. One simple way is to write an observation sheet. An observation sheet is a (digital or paper) form to capture experiences. An experience is a triple [21]. It consists of an observation, an emotion and a conclusion or hypothesis1 . An observation sheet may contain sensible and strongly emotional content. These observation sheets are collected and stored as experience packages for the entire project. Experience packages are stored in the base. Observation sheets can be created by any knowledge worker, e.g. students, research associates or any project member.
1

An example of an observation is presented in Chapter 4.3.

2 Experience Engineering: In this step experience engineers derive recommendations and best practices out of experience packages. A best practice is a procedure that is based on experiences from practice [21]. We dene recommendations as experience artifacts that have not yet been successfully applied in a project to be called a best practice. Our experience engineering method is based on Basilis experience factory principle [2]. 3 Active Dissemination: People should be actively made aware that recommendations and best practices exist and can be applied. 4 Activate: Reusing experiences can activate new experiences and feedback, initiating a new life-cycle of reengineering existing best practices and creating new ones. In a globally distributed project the experience factory can be a central organizational unit or a group of scattered suborganizations at each project partners location. The job of an experience engineer can also be assigned temporarily to a project participant. In this paper we focus on the experience engineering step of creating best practices from raw experience in a distributed environment (Figure 2). It is based on Schneiders process [21]. Our experience base can be depicted as a pyramid storing experience artifacts for each partner organization Orgi , i {1, . . . , N }. It bears a large amount of raw experiences at the bottom and a small number of valuable best practices at the top level. The experience engineering process goes as follows:
Best Practices (e)

to be uploaded into the base. Observation sheets can be written directly into a form in the base or on a paper form (a). The paper observation sheets should be scanned and uploaded into the base. This step ensures that these sheets of paper are stored at least as images and do not get lost. Together with other experience artifacts the observation sheets are combined to experience packages in every partner organization (b). Documents containing sensible content in each experience package have to be anonymized and released. Other documents can be released directly. This is usually performed by experience engineers. Sharing sensitive information or even trade secrets will put the author in a bad position. A knowledge worker may not always be sure, if the piece of information she is about to contribute is allowed to be disclosed. Therefore, we generally withhold the observation sheets. The process of checking the contents of the observation sheets and anonymizing them should reassure the knowledge worker that her observation sheet will not compromise her, demotivating her to share observations. This will, of course, work only if the experience providers are made aware of this ltering step. From each experience package, an experience engineer copies remarkable or recurring passages into a document with consolidated experience extracts (c). These citations have now to be sorted and rephrased into more formal language. After that, they are combined with statements of a similar topic and categorized. For the rather tedious and mechanical work of copy/pasting and categorizing each text passage, a tool support facilitating the creation of an experience extract can be helpful (see Marker plugin in Chapter 4.2). From these extracts the experience engineer can now derive and conclude the recommendations (d). If a recommendation proves itself to be useful, it can be approved by the authoring organization to be promoted to a best practice (e). During this process all experience artifacts mentioned above are stored in the experience base and should not be deleted. In order to be able to trace how certain steps in a best practice were concluded, each best practice should be linked to the observation sheets it is derived from. However, not all documents should be accessible to all organizations or individuals. In the next chapter we present the concept to manage access rights to the experience artifacts in a globally distributed environment.

(d) Recommendations (c) Experience Extracts

...

Experience Packages

3.2

The Rights Management Concept

...
Observations Exp.Artifacts fromOrg1

(b)

...

(a)

In this chapter we present our rights management idea. Firstly, we show why the base needs access rights in a distributed project and why it has the particular characteristics. In our experience with distributed projects the following principles for rights management are important when establishing experience bases:
Exp.Artifacts fromOrgN

Figure 2: Documents in the experience engineering process. Shaded areas mark documents that only one organization can access. The arrows mark renement of experiences. During a distributed project, knowledge workers in every partner organization write observation sheets to document experiences. As a rst step, the observation sheets have

I. Make the contents of the experience base as open as possible to motivate the users to contribute. Users should be able to have access to as much information in the base as possible and see and react to what other colleagues have written or commented. II. Enable organizations to regulate access to these artifacts. Organizations produce knowledge and experience that is condential and must not be disclosed.

Org1

IV. Consider dierent user groups interacting with an experience base. These users are interested in dierent experience artifacts. In an experience base, picking the wrong presentation for an audience is worse than retrieving a slightly wrong topic. People react strongly when they are presented an inappropriate style of information [20]. Principles I and II have conicting goals seeking at the same time openness and nondisclosure of valuable knowledge. On the one hand, it is important for a successful experience life-cycle to have a rich seed in the base and not to impose restrictions on the users to access the knowledge and prot from its contents. On the other hand, we have a typical problem in a distributed joint venture: less trustful atmosphere between the partners and the need to secure knowledge and not give it away to competitors [14]. The lack of trust, security policies, but also dierent interests and approaches to knowledge, inuence the III. principle as well. An experience engineer may not be allowed to or want to read all observation sheets made at the partner organizations. The partners may not always be willing to share their best practices, as this knowledge may be a trade secret or considered irrelevant. In a distributed project security considerations, dierent interests, opinions, approaches and appropriate presentation have to be brought in line. The EKM should ensure that raw experiences containing sensitive and maybe compromising information, are not viewed by a partner organization before it is presented in a more appropriate form. Considering principle II, the base needs a rights management system. These rights have to be as little restrictive as possible to preserve the goals in principle I. The statement in principle IV can be taken as a guideline for creating the dierent user rights. The access restriction will then hide experience artifacts with the inappropriate style from users. To resolve the problem from principle III, we suggest to employ an independent experience engineer, e.g. from a party that is not involved in the project. We will go further into this topic later in this chapter. Next, we determine the user roles that interact with the experience base and their interests concerning the bases contents. Based on Schneiders user concept we divide the users into six groups [20]: Novice user. These users only look into the base to get a rough overview of the bases topic. They expect easily readable content to get a rst impression and further contact option. This kind of user can be a new project participant, who has to become acquainted with the general topic rst and needs a starting point. If this experience base is accessible online, it can also be a random person landing on the homepage.

(g) (e) Independent (d) (b)

Experience Engineer fromOrg1

...
(g)

... ...

Librarian fromOrg1

(a)

Exp.Artifacts fromOrg1

Figure 3: A rights management concept in an experience base for global software engineering. Shaded areas mark documents that only one organization may access. Each user is placed in the compartment he is allowed to access. The solid arrows point at further compartments they are also allowed to see. A dashed arrow mean that the access right is allowed under conditions.

Mass customer. This user type knows the basics and is looking for immediate support in a limited area [20]. This user is interested in best practices in the form of ready-to-use guidelines or checklists, rarely as free text. These users may be project leaders or project members who have to conduct a process or task they are not acquainted with or have failed to accomplish before. Long-standing customer. Like the mass customers, these users are also interested in best practices. However, they require coaching and more tailoring information. They are the most willing to give feedback, thereby initializing the reengineering of best practices. Experience engineer. The tasks of this user group are described in Chapter 3.1. Experience engineers need access to raw experiences in the base. In a distributed project environment an experience engineer could be a project participant working for a partner organization or an employee from an independent organization that has the sole role of doing experience management. Librarian. This experience engineers assistant has the task to upload the observation sheets into the base and combine them into experience packages. He should also provide a way to collect the experiences by creating observation sheet templates in the base or spread paper observation sheets. This user inevitably needs access to the raw observation documents. This role can be e.g. taken by a student assistant or intern.

...

III. Enable organizations to reuse experience and knowledge residing at a project partners location. The partners of a joint venture should gain more value and insight from a cooperative EKM system than in a separate company-wide initiative. Therefore, experience engineer(s) should be able to access experience packages from all partners when rening experiences (cf. Chapter 3.1).

Org1

(g)
Novice,mass, longstanding customers

OrgN

(f)

Mass,long standing Customers FromallOrgs.

OrgN

(g)
Experience Engineer

Experience Provider fromOrgN

(c)

Exp.Artifacts fromOrgN

User Role Novice user Mass customer from Orgi Long-standing cust. from Orgi Experience engineer from Orgi Independant experience eng. Librarian from Orgi Experience provider

Observation Sheets (Not Anonym.) Ri Ci Wi RCW Ri Ci Wi Ri Ci

Experience Packages (Anonym.) Rlink Clink Rlink Clink Ri Ci Wi RCW Ri Ci Wi Rlink Clink

Experience Extracts Ri Ci Wi RCW -

Recommendations R R R R R R

Best Practices R R R R R R R C C C CW CW C

C C CW CW C

Table 1: Overview over the user roles and their access rights to the experience artifacts. R, Ri , Rlink = read only access to all artifacts, only to artifacts from Orgi , artifacts accessed through a link and not as search retrieval. C, Ci , Clink = comment or create artifacts, only artifacts from Orgi , artifacts accessed through a link and not as search retrieval. W, Wi = edit and delete any artifacts; only artifacts from Orgi . Experience provider. The provider contributes new raw experiences. These can be an observation sheet, a comment, a contradicting experience or another knowledge artifact. It is unlikely that a knowledge worker makes comments without being experienced in the topic. Mass and long-standing customers are most likely to be providers. They know the eld and may already have applied the bases products. They are more likely to contribute new experiences or give feedback on existing ones. Providers should only have access to recommendations, best practices, and experiences from their organizations. Based on the principles above, we present in Figure 3 the following rights management concept for the experience base, its artifacts as presented in Chapter 3.1, and the user groups from above. We assume again a globally distributed software engineering project with N partner organizations. Each partner organization Orgi , i {1, . . . , N }, may employ its own librarians. Due to sensibility of observation sheets, librarians from Org1 may only work with observation sheets from Org1 . They are not allowed to see other observation sheets (a). Assuming that in the experience engineering step experiences are already collected, we do not consider the experience providers in Figure 3. The lowest level of the experience base pyramid with the experience packages should only be accessed by experience engineers and providers. Thereby, an experience engineer from Org1 should only see experience packages that were produced by Org1 , but no packages from other organizations (b). An experience provider from OrgN should be able to view observation sheets from his colleagues in OrgN (c). He should, of course, be able to review his own contributions. At the next higher layer the situation is similar. The experience extracts may still have sensitive content, e.g. quotes from observation sheets. The experience engineer from Org1 should only view the experience extract from observation sheets in Org1 . Hence, she can only process the observation sheets from Org1 (d). To draw conclusions out of experiences from all partners, which is the goal of a joint experience and knowledge initiative, the project needs an independent experience engineer (e), who can access all experience extracts. Mass and long-standing customers (f) (providers are part of them) should not be allowed to view experience extracts at all. At some point, a mass or long-standing customer may distrust a recommendation or best practice and might want to trace how it was concluded. Therefore, statements in recommendations and best practices are linked (g) to the sources they were derived from, i.e. the observation sheets. These observation sheets have to be anonymized. However, a mass or long-standing user should not retrieve observation sheets as a search result. The recommendations at the next layer, being anonymized and rephrased extracts, can be made available within all Orgi , i {1, . . . , N }, for mass and long-standing customers to try them out. However they should not be made open to people outside the project environment, until they have become best practices. On top of the base stands the end product in the shopping window [20] for all to see. The inferred best practices are the ready-to-use products. They should be viewed by all interested people within and outside of the project: mass customers, providers, novice, and long-standing customers (f). Table 1 gives an overview and sums up the various roles and their access rights on the documents in the experience base. In contrast to Figure 3, it goes into more detail concerning the access types for each user role. To comply with principle I at the beginning of the chapter, all users (besides librarians) are allowed to read (R), comment on experience artifacts (C) and write new observation sheets (also C). A librarian merely provides technical and administrative assistance and is assumed not to be knowledgeable on the topic. He should not be able to comment the contents. Editing or deleting the experience artifacts (by accident or as an act of vandalism) by others than the experience engineer should be prevented. Therefore, no users except for the experience engineers and librarians are allowed to write, edit or delete (W) experience artifacts. To satisfy principle II, customers are not allowed to read raw observation sheets that are not ltered and anonymized. Mass and long-standing customers and providers are only allowed to read and comment the anonymized observation sheets as linked proof of best practices. They should not retrieve them as a search result, since we assume that they are not interested in them. Commenting an experience or writing a new observation sheet turns the customer into a provider and allows him to read and comment his raw observation sheets and those from his organization. We also considered the possibility to restrain providers from reading other observation sheets than their own. We decided to rather allow them to view the contributions from their colleagues out of motivational reasons, but have not evaluated the consequences yet. Further, due to principle II, experience engineers are not allowed to read, comment or

edit raw observation sheets from partner organizations. We solve the conict between principle II and III by employing independent experience engineers. In an academic environment, these engineers can be student assistants, who are not involved in the project itself and do not care for stealing its results. Industrial joint ventures may cooperate with a university department working in the EKM eld. In this case all sides may prot from the cooperation. Principle IV is reected in the restrictions themselves by, e.g., not letting all customers read the experience extracts, which are neither the bases end products, nor their proving source, i.e. the observation sheets.

4.

PRELIMINARY EVALUATION

In this chapter we present a case, in which the experience base concept with rights management is prototypically implemented. First we describe the distributed project the base was developed for, then technical realization of the base and further experiences that have already been processed.

search and a page structure as well as various extensions. Wikis are designed for collaborative editing. There are currently over 130 Wiki types to choose from and most of them are free to use3 . We have chosen MediaWiki for its popularity. It oers a great number of extensions and a wide community support. Besides, the GloSE partners from academia are used to working with it. They know the syntax and its page layout. Hence, they may have a lower barrier to contribute to the base. MediaWiki can be extended to a semantic Wiki with the help of the Semantic MediaWiki extension SMW 4 . SMW allows to create a semantic structure with categories, relations and attributes to semantically classify the experience artifacts and relate them to each other. GloSE Base provides templates and forms to enter observation sheets and best practices. We conceived and implemented a tool to support the creation of experience extracts as a MediaWiki plugin. This Marker plugin is a button on each Wiki page. If activated, it captures text that is selected with the mouse on the current Wiki page and inserts it into a special experience extract page in the Wiki. Each copied passage on the experience extract page can be categorized, annotated, altered and deleted. The implemented MediaWiki supports the creation of all experience artifacts mentioned in Figure 2. Each experience artifact is stored on one Wiki page. Navigation controls assist in nding and creating the artifacts. This supports the steps collect, experience engineering, and active dissemination from the experience life cycle in Figure 1 (see Chapter 3.1). The step feedback in the life cycle is supported by including ratings for best practices and recommendations. This feedback helps the experience engineer to determine, whether a document was helpful or not and might initiate a revision of the document. If chosen not helpful, an additional reason can be provided. We implemented the rights management concept with the help of the extension Halo Access Control List 5 , since the core MediaWiki does not provide any access management apart from general login. It allows page-, attribute-, category- and namespace-based access control for individual users or user groups. With HaloACL we were able to implement all read and edit rights (R, Ri , W, Wi ) from Table 1. However, in HaloACL it is not possible to limit access through a link only (Rlink , Clink ). We used simple access rights (R, C) in these cases. Also, comment rights (C) cannot be assigned to individual user groups but only to all users. In the GloSE project the experience engineer role is taken by a research assistant and the librarian is a student assistant. The project employs another research assistant as an independent experience engineer, who researches in the eld of EKM and not in global software engineering. Until now, GloSE Base has been consulted by research assistants to prepare a distributed student project. These users can be categorized as long-standing customers. In the next distributed student project, we will make the base available to students. These students are categorized as novice users, committed students as mass users. Anonymous Wiki users will be classied as http://www.wikimatrix.org http://semanticweb.org/wiki/Semantic_MediaWiki 5 http://www.mediawiki.org/wiki/Extension:Halo_ Access_Control_List
4 3

4.1

Evaluation Context

We have employed our concepts in a joint research association on global software engineering (GloSE). It approaches the challenges of global software engineering [1]. Besides partners from academia, i.e. Leibniz Universit at Hannover (LUH), Technische Universit at M unchen (TUM), Technische Universit at Clausthal (TUC) and Rheinisch-Westfaelische Technische Hochschule Aachen (RWTH) it has also industrial partners like Daimler or Siemens. The main research question in GloSE is to determine and to approach the dierence between classical software engineering and global software engineering [1]. GloSE addresses challenges in process design and communication between distributed partners [24]. It is necessary for the distributed partners to combine their dierent development processes in order to jointly create a product. Eective communication between partners is essential and requires a certain eort to be established. Also, the joint creation and management of development artifacts, like documents and dierent models, are a main focus within the project. In connection with the GloSE project, labs are provided as part of the course oerings. There, student groups from the four partner universities get a chance to work together in distributed environments and to gain experience with these. To examine and improve these labs and to derive new ideas from there is a part of the research within the GloSE project. The project also aims to collect best practices and combine them into new methods and software engineering techniques. Therefore, there was a need to establish a lightweight experience base, where best practices can be maintained, created and retrieved.

4.2

Technical Realization

We have implemented our experience engineering and rights management concepts in a base for the GloSE project. This experience base, further referred to as the GloSE Base, is a MediaWiki 2 . We chose a Wiki-based approach because of the following reasons: A Wiki is a lightweight repository, which was a requirement. Most Wikis are easily installed and readyto-use. They provide easy editing in a browser, have a quite simple syntax, a versioning and rollback mechanism and easy linkage between pages. They also provide functionalities like
2

http://www.mediawiki.org

novice users. We are about to roll out and evaluate the experience base as a next step.

4.3

Dataset

So far, 82 observation sheets about communication in GloSE have been collected from two projects within the GloSE consortium and stored in the GloSE Base. 44 sheets are from a globally distributed project named Minotaurus [22] and 38 from a student distributed agile software engineering (ASE) lab [9]. The experience engineer, a student assistant, found 23 problems and 10 remarkable statements. Before the GloSE Base she had used spreadsheets and had to manually copy and paste the text. She considered the Marker plugin faster and more comfortable to use than spreadsheets. The observation sheets altogether resulted in 4 recommendations on how to plan communication and conduct observations in a globally distributed project: 2 from the Minotaurus project and 2 from the ASE lab. The best practices from Minotaurus exist in form of checklists that are divided into categories like room, communication, and team. This categorization is an example and depends on the number of checklist points found on this topic. Recommendations and best practices can also be the conclusion of experiments like those from the ASE lab [23]. To give an impression of the experience engineering process, take for example the following observation sheet from the Minotaurus project (translated from German): Observation: Every time we are making a phone call, a lot is going on in the background. We are often disturbed during programming. Emotion:Annoyance: it is hard to concentrate. (Conclusion: Left blank by the author.) This observation sheet was categorized as communication and room. Afterwards, we drew the conclusion for this and other observation sheets. It results in the following recommendation under category room :
2 2 2 2 Find a room that is not occupied otherwise during the development period. Oil squeaky doors. Put the copy machine away. Put a Do not disturb! sign on the door.

EKM. The partner organizations may already have their own EKM solutions (similart to our observation sheets) that work well for them. They might not want to waste any additional eort on transferring their knowledge and experiences to the GloSE Base. Based on our experiences during preliminary evaluation, experiences from these dierent EKM solutions can be imported in the GloSE Base with comparable eort to our observation sheets. We will oer such a service during rollout for a broader user spectrum. A successful experience management initiative should also employ further mechanisms to motivate participation that go beyond the scope of this research paper, see [8, 21]. A major problem in a distributed joint venture is to access all observation sheets and process them. In a less trustful environment this can be accomplished with the help of an independent experience engineer. Capable and independent experience engineers are not easy to nd. An option in an academic research project is to assign a research assistant. In a larger joint venture this assignment can go to university departments working in the EKM eld. If an independent experience engineer is not available, he could be substituted by a board of experience engineers from each project partner. The technical realization of the GloSE Base with a (Media) Wiki platform surely inuences the evaluation. We could have chosen to develop a dedicated Web application. The reasons in favor of a specically tailored solution are that we cannot clearly say, if all requirements from our concepts can be realized with a Wiki and how complex the work can become. Also the HaloACL rights management plugin may not be secure enough for some companies with a strict security policy. This is noted by the MediaWiki developers6 , presenting a list of limitations to currently available security extensions. A dedicated application could be made more secure through a dierent architecture. A Wiki, on the other hand, has the advantages of being lightweight and well known (cf. Chapter 4.2). The expense of developing a dedicated application can become much higher than of having a Wiki that satises the majority of our requirements.

6.

CONCLUSION AND OUTLOOK

This recommendation, among others, can now be used as preparation help in the next GloSE lab. It can be accessed by all project partners.

5.

DISCUSSION

The GloSE Base supports the lower levels of the pyramid (cf. Figure 2) well, i.e. the collection of experiences in situations make ad-hoc observation sheets and quickly write them on a sheet of paper at hand. These observation sheets can be easily and quickly added to the base from each partner location and then engineered into best practices. Nevertheless, the idea of a joint experience initiative has to be actively advertised to the partners (the management and the project participants). Without convincing of the advantages that collective EKM systems can bring, partners may have difculties to see the increase of insight gained from a global

In this paper we presented a concept of an experience base for global software engineering approaching two major problems in globally distributed software engineering projects. We approached the lack of awareness about knowledge that other partners might have. We provided a way to process observation sheets into best practices and present the right experience artifacts according to user roles and their interests. To motivate exerience sharing among partners, we presented a rights management concept for the experience base. We also presented a preliminary evaluation of our concepts. In future work, we will try to promote the active dissemination of experiences in the GloSE Base. One possibility could be to employ experience brokers [15]. It is also important to assess on how to manage the rights transitions, e.g. from a customer to a provider. A solution could be to manually grant rights, after the customer wrote an observation sheet. This can work for a small number of users. We will
6 http://www.mediawiki.org/wiki/Security_issues_ with_authorization_extensions

also examine possibilities to automatize the role transition. Further, we will assess on less immediate censorship rules with a mechanism to notify experience engineers to check new observation sheets on their content and quality before sharing them with partner organizations. At the moment, we are about to extend the GloSE Base and combine it with a highly structured publication knowledge base on global software engineering. This consolidation will provide additional seed to the base and a valuable source for researchers in global software engineering. We will have to analyze how to place and link the recommendations and best practices into the paper structure. We will also have to introduce and popularize the base and evaluate it to achieve a good balance between security considerations and openness in our rights management concept.

7.

REFERENCES

[1] C. Bartelt, M. Broy, C. Herrmann, E. Knauss, M. Kuhrmann, A. Rausch, B. Rumpe, and K. Schneider. Orchestration of Global Software Engineering Projects. In Proceedings of the Third International Workshop on Tool Support and Requirements Management in Distributed Projects (REMIDI09), pages 332337, Limerick, Ireland, 2009. Collocated with ICGSE 2009. [2] V. Basili, M. Lindvall, and P. Costa. Implementing the Experience Factory concepts as a set of Experience Bases. In In Proceedings of 13 th International Conference on Software Engineering & Knowledge Engineering, pages 102109, 2001. [3] R. Bergmann. Experience Management: Foundations, Development Methodology, and Internet Based Applications. LNAI 2432. Springer, 2002. [4] E. Carmel and R. Agarwal. Tactical approaches for alleviating distance in global software development. Software, IEEE, 18(2):22 29, 2001. [5] V. Clerc, E. de Vries, and P. Lago. Using wikis to support architectural knowledge management in global software development. In Proceedings of the 2010 ICSE Workshop on Sharing and Reusing Architectural Knowledge, SHARK 10, pages 3743, New York, NY, USA, 2010. ACM. [6] R. Conradi and T. Dingsoyr. Software Experience Bases: A Consolidated Evaluation and Status Report. In Profes, 2000. [7] F. Q. B. da Silva, C. Costa, A. C esar, C. Fran ca, and R. Prikladnicki. Challenges and Solutions in Distributed Software Development Project Management: a Systematic Literature Review. In ICGSE 10: Proceedings of the IEEE International Conference on Global Software Engineering, pages 8796, 23-26 Aug 2010. [8] L. Damodaran and W. Olphert. Barriers and facilitators to the use of knowledge management systems. Behaviour & Information Technology, 19:405413, 2000. [9] C. Deiters, C. Herrmann, R. Hildebrandt, E. Knauss, M. Kuhrmann, A. Rausch, B. Rumpe, and K. Schneider. GloSE-Lab: Teaching Global Software Engineering. In Proceedings of 6th IEEE International Conference on Global Software Engineering (ICGSE), Helsinki, Finland, 2011.

[10] H.-J. Happel. Towards Need-driven Knowledge Sharing in Distributed Teams. In I-KNOW 09, 2009. [11] J. D. Herbsleb. Global Software Engineering: The Future of Socio-technical Coordination. In FOSE 07: Future of Software Engineering, 2007. [12] J. D. Herbsleb and D. Moitra. Global Software Development. IEEE Software, 18(2):1620, 2001. [13] J. D. Herbsleb, D. J. Paulish, and M. Bass. Global software development at siemens: experience from nine projects. In Proceedings of the 27th international conference on Software engineering, ICSE 05, pages 524533, New York, NY, USA, 2005. ACM. [14] A. C. Inkpen. Learning Through Joint Ventures: A Framework Of Knowledge Acquisition. Journal of Management Studies, 37:10191044, 2000. [15] C. Johannson, P. Hall, and M. Coquard. Talk to Paula and Peter - They are Experienced. In International Conference on Software Engineering and Knowledge Engineering (SEKE99). Workshop on Learning Software Organizations, 1999. [16] M. Jrgensen, D. I. K. Sjberg, and R. Conradi. Reuse of software development experience at Telenor Telecom Software. In European Software Process Improvement Conference (EuroSPI98), pages 10.1910.31, Gothenburg, Sweden, 1998. [17] A. Mockus and J. Herbsleb. Challenges of global software development. In Software Metrics Symposium, 2001. METRICS 2001. Proceedings. Seventh International, pages 182 184, 2001. [18] F. M odritscher, R. Homann, and W. Klieber. Integration and Semantic Enrichment of Explicit Knowledge through a Multimedia, Multi-source, Metadata-based Knowledge Artefact Repository. In I-KNOW 07, 2007. [19] I. Nonaka, R. Toyama, and N. Konno. SECI, Ba and Leadership: a Unied Model of Dynamic Knowledge Creation. Long Range Planning, 33:534, 2000. [20] K. Schneider. LIDs: A Light-Weight Approach to Experience Elicitation and Reuse. In F. Bomarius and M. Oivo, editors, Product Focused Software Process Improvement, volume 1840/2000 of Lecture Notes in Computer Science, pages 407424. Springer Berlin / Heidelberg, 2000. [21] K. Schneider. Experience and Knowledge Management in Software Engineering. Springer-Verlag, 2009. [22] K. Stapel, E. Knauss, and K. Schneider. Using FLOW to Improve Communication of Requirements in Globally Distributed Software Projects. In Workshop on Collaboration and Intercultural Issues on Requirements: Communication, Understanding and Softskills (CIRCUS 09), Atlanta, USA, 2009. [23] K. Stapel, E. Knauss, K. Schneider, and N. Zazworka. FLOW Mapping: Planning and Managing Communication in Distributed Teams. In Proceedings of 6th IEEE International Conference on Global Software Engineering (ICGSE), Helsinki, Finland, 2011. [24] K. Stapel and K. Schneider. Managing Knowledge on Communication and Information Flow in Global Software Projects. Expert Systems - Special Issue on Knowledge Engineering in Global Software Engineering, 2011. to appear.