An Experience Base with Rights Management for Global Software Engineering
Distributed software engineering projects have become more and more common due to economical, organizational and strategic advantages. However, globally distributed projects also hold challenges due to cultural, linguistic, temporal and security policy differences. This often leads to problems in communication between project partners and hinders knowledge and experience management. Project members might hesitate to share experience because of security considerations. Nevertheless, these experiences may be very valuable and should be stored in an experience base for further processing. We created a concept for an experience base for distributed software engineering projects with the following (two main) features:
- Our experience engineering method supports refinement of raw observation sheets into best practices. These observation sheets exist in a distributed way among several sites of a globally distributed software engineering endeavor. For a more detailed description see our i-KNOW contribution .
- We provide a concept to manage access rights for the various stages of experiences for certain user roles in the software engineering domain.
Rights Management Concept for an Experience Base in a Distributed Context
In our experience with distributed projects the following principles for rights management are important when establishing experience bases:
- 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.
- Enable organizations to regulate access to these artifacts. Organizations produce knowledge and experience that is confidential and must not be disclosed.
- Enable organizations to reuse experience and knowledge residing at a project partner's 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 refining experiences.
- Consider different user groups interacting with an experience base. These users are interested in different experience artifacts. In an experience base, picking the wrong presentation for an audience is worse than retrieving a slightly wrong topic.
We defined user groups interacting with the experience base according to their requirements. Figure 1 depicts their access rights on the various experience documents in the base.
The main idea of the rights management system is to hide observation sheets with sensible information from other partner organizations and users who are only interested in reading best practices ((f) and (h): novice, mass and long-standing customers). Experience providers are users that have contributed experiences to the base (c) and should see all experiences from their organization. Experience engineers (b) need access to all documents in the base to refine best practices out of observations. They can be assisted by a librarian, who administers the experience base (a). However, due to principle 4., an experience engineer may likely not be allowed to access observations from a partner location. To make the creation of best practices from all partners possible an independent experience engineer is needed (e). For more details you are again referred to .
Figure 1: 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 means that the access right is allowed under conditions. 
We have implemented our experience engineering and rights management concepts in a base for the Global Software Engineering (GloSE) project with a MediaWiki. Wiki is a lightweight repository, which was a requirement. Most Wikis are easily installed and ready to 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 search and a page structure as well as various extensions. Wikis are designed for collaborative editing.
We have chosen MediaWiki for its popularity. It offers a great number of extensions and a wide community support. Besides, the GloSE project partners from academia are used to working with it. We have enriched MediaWiki with several extensions. They enable semantic categorization of all experience artifacts (Semantic MediaWiki) and regulate page-, attribute-, category- and namespace-based access for individual users or user groups (Halo ACL).
To support the experience engineer in his task of experience refinement we provide a plugin that, when activated, automatically copy/pastes interesting experience extracts on a special page. It then allows the user to categorize, annotate, alter and delete them. The main page of the GloSE Base is displayed in Figure 2. The Marker plugin (activated) is the yellow button with the pen in the right corner.
|Figure 2: GloSE Base: An implementation of the experience base concept for the GloSE project.