Process-Based Knowledge Management Support for Software Engineering

Process-Based Knowledge Management Support for Software Engineering

vom Fachbereich Informatik der Universität Kaiserslautern zur Verleihung des akademischen Grades Doktor der Naturwissenschaften (Dr. rer. nat.) genehmigte Dissertation

von

Dipl.-Inform. Harald Holz

Vorsitzender:

Prof. Dr. Otto Mayer

Berichterstatter:

Prof. Dr. Michael M. Richter Prof. Dr. Frank Maurer

Dekan:

Prof. Dr. Jürgen Avenhaus

Tag der wissenschaftlichen Aussprache: 14. November 2002

(D 386)

Holz, Harald: Process-Based Knowledge Management Support for Software Engineering / Harald Holz. – Als Ms. gedr.. – Berlin : dissertation.de – Verlag im Internet GmbH, 2003 Zugl.: Kaiserslautern, Univ., Diss., 2002 ISBN 3-89825-728-2

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Copyright dissertation.de – Verlag im Internet GmbH 2003 Alle Rechte, auch das des auszugsweisen Nachdruckes, der auszugsweisen oder vollständigen Wiedergabe, der Speicherung in Datenverarbeitungsanlagen, auf Datenträgern oder im Internet und der Übersetzung, vorbehalten. Es wird ausschließlich chlorfrei gebleichtes Papier (TCF) nach DIN-ISO 9706 verwendet. Printed in Germany.

dissertation.de - Verlag im Internet GmbH Pestalozzistraße 9 10 625 Berlin URL:

http://www.dissertation.de

iii

Abstract The primary goal of Process-Oriented Knowledge Management (POKM) is to establish, run and maintain an organizational environment that provides process participants with the information needed to successfully perform their activities as defined in the process model. In this work, we present a detailed life-cycle model for POKM that is specific to software development processes. This life-cycle model for Software Engineering Process-Oriented KM (SE-POKM) is integrated into the life-cycle model performed by the organization’s Process Group (PG), and becomes an essential part of a continuous organizational learning process. SE-POKM distinguishes between three stakeholders: the PG (focusing on process quality and improvement), the Knowledge Department (KD; responsible for knowledge management within the organization), and process participants (performing activities and requiring access to available knowledge). The SE-POKM model encompasses the following: • an explicit representation of dynamic (i.e. situation-specific) information needs that typi-

cally arise for process participants during software development activities; this representation also covers potential ways to satisfy those information needs. Furthermore, we present a process-oriented organization scheme for information needs that is based on standard process modeling concepts. • a specification of the information need retrieval during process enactment. Depending on a characterization of their current situation (i.e. current activities, individual preferences and skills etc.), process participant are provided with modeled information needs that are expected to arise for them during their activities; in particular, corresponding selected information items are retrieved for each of these information needs, which are assumed to satisfy the information needs in required detail. • a guideline for the experience packaging phase based on feedback from process participants; during this phase, the initial model of relevant and useful information needs is updated to better reflect the participants’ actual information needs. In order to automate the retrieval of information needs and corresponding information items, we present the Process-oriented Information resource Management Environment (PRIME). PRIME provides a technical infrastructure for knowledge distribution and feedback communication, and is designed to be coupled with the organization’s Process-Centred Software Engineering Environment (PSEE); in this work we demonstrate its integration into the MILOS PSEE. We argue that the light-weight integration of PRIME with the organization’s PSEE improves the efficiency of the process participants and the KD in their every-day work; in the least, participants are provided with answers to standard questions (especially to those of new participants), so that human experts in the KD need only be consulted for new, more difficult problems. Thus, the approach presented in this thesis facilitates an easy, incremental phase-in of Knowledge Management techniques into a software organization.

iv

v

Acknowledgments If it took me somewhat longer to write this thesis, this has been mostly due to the fact that working in Prof. Dr. Michael Richter’s research group has been a privilege I have been very reluctant to part with. It will be difficult to another place that is equal in its inspiring atmosphere, supportiveness of colleagues, and freedom to pursue interesting research topics. I am sorry for the next generation of computer science students in Kaiserslautern, for whom the "AG Richter" will only be rumour, this, alas, being the last year of the group’s existence. My thanks go to: • My thesis advisors, Prof. Dr. Michael Richter and Prof. Dr. Frank Maurer, for their great

•

• • • •

•

•

•

• • •

support as well as for many stimulating discussions and useful suggestions concerning my research. Prof. Dr. Ralph Bergmann, Sigrid Goldmann, Boris Kötting, Dr. Charles Petrie, Markus Roggenbach, and Martin Schaaf, for proof-reading and commenting on earlier versions of this thesis. In particular, Sigrid Goldmann’s detailed comments helped to make the thesis much more readable. Sigrid Goldmann, Thomas Sauer, Martin Schaaf, and Jochen Schäfer, for a final night shift that helped me to keep the deadline. Arne Könnecker, Guido Mayer, and Jochen Schäfer, for interesting discussions and implementation work that made PRIME a running system. Empolis GmbH, for providing me with their knowledge management tool suite "orenge". Sigrid Goldmann, Jochem Hüllen, Boris Kötting, Armin Stahl, and Sascha Schmitt, for keeping work away from me by shouldering it themselves, while I was writing this thesis. The MILOS team: Fawsy Bendeck, Barbara Dellen, Boris Kötting, Prof. Dr. Frank Maurer, Martin Schaaf, and all those many students who helped making the project a success (you know who you are, guys. Your names are listed in the system’s "About" window). It has been a great pleasure working with you. Christoph Globig, Willi Klein, Martin Schaaf, Armin Stahl, Ivo Vollrath, and Frank Weberskirch, for keeping the group’s IT infrastructure up and running, and for providing excellent troubleshooting support. Edith Hüttel and Petra Homm, for always removing administrative burdens with a smile, and for turning the (secretary’s) office into a refugium. Edith Hüttel has been the "soul of the AG Richter" for most of the years I have worked there. My parents, Helen and Heinz Holz, and grandparents, Gisela and Eric von Åkerman, for supporting me during my studies without putting pressure on me to "finish" university. Doris and Dietrich Sturm, for numerous invitations to write this thesis undisturbed in their beautiful house in France. Anja Fährmann, Markus Roggenbach, and Gabriel Zachmann, for their friendship and very, very long telephone conversations that encouraged me and cheered me up.

vi

• Stefan Besling, for first raising my interest in A.I. back in 1982; never again has pair pro-

gramming been so much fun (of course, we were younger, then... ;-) • my first computer science teacher, Ulrich Seitz, for his excellent course he gave at the Lessing-Gymnasium at a time when other so-called computer science teachers had difficulties using their programmable calculators. • the people at Infocom, Inc., for their unforgettable text adventures.

Kaiserslautern, September 2003

vii

To E. F., without whom this thesis might have never been finished.

viii

ix

Contents 1. Introduction

1

1.1 1.2

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Contributions of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 1.4

Assumptions Underlying the Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Structure of Dissertation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Knowledge Management and Software Engineering 2.1 2.2

2.3

A Life-Cycle Model for Knowledge Management . . . . . . . . . . . . . . . . . . . . . . 13 Knowledge Management for Software Engineering . . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.2 Process-Centred Software Engineering Environments . . . . . . . . . . . 19 Shortcomings of SE Knowledge Management Approaches . . . . . . . . . . . . . . . 21 2.3.1 Shortcomings of Experience Base Approaches . . . . . . . . . . . . . . . . . 21 2.3.2 Shortcomings of Process-Centred SE Environments . . . . . . . . . . . . . 22

3. Process-Oriented Knowledge Management 3.1

3.2

4.3

25

What is Process-Oriented Knowledge Management? . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Process-Oriented Knowledge Capture . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 Process-Oriented Knowledge Organization . . . . . . . . . . . . . . . . . . . . 31 3.1.3 Process-Oriented Knowledge Formalization . . . . . . . . . . . . . . . . . . . 33 3.1.4 Process-Oriented Knowledge Distribution . . . . . . . . . . . . . . . . . . . . . 35 3.1.5 Process-Oriented Knowledge Application . . . . . . . . . . . . . . . . . . . . . 37 3.1.6 Process-Oriented Knowledge Evolution . . . . . . . . . . . . . . . . . . . . . . 37 A Model for Software Engineering Process-Oriented KM . . . . . . . . . . . . . . . . 39 3.2.1 Capturing Process-Specific Information Needs . . . . . . . . . . . . . . . . . 41 3.2.2 Process-Oriented Information Resource Organization . . . . . . . . . . . . 49 3.2.3 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.2.4 Information Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4. Integrating POKM into a Process-Centred SEE 4.1 4.2

11

101

MILOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 PRIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.2.1 System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

x

5. Process-Oriented Knowledge Evolution

127

6. Discussion

143

6.1 6.2

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Case Study Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 6.2.1 Quality Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 6.2.2 Efficiency Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 6.2.3 Convenience Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

7. Summary & Outlook 7.1

159

Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

References

165

List of Figures

175

List of Tables

179

List of Clarifications

181

xi

xii

CHAPTER 1

Introduction

"An immense and ever-increasing wealth of knowledge is scattered about the world today; knowledge that would probably suffice to solve all the mighty difficulties of our age, but it is dispersed and unorganized. We need a sort of mental clearing house for the mind: a depot where knowledge and ideas are received, sorted, summarized, digested, clarified and compared." (H.G. Wells, 1940)

In order to meet the challenges of today’s economy, companies are beginning to realize the potential of Knowledge Management (KM). A Conference Board survey of 200 senior executives from leading global companies revealed that 80 percent of them have some KM efforts under way [Hac00]. Measurable business benefits are being attributed to the innovative use of KM in the areas R&D, sales, marketing and customer service: e.g., BP Amoco reports gains of more than $600 million as a result of its knowledge and learning initiatives. Central to Knowledge Management is the concept of an Organizational Memory (OM), alternatively called Corporate Memory. In essence, an OM is a logical or physical unit (not necessarily automated) that is responsible for • converting knowledge, i.e. knowledge that is created both within and

outside the organization needs to be collected, prepared and organized in an appropriate form, and • connecting knowledge, i.e. knowledge has to be disseminated within the organization to employees who require it for their work [OLe98a]. Problems with OMs range from an organizational level (e.g.: How to assure management support?) to a cultural level (e.g.: How to establish a culture of information sharing?) to a technical level (e.g.: How to cope with heterogeneous data representations?). Studies and experience reports (see e.g. [Hac00]) stress the importance of the first two levels and the need to address them as part of an organization’s KM initiative. However, problems on these levels lie outside the scope of computer science, whose role in Knowledge Management research so far has mainly been to provide solutions on a technical level, e.g. in the form of Organizational

1

2

CHAPTER 1 Introduction

Memory Information Systems (OMIS) [SZ95] as a technical infrastructure for OMs. Existing OMIS approaches (see e.g. [Ack93], [WWT98]) encompass various information sources and formats, ranging from informal text documents to semi-formal documents to formal data and knowledge representations. passive vs. active OM

In general, we can distinguish between passive and active OMs (see e.g. [RMS00]). An OM is called passive if it expects employees to explicitly query it for relevant information whenever they have a specific information need. In contrast, an OM is called active if it distributes information to employees whenever it is necessary for their work. In order to realize active OMs that provide employees with relevant information, it is essential to keep track of the activities they are about to perform. The importance of active Organizational Memories has been illustrated by empirical studies, showing that a crucial problem with reusing existing information is to know that certain knowledge is available for reuse [MR97]. Thus, the question of how to make sure that each employee is putting the wealth of knowledge stored in the OM to its best possible use forms a major issue that needs to be addressed. 1.1

Motivation

In this work, we will focus on information system-supported Knowledge Management for software organizations1. In our opinion, Knowledge Management appears to be particularly relevant for software organization for the following reasons: • Dealing with almost daily advances in technology, software organiza-

tions have to ensure that any new information is spread quickly to all employees whose work might benefit from it. At the same time, care must be taken to avoid information overload. • With the emergence of virtual software organizations, e-market-places for software development tasks, and open-source projects, the tendency towards geographically dispersed software development has increased. The limited opportunities for face-to-face communication impede knowledge exchange between different sites, restricting it mostly to e-mail or telecommunication. This results in an increased importance of ensuring that either knowledge bearers (i.e. people who have knowledge about a specific subject) can be identified and con-

(1)

For the remainder of this work, we will use the terms ’organization’ and ’software organizations’ synonymously.

1.1 Motivation

tacted immediately, or that knowledge on a specific subject has been made explicit and can be accessed whenever the need for it arises. • In the still growing software industry, companies are confronted with the problem of providing new employees quickly and efficiently with the knowledge required to successfully perform their tasks. Knowledge Management has a long tradition in Software Engineering (SE) research, the most prominent approach being the Experience Factory concept proposed by Basili et.al. [BCR94]. Compared to standard KM approaches, the Experience Factory corresponds to the concept of an Organizational Memory; the Experience Factory’s main technical infrastructure, called Experience Base, corresponds to an OMIS that is dedicated to maintain Software Engineering-related, packaged experiences. These experiences can be regarded as a special kind of knowledge. At the time of writing this thesis, only few implementations of this approach are found in current software organizations. In our opinion, one of the main reasons for this reluctance is that the approach lacks a systematic integration into every-day activities performed by employees: the Experience Factory is not tuned towards functioning as an active OM. Companies will not be willing to invest resources in an Experience Factory that is in danger of becoming an ’experience cemetery’. The initial scenario that we consider in this work is depicted in Figure 1.1.

Fig. 1.1: Motivational scenario.

On one hand, the software organization’s employees are performing activities within various software projects. While they are performing certain

3

4

CHAPTER 1 Introduction

Information Needs

activities, information needs arise that need to be satisfied in order to successfully perform the activities. These information needs range from simple questions (e.g. “Who has working experience with EJB in this company?”) to questions that usually are more complicated to answer (e.g. “What issues need to be addressed when using Serialization together with RMI?”)

Information Source

On the other hand, typically there are several information sources available to the employees, which potentially contain information that can be used to satisfy the employees’ information needs. These information sources can be either human subject-matter experts (e.g. experienced colleagues) that employees can contact, or any electronic information system that is accessible by employees. Furthermore, information sources might either be maintained outside the company (e.g. newsgroups, mailing list archives, tool vendor websites, etc.), or they might be internally maintained within the organization (e.g. the company’s document management system (DMS), bug tracking systems, lessons learned systems, etc.). For software organizations, the existence of external information sources is an important factor, as a considerable amount of relevant up-to-date technical knowledge (in the form of documents, newsgroup postings, etc.) is created and made available outside the organization via Internet technology. A complete replication of this knowledge by converting it into organization-specific information sources would be either too expensive or technically infeasible.

Query-Return Model

For the remainder of this work, we will consider the organization’s OMIS as only one of several information sources available to the organization. Typically, the information sources maintained by the OM follow the standard passive query-return model that expects employees to access an appropriate information source whenever they want to satisfy an information need2 that arose during one of their activities. As pointed out above, this entails the danger of relevant information being overlooked, because employees • might be unaware that they should have an information need (e.g.

when they are using technology for which relevant lessons-learned are available), • might be unaware of a relevant information source they could use to satisfy an information need, • might be unable to query an information system appropriately, or • will not be notified when new relevant becomes available.

(2)

In the field of information retrieval, an information need denotes what a user really wants to know, typically expressed in natural language; a query is an approximation of the information need.

1.1 Motivation

5

Therefore, the query-return model seems to be impractical for software development activities. As an alternative to the passive query-return model, information filtering approaches for active information delivery have been developed [BC92]. Typically, these approaches are based on long-term queries or user profiles that facilitate the filtering of newly created documents, alerting the user to new documents only if they meet certain relevance criteria.

Information Filtering

However, in the context of software organizations, these information filtering approaches also seem to be inadequate for the task of distributing relevant documents: during software development projects, employees typically are continuously starting new activities, changing roles during the activities (e.g. a designer of a certain component might be the reviewer of another component), or dropping out of activities. Furthermore, the characteristics of these activities change frequently, e.g. because of changes to products handled, or changes to the set of tools being used during the activity. As a consequence, information retrieved by a longterm query that an employee once specified for an already completed activity is likely to have become irrelevant to him, as has the information retrieved by a long-term query that no longer reflects the current characteristics of the employee’s current activities3. Even though approaches exist that can adapt to users’ changing interests via learning strategies (see e.g. [MMP96]), it seems doubtful to us whether an employee’s changing interests, caused by the diverse characteristics of the activities that he is assigned to, allow these learning algorithms to converge quickly enough. In this work, we argue that, in order for a software organization to utilize its Organizational Memory Information System effectively, knowledge should be structured around process models (i.e. abstract activity descriptions). Taking into account the fact that, in many cases, a diverse set of information systems are already in use by employees within the organization, we propose an approach where process models serve as entry points (or query triggers) to different information sources. In particular, process models will define views on information sources by specifying a particular context in which process participants should be provided with relevant information that can be retrieved from available information sources. Thus, this work contributes to the problem of knowledge dissemination in organizations by means of Process-Oriented Knowledge Management (POKM).

(3)

Wolverton has made similar observations for the domain of battle planning [Wol99].

ProcessOriented Knowledge Management

6

CHAPTER 1 Introduction

1.2

Contributions of this Thesis

In this thesis, we present an approach that addresses the problem of how to facilitate a distribution of information available within the organization’s OM to its software engineers such that the information distribution is: • (pro)active, i.e. the organization does not rely on its engineers request-

ing information from the OM, but aims at providing relevant information without their explicit request; • activity- and situation-specific, i.e. the proactive information distribution is based on the activity a software engineer is currently working on, as well as on the engineer’s personal preferences and/or skills. • systematic, i.e. it is possible to ensure that the OM regularly provides an engineer with relevant information whenever a certain situation arises; • automated, i.e. as far as possible, members of the OM are relieved from proactively providing engineers with relevant information for their current activities by appropriate tools. Conceptual Contributions

In particular, the conceptual contributions of the approach presented in this thesis to KM support within software organizations consist of: • A detailed life-cycle model for Process-Oriented Knowledge Manage-

ment with regard to Software Engineering: Based on a standard Knowledge Management life-cycle model [NKS00], we present a detailed life-cycle model for Software Engineering Process-Oriented Knowledge Management (SE-POKM). The phases of this model are assumed to occur in the context of an organization that is willing to deploy (or already has deployed) a ProcessCentred Software Engineering Environment (PSEE) [GJ96]. Typically, the PSEE is a means of the organization’s Software Engineering Process Group (PG) to capture best practices in the form of abstract process models, and to disseminate these best practices as the basis for concrete software projects. Thus, the PSEE already stands in the centre of a life-cycle model operated by the PG in order to capture and distribute knowledge on how development processes should be performed. The phases of the SE-POKM life-cycle model presented in this thesis are integrated into the life-cycle model operated by the Process Group; these phases are concerned with the collection and distribution of knowledge on what information is required to successfully perform development activities, and where as well as how it can be found. In particular, our SE-POKM life-cycle model presents an approach for bootstrapping the cycle and continuous knowledge evolution.

1.2 Contributions of this Thesis

• A representation formalism for recurrent information needs:

We introduce an explicit, structured representation of information needs that typically arise for process participants during software development activities. In addition to a textual question that expresses such a recurrent information need, the representation allows to formally specify: • a set of preconditions that state when the information need is

expected to arise, • for whom it is expected to arise (i.e. information needs are expected to arise only for process participants with a certain skill profile and/ or role assignment), • information sources that potentially contain information that can be used to satisfy the information need, as well as how to retrieve this information automatically (whenever possible). In particular, the representation may contain parameters in order to specify a generic information need. A generic information need represents a class of (concrete) information needs that uniformly arise and can uniformly be satisfied. For example, the information need "What similar activities have been performed before?" might be expected to occur for any concrete, current activity; it can be satisfied by a similarity-based search in the organization’s activity case-base, using the representation of the current activity as the query case (i.e. as a search parameter). • An organization scheme for recurrent information needs:

The entities defined in the process model that is maintained within the Process-Centred Software Engineering Environment serve as the basis for the organization of recurrent information needs. In general, a recurrent information need will be associated with a certain model entity if the entity’s presence in the situational context of a concrete activity gives rise to the information need. Thus, the organization scheme of recurrent information needs can be regarded as an extension and refinement of the organization’s process model. • A specification of situation-specific, systematic retrieval of infor-

mation: Based on a characterization of their current situation (i.e. current activities, individual preferences and skills etc.), process participants are provided with modeled information needs that are expected to arise for them during their activities; in particular, certain selected information items are retrieved for each of these information needs, which are assumed to satisfy the information needs in required detail. The approach presented in this thesis aims at turning any passive OMIS into an active one that distributes relevant information to employees "just-in-time" [CFS97]. Rather than enforcing the construction of a

7

8

CHAPTER 1 Introduction

new central knowledge repository in which all knowledge is maintained, our approach takes into account the existence of information sources already in use within the organization. Instead of attempting to automatically retrieve all information that might be relevant for a process participant during his activity, we present a two-phase, interactive retrieval model: first, the set of information needs that are likely to arise for the process participant during a given activity is determined and presented to him. Second, the information retrievable from one of the information sources as specified in these information needs is presented to the process participant on demand. The explicitly represented information need also serves as an explanation of why a retrieved information item is relevant to the process participant. Practical Contributions

The concepts presented in this thesis have been implemented in a system called PRIME4, which can provide users of the organization’s ProcessCentred Software Engineering Environment (PSEE) with activity- and situation-specific information. As a proof-of-concept implementation, PRIME has been coupled with the MILOS5 PSEE [HKM01][MH02]. Instead of having to access available information sources by formulating explicit, source-specific queries to satisfy information needs that repeatedly occur during their activities, PRIME provides software engineers with a list of pre-defined information needs expected to arise for them during their activity. From this list, they can choose the one that best corresponds to their actual information need, and trigger an automatic retrieval of information from available sources that is assumed to satisfy the information need. In order to facilitate an easy adoption of Knowledge Management support within an organization, it is important that knowledge modeling effort can be kept low in the beginning, and that an immediate benefit can be achieved. Our approach promotes this by providing process participants with the functionality of activity-specific, personal lists of information items ("favorites") considered to be useful/relevant during the activity, as well as activity-specific forums for information request postings. A later formalization of these information item preferences and requests into explicit information needs by Knowledge Engineers at enactment time facilitates an incremental, bottom-up strategy of introducing Knowledge Management into an organization.

(4) (5)

PRocess-oriented Information resource Management Environment. Minimally-Invasive Long-term Organizational Support [MDB+00].

1.3 Assumptions Underlying the Approach

For an organization, we expect the following main benefits from a deployment of PRIME: 1. Relevant information is not overlooked (quality aspect): Users are actively provided with access to available information. As a consequence, the danger of additional costs or a loss of quality caused by information being overlooked is reduced. 2. Time spent on searching is reduced (efficiency aspect): Posting queries is time-consuming; it interrupts the users’ primary work, forcing them to spend time on searching and browsing available information sources. Providing users with preformulated queries that automatically retrieve the information relevant to them reduces their search efforts. 3. Searching for information is more convenient (convenience aspect): Because query generation can be automated, users need not be bothered with formulating queries in proprietary, information source-specific query languages. In particular, the user does not need to repeatedly enter the same activity characteristics (or certain project characteristics perhaps unknown to him) to search for relevant information. Initial proposals on corresponding measurable success criteria will be presented in Section 6.2. 1.3

Assumptions Underlying the Approach

The following is a list of assumptions on the organization that must hold as a prerequisite to the approach presented here: 1. The main organizational and cultural issues of KM [Hac00] have been successfully addressed and are taken care of; in particular, senior management is committed to the organization’s KM initiative, and a culture of knowledge sharing has been or is being established. 2. The organization is willing to assign resources to an organizational unit (in the following called Knowledge Department) that is responsible for the management of knowledge related to the organization’s software engineering domain. 3. The organization is willing to deploy (or already has deployed) a Process Support Environment that provides the basic functionality of a workflow engine [Hol95]; in particular, employees are provided with to-do lists that contain their individual tasks (activities).

9

Expected Benefits

10

CHAPTER 1 Introduction

1.4

Structure of Dissertation

The remainder of this work is structured as follows: Chapter 2 contains a short introduction to Knowledge Management and reviews existing work on Knowledge Management in the field of Software Engineering. In Chapter 3, a life-cycle model is presented for Process-Oriented Knowledge Management (POKM). Based on this model, we introduce a refined model for Software Engineering Process-Oriented Knowledge Management (SE-POKM) that takes into account the specific demands encountered within software organizations. In Chapter 4, we present the Process-oriented Information resource Management Environment (PRIME). PRIME provides a technical infrastructure to support Software Engineering Process-Oriented KM, and is designed to be coupled with the organization’s Process-Centred Software Engineering Environment. The integration of MILOS and PRIME is used as an example to demonstrate how SE-POKM is supported by a tool environment, in particular, how users of a PSEE benefit from services provided by PRIME6. Chapter 5 outlines a complete knowledge utilization cycle, covering incremental knowledge evolution based on continuous user feedback. Chapter 6 discusses the work presented here, followed by a summary and an outlook on future work in the concluding chapter.

(6) In fact, we believe that the provision of this service will become one of the main reasons for introducing a PSEE into an organization.

CHAPTER 2

Knowledge Management and Software Engineering

"Those who cannot remember the past are condemned to repeat it." (George Santayana)

In the so-called information age in which the knowledge society has been proclaimed, where companies face the difficulties of high staff turnover rates and a lack of skilled people for positions that demand higher education, there is an increased tendency towards regarding knowledge as a valuable resource for modern organizations. Motivated by this insight, Knowledge Management (KM) has been proposed as a means to systematically manage the experience and know-how created and used within an organization. In an analogy to physical resources, knowledge is viewed as a special kind of raw material that needs to be acquired or created, stored and distributed just-in-time to specific locations where it is needed by certain employees during their tasks or activities. Consequently, management of knowledge not only involves the identification and maintenance of valuable knowledge, but also managing the logistic processes that prepare and distribute this knowledge. Thus, an organization not only needs to "know what it knows", but also needs to know "who needs what knowledge, and when?" Knowledge Management is an interdisciplinary topic that addresses economical, organizational, cultural, psychological and technological issues. Hence, various alternative definitions of Knowledge Management exist, reflecting the particular focus of the respective research disciplines (see e.g. [Lie99]). In this work, we will focus on the Computer Science view on KM, and start from a clarification of the term provided by O’Leary [OLe98b].

11

12

CHAPTER 2 Knowledge Management and Software Engineering

Clarification 2.1: Knowledge Management Knowledge Management (KM) is the formal management of knowledge for facilitating creation, access, and reuse of knowledge, typically using advanced technology. Knowledge that is or might be valuable to an organization typically resides in many different places and various formats, e.g. inside people’s heads, books, filing cabinets, file systems, databases, knowledge bases, information systems, etc. Motivated by this observation, O’Leary further characterizes Knowledge Management as "a process of converting knowledge from the sources accessible to an organization and connecting people with that knowledge“ [OLe98a]. Figure 2.1 illustrates this view on Knowledge Management, where we assume that a separate organizational unit, called the Knowledge Department (KD), has been established, which is responsible for the organization’s knowledge converting an connecting processes. Organization ?

information systems

external experts

Knowledge Department ?

External Information Sources

employees

Internal information systems Information Sources capture & convert knowledge

connect to knowledge items/bearers

knowledge transfer

Fig. 2.1: External view on Knowledge Management.The Knowledge Department is responsible for capturing, converting and storing available knowledge from internal and external information sources (subject matter experts, books, databases, etc.). In order to facilitate knowledge transfer to employees with information needs, it connects stored knowledge items or experts with employees to satisfy their information needs.

In the literature, this Knowledge Department is also often called an Organizational Memory (see e.g. [SZ95]) or Corporate Memory. In the context of this thesis, we will use the term "Knowledge Department", hoping to avoid any confusion between the organizational unit responsible for Knowledge Management activities, and any technical infrastructure that is operated by the Knowledge Department to support or automate these activities.

2.1 A Life-Cycle Model for Knowledge Management

Clarification 2.2: Knowledge Department The Knowledge Department (KD) is a logical or physical unit that is responsible for knowledge connecting and converting activities. The KD is headed by a Chief Knowledge Officer (CKO), who is supported by a group of Knowledge Engineers and Knowledge Brokers. Knowledge Engineers perform or automate the tasks of capturing, formalizing, and maintaining knowledge (i.e. their focus lies on "converting"). Knowledge Brokers are responsible for distributing captured knowledge that is relevant to other employees (i.e. their focus lies on "connecting"); typically, Knowledge Brokers act on explicit requests from other employees. Knowledge Brokers might be supported by automated tools provided and maintained by Knowledge Engineers. 2.1

A Life-Cycle Model for Knowledge Management

In order to achieve a systematic Knowledge Management, several lifecycle models for Knowledge Management have been proposed in the literature (see e.g. [DP98], [DC99], [CHL+94], [Nis99]). As Nissen [NKS00] points out, these models differ mainly in their naming of phases, but otherwise share many similarities. In the following, we mostly adhere to the Nissen model [Nis99][NKS00], which distinguishes between six phases: 1. Capture: Valuable knowledge is elicited and externalized1 2. Organize: Captured knowledge is systematically stored for later access 3. Formalize: Whenever necessary, captured knowledge is formalized, e.g. for the sake of clarity or an intended automation 4. Distribute: Captured knowledge is made available to employees 5. Apply: Employees make use of the distributed knowledge during their work 6. Evolve: During knowledge application, new knowledge is created that might be valuable to the organization (or other employees) As Nissen points out, “knowledge evolution leads in turn to further knowledge creation, thereby completing the cycle” [NKS00]. Thus, the resulting model might best be depicted in analogy to the Spiral Model [Boe87], to better illustrate the model’s iterative nature (see Figure 2.2).

(1)

Later, Nissen renamed the phase “Capture” to “Create” [NKS00]. However, we prefer to use his original notation.

13

14

CHAPTER 2 Knowledge Management and Software Engineering

Evolve Apply

Capture

Distribute

Organize

Formalize

Fig. 2.2: Nissen life-cycle model.

In Chapter 3, we will refine this life-cycle model into a model for ProcessOriented Knowledge Management with a focus on software organizations. The next section reviews existing Knowledge Management research in the context of Software Engineering. Further details on Knowledge Management in general can be found in [Lie99][DP98]. 2.2 Experience Factory

Knowledge Management for Software Engineering

In Software Engineering, Knowledge Management is addressed by the Experience Factory (EF) approach proposed by Basili et.al. [Bas89][BR91] [BCR94]. In order to support comprehensive reuse of experiences (software products, software processes, lessons learned, etc.), the operation of a separate organizational unit (called the Experience Factory) is described: Clarification 2.3: Experience Factory "The Experience Factory is a logical and/or physical organization that supports project developments by analyzing and synthesizing all kinds of experience, acting as a repository for such experience, and supplying that experience to various projects on demand. It packages experience by building informal, formal or schematized, and productized models and measures of various software processes, products, and other forms of knowledge via people, documents, and automated support." [BCR94] As the name suggests, the EF focuses primarily on experiental knowledge, i.e. knowledge that reflects concrete experience made by individuals, as opposed to generalized knowledge (e.g. rules, heuristics, etc.). The repository deployed as a technical infrastructure to store the experience is called an Experience Base (EB). The Experience Base stores knowledge that is related to software development (e.g. process models, software products, available resources) in the form of experience packages. Each

2.2 Knowledge Management for Software Engineering

experience package consists of an artifact (i.e. a piece of information that can be processed electronically) and an artifact characterization. The characterization is intended to facilitate a decision on whether the artifact should be used in future situations [BCR94]. Figure 2.3 illustrates the Experience Factory concept.

Characterize Set Goals Choose Process

Execution Plans

Execute Process

Environment Characteristics

Project Support Goals, Processes, Tools, Products, Resource Models, Defect Models, ...

Package

Generalize EXPERIENCE BASE

Data, Lessons Learned

Tailor Formalize

Project Analysis

Analyze Project Organization

Experience Factory

Fig. 2.3: Experience Factory Organization (adapted from [BCR94]).

However, the responsibilities of the Experience Factory exceed those of setting up and running the Experience Base: "The Experience Factory can be used to consolidate and integrate activities, such as packaging experience, consulting, quality assurance, education and training, process and tool support, and measurement and evaluation." [BCR94] Consequently, the EF is also responsible for a continuous improvement of the organization’s software development process. This responsibility is made explicit by the Quality Improvement Paradigm (QIP) (see Figure 2.4) that underlies the operation of the Experience Factory [BCR94].

15

16

CHAPTER 2 Knowledge Management and Software Engineering

Package

Characterize

Set Goals

Analyze

Execute

Choose Artifacts

Fig. 2.4: Quality Improvement Paradigm cycle (adapted from [BCR94]).

In general, the QIP cycle can be applied at different granularity levels, e.g. at an organizational, project or activity level (see e.g. [Tau00]); Table 2.1 shows an example on the project level. QIP Step

Project Level

1. Characterize

Characterize project and identify relevant models to be reused

2. Set Goals

Define project goals in measurable terms and derive related measures

3. Choose Artifacts

Choose appropriate processes and develop project plan

4. Execute

Perform project according to plan, collect data, and provide online feedback for project guidance

5. Analyze

Analyze project and collected data, and suggest improvements

6. Package

Package analysis results into improved reusable artifacts

Tab. 2.1: The QIP cycle instantiated on a project level (adapted from [Tau00]).

Several successful realizations of the Experience Factory concept have been reported from major software development-intensive organizations, e.g. NASA [BCR94], DaimlerChrysler [HSW98] or sd&m [Schie01]. In particular, various tools that aim at supporting the Experience Factory have been and are being developed (see e.g. [ABT98][WSM+99][Fel00]). In general, these tools encompass mechanisms that help to capture experience, and make it accessible and reusable via appropriate interfaces. Retrieval of experience packages is either based on standard information retrieval approaches using statistic document analysis techniques, or deploys more advanced, knowledge-intensive techniques for similarity-

2.2 Knowledge Management for Software Engineering

based or ontology-based retrieval. For a recent overview on Experience Factory research, the reader is referred to [Tau00]. Because of the holistic reuse scenario outlined by the Experience Factory framework, other reuse-oriented approaches can be interpreted as (necessary!) framework refinements that focus on particular software engineering activities or artifacts. For example, Domain Analysis techniques [Ara93] will have to be applied in order to identify organization-specific types of reusable artifacts and appropriate characterization languages. Furthermore, various research disciplines have developed specific reuse concepts for several of these artifacts types, e.g. Product Line Approaches [BJM+00], Process Patterns (e.g. [Mün01]), Analysis Patterns [Fow97], Design Patterns [GHJ+96], or source code reuse [PF87]. In the following, we will look in more detail at process models, a specific kind of artifacts typically maintained by the EF. More information on software reuse in general can be found in [SPM94][SCK95][JGJ97]. 2.2.1

Process Modeling

Process modeling as a way to capture and reuse knowledge about software development processes has a long tradition in SE research [RV95]. Process modeling is concerned with the specification and evolution of explicit representations (process models) of real-world processes occurring within software organizations. Process models are mainly used to serve as a means to support human communication about processes, or to facilitate optimization of processes, e.g. in terms of throughput or quality. To achieve the latter, process models serve • as a basis for reasoning about real-world processes (e.g. simulation,

critical path analysis, deadlock detection, etc.), • as domain knowledge or ’best-practice’ patterns (see e.g. [Mün01]) during project planning, • as a means to support the enactment of real-world processes, ranging from non-restrictive guidance (see e.g. [BW98]) to restrictive process automatization by workflow engines (see e.g. [Fer93]). So far, three main [Law97][CHR+98]:

approaches

have

been

distinguished

• communication-based modeling describes processes as communication

acts between performers and customers [WF87]. • artifact-based modeling is centred around the products (i.e. documents) on which specific operations (e.g. creation, read-access, modification) can be performed as the artifacts pass through a series of activities (see e.g. [CG99]).

17

18

CHAPTER 2 Knowledge Management and Software Engineering

• activity-based modeling focuses on the activities that occur during the

process, along with the flow of information (product flow) between these activities and the order in which they occur (control flow) (see e.g. [SO97]). For each of these approaches, various representation techniques have been proposed, including Petri nets [BFG93], several languages inspired by different programming language paradigms (e.g. procedural [SO97], object-oriented [CHL+94][JPL98], and rule-based [TKP94][PSW92] languages), description logics [SV99], and also multi-view concepts [Ver94]. The classification scheme mentioned above provides only a coarse differentiation, i.e. there are modeling languages that facilitate both artifactbased and activity-based modeling. Whereas several different process modeling languages have been proposed, a certain core set of concepts can be identified (see [STO95]): • Activity descriptions: to define the steps that occur as part of the proc-

• • •

•

Type Level vs. Instance Level

esses; for example, activity descriptions might consist of a name, goals to be achieved, or guidelines of how to perform the activities Artifact (or product) descriptions: to define the various products that are handled during activities Resource description: to specify human or computer resources (e.g. tools) that can be assigned to activities or used during activities Relationships among entities: to define different kinds of associations and dependencies between activities, artifacts and resources; for example, to specify decompositions on activities into sub-activities, to define which products have to be created during certain activities, or to specify the roles in which a resource can participate in activities Constraints: to specify conditions over activities, products, and resources that have to be satisfied (e.g. entry/exit conditions that must hold when the assigned agent attempts to start/finish an activity).

For process models, it is important to distinguish between a type level and an instance level (see e.g. [JPL98]). The type level represents classes of (real-world) activities (e.g. the class of all implementation activities), products, and resources. The instance level represents concrete occurrences of (real-world) activities (e.g. a concrete implementation activity currently being performed by an agent), products, and resources. In this work, the term "process model" always denotes a type level model, in which process types, product types and resource types represent classes

2.2 Knowledge Management for Software Engineering

19

of activities, products and resources, respectively; Figure 2.5 shows a typical example of a process type definition. process type definition name Implementation Process What is the name of the activity class? goal Transformation of the Detailed Design representation of a software product into a programming language realization products What is the goal consume to be reached? reqdoc: Requirements Document desdoc: Design Document W h a t p ro d u cts a re ... a ccessed? produce codedoc: Code Document

What products are created?

When can activities of conditions this class be started? precondition reqdoc.status = "complete" and desqdoc.status = "complete". ... end process definition

Fig. 2.5: Excerpt from a process type definition in the process modeling language MILOS (for details, see [VBM+96]).

The terms "activity", "product", and "agent" denote an individual occurrence (or instance); it will be clear from the context whether the realworld occurrence or its corresponding (instance level) representation is meant. In Software Engineering, the elicitation, maintenance, and distribution of process models is typically considered to be the responsibility of a specific organizational unit, called Software Engineering Process Group (or Process Group (PG) for short), as proposed by various software process improvement initiatives (e.g Capability Maturity Model [PCC+93], or SPICE [EDM98]). The Process Group can be regarded as a subgroup of the Experience Factory staff. 2.2.2

Process-Centred Software Engineering Environments

In the literature, tool support for Knowledge Management that focuses on Software Development Processes has been proposed in the form of Process-Centred Software Engineering Environments (PSEEs) [GJ96]. The support provided encompasses several process-relevant areas such as modeling, planning, managing, executing, and monitoring software processes.

Process Group

CHAPTER 2 Knowledge Management and Software Engineering

Garg and Jazayeri distinguish between three different areas [GJ96]: • Process engineering: The definition and maintenance of software proc-

ess models. • Software engineering: The development and maintenance of a software product (by following a software process). • Project management: The coordination and monitoring of the activities performed during software engineering. A PSEE provides tool support for these three areas, integrated into a single environment (see Figure 2.6). So

re Engineeri ftwa ng Status

Automation

Guidance

Enforcement Analysis

Process

Definition

PSEE

Status Monitoring

Simulation History

ine Eng

Measurement

er ing

Improvement

tM ana geme nt

20

Modification Controlling

jec o r P

Fig. 2.6: Software Development Support by a PSEE [GJ96].

Again, it is important to distinguish between the generic (type level) process models defined during process engineering, and the project-specific (instance level) process model also called the project plan. The latter might be modified as part of Project Management due to external or internal reasons. Figure 2.7 illustrates this distinction by outlining an idealized dataflow between process engineering, project management and software engineering. The dataflow has been annotated with the corresponding QIP steps (see Table 2.1).

2.3 Shortcomings of SE Knowledge Management Approaches

Learning (QIP 5-6)

Past experience Process requirements

Process engineering

Process model

Project requirements Product requirements

Project planning

Project management & Software engineering

(QIP 1-3)

(QIP 4)

Project plan

Product

Fig. 2.7: Dataflow between the three areas supported by a PSEE (adapted from [GJ96]).

An initial process model is created during process engineering; this process model is supposed to be independent of particular projects. For a specific project, the process model (or part of it) is instantiated to reflect a given project’s characteristics and requirements. This instantiated (or tailored) process model, the initial project plan, is the result of a project planning step. The project plan specifies the activities that are to be performed during software engineering. The PSEE supports this plan enactment by enforcing or automating activities, guiding process performers (e.g. designers, reviewers, programmers, etc.) through the process, or providing status information. Based on experience acquired during specific projects, the process model might need to be adapted to better meet the organization’s goals, resulting in a continuous process (model) improvement. 2.3

Shortcomings of SE Knowledge Management Approaches

2.3.1

Shortcomings of Experience Base Approaches

At the time of writing this thesis, most existing Experience Bases are based on the passive query/return model, where users are assumed to expresses their information need in the form of a query2, and are provided with the result set determined by the query. As argued in Chapter 1, such

(2)

Note that, according to Clarification 2.3, the EF supplies experiences "on demand".

21

22

CHAPTER 2 Knowledge Management and Software Engineering

an approach is inadequate to effectively provide software process participants with up-to-standard, relevant information. In particular, systematic reuse is difficult to ensure, because the passive query/retrieve model: • relies on the user to decide when to search for relevant experiences, • requires that users know about the existence of an appropriate informa-

tion source (which, in the case that several information systems are available in addition the Experience Base, might not be trivial), know how to access them, and how to specify queries correctly, and • forces users to repeat queries regularly in order to obtain newly available information. Furthermore, current Experience Base implementations typically do not maintain the context of a user’s queries: as a consequence, users are repeatedly asked to enter project and activity characteristics in order to specify their current situation. The next time a user logs in to search for experiences related to his current activity, he will have to specify the activity characteristics again. 2.3.2

Shortcomings of Process-Centred SE Environments

While process modeling has been accepted by several software organizations3 (even if only in the form of informal documentation), for various reasons the use of PSEEs by process performers during their enactment of individual software engineering activities has not become state-of-practice. In our opinion, two main reasons for this lack of acceptance can be identified: 1. the highly dynamic nature of SE projects (e.g. as opposed to handling standard business processes), and 2. the inherently knowledge-intensive, creative nature of software development activities. While several approaches address the first issue by facilitating change management (see e.g. [BT96] [CHL+94]), only few address the issue of knowledge-intensive processes [DJB97]; even recent comprehensive standardization initiatives (e.g. PSL [SGT+00]) do not take this issue into account.

(3)

For example, see the recent (non-exhaustive) list of all CMM Level 3 (or higher) certified companies published by the Software Engineering Institute (http:// www.sei.cmu.edu/sema/pub_ml.html)

2.3 Shortcomings of SE Knowledge Management Approaches

In particular, most existing approaches lack the concept of situation-specific information delivery. During their enactment of software engineering activities, process performers typically need access to various information that is maintained either inside (e.g. by the Experience Factory) or outside the organization in order to successfully perform their activities. However, the support provided by a PSEE is mainly focused on coordinating the different activities within a project, e.g by providing process performers with to-do lists, and notifying them when new activities have been assigned to them, or when changes in products have occurred. Desirable here would be the concept of an automated assistant that "looks over the process performer‘s shoulder" and (pro)actively provides him with available information that is relevant for the activity currently being performed. For example, during an implementation activity that involves the use of Remote Method Invocation (RMI) technology and Serialization, the programmer might be provided with the RMI specification document, a set of relevant lessons learned on RMI, as well as known issues and problems with using RMI and Serialization technology at the same time. If, however, a change in the project plan results in the substitution of RMI with another technology during the implementation activity, the information on RMI should no longer be offered to the performer, but should be replaced by information on the new technology. In particular, any information about known conflicts between the new technology and Serialization should be offered now to the programmer. An analysis of the shortcomings identified for Experience Bases and Process-Centred Software Engineering Environments reveals the possibility to address them by an appropriate integration of both approaches. Such an integration would aim at using the process model as a means to structure the Experience Base, in a way such that it serves as a kind of index for experience packages. As a consequence, a proactive, situation-specific delivery of relevant experience packages (as well as other knowledge items) to performers of the activities as defined in the process model might be facilitated. The following chapter will present this integrated approach, also called Process-Oriented Knowledge Management, in more detail.

23

24

CHAPTER 2 Knowledge Management and Software Engineering

CHAPTER 3

Process-Oriented Knowledge Management

In this chapter, we provide a clarification of Process-Oriented Knowledge Management (POKM), and present a detailed life-cycle model for Software Engineering Process-Oriented KM (SE-POKM). This model is based on an explicit representation of information needs that potentially arise for process participants during their activities.

3.1

What is Process-Oriented Knowledge Management?

In the literature, a distinction is made between Product-Oriented Knowledge Management (i.e. focus on knowledge as artifacts) and Process-Oriented Knowledge Management (i.e. focus on knowledge as a resource to support human work processes)[SAD99]. Typical examples of the latter are the management of process descriptions (e.g. process modeling), or the management of experiences on performing these processes (e.g. traces, design rationales, or lessons learned). The primary goal of POKM is to establish, run and maintain an organizational environment that provides process participants with the information needed to successfully perform their activities. In the context of this work, we call Knowledge Management to be process-oriented when the Knowledge Department maintains an activity-based process model as its primary means to convert knowledge and to connect process participants with available knowledge. The following clarifications specify this in more detail. Clarification 3.1: Process-Oriented Knowledge Management Process-Oriented Knowledge Management (POKM) is a specialized form of Knowledge Management, in which a process model is the primary means to: • capture • organize • formalize • distribute • apply

25

26

CHAPTER 3 Process-Oriented Knowledge Management

• evolve

knowledge on what information might be useful to successfully perform the classes of activities specified in the process model. In the following, we explain what we mean by this process (model)-orientation of the KM phases. 3.1.1

Process-Oriented Knowledge Capture

Among the knowledge to be captured are the classes of activities performed by employees within the organization. We assume that these activity classes are explicitly represented in the form of process types (see Figure 3.1). “Real World” Activities

Process Model Testing

Black-Box Testing

s activity

t

Glass-Box Testing

process type t is sub-type of process type s

Fig. 3.1: Simplified process model example (depicted as a UML diagram). Classes of (real-world) activities are represented by process types.

Clarification 3.2: Process Type A process type is an abstract description of a class of activities, ranging from activities ’in-the-large’ (e.g. "Create a system design") to activities ’in-the-small’ (e.g. "Run the Test-Driver for a component"). Process types can be represented either informally (e.g. in textual form) or formally (e.g. as a concept class in description logics). Clarification 3.3: Activity of Type T We say that an activity act is of type T, if act is a member of the class that is is represented by T.

3.1 What is Process-Oriented Knowledge Management?

Process types are maintained in the organization’s process model, that can be regarded as a part of the organization’s enterprise ontology [UG96]. Depending on the representation formalism for process types, different relationships can be defined between process types, e.g. specialization, decomposition, or ordering relationships (see e.g. [JPL98]). Clarification 3.4: Process Model A process model consists of a set PT of process types, and a set of relations defined on PT. For the specialization relation, we assume the following interpretation: Clarification 3.5: Process Type Specialization P(A | B2). Based on the terminology introduced above, we give the following clarification of a process-oriented knowledge capture phase: Clarification 3.13: Process-Oriented Knowledge Capture Process-Oriented Knowledge Capture is concerned with capturing two kinds of knowledge: 1. a process model, 2. knowledge on what information might be useful to successfully perform the classes of activities described in the process model. MetaKnowledge

Knowledge on what information might be useful can be considered as meta-knowledge, as it makes a statement about the knowledge items stored in the information sources.

3.1 What is Process-Oriented Knowledge Management?

Example: The sentence "During implementation activities of type ’ImplementationProcess’ in which EJB technology is used, tutorials on EJB are useful for agents who have not used EJB before." captures metaknowledge on the usefulness of EJB tutorials (i.e. certain knowledge items). 3.1.2

Process-Oriented Knowledge Organization

The organization of available knowledge aims at supporting an efficient mapping from activities to the knowledge items that are considered to be useful for agents performing these activities. To this end, corresponding meta-knowledge is associated with each process type (see Figure 3.2). Process Model

Meta Knowledge MKTesting

Testing

Black-Box Testing

Information Universe

MKGB-Testing

Glass-Box Testing MKBB-Testing

s

MKs

t

MKt

process type t is sub-type of process type s

Meta-knowledge MKt is a spezialization of meta-knowledge MKs

Fig. 3.2: Meta-knowledge organization based on process types. The type-specific metaknowledge allows to selects useful information items from the Information Universe.

For each process type specified in the process model, the meta-knowledge chunk captured during the process type-specific knowledge capture task is associated with that process type. These chunks refer either directly (e.g. via a static link) or indirectly (e.g. via a query statement to a database) to certain knowledge items from the organization’s information universe. Thus, for a process type S, the associated meta-knowledge MKS can be used to determine a useful set of knowledge items for agents performing activities of type S. Clarification 3.14: Information Universe IUt The Information Universe IUt is the set of all information items that can be retrieved from the information sources available to the organization at time t.

31

32

CHAPTER 3 Process-Oriented Knowledge Management

Since typically new knowledge items are continuously created (as well as deleted) both within and outside the company, the set of available items evolves over time. If the process model defines a specialization relation on the set of process types, then the knowledge organization has to reflect this relation by a corresponding specialization relation on the associated meta-knowledge (see Figure 3.2). Given our interpretation of process type specialization (see Clarification 3.5), it seems natural that meta-knowledge should be ’inherited’ along the specialization relation: a knowledge item that is considered useful for activities of a given process type is, by default, also considered useful for activities of subtypes of that process type. On the other hand, given T n group

Deploy Group B as a "control group" in order to validate stable system behaviour (i.e. monitor and compare the number of relevant information items offered by their Information Assistants). 6.2.2

Efficiency Aspect

The original benefit formulation "Time spent on searching is reduced" is reformulated in the following way: Relevant information is found faster when using PRIME than without it. This hypothesis might be tested by the following extensions to the case study outlined in Section 6.2.1: • In addition to Step (4), measure the cumulative time tsystem needed by

PRIME to retrieve the information items for Group A members during their activities. • In addition to Step (5), measure the time tgroup that members of Group A spent on searching for information items.

(6)

Whether an information item would have been actually useful might be subject to some discussions. However, the final decision should be left to the team member who performed the activity, as the Information Assistant is primarily intended to satisfy individual information needs.

6.2 Case Study Outline

Then the post-mortem analysis in Step (6) is intended to validate the following hypothesis: t system t group --------------- < -------------n system n group

i.e., the time required by PRIME for information delivery with respect to the number of useful information items found is shorter than the time spent on searching by Group A members with respect to the number of actually useful information items found by them during their software engineering activities. Deploy Group B as a "control group" to compare the amount of time spent on searching by them (in addition to monitoring system behaviour in terms of the number of relevant information items offered by their Information Assistants). 6.2.3

Convenience Aspect

The expected benefit "Searching for information is more convenient" might be analyzed by conducting a survey on the members of Group B at the end of the case study outlined in Section 6.2.1. The survey could be based on a questionnaire that allows Group B members to express their subjective opinion on whether they found working with the Information Assistant was preferable to the way in which they had to search for information during their former software engineering projects. It is important that the questionnaire distinguishes between the initial "bootstrapping phase" and the phase in which PRIME is supposed to be "fully-operational", starting with the disabling of the Information Assistant for Group A members. Apart from the usual "tool mastery burden" caused by any new tool that is introduced into an organization, the benefit of PRIME during bootstrapping is likely to be limited to providing team members with personal, activity-specific information items ("bookmarks"). As this requires that the team members first have to find these items on their own, the convenience gain will probably be considered to be comparatively low during this phase. As the approach presented in this thesis is intended for sufficiently large software organization (see the influencing factors listed in Section 6.1), the case studies outlined above would have to be conducted in an appropriate industry context, which would have exceeded the boundaries of this work. Conducting the case studies in a smaller setting (e.g. with a group of students at our university) might have a psychological benefit, but bears a high possibility of not yielding statistically significant results for this type of work, as required for a scientifically sound evaluation. Hence,

157

158

CHAPTER 6 Discussion

we decided against a statistical evaluation of the experience gained with our approach so far as part of this thesis. However, the need for an active information delivery as provided by PRIME within the context of a PSEE has been acknowledged by an industry study conducted with MILOS at DaimlerChrysler (Ulm).

CHAPTER 7

Summary & Outlook

This chapter recapitulates the main contributions of this thesis and concludes with an outlook on future work.

For the successful enactment of software development processes, it is essential that process participants are provided just-in-time with all information available that is relevant and useful for their current activities. The difficulty is rooted in the continuous change of both process characteristics and process environment: 1. participants are continuously starting new activities, changing roles during the activities, or dropping out of activities. 2. the characteristics of activities change frequently, e.g. because of changes to relevant input products, or changes to the set of tools being used. 3. the process environment changes frequently: both inside and outside the organization in which the process occurs, new information is continuously created that might be highly relevant to the process participants. Standard information filtering/retrieval approaches are inadequate in such situations: the passive query-return model typically leads to under-utilization of available information [MR97], e.g. because it assumes agents to know about the existence of relevant information sources, as well as when and how to query them appropriately. While information filtering approaches based on long-term queries or user profiles address issue (3), they fail to distribute relevant documents because of (1) and (2), unless the long-term queries are continously updated in order to reflect the changes. In order to address these problems, we decided to utilize the organization’s process model as the basis to coordinate the Knowledge Manage-

159

160

CHAPTER 7 Summary & Outlook

ment activities required for a systematic, active delivery of information. The thesis presented a detailed life-cycle model for Software Engineering Process-Oriented Knowledge Management (SE-POKM). This model specifies the activities and responsibilities of three different stakeholders: the Process Group (PG; focusing on process quality and improvement), the Knowledge Department (KD; responsible for knowledge management within the organization), and process participants (performing activities and requiring access to available knowledge). At the basis of the life-cycle model for SE-POKM lie (i) an explicit representation of the organization’s process model, and (ii) an explicit representation of meta-knowledge on what information might be useful for participants to successfully perform the classes of activities described in this process model. In this work, we introduced a representation formalism for this kind of meta-knowledge in the form of situation-dependent, recurrent information needs that typically arise during software development activities. Essential components of these information needs representation are: • a question (or question template) in natural language that denotes the

information need • a structured precondition that specifies the situation in terms of constraints on the activity, activity-related entities (e.g. products), the participant’s role in this activity, as well as the participant’s profile (e.g. his skills, preferences, etc.) • alternative ways to potentially satisfy the information need in the form of information source usage recommendations that contain parameterized, executable query commands to available information sources. The organization’s process model serves as a starting point to elicit information needs that are likely to arise for each process (activity) type; in addition, it is used to maintain the captured information needs by associating them with appropriate process model entities. In the presence of process type-specialization, the organization scheme presented in this work allows inheritance of information needs along the specialization relation. Together with the concept of generic (i.e. parameterized) information needs, this facilitates reuse of information need definitions in sub-types. In order to prevent the inheritance of information needs that should be refined in correpondence to the level of detail reflected by a sub-type, our approach provides an explicit specialization relation on information needs. Depending on the complexity of the organization’s domain (measured in terms of the number of different products, tools and technologies that are

161

handled by the participants during activities of a given type), the large number of information needs associated with one process model entity is likely to become difficult to maintain over time. In order to address this scaling problem, we extended the basic process-oriented organization scheme to encompass additional domain entities (e.g. product types, tools, technologies, etc.) that can be referenced by activity representations, giving rise to an incremental construction of a software organization-specific domain ontology. Based on this information need organization scheme, we presented a retrieval mechanism in order to automatically determine the set of information needs that are likely to arise in a specific situation. Given the characterizations of a process participant and an activity that he has been assigned to perform in a certain role, the mechanism determines the set of information needs via an activate/trigger strategy: first, the domain entities present in the object-oriented activity characterization activate all information needs being associated with these entities. In a second step, the preconditions of activated information needs are evaluated: only those whose precondition holds in the current situation are triggered, i.e. supposed to be presented to the process participant. Thus, in contrast to other Process-Oriented Knowledge Management approaches, our approach does not attempt to directly retrieve all information items that might be useful/relevant for the process participant during his activity. Instead, we assume that the triggered information needs are presented to the participant in the form of a list of corresponding textual questions. From this list, the participant is assumed to choose one that corresponds best to his current information need. For this chosen information needs, the predefined information source usage recommendations are executed (i.e. the specified query commands are instantiated and sent to appropriate information systems, or contact information for human subject-matter experts is displayed) to provide the process participant with information items that potentially satisfy his information need. Because of the dynamic nature of software processes and their changing environment, it seems unrealistic to assume that a fixed set of information needs can be identified and modeled in advance that covers all information needs that will actually arise. Therefore, our life-cycle model for SEPOKM specified an evolution phase in which the information need model is continuously updated to better reflect the participants actual information needs. In order to capture actual information needs that currently arise for participants during process enactment, the life-cycle model presented in this thesis proposed the deployment of a forum that is operated by the Knowledge Department. Participants can post requests for information to this

162

CHAPTER 7 Summary & Outlook

forum or provide feedback on information needs presented to them automatically. In addition to replying to information requests with appropriate information items, members of the Knowledge Department are assumed to identify information requests that are likely to recur. The formalization of these recurrent requests as information needs (i.e. including potential ways to automatically retrieve information to satisfy them) should be in the interest of both the process participants and the Knowledge Department: on one hand, participants can be provided automatically during future activities with information that satisfies their information needs, without bothering to contact the Knowledge Department, or manually formulating queries to information systems. On the other hand, the Knowledge Department will be spared from repeatedly answering standard questions (especially those of new participants), so that human experts in the KD need only be consulted for new, more difficult problems. The concepts presented in this thesis have been implemented in a system called PRIME (PRocess-oriented Information resource Management Environment). PRIME provides tool support for process participants and members of the Knowledge Department. PRIME is designed to be coupled with the organization’s Process-Centred Software Engineering Environment (PSEE), such that it can provide users with activity- and situation-specific information from information sources available to the organization. As a proof-of-concept implementation, PRIME has been coupled with the PSEE MILOS [HKM01].

Bootstrapping Knowledge Management with PRIME

In particular, PRIME allows a smooth introduction of Knowledge Management services into the every-day work practice of process participants. To begin with, the system can be used by participants to maintain activityspecific bookmarks (i.e. URL links to favourite documents), providing participants with an activity-oriented way to organize and quickly access their documents. In addition, PRIME’s Information Request Forum serves as platform for activity-specific communication with the Knowledge Department. Alternatively, if a KD has not yet been established within the organization, requests for information can also be posted to a forum of collaborators that support each other by answering other persons’ questions. At this stage, no modeling effort is required other than the effort already spent on providing participants with to-do lists; hence, a Knowledge Department is not a prerequisite for this level of service. Only when • users start to express an interest in being provided with certain book-

marks on a systematic basis during a certain class of activities, or • the Process Group requests that users should be provided with certain information during a class of activities (captured by them in the form of a corresponding process type),

7.1 Outlook

the need for a KD arises to capture and formalize these requests in the form of explicit information resources, and to provide access to the requested information from appropriate information sources. 7.1

Outlook

Future work has to be conducted mainly in two directions: (i) the empirical evaluation of the approach presented in this thesis, and (ii) conceptual extensions based on the results of this evaluation. An evaluation of the approach will have to based on appropriate tool support, as the life-cycle model focuses mainly on the automation of situation-specific information distribution. At the time of writing this thesis, the implementation of PRIME has reached a stage where students have started to use it during their implementation activities on MILOS. An empirical evaluation of the benefits expected from a deployment of PRIME within software organizations has to be the object of future research. In anticipation of a likely result of such an empirical evaluation, future extensions of the work presented here will need to address the high effort required for information need modeling. As an alternative to the explicit representation of logical preconditions, techniques known from Collaborative Filtering (see e.g. [Lie95]) or Case-Based Reasoning (see e.g. [RA01][Ric01]) should be adapted and integrated with our mechanism for situation-specific information need retrieval. Usage of this technology could allow to provide participants with information items that other participants found useful who had ’similar’ information needs, or with former information needs that (other) participants had during ’similar’ situations. It is to be hoped that such extensions could narrow the current gap between the low effort required to maintain the participants’ personally preferred information resources during their activity, and the relatively high effort required to model fully-specified, generic information needs.

163

164

CHAPTER 7 Summary & Outlook

165

References [Aar98] R. J. Aarts. A CBR Architecture for Project Knowledge Management. In B. Smyth, P. Cunningham (Eds.): Advances in Case-Based Reasoning, Proceedings of the 4th European Workshop on Case Based Reasoning (EWCBR-98), Dublin, Ireland, September 1998. LNCS 1488, Springer, 1998. [ABM+00] A. Abecker, A. Bernardi, H. Maus and C. Wenzel. Information Support for Knowledge-Intensive Business Processes - Combining workflow with document analysis and information retrieval. AAAI Workshop on Bringing Knowledge to Business Processes, 20-22 March, 2000. [ABN+01] A. Abecker, A. Bernardi, S. Ntioudis, G. Mentzas, R. Herterich, C. Houy, S. Müller and M. Legal. The DECOR Toolbox for Workflow-Embedded Organizational Memory Access, In: Proc. of the 3rd Int. Conf. on Enterprise Information Systems (ICEIS 2001), Portugal, July 7-10 2001, Vol. 1, 2001. [ABS99] A. Abecker, A. Bernardi and M. Sintek. Enterprise Information Infrastructures For Active, Context-Specific Knowledge Delivery. ECIS’99 - The 7th European Conference on Information Systems, Copenhagen, Denmark, June 1999. [ABT98] K.-D. Althoff, F. Bomarius and C. Tautz. (1998). Using Case-Based Reasoning Technology to Build Learning Software Organizations. In Proceedings of the 1st Interdisciplinary Workshop on Building, Maintaining, and Using Organizational Memories (OM-98), 13th European Conference on AI (ECAI’98), Brighton, http://SunSITE.Informatik.RWTH-Aachen.de/Publications/CEUR-WS/Vol-14. [Ack93] Mark S. Ackerman. Answer Garden: A Tool for Growing Organizational Memory. Massachusetts Institute of Technology, Ph. D. Thesis, 1993. [ADE+99] D.F.J. Angele, S. Decker, M. Erdmann, H. Schnurr, S. Staab, R. Studer and A. Witt. On2broker: Semantic-Based Access to Information Sources at the WWW. Proceedings of the World Conference on the WWW and Internet (WebNet 99), Honolulu, Hawaii, USA, October 1999. [AH99] M. S. Ackerman and C. Halverson. Organizational Memory: Processes, Boundary Objects, and Trajectories. Proceedings of the IEEE Hawaii International Conference of System Sciences (HICSS 99), January, 1999. [AHM+02] A. Abecker, K. Hinkelmann, H. Maus and H.-J. Müller (Hrsg.). Geschäftsprozessorientiertes Wissensmanagement, Springer, 2002. [AM95] Mark S. Ackerman and E. Mandel. Memory in the Small: An Application to Provide Task-Based Organizational Memory for a Scientific Community. Proceedings of the IEEE Hawaii International Conference of System Sciences (HICSS 95), January, 1995, vol. IV, pp. 323-332.

166

[AM99] M. S. Ackerman and E. Mandel. Memory in the Small: Combining Collective Memory and Task Support for a Scientific Community. Journal of Organizational Computing and Electronic Commerce, 1999, 9(2-3), pp. 105-127. [Ara93] G. Arango. Domain Analysis Methods. In Software Reusability, Ellis Harwood, 1993. [Bas89] V.R. Basili. The Experience Factory: packaging software experience. In Proceedings of the Fourteenth Annual Software Engineering Workshop, NASA Goddard Space Flight Center, Greenbelt, MD 20771, 1989. [BC92] N. J. Belkin and W. B. Croft. Information filtering and information retrieval: Two sides of the same coin?, Communications of the ACM 35(12): 29–38, 1992. [BCR94] V.R. Basili, G. Caldiera and H. D. Rombach: Experience Factory. In Encyclopedia of Software Engineering, volume 1, pp. 496-476, John Wiley & Sons, 1994. [BDF96] S. Bandinelli, E. Di Nitto and A. Fuggetta. Support Cooperation in the SPADE-1 Environment. IEEE Transactions Software Engineering, Vol. 22, No. 12, December. 1996, pp. 841-865. [BFG93] S. Bandinelli, A. Fuggetta and S. Grigolli. Process Modeling-in-the-large with SLANG. In IEEE Proceedings of the 2nd International Conference on the Software Process, Berlin (Germany), 1993. [BGH+98] F. Bendeck, S. Goldmann, H. Holz and B. Kötting. Coordinating Management Activities in Distributed Software Development Projects, Proceedings of the 7 th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE '98), IEEE Computer Society Press, ISBN 0-8186-8751-7, pp. 3338, 1998. [BJM+00] D. S. Batory, C. Johnson, B. MacDonald, and D. von Heeder. Achieving extensibility through product-lines and domain-specific languages: A case study. In International Conference on Software Reuse, Springer, LNCS 1844, pp. 117-136, 2000. [Boe87] B. Boehm. A Spiral Model of Software Development and Enhancement. Computer, 20(9), pp. 61-72, 1987. [BR91] V.R. Basili and H. D. Rombach. Support for a comprehensive reuse. Software Engineering Journal, September 1991. [BT96] G.A. Bolcer and R.N. Taylor. Endeavors: A Process System Integration Infrastructure. Proceedings IEEE Computer Soc. International Conference on Software Process (ICSP4), Los Alamitos, California, USA, 1996, pp. 76-89. [BW98] U. Becker-Kornstaedt and R. Webby. Towards a Comprehensive Schema Integrating Software Process Modelling and Software Measurement. IESE Report No. 021.97/E, Fraunhofer IESE, 1998. [CFH+99] A. Cushman, M. Fleming, K. Harris, R. Hunter and B. Rosser. (1999). The Knowledge Management Scenario: Trends and Directions for 1998-2003, Gartner's Group Strategic Analysis Report R-07-7706, 1999.

167

[CFS97] K. Cole, O. Fischer and Ph. Saltzman. Just-in-Time Knowledge Delivery, Communications of the ACM, Vol. 40, No. 7, 1997. [CG99] G. Cugola and C. Ghezzi. Design and implementation of PROSYT: a distributed process support system. In Proceedings of the 8th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, California, USA, June 1999. [CHL+94] R. Conradi, M. Hagaseth, J. O. Larsen, M. Nguyen, G. Munch, P. Westby and W. Zhu. EPOS: Object-Oriented and Cooperative Process Modeling. PROMOTER book: A. Finkelstein, J. Kramer and B. A. Nuseibeh (Eds.). Software Process Modeling and Technology, 1994, p. 33-70. Advanced Software Development Series, Research Studies Press Ltd. (John Wiley). [CHR+98] A. Cichocki, A. S. Helal, M. Rusinkiewicz and D. Woelk. Workflow and Process Automation: Concepts Technology. Kluwer. 1998. [DC99] C. J.-N. Despres and D. Chauvel. Mastering Information Management: Part Six Knowledge Management, Financial Times, March 8, 1999, pp. 4-6. [Del00] B. Dellen. Change Impact Analysis Support for Software Development Processes, Ph.D. Thesis, Fachbereich Informatik, Universität Kaiserslautern, 2000. [DHM+97] B. Dellen, H. Holz, F. Maurer and G. Pews. Knowledge-Based Techniques to Improve the Flexibility of Workflow Systems (in German), Software Management 1997, Reihe Wirtschaftsinformatik, B.G. Teubner Verlagsgesellschaft, Germany, 1997. [DHP97] B. Dellen, H. Holz and G. Pews. Knowledge Management in CoMo-Kit (in German), Proceedings of the KI-97, 1997. [DJB97] T. Davenport, S.L. Jarvenpaa and M.C. Beers. Improving Knowledge Work Processes. Sloan Management Review, Vol. 37, No. 4, pp.53-65, 1997. [DM95] B. Dellen and F. Maurer. Integrating planning and execution in software development processes. In proceedings of the Workshop on Enabling Technologies: Infrastructures for Collaborative Enterprises (WET ICE ’96). IEEE CS Press, June 1996. [DM98] B. Dellen and F. Maurer. Change Impact Analysis Support for Software Development Processes. Journal of Applied Software Technology, International Academic Publishing, 1998. [DMM+97] B. Dellen, F. Maurer, J. Münch and M. Verlage. Enriching Software Process Support by Knowledge-based Techniques. In International Journal of Software Engineering and Knowledge Engineering, Volume 7, No.2, 1997, pp. 185-215. [DP98] T. Davenport and L. Prusak. Working Knowledge: How organizations manage what they know, Harvard Business School Press, Boston, 1998. [EDM98] K.E. Emam, J.N. Drouin and W. Menlo. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. IEEE Computer Society, Los Alamitos, CA, 1998. [EGR91] C. A. Ellis, S. J. Gibbs and G. L. Rein. Groupware - Some Issues and Experiences. Communications of the ACM, 34:1, pp. 38-58, 1991.

168

[Fel00] R.L. Feldmann. On Developing a Repository Structure Tailored for Reuse with Improvement. In G. Ruhe, F. Bomarius (eds.): Learning Software Organization -Methodology and Applications. Lecture Notes in Computer Science #1756, Springer-Verlag, 2000. [Fer93] C. Fernström. Process WEAVER: Adding Process Support to UNIX. Proceedings of the 2nd International Confernence on Software Process, IEEE, Society Press, March 1993. [Fow97] M. Fowler. Analysis Patterns. Addison-Wesley, 1997. [GH98] J. C. Grundy and J. G. Hosking. Serendipity: integrated environment support for process modelling, enactment and work coordination. Automated Software Engineering: Special Issue on Process Technology 5(1), Kluwer Academic Publishers, pp. 27-60, January 1998. [GHJ+96] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-oriented Software. Addison Wesley, Reading, 1996. [GJ96] P. K. Garg and M. Jazayeri. Process-centered Software Engineering Environments. IEEE Computer Society Press, 1996. [GMH99a] S. Goldmann, J. Münch and H. Holz. A Meta-Model for Distributed Software Development, Proceedings of the 8 th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE '99), IEEE Computer Society Press, ISBN 0-7695-0365-9, pp. 48-53, 1999. [GMH99b] S. Goldmann, J. Münch and H. Holz. MILOS: A Model of Interleaved Planning, Scheduling, and Enactment, presented at the ICSE '99 Workshop on Software Engineering over the Internet. Web proceedings only: http://sern.cpsc.ucalgary.ca/~maurer/ ICSE99WS/Program.htm. [GMH00] S. Goldmann, J. Münch and H. Holz. Distributed Process Planning Support with MILOS. Int. Journal of Software Engineering and Knowledge Engineering, Vol. 10, No. 4, pp. 511-525, 2000. [Hac00] B. Hackett. Beyond Knowledge Management: New Ways to Work, The Conference Board Inc, March 2000. [HKM01] H. Holz, A. Könnecker and F. Maurer. Task-Specific Knowledge Management in a Process-Centred SEE, in K.-D. Althoff, R.L. Feldmann and W. Müller (eds.): Advances in Learning Software Organizations, Proc. of the Third International Workshop (LSO 2001), Kaiserslautern, Germany, September 12-13, 2001. Springer, LNCS 2176, ISBN: 3-540-42574-8. [Hol95] D. Hollingsworth. Workflow Managament Coalition: The Workflow Reference Model. Workflow Managament Coalition, Document Number TC00-1003, January 1995, http://www.wfmc.org/standards/docs/tc003v11.pdf. [HSW98] F. Houdek, K. Schneider, and E. Wieser (April 1998). Establishing Experience Factories at Daimler-Benz: An Experience Report, In Proc. of 20th International Conference on Software Engineering, Kyoto, Japan, pp. 443-447, 1998.

169

[JGJ97] I. Jacobson, M. Griss, and P. Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, ACM Press, 1997. [JPL98] M. L. Jaccheri, G. P. Picco and P. Lago. Eliciting Software Process Models with the E3 Language, ACM Transactions on Software Engineering and Methodology, Vol. 7(4), 1998. [KB97] B. Krulwich. and C. Burkey. The InfoFinder Agent: Learning User Interests through Heuristik Phrase Extraction, IEEE Intelligent Systems, Vol. 12, No. 5, Sept./Oct. 1997, pp 22-27. [KLW95] M. Kifer, G. Lausen, and J. Wu. Logical Foundations of Object-Oriented and Frame-Based Languages. Journal ACM, 42:741-843, 1995. [Kno96] C. A. Knoblock. Building a Planner for Information Gathering: A Report from the Trenches. AIPS 1996. [Kön00] A. Könnecker. Extending a Process-Centred SEE by Context-Specific Knowledge Delivery, Diploma Thesis, University of Kaiserslautern, 2000. [LAB+99] M. Liao, A. Abecker, A. Bernardi, K. Hinkelmann and M. Sintek. Ontologies for Knowledge Retrieval in Organizational Memories. Workshop on Learning Software Organizations (LSO) at SEKE’99, Kaiserslautern, Germany, June 1999. [Law97] P. Lawrence (Ed.). WfMC Workflow Handbook 1997. John Wiley & Sons, 1997 [LBH+99] D. Leake, L. Birnbaum, K. Hammond, C. Marlow and H. Yang. Task-based Knowledge Management. Technical Report on Exploring the Synergies of Knowledge Management and Case-based Reasoning, AAAI-99 KM/CBR Workshop, October 1999, pp. 35-39. [LC98] M. Letizia and R. Conradi. Techniques for Process Model Evolution in EPOS. IEEE Transactions on Software Engineering, Vol. 19, No. 12, December 1998, pp. 1145-1156. [LHR95] C. M. Lott, B. Hoisl and H. D. Rombach. The use of roles and measurement to enact project plans in MVP-S. In W. Schäfer, editor, Proceedings of the Fourth European Workshop on Software Process Technology, pages 30-48, Noordwijkerhout, The Netherlands, April 1995. [Lie95] H. Liebermann. Letizia: An Agent that assists web browsing. In Proc. of the 13th Int. Joint Conference on Artificial Intelligence, San Francisco, CA, Morgan Kaufmann, 1995. [Lie99] J. Liebowitz. Knowledge Management Handbook, CRC Press, Boca Raton, FL., 1999. [LR00] F. Leymann and D. Roller. Production Workflow - Concepts and Techniques. Prentice Hall, 2000 [LSR+97] S. Luke, L. Spector, D. Rager and J. Hendler. Ontology-based web agents. Proceedings of First International Conference on Autonomous Agents 1997. [Mae94] P. Maes. Agents that Reduce Work and Information Overload. Communications of the ACM 37(7): 31–40, 1994.

170

[May00] W. May. How to Write F-Logic Programs in Florid, Internal Report, Institut für Informatik, University of Freiburg, Germany, 2000. [May01] G. Mayer. Erweiterung einer prozeßorientierten Software-Entwicklungsumgebung um ähnlichkeitsbasiertes Knowledge-Management, Diploma Thesis, Universität Kaiserslautern, 2001. [MDA98] D. W. McDonald and M. S. Ackerman. Just Talk to Me: A Field Study of Expertise Location. Proceedings of the ACM Conference on Computer Supported Cooperative Work (CSCW ’98), November, 1998, pp. 315-324. [MDB+00] F. Maurer, B. Dellen, F. Bendeck, S. Goldmann, H. Holz, B. Kötting and M. Schaaf. Merging Project Planning and Web-Enabled Dynamic Workflow Technologies. IEEE Internet Computing May/June 2000, pp. 65-74. [MDH99] F. Maurer, B. Dellen and H. Holz. Process Support for Virtual Software Organizations, Proceedings of the 11th International Software & Engineering and Knowledge Engineering Conference (SEKE '99), Knowledge Systems Institute, ISBN 1-891706-012, 1999. [MH99a] F. Maurer and H. Holz. Process-Oriented Knowledge Management for Learning Software Organizations, Proceedings of the 12th Knowledge Acquisition Workshop (KAW '99), Banff, Canada, 1999. [MH99b] F. Maurer and H. Holz. Process-Centered Knowledge Organization for Software Engineering, In D.W Aha and H. Munoz Avila (Eds.). Exploring Synergies of Knowledge Management and Case-Based Reasoning, A 1999 AAAI Workshop (Working Notes). (Technical Report AIC-99-008). Washington, DC, Naval Research Laboratory, Navy Center for Applied Research in Artificial Intelligence. 1999. [MH02] F. Maurer and H. Holz. Integrating Process Support and Knowledge Management for Virtual Software Development Teams, Annals of Software Engineering, Vol. 14, Kluwer Academic Publishers, 2002 (in press). [Mil] The project web page can be found at http://wwwagr.informatik.uni-kl.de/~milos/. [MK99] D. E. Mahling and R. C. King. A goal-based workflow system for multiagent task coordination. Journal of Organizational Computing and Electronic Commerce, 1999, 9(1), pp. 57-82. [MMP96] S. Mukhopadhyay, J. Mostafa and M. Palakal. An Adaptive Multi-level Information Filtering System. Proceedings of the Fifth International Conference on User Modeling, 1996, pp. 21-28. [MR97] S. Mahe and C. Rieu. Towards a Pull-Approach of KM for Improving Enterprise Flexibility Responsiveness: A Necessary First Step for Introducing Knowledge Management in Small and Medium Enterprises. In Proceedings of the International Symposium on Management of Industrial and Corporate Knowledge (ISMICK ‘97), Compiegne, 1997.

171

[MSH+99] F. Maurer, G. Succi, H. Holz, B. Kötting, S. Goldmann and B. Dellen. Software Process Support over the Internet, Proceedings of the 21th International Conference on Software Engineering (ICSE '99), ACM Press, ISBN 1-58113-074-0, pp. 642-645, 1999. [Mün01] J. Münch. Muster-basierte Erstellung von Software-Projektplänen, Ph. D. Thesis, Fachbereich Informatik, Universität Kaiserslautern, 2001. [NFS98] F. Naumann, Ch. J. Freytag, M. Spiliopoulou. Quality-driven Source Selection using Data Envelopment Analysis, In Proc. of the 3rd Conference on Information Quality (IQ), Cambridge, MA, 1998. [NHM00] P. Nour, H. Holz and F. Maurer. Ontology-based Retrieval of Software Process Experiences. Proceedings of the ICSE 2000 Workshop on Software Engineering over the Internet. Web proceedings only: http://sern.cpsc.ucalgary.ca/~maurer/icse2000ws/submissions/Submissions.html. [Nis99] M. E. Nissen. Knowledge-Based Knowledge Management in the Reengineering Domain, Decision Support Systems (27)1-2, 1999. [NKS00] M. E. Nissen, M. Kamel and K. Sengupta. Integrating Knowledge Management, processes and systems, AAAI Workshop on Bringing Knowledge to Business Processes, 20-22 March, 2000. [OLe98a] D. E. O’Leary. Knowledge Management Systems: Converting and Connecting, IEEE Intelligent Systems, May-June, 1998, p30-33. [OLe98b] D. E. O’ Leary. Using AI in Knowledge Management Knowledge Bases and Ontologies, IEEE Intelligent Systems, May-June, 1998, p34-39. [Ost87] L. Osterweil. Software Processes are Software Too. In Proc. of the Ninth Int. Conf. of Software Engineering, Monterey CA, 1987, pp. 2-13. [PCC+93] M.C. Paulk, B. Curtis, M. Chrissis and C.V. Weber. Capability Maturity Model, Version 1.1. IEEE Software, 10(4), pp. 18-27, 1993. [PF87] R. Prioto-Diaz and P. Freeman. Classifying Software for Reusability. IEEE Software, 4(1), pp. 6-16, 1987. [PSW92] B. Peuschel, W. Schäfer and S. Wolf. A Knowledge-based Software Development Environment Supporting Cooperative Work. International Journal on Software Engineering and Knowledge Engineering, 2(1), pp. 79-106, 1992. [RA01] M. M. Richter and K.-D. Althoff. Similarity and Utility in Non-Numerical Domains, Mathematische Methoden der Wirtschaftswissenschaften, Physika-Verlag, pp. 403 – 413, 2001. [Rem00] U. Remus. The role of process modeling in designing process-oriented knowledge management systems, AAAI Workshop on Bringing Knowledge to Business Processes, 20-22 March, 2000. [Ric01] M. M. Richter. CBR: Past and Future - A Personal View. Invited Talk, International Conference on Case-Based Reasoning (ICCBR-2001), Vancouver, British Columbia, Canada, 30 July - 2 August 2001. http://wwwagr.informatik.uni-kl.de/~richter/

172

[RMS00] U. Reimer, A. Margelisch and M. Staudt. A Knowledge-Based Approach to Support Business Processes, AAAI Workshop on Bringing Knowledge to Business Processes, 20-22 March, 2000. [RV95] H.-D. Rombach and M. Verlage. Directions in software process research. M. V. Zelkowitz (editor), Advances in Computers, vol.41, pages 1-63. Academic Press, 1995. [SAD99] R. Studer, A. Abecker and S. Decker. Informatik-Methoden für das Wissensmanagement, In Festschrift Zum 60. Geburtstag Von Prof. Dr. Wolffried Stucky, Teubner, 1999, [Sau01] Th. Sauer. MILOS Project Trace. Project Thesis, Universität Kaiserslautern, 2001. [Schie01] K. von Schierstedt. Praktischer Einsatz von Wissensmanagement von sd&m. Eingeladener Vortrag auf der 1. Konferenz Professionelles Wissensmanagement Erfahrungen und Visionen, Baden-Baden, 14.-16. März 2001. [SCK95] G. Sindre, R. Conradi, and E.-A. Karlsson. The REBOOT approach to software reuse. Journal of Systems and Software, 30(201--212), 1995. [SFB] The web page of the "Sonderforschungsbereich 501" is http://wwwsfb501.informatik.uni-kl.de/. [SGT+00] C. Schlenoff, M. Gruninger, F. Tissot, J. Valois, J. Lubell and J. Lee. The Process Specification Language (PSL): Overview and Version 1.0 Specification. NISTIR 6459, National Institute of Standards and Technology, Gaithersburg, MD, 2000. http:// www.mel.nist.gov/psl/pubs/PSL1.0/paper.doc [SM83] G. Salton and M. McGill. Introduction to Modern Information Retrieval, McGrayHill, 1983. [SO97] M. Sutton, Jr. and L. Osterweil. The Design of a Next-Generation Process Language. In M. Jazayeri and H. Schauer (eds.), Software Engineering - ESEC/FSE'97, Proceedings, LNCS 1301, Springer, 1997; pp. 142-158. [SPM94] W. Schaefer, R. Prieto-Diaz, M. Matsumoto, Software Reusability, Ellis Horwood, 1994. [SS99] S. Staab and H. Schnurr. Knowledge and Business Processes: Approaching an Integration. Proceedings of the International Workshop on KM and OM (IJCAI-99), Stockholm, Sweden, 1999. [SS00] S. Staab and H.-P. Schnurr. Smart Task Support through Proactive Access to Organizational Memory. Journal of Knowledge-based Systems 13(5). Elsevier, 2000. [SSS99] H.-P. Schnurr, S. Staab and R. Studer. Ontology-based Process Support. Workshop on Exploring Synergies of Knowledge Management and Case-Based Reasoning (AAAI99). Technical Report, Menlo Park: AAAI. [SSS+01] H.-P. Schnurr, S. Staab, R. Studer, G. Stumme and Y. Sure. (Ed.). Professionelles Wissensmanagement - Erfahrungen und Visionen, Beiträge der 1. Konferenz Professionelles Wissensmanagement - Erfahrungen und Visionen, Baden-Baden, 14.-16. März 2001, Shaker Verlag, 2001.

173

[STO95] S. M. Sutton, Jr., P. L. Tarr and L. J. Osterweil. An Analysis of Process Languages, CMPSCI Technical Report 95-78, University of Massachusetts, 1995. [SV99] W. Scacchi and Andre Valente. Developing a Knowledge Web for Business Process Redesign. In Proceedings of the 12th Knowledge Acquisition Workshop (KAW '99), Banff, Canada, 1999. [SZ95] E. W. Stein and V. Zwass. Actualizing Organizational Memory with Information Technology, Information Systems Research, 6(2), pp. 85-117, 1995. [Tau00] C. Tautz. Customizing Software Engineering Experience Management Systems to Organizational Needs, Ph.D. thesis, Universität Kaiserslautern, 2000. [Tau01] C. Tautz. Traditional Process Representations are Ill-Suited for Knowledge-Intensive Processes, In Proc. of the Int. Conf. on Case-Based Reasoning (ICCBR-01), Workshop on Processes and KM, Position Paper, 2001. [TKP94] A. Tong, G. Kaiser and S. Popovich: A Flexible Rule-Chaining Engine for process Based Software Engineering. 9th Knowledge-Based Software Engineering Conference, September 1994 [UG96] M. Uschold and M. Gruninger. Ontologies: Principles, Methods, and Applications, The Knowledge Engineering Review, Vol. 11:2, pp. 93-136, 1996. [UW91] G. R. Ungson and J. P. Walsh. Organizational Memories. Academy of Management Review, 16(1), pp. 57-91, 1991. [VBM+96] M. Verlage, B. Dellen, F. Maurer and J. Münch. A synthesis of two software process support approaches. Proceedings of the 8th Software Engineering and Knowledge Engineering (SEKE-96), USA, June 1996. [Ver94] M. Verlage. Multi-view modeling of software processes. B. C. Warboys (ed.), Proc. Third European Workshop on Software Process Technology, (Springer Verlag, 1994) 123127. [WF87] T. Winograd and F. Flores. Understanding Computers and Cognition, AddisonWesley, 1987. [Wii93] K.M. Wiig. Knowledge Management: Foundations. Schema Press, Arlington, Texas, 1993. [Wol99] M. Wolverton. Task-Based Information Management, ACM Computing Surveys, Vol. 31, Number 2es, 1999. [WSM+99] R. Webby, C. Seaman, M. Mendonca, V. Basili and Y.-M. Kim. Implementing an Internet-Enabled Software Experience Factory: Work in Progress. International Conference on Software Engineering (ICSE '99), 2nd Workshop on Software Engineering over the Internet, Los Angeles, CA, USA, 16-22 May, 1999. Web proccedings only: http://sern.ucalgary.ca/~maurer/ICSE99WS/Submissions/Webby/Webby.html [WWT98] C. Wargitsch, T. Wewers and F. Theisinger. An Organizational-Memory-Based Approach for an Evolutionary Workflow Management System - Concepts and Implementation, Proceedings of the 31st Annual Hawaii International Conference on System Sciences, 1998, p174-183.

174

175

List of Figures Fig. 1.1:

Motivational scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Fig. 2.1:

External view on Knowledge Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Fig. 2.2:

Nissen life-cycle model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Fig. 2.3:

Experience Factory Organization (adapted from [BCR94]). . . . . . . . . . . . . . . . . . . . . . . . . .15

Fig. 2.4:

Quality Improvement Paradigm cycle (adapted from [BCR94]). . . . . . . . . . . . . . . . . . . . . . .16

Fig. 2.5:

Excerpt from a process type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Fig. 2.6:

Software Development Support by a PSEE [GJ96]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Fig. 2.7:

Dataflow between the three areas supported by a PSEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Fig. 3.1:

Simplified process model example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Fig. 3.2:

Meta-knowledge organization based on process types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Fig. 3.3:

Examples of information needs during planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Fig. 3.4:

Examples of information needs during enactment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Fig. 3.5:

Example information need "ejb_tutorial_in". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Fig. 3.6:

Process-oriented organization scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Fig. 3.7:

Process type decomposition example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Fig. 3.8:

Process type specialization example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Fig. 3.9:

Computer science domain example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Fig. 3.10: Spreading activation example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Fig. 3.11: Two required topics: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Fig. 3.12: Illustration of the heuristic’s effect on the organization via a domain ontology. . . . . . . . . . .58 Fig. 3.13: Process type with parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Fig. 3.14: Product model example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Fig. 3.15: Parameter declarations referencing the view "design view". . . . . . . . . . . . . . . . . . . . . . . . . .60 Fig. 3.16: Illustration of the heuristic’s effect on the organization via a product model. . . . . . . . . . . . .61 Fig. 3.17: Information resources indexed by category graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Fig. 3.18: F-Logic excerpt from the definition of the base class process. . . . . . . . . . . . . . . . . . . . . .64 Fig. 3.19: F-Logic representation of the process type implementation_process.. . . . . . . . . . . .64 Fig. 3.20: F-Logic representation of an activity impl_act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Fig. 3.21: F-Logic representation for class iSource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Fig. 3.22: F-Logic representation for the information source example from Table 3.1 . . . . . . . . . . . . .65 Fig. 3.23: F-Logic representation for class iSourceRec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Fig. 3.24: Rule patterns used to represent activity, role, and skill constraints. . . . . . . . . . . . . . . . . . . . .66 Fig. 3.25: F-Logic representation for the information source recommendation example . . . . . . . . . . . .67 Fig. 3.26: Method info_resources for instances of process_type. . . . . . . . . . . . . . . . . . . . . .68 Fig. 3.27: Process type implementation_process with associated information resource . . . . . .68 Fig. 3.28: F-Logic representation for class infoNeed.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Fig. 3.29: F-Logic representation for the information need example from Figure 3.5 (excerpt). . . . . . .69

176

Fig. 3.30: Rule pattern for a parameterized query command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Fig. 3.31: Example for a parameterized query command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Fig. 3.32: F-Logic excerpt from the definition of class process_decomposition. . . . . . . . . . . . 70 Fig. 3.33: Formal representation of type decompositions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Fig. 3.34: Excerpt from the formal representation of the decomposition example shown in Figure 3.7.71 Fig. 3.35: Excerpt from the formal representation of an activity decomposition . . . . . . . . . . . . . . . . . . 72 Fig. 3.36: Information need associated with type decomposition as shown in Figure 3.7.. . . . . . . . . . . 73 Fig. 3.37: Formal representation of the type specialization example depicted in Figure 3.8.. . . . . . . . . 74 Fig. 3.38: Inheritable multi-valued method info_resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Fig. 3.39: Signature extension for class iSourceRec.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Fig. 3.40: Pattern for specialization relation element