Extending a process-centred SEE by context-specific knowlegde delivery

Declaration:

I hereby declare that I have written the presented thesis by myself and that I have not used any other material than that listed in the references chapter.

Erklärung:

Hiermit versichere ich, daß ich diese Arbeit selbständig angefertigt und keine anderen Hilfsmittel als die im Literaturverzeichnis aufgeführten verwendet habe.

Kaiserslautern, December 15, 2000

Arne Könnecker

1

Contents

CHAPTER 1  Introduction  5

1.1  Motivation  5

1.2  Aims and scope of this work  6

1.3  Structure of the document  8

1.4  Recommended background  9

CHAPTER 2  Information needs within software projects  11

2.1  The nature of information needs  11

2.2  Scenarios with inherent information needs  13

2.3  Problems with required information  15

2.4  Changing the common process of information retrieval  18

2.4.1  The integration of information retrieval into workflows  18

2.4.2  Information needs defined as workflow  20

2.5  Requirements for a support concept  21

CHAPTER 3  MILOS as a process-centred SEE  23

3.1  Purpose of MILOS  23

3.2  MILOS system components  24

3.2.1  Process modelling  25

3.2.2  Project planning  28

3.2.3  Project enactment  30

CHAPTER 4  A concept for context-specific knowledge delivery within a  

  PSEE  33

4.1  A representation for information needs  34

4.1.1  Information needs as objects  35

4.1.2  Information sources as objects  41

4.2  Project planning and enactment based on enriched process  

  models  45

4.3  A non-invasive but active knowledge delivery  46

4.3.1  Workflow-integrated support  46

4.3.2  Non-invasive but active support  47

4.3.3  A context-specific, and structured set of INOs  49

4.3.4  The execution of an INO  50

4.3.5  Updating strategies related to INOs  52

4.3.6  Comprehensive knowledge delivery support  53

4.4  A learning concept for information need specifications  53

4.4.1  Posting of information needs as questions  54

4.4.2  Rating of retrieved information  56

4.4.3  Building and refining an attribute concept  56

4.5  Open concept issues  57

2

4.6  Concept overview  57

CHAPTER 5  The realization of context-specific knowledge delivery  

  within MILOS  61

5.1  Persistent modelling of INOs and ISOs  62

5.1.1  The INO Manager  63

5.1.2  The ISO Manager  67

5.2  How to use persistent INOs for project planning and workflow  

  enactment  69

5.2.1  The information assistant  71

5.3  Learning concepts within MILOS for INO refinement  74

5.4  The extended MILOS system architecture  76

5.5  Comments on the current implementation  78

5.5.1  Current limitations of the implementation  78

5.5.2  MILOS specific concept extensions  79

CHAPTER 6  Example scenario for knowledge delivery support  81

6.1  Support within an example project  82

CHAPTER 7  Related work  89

7.1  The KnowMore WFMS prototype  90

7.2  Support of business processes by an OM  91

7.3  Support for design processes using CBR  92

CHAPTER 8  Summary  95

8.1  Summary  95

8.2  Outlook  97

CHAPTER 9  References  99

APPENDIX 1  System documentation  103

Introduction

CHAPTER 1

The introduction chapter describes the motivation, the aims and the scope of this work. It closes by explaining the structure of the documentation to the reader.

Process-centred software engineering environments (PSEE) [Garg96]

are acknowledged tools to help in planning, managing and executing today’s software projects. Their support is mainly focused on the coordination of the different activities within a project following a defined development process, i.e. focused on project coordination. That is why the support for the individual participating agent in per-forming tasks (which have been assigned to him) is mainly restricted

to provide access to input products for a task and to tools to create defined output products.

Main tasks for a software project are the creation of a project plan and the enactment of this project plan in order to deliver certain software products. Planning and enactment tasks require access to multiple information related to the current project context. If no direct access can be supported, e.g., in the form of defined input products for a task, agents are confronted with issues to identify and find suitable information. This information can be distributed, heterogeneous, unstable (i.e. being prone to changes), hard to find, and the retrieval task can disturb the current workflow as it is commonly not a defined part of the development workflow. Even if suitable information does exist agents are not always aware of the existence and where to find it. The big issue of reusing experience [Basili91] in form of documented descriptions becomes obsolete if agents do not know that they exist and how to integrate it.

Another main stream which has been adopted from the field of artificial intelligence to the field of software development is knowledge management (KM) [Wiig93]. Different concepts in software develop-

5

6 CHAPTER 1 Introduction

ment use its foundations to build knowledge bases like organisational memories (OM) [Ungson91], experience factories (EF) with experience bases (EB) [Basili94], case-based reasoning systems (CBR) [Althoff98] and derive concepts for learning software organisations (LSO). They encompass mechanisms which help to capture and make information and knowledge accessible and (re)usable. Main concept is here to document and store any kind of information (e.g., knowledge, experience) and to access it via provided interfaces in a structured way. The common information retrieval based on statistic document analysis techniques mainly used in document management systems (DMS) is extended by, e.g., similarity-based or ontologybased retrieval, to better find relevant information items and to extract new information facts by the combination of two or more existing items.

The problem in using information sources is to determine which kind of information can be helpful within a given context and which information source can provide it. Coming back to the PSEEs these con-

texts can be planning or development activities within a software project which have certain inherent information needs, i.e. agents require and search for certain information to perform activities.

Besides the identification of required, helpful information the time effort to search for it (maybe multiple times) within different contexts is another critical factor especially when considering today’s problems in holding project schedules. Often users are not aware that relevant information exists in an available information source. Relevant information should actively be offered to a user, though.

We have explained that activities performed during a software project can be supported by a PSEE and participating agents have certain information needs within a specific context. Further more the knowledge management concepts developed for the software development field have been designed to make information and knowledge items accessible by providing search interfaces. Why not creating an environment in which to manage software projects by a PSEE supported by a knowledge delivery concept using knowledge bases which is triggered by a projects’ context? This idea and prior research on knowledge management has been the starting point for the work described in this thesis.

This work is part of the MILOS ¹ project [Milos] in the working

group of Prof. Richter at the University of Kaiserslautern. The MILOS system is a PSEE which provides tools for process modelling, project planning, workflow enactment, and change notification.

1.2 Aims and scope of this work 7

We describe the system foundations in chapter 3. Using these con-

cepts MILOS provides an environment to support flexible, dynamic coordination of distributed software development teams by integrating project planning and workflow technologies over the Internet [Maurer00].

Our aim with this work has been the development of a concept for context-specific knowledge delivery for PSEEs which can then be integrated into MILOS. The specific context in a PSEE is the enactment environment of a development process where assigned tasks have to be carried out by participating agents.

Within our work we developed an object-oriented solution which is described in chapter 4 and the realization within MILOS in chapter 5. The concept helps to provide agents involved in software project activities (like project planning and system development) using a PSEE with support to better find helpful and context-specific information within different information sources. We describe how this can be provided in chapter 6 for an example project. We want to contribute with our work in closing the loop of information packaging for the purpose of learning from it by supporting its dissemination back into project environments by providing a process-centred knowledge support strategy [Maurer99].

Software process models define which data to access at which stage of the process by defining input and output products. PSEEs support this by giving people an according access and creation framework. They apply the approach of "Giving the right information to the right people at the right time.".

Why not apply this principle to define something similar for information which has to be retrieved from an information source prior to its usage? To apply would mean to define at which stage of a process particular information or knowledge can be retrieved because it might be helpful to perform the current task. Therefore we aimed to develop a concept which makes it possible to model information sup-port specifications persistently storable in process models. These

specifications are usable within projects which are planned and enacted based on such process models as the skeleton to define required tasks. Agents working on project planning or project execution tasks supported by a PSEE can then have access to support spec-

ifications relevant for their tasks and are able to retrieve contextspecific information by executing given specifications. The execution is a posting action of a context-specific generated query to an information retrieval interface. All this is described in chapter 4. The definition and extension of support specifications can be supported by an organizational learning loop [Maurer99] as we describe in chapter 4 by a posting technique.

8 CHAPTER 1 Introduction

Benefits of introducing such a support concept are believed to be an improvement in finding and integrating suitable information to software projects, a reduction in the time effort for searching, and a better understanding of the nature and requirements of information needs within software projects by their explicit and persistent modelling. We provide a scenario to clarify all this in chapter 6. The persistent modelling can be seen as an activity to build an experience base of information needs. Over time this can provide a best practice support via information need specifications which are integrated into processes. If the information need specifications are actively provided we can even aspire to secure reuse.

The scope of our work has been to cover literature research on knowledge delivery support within software projects (the results are summarized in chapter 7 about related work), the development of a context-specific knowledge delivery concept, and its prototypical implementation within MILOS. Technically our work is focused on concepts to specify information needs by a persistent representation s and to provide mechanisms to satisfy these information needs by the

invocation of knowledge retrieval actions. Both is described in chapter 4. It has been our aim to use existing technologies and interfaces to provide retrieval support and not to develop query languages or concepts to support processing of queries. It has not been in our scope to provide mechanisms for knowledge structuring like ontologies [Liao99] or retrieval techniques like ontology-based web agents [Lott95].

Our work builds on concepts for process-centred knowledge organization stated in [Maurer99]and the provisions for a knowledge delivery concept developed within the KnowMore prototype [Abecker99], which is further discussed in the related work chapter.

1.3 Structure of the document

In chapter 2 we describe the overall system concept of the PSEE MILOS in its current implementation and explain those components in more detail which have been relevant for this work like the process modelling approach. We further use the MILOS system to introduce a term base used throughout our work. Chapter 3 defines what the term information need stands for in our work, it elaborates more about the problem context of information needs within software development projects, and states some resulting requirements for a support concept. The key elements of our knowledge delivery concept for PSEEs based on an object-oriented representation of information needs are described in chapter 4 and its prototypical implementation within our PSEE MILOS is topic of chapter 5. Within chapter 6 we sketch an example scenario for knowledge delivery support provided by an information assistant in a demo project using the extended MILOS

1.4 Recommended background 9

PSEE. We close the main part of this thesis with a comparison to related work and give a summary and outlook afterwards.

The appendix provides a more detailed chapter about the MILOS specific implementation of the developed concept. It is intended for some one concerned with the further development of the concept implementation, the interested reader might gain some general ideas.

A bold term which stands left of the normal text column marks a paragraph in which we state a term clarification to which we reference when using the named term further on in this document.

To understand the concepts developed in this thesis we assume the reader to have at least some basic knowledge about concepts and purpose of PSEE, process modelling and here especially object-oriented approaches, project planning, workflow management systems (WFMS), and software development processes. Basic knowledge about knowledge management, organisational memories, and techniques for information retrieval, e.g., information agents is helpful but not necessarily required.

10 CHAPTER 1 Introduction

Information needs within

CHAPTER 2

software projects

In this chapter we elaborate on situations within software projects where information needs arise for participating agents which serves as a problem context description for our work. From these we identify types of information and initial requirements for a knowledge delivery concept.

A software project is composed by different development phases and within these phases divided into different activities. Typical phases include project acquisition, project planning, system development, and system integration. In this work we focus on project planning and system development which can mainly be supported by a PSEE by the provision of according tools. We use these two project phases to evaluate the nature of information needs within software projects and to define the foundations of a support concept. The following clarification describes to which meaning we reference when writing about information needs.

Information need An information need (IN) encompasses a situation where an agent requires a certain knowledge or information item either to generally be able to carry out a certain activity, e.g., to test a system component he requires to have the components code, or to be able to provide a better quality of output product, e.g., a design document. These situa-

tions are most of the times describable by a question.

It is commonly acknowledged that project planning is a highly complex and dynamic task. Issues arising while creating a project plan range from the delegation of a project task to a responsible agent, over the scheduling of tasks, to decisions which methods might be suitable and could quaranty a certain quality of a task’s output products. To be able to make these decisions a project planer is required to have high experience in conducting projects, a feeling for problems which have to be predicted, and he has to use information which is prone to changes. For example a project planer confronted with the delegation of a task to an agent needs to have an overview about the

11

12 CHAPTER 2 Information needs within software projects

agents available at a certain time and to identify an agent most qualified for a task or to find a compromise of those two properties (availability and skills). Both properties are prone to changes and information about them might be held in different sources (skill database, schedule plan) and different formats (profile as a text document, scheduling dates within a database).

The complexity of project planning becomes even higher if we consider that project plans need ongoing adaption to the current project situation, i.e. the project plan itself is prone to changes because of replanning. To make replanning actions, the project planer requires on-line information about the project products, the project progress, and current information reflecting the market situation and software technologies. Project state changes imply a changing context which has to be considered while searching for helpful information.

From the consideration made above we can say that a support concept for knowledge delivery within software projects should consider the following points:

• different task types have to be supported,

• information is prone to changes,

• information is stored in different sources, even distributed,

• information is held in different storage formats, and

• project contexts change continuously.

An agent participating in the system development phase of a project is confronted with different situations as a project planer. Agents assigned to certain roles in software projects perform different tasks, have different skills, and thus require different information. An agent, e.g., responsible for the testing of a software component does not only require the component code and the method how to test it, e.g., black box testing. He also might want to use or even requires access to additional information due to given quality or process restrictions. For example to better focus the testing activity on common errors for the component type he needs information about errors detected in the past for this component type or about errors the agent who has developed the component is likely to cause. These information might be found in a database containing quality models which are updated after each conducted project or even each tested component, i.e. the retrieved quality model is only up-to-date within a certain time frame.

Identical information retrievals on a changing information source can lead to different results. But the changing information might not be the only unstable component as the context in which the information is required changes over time as well. The tester might for example test different component types during his testing activity. The required quality model is thus depending on the context attribute ’component type’.

2.2 Scenarios with inherent information needs 13

From the considerations made for system development we can say that a support concept for knowledge delivery should additionally consider the following points:

• different roles have to be supported,

• identical retrievals can lead to different results in a certain time frame, and

• required information is dependent on the context.

We will often use the terms information and knowledge with a similar understanding. Commonly the distinction is made between data, information, and knowledge in terms of having unstructured data, data with a defined semantic, and data which is intended and structured for a certain usage context.

Both terms encompass all data items which can be retrieved via an interface from a certain source and can be used to help in performing a software project task. These items include data, documented experience, general information, or concrete knowledge.

In particular our concept is called context-specific knowledge delivery but is not restricted to items commonly acknowledge as knowledge items. All retrievable information can be usable within the concept as data items stored in information sources are interpreted for their relevance.

2.2 Scenarios with inherent information needs

In the following we describe some typical scenarios for project planning and system development with inherent needs for information and the usage of additional information. Additional means here that the information is not accessible from within the development process definition provided within a PSEE. For a project planer this can be scheduling information from a database and for a programmer this can be his personnel distribution of error types during implementation with Java in the past. These additional information might help in better performing a task at hand in terms of increasing the quality, e.g., a programmer aware of his common errors often has a special focus on the critical parts then and makes less errors. Information within a development process definition is mainly restricted to input products and context documents for a process step as the process definition is limited to the most abstract view of the process to make him reusable in a broad range of contexts.

In the following we describe some typical scenarios within a development project. A detailed example scenario with information needs is described in chapter 6.

14 CHAPTER 2 Information needs within software projects

Scenario 1: A project planer who uses a project planning tool wants to assign an agent to the software design task of a project which has to use the method UML. To make a decision for an agent he needs information about:

• the set of agents he could chose from, which he could retrieve from a resource pool,

• which of these agents are timely available, which he could determine from a schedule database, and

• which of these agents has the best experience related to software design using UML, which he could retrieve from a skill database.

Scenario 2: A project planer has to decide which programming language to use for an implementation task based on an object-oriented design. The decision for a method depends on information about:

• the available methods for the implementation, which he could get from the process definition or the methodology database within a department,

• the functional and quality requirements for the overall system, which he could determine from a requirements document created in a preceding process,

• the available agents with experience for a certain method, which he could retrieve from a skill database, and

• available tools which can support the usage of a certain method to create products, which he could get from a tool web page.

Scenario 3: A programmer has to estimate the required time for the implementation of a Java component based on a given class diagram. To be able to make a time estimation he might need the following information:

• his coding speed using the programming language Java in classes per time unit, which he could get from a database storing agent performance data,

• the number of classes within the input product ’Class Diagram’, which he can get by opening the input product or by accessing an according attribute of it via an API, and

• a time estimation equation to process these two information, which he could find in a document about project planning techniques stored in a DMS.

Scenario 4: A programmer who is responsible for the implementation of a workflow engine component with a given specification wants to reuse an existing component if possible. For this he needs to know:

2.3 Problems with required information 15

• if reusable components generally exist, which he might find in an experience base,

• which of these components have a similar specification to the given, which he could determine from the experience base as well,

• what the time effort for the modification of found components in the given context could be, which he might find in the experiences base as well, and

• which agents have developed a reusable component and which have reused it in a past project, which he could find in a project data database.

The stated required information exceeds most often the amount of information which is available from the definitions for a project and the required information can be quite complex. There are truly experienced people which have certain required information already in their minds but as projects become more and more complex it is also an aim to free people of this effort to know everything. Information is prone to changes, in the field of software development even more extreme, and keep track of all changes is nearly impossible. Especially because that is not the main task of an agent participating in a project. He has to deliver products and might use the stated information items in the scenarios to perform a task with a better resulting quality.

What is important is that the stated information needs can often only be satisfied by accessing information stored in sources outside the project enactment environment, the PSEE. The definitions for a project are a framework for the coordination of activities and should not be seen as a closed world which builds only on the experience of the participating human beings.

As we can see from the nature of information needs and the stated scenarios in 3.2, different tasks and different roles require different types of information. Todays situation in software development

companies is still characterized by a distributed structure of information systems or databases. The approach to have one central reposi-tory finds more and more application but is still not the standard. Thus an agent searching for information still has to use different sources where to find and in certain cases from which to combine information items to derive facts he requires. Different required sources can be, e.g., documents might be stored in a document management system, information about past projects on web pages, and quality models in an experience base.

16 CHAPTER 2 Information needs within software projects

Different information sources store the items in different formats and they are accessible in different ways. As it becomes more and more common that the access is supported by a search interface using queries, we restrict our considerations on information sources which provide this. We further make the assumption that the information sources are mainly web-enabled, i.e. they provide a web page from where to access their contents by defining a query and search results are represented on a web-page. With these assumptions we can say that accessing information is characterized by different query types which are executed on different information sources. Query types as stated in [Maurer99] might be an SQL statement, a query on a casebased reasoning (CBR) database [Althoff98], or keyword search on a document management system (DMS). Web search engines like Yahoo are based on a keyword search as well.

With different query types executed on different information sources we can retrieve information in different formats as the format depends on the internal structure of the information source. Formats can range from complete documents, web links, a set of table entries (SQL), over single decision statements from an expert system, to cases retrieved from a CBR system. The different formats even reflect different levels of detail. A decision proposal from an expert system is surely much more specific than the return of a DMS which gives back a list of documents matching the properties defined in the query. These different abstraction levels make it harder to integrate

the retrieved information into a given context. Especially to provide an automatic integration, e.g., into templates, the structure of the retrieved information as well as its semantic has to be known. To build up repositories with a defined structure of stored information is today done by using ontologies [Liao99] and the repositories are often called organisational memories intended to provide access to any type of information or knowledge within a company. In [Abecker99] the authors describe a system called On2Broker which can extract information from external sources, structure it, and store it in its repository.

Information used for software development is also distributed in the web, e.g., on web pages of companies providing technologies for software development like the Sun Microsystems Javasoft site. The

information on these sites (accessible by a search interface provided by the site itself) might be extractable if the company allows this but for what use? The information there is prone to changes and maintained by the company. To have an up-to-date reflection of this site one would have to extract information too often. To have a system like On2Broker for fairly stable, locally related information seems to be more feasible and as we know that agents do use web repositories we have to consider information to be distributed. The common problem is that information extracted from a source might become out of date, but if not extracted the search might take longer and data can not combined to find additional facts.

2.3 Problems with required information 17

The integration aspect of information is not an easy task to automate in the field of software development. Still the processes are highly creative depending on the agents knowledge and there is still few support by the provision of formal templates. In the field of business

processes the level of automation is much higher as the processes are well known and often not that complex. As the scope of this work is not to improve software processes in terms of standardizing them by the definition of templates (which we think is even just possible to a certain level) we do not develop any concept supporting the automated integration of information. It is fairly hard to provide an automated integration for e.g., the design of a software component. It is mainly creative to decide whether an existing component design is reusable or not. Task is to provide an agent participating in a design process with similar component designs.

Automated information integration might be possible for business processes, done by [Abecker99], but from our point of view can not generally be supported. Due to the highly creative nature of software development we have to rely on the human agents when it comes to the integration of information.

A further aspect of information is the nature of changing over time. Some information types more, some less. Documents which have been created and released are less prone to changes than the contents of a maintained database. To use a document it is sufficient to provide a static link to it. Even if it is updated to a new version, when its location does not change it is still available. As the contents of a database is changing, i.e. the same query on it leads to different results in certain time frames. These information has to be referenced by a given query executable to retrieve the newest possible results. That encompasses the unstable nature of information and we call a query referencing information a dynamic link.

Information used to make a decision or to create an output product is dependent on the trace of actions which has been performed to a current point where further information is required. These information is then called to be context-specific. The context changes ongoing and in the same way the required information might change in the same manner. In the example of using queries to retrieve required information these can be captured by defining queries in a generic way. The generic aspect can be the usage of certain project attributes which are changing dependent on activities performed within a project, e.g., a attribute for a process step is the responsible agent which can change due to rescheduling activities.

The considerations above about the different types of information imply some requirements which have to be considered by a support concept dealing with these information:

• information can be unstable,

18 CHAPTER 2 Information needs within software projects

• information can be distributed (different sources and different locations),

• information can be accessible in different ways (different interfaces and queries),

• information can have multiple formats,

• information is required context-specific,

• information can have different abstraction levels, and

• information integration within software development is complicated.

2.4 Changing the common process of information retrieval

2.4.1 The integration of information retrieval into workflows

If an individual has an information need he tries to satisfy it by per-forming an information retrieval (IR). Today IR mainly uses search interfaces which provide access to electronic information bases via queries which can be submitted to a query engine. The engine can return information items which fit to the specified properties in the query. The search criteria can be e.g., a similarity-based or exact key-word match retrieval. In the age of the Internet a huge number of information bases can be accessed via the web using search query interfaces.

In this work we relate for information retrieval (IR) to the following clarification:

Information retrieval The term information retrieval (IR) encompasses all retrieval techniques used to find information items in information systems, databases, or the Internet. This includes techniques like keyword-based, similarity-based, ontology-based, and logic-based retrieval.

The common process of todays IR using information systems or web

databases can roughly be sketched by the following steps:

2. identification of the required information based on an information need,

3. identification of the information source where it can possi-

bly be found,

4. specification of properties of the required information as a

query using the given interface of the identified source,

5. execution of the query specification, and

6. representation of the retrieval results.

Following todays issues of quality assurance and structured develop- ment, software development projects should be based on standard or

2.4 Changing the common process of information retrieval 19

defined process model which are used to define a project plan. That means within a company using standardized process models certain tasks have to be performed again and again in each project only in different contexts (e.g., project type, performing agent, current documents). If the tasks are performed again and again the same information needs may arise again and again as well. Following the above sketched process of IR it would mean to do each step again and again.

One might say if the information has been retrieved before, it might already be available or known by the agent carrying out a task. But information is prone to changes as we identified it in section 3.1 and thus the retrieval has to be performed again to get up-to-date information.

This leads to the idea of representing information needs which arise during the execution of a process directly within an explicit model of the process. If it is possible to identify and represent common information needs for a process at least steps 1 to 3 of the sketched IR process can be saved by using the stored representation instead. To be able to use them again and again implies that they have to be persistent. As the processes are used in different projects, i.e. in different contexts, they require to have a generic representation. The generic

representation should than be instantiated in a given context where they are intended to be used. Even more someone has to identify the information needs which arise while executing a certain process. This can be done by initial anticipation from the understanding of process requirements and further on by collecting process execution experience which is usable to identify and specify information needs.

The concept of representing information needs directly within process models brings up two more things. First we gain a possibility to integrate the IR process into a workflow because workflows are based on project plans and these can be based on standard process models which can capture information need representations. For the full integration we further need a concept how to access these representations at the right time (i.e. during the execution of a process step as a task) and an environment where one can execute a representation and would receive the retrieval results. That would encompass steps 4 and 5 of the IR process.

Second we could provide an active support for information retrieval. On the one hand people do know what kind of information might be helpful but they do not know where to look for it. On the other hand often people are not even aware that there might exist helpful information. Thus the provision of a workflow-integrated, i.e. a PSEE integrated support environment can improve the usage of information and free the agents of the burden to do all the IR steps on their own. With the implementation of such a concept a PSEE can extend the requirement that agents performing a process need to be guided [Verlage96] by giving them active guidance for IR. Active means to

20 CHAPTER 2 Information needs within software projects

present them suitable information need specifications in a current context if support is required and to give them a tool to execute these specifications to retrieve available information.

It has been one of our issues for a knowledge delivery concept to find a suitable representation for information needs to realize the above ideas. We describe the representation in the next chapter. For now we summarize which requirements we have additionally identified in the last paragraphs. A knowledge delivery concept should consider:

• the persistent storage of information needs in a process-oriented way,

• the requirement to identify and represent common information needs,

• the integration of the knowledge delivery support into the project workflow,

• the access to search interfaces including web interfaces,

• the execution of retrievals and representation of retrieval results, and

• an active support strategy.

2.4.2 Information needs defined as workflow

In the paragraphs before we talked about the integration of a support concept into a workflow enactment environment. So far information needs are seen as isolated issues possible to satisfy with a single information retrieval. A further step can be to see information needs and their satisfaction by information retrieval (IR) as workflow as well.

An information need might not be possible to satisfy by one isolated retrieval, i.e. this can be seen as a complex information need instead of an atomic one. It might require the combination of information from different sources (implies more than one specified retrieval) or an initial information need can imply a chain of resulting actions partly composed of additional information needs and corresponding retrievals. Thus, an information need might also be representable as a workflow which can be enacted by one or more agents. The results at the end of the workflow might then satisfy the initial information

need. To get a better idea of the workflow approach for information needs we recommend to have a look at [Knoblock96]. The authors describe a planner for information gathering. An information gathering plan is a sequence of actions to efficiently retrieve requested data. The presented concepts even address the issue of using different information sources. The sequence of actions can be seen as a workflow. In contrast to that the authors in [Abecker99] do not believe that it is possi- ble to specify a knowledge intensive task (KIT) in their context as a

2.5 Requirements for a support concept 21

workflow composed of information needs and activities processing the retrieved information. They say that the set of relations and interdependencies between activities is to complex. But concepts for information gathering plans exist and might be worth an evaluation for process-centred environments.

We focus in our work on information needs to be seen as atomic actions, i.e. each information need stands for one retrieval action and thus does not require a sequence of activities. The workflow representation might be a topic for further research. For now a complex information need can be satisfied by combining suitable atomic information needs but the combination has to be done by a performing agent, i.e. is not supported within our concept.

The combination of the findings in the last four sections leads us to a set of requirements which a knowledge delivery concept helping in satisfying information needs would have to consider. The set of requirements is not to be understood as an exhaustive list of features of a support concept. Some requirements are certainly crucial for the acceptance of a support concept by agents using a PSEE like requirement 1. Others are more relevant for the ability to integrate a support concept into a PSEE considering the properties of such an environ-

ment and software development like requirement 6.

Requirement 1 The concept should extend the guidance purpose of PSEEs by an active knowledge delivery strategy.

Information support specifications require to be stored persistently and in a

process-oriented way to be usable in a PSEE.

Requirement 3 The support concept should be integrated into the project enactment environment to be minimal invasive, i.e. not to disturb the natural flow while using a PSEE.

Requirement 4 The execution of retrievals based on information specifications and the representation of retrieval results has to be supported.

Requirement 5 A strategy should exist to identify and capture common information needs to be able to extend support specifications.

Requirement 6 Different roles and task types have to be supported. within software development.

Requirement 7 Required information is dependent on the project context which is changing continuously, i.e. information support specifications require to be generic based on context attributes.

Requirement 8 Access of distributed information sources has to be supported as required information can be distributed in different sources and over different loca- tions.

22 CHAPTER 2 Information needs within software projects

Requirement 9 Information can be accessible in different ways (different interfaces using different queries) and especially using web technology.

In [Abecker99] three requirements are given for organisational mem-ories (OM) supporting knowledge management for projects. To be an evolutionary step to the existing generation of information management systems they should actively offer interesting knowledge to a user, they should implement functions for the integration of heterogeneous information, and they should support self-adaptiveness and self-organization. The requirements we identified for our context mainly address the active support by workflow-integrated contentspecific information retrieval support. The integrative requirement is seen ambitious for software development because of the lacking process support by templates but this is definitely an issue for further research. As the scope of our work is a knowledge delivery concept using the technical provisions of e.g., existing OMs we do not consider any issues concerning self-adaptiveness or self-organisation of an OM.

In the following chapter we describe our concept for context-specific knowledge delivery for PSEEs which aims at meeting the above stated requirements.