Excerpt
Contents
CHAPTER 1 Introduction
1.1 Motivation
1.2 Aims and scope of this work
1.3 Structure of the document
1.4 Recommended background
CHAPTER 2 Information needs within software projects
2.1 The nature of information needs
2.2 Scenarios with inherent information needs
2.3 Problems with required information
2.4 Changing the common process of information retrieval
2.4.1 The integration of information retrieval into workflows
2.4.2 Information needs defined as workflow
2.5 Requirements for a support concept
CHAPTER 3 MILOS as a process-centred SEE
3.1 Purpose of MILOS
3.2 MILOS system components
3.2.1 Process modelling
3.2.2 Project planning
3.2.3 Project enactment
CHAPTER 4 A concept for context-specific knowledge delivery within a PSEE
4.1 A representation for information needs
4.1.1 Information needs as objects
4.1.2 Information sources as objects
4.2 Project planning and enactment based on enriched process models
4.3 A non-invasive but active knowledge delivery
4.3.1 Workflow-integrated support
4.3.2 Non-invasive but active support
4.3.3 A context-specific, and structured set of INOs
4.3.4 The execution of an INO
4.3.5 Updating strategies related to INOs
4.3.6 Comprehensive knowledge delivery support
4.4 A learning concept for information need specifications
4.4.1 Posting of information needs as questions
4.4.2 Rating of retrieved information
4.4.3 Building and refining an attribute concept
4.5 Open concept issues
4.6 Concept overview
CHAPTER 5 The realization of context-specific knowledge delivery within MILOS
5.1 Persistent modelling of INOs and ISOs
5.1.1 The INO Manager
5.1.2 The ISO Manager
5.2 How to use persistent INOs for project planning and workflow enactment
5.2.1 The information assistant
5.3 Learning concepts within MILOS for INO refinement
5.4 The extended MILOS system architecture
5.5 Comments on the current implementation
5.5.1 Current limitations of the implementation
5.5.2 MILOS specific concept extensions
CHAPTER 6 Example scenario for knowledge delivery support
6.1 Support within an example project
CHAPTER 7 Related work
7.1 The KnowMore WFMS prototype
7.2 Support of business processes by an OM
7.3 Support for design processes using CBR
CHAPTER 8 Summary
8.1 Summary
8.2 Outlook
CHAPTER 9 References
APPENDIX 1 System documentation
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
CHAPTER 1 Introduction
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.
1.1 Motivation
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 soft- ware products. Planning and enactment tasks require access to multi- ple 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 suita- ble 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 docu- mented 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 artifi- cial intelligence to the field of software development is knowledge management (KM) [Wiig93]. Different concepts in software develop- ment use its foundations to build knowledge bases like organisational memories (OM) [Ungson91], experience factories (EF) with experi- ence 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., knowl- edge, experience) and to access it via provided interfaces in a struc- tured 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 ontology- based 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 infor- mation 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 prob- lems in holding project schedules. Often users are not aware that rele- vant 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 knowl- edge 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 envi- ronment 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.
1.2 Aims and scope of this work
This work is part of the MILOS1project [Milos] in the working group of Prof. Richter at the University of Kaiserslautern. The MILOS system is a PSEE which provides tools for process model- ling, project planning, workflow enactment, and change notification.
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 integrat- ing 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 infor- mation within different information sources. We describe how this can be provided in chapter 6 for an example project. We want to con- tribute 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 informa- tion 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 execu- tion tasks supported by a PSEE can then have access to support spec- ifications relevant for their tasks and are able to retrieve context- specific information by executing given specifications. The execution is a posting action of a context-specific generated query to an infor- mation retrieval interface. All this is described in chapter 4. The defi- nition and extension of support specifications can be supported by an organizational learning loop [Maurer99] as we describe in chapter 4 by a posting technique.
Benefits of introducing such a support concept are believed to be an improvement in finding and integrating suitable information to soft- ware 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 proc- esses. 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 chap- ter 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 con- cept. 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 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.
1.4 Recommended background
To understand the concepts developed in this thesis we assume the reader to have at least some basic knowledge about concepts and pur- pose 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 tech- niques for information retrieval, e.g., information agents is helpful but not necessarily required.
CHAPTER 2 Information needs within 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 informa- tion and initial requirements for a knowledge delivery concept.
2.1 The nature of information needs
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 clarifi- cation 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 situations are most of the times describable by a question.
It is commonly acknowledged that project planning is a highly com- plex 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 prod- ucts. 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 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 con- sider 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 devel- oped 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’.
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.
Information and knowledge
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 experi- ence, general information, or concrete knowledge.
In particular our concept is called context-specific knowledge deliv- ery but is not restricted to items commonly acknowledge as knowl- edge 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 plan- ning 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 proc- ess 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 implementa- tion 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 def- inition 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 devel- opment project. A detailed example scenario with information needs is described in chapter 6.
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 soft- ware design using UML, which he could retrieve from a skill database.
Scenario 2: A project planer has to decide which programming lan- guage 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 sys- tem, which he could determine from a requirements docu- ment 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 Dia- gram’, 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 implementa- tion of a workflow engine component with a given specification wants to reuse an existing component if possible. For this he needs to know:
- 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 compo- nents 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 expe- rienced 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. Espe- cially because that is not the main task of an agent participating in a project. He has to deliver products and might use the stated informa- tion 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.
2.3 Problems with required information
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 informa- tion 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 man- agement system, information about past projects on web pages, and quality models in an experience base.
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 que- ries, we restrict our considerations on information sources which pro- vide 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 case- based 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 main- tained 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 prob- lem 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.
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 auto- mated integration of information. It is fairly hard to provide an auto- mated 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 loca- tion 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 cer- tain time frames. These information has to be referenced by a given query executable to retrieve the newest possible results. That encom- passes the unstable nature of information and we call a query refer- encing 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 cur- rent 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 informa- tion 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,
- information can be distributed (different sources and differ- ent 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 tech- niques used to find information items in information systems, data- bases, 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 infor- mation 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 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 docu- ments). If the tasks are performed again and again the same informa- tion 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 informa- tion.
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 infor- mation 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 persist- ent. 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 experi- ence which is usable to identify and specify information needs.
The concept of representing information needs directly within proc- ess 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 repre- sentations 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 infor- mation. 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 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-ori- ented way,
- the requirement to identify and represent common informa- tion 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 pre- sented concepts even address the issue of using different information sources. The sequence of actions can be seen as a workflow. In con- trast 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 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.
2.5 Requirements for a support 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 require- ment 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.
Abbildung in dieser Leseprobe nicht enthalten
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 manage- ment systems they should actively offer interesting knowledge to a user, they should implement functions for the integration of heteroge- neous 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 content- specific 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 con- sider 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.
CHAPTER 3 MILOS as a process-centred SEE
This chapter describes the PSEE MILOS which is the target environment in which we prototypically implemented the concepts developed in this work. The chapter gives an overview about the concepts of the MILOS system is so far as they have been relevant for our work.
Besides the aim to develop a concept for context-specific knowledge delivery within PSEEs the other main aim of our work is to combine this concept with those of the PSEE MILOS and to implement the outcome within MILOS. Due to that we describe the MILOS system with its components in this chapter as an entry point for the reader. We use this chapter to build a common understanding of the compo- nents and objects within the MILOS system and we provide the basis of a terminology used in this thesis.
3.1 Purpose of MILOS
The purpose of MILOS as a PSEE is the support of software develop- ment projects by providing tools for process modelling, project plan- ning, and project plan enactment. The coordination aspect within projects is thereby a major issue as there are multiple interrelations between project elements and project management consists of multi- ple interacting activities and decisions. Common PSEEs provide sup- port for coordination for projects which are conducted at one location. A feature of the MILOS system is the coordination of dis- tributed project teams and their activities by providing a system based on a distributed architecture for web-enabled project coordina- tion.
With a distributed project team the issue of propagating changes to the project environment becomes even more important. Aim is here to keep all parts of a project consistent, e.g., by information partici- pants about delays and changes to prevent inconsistencies. The MILOS system provides an environment to support flexible, dynamic coordination of distributed software development teams by integrat- ing project planning and workflow technologies over the Internet [Maurer00].
The MILOS system is the result of the combination of two approaches for building, instantiating, and managing processes: CoMoKit [Dellen95] and MVP-E [Lott95]. The development of the MILOS system has been part of the Sonderforschungsbereich (SFB) 501 ’Development of Large Systems with generic Methods’ [SFB]. Detailed information on the origin of MILOS can be found in [Dellen95]. The descriptions in this chapter and thus our work is based on the current MILOS system as described in [Maurer00].
The next section describes the main components and concepts of the MILOS system which build the context for the concept development and implementation presented in this work. Especially the MILOS property of being based on object-oriented models influenced our concept considerations to the extend that we followed an object-ori- ented concept strategy.
3.2 MILOS system components
Support for software development projects needs to be supported on three stages:
- process modelling creates an abstract representation of a development activity,
-project planning and replanning instantiates and tailors proc- ess models to a specific project and schedules the project, and
- project enactment provides the execution of a project plan and leads to the creation of products.
MILOS provides components for the support of the activities within each of these stages and provides access to these components by either a client workbench as shown in figure 1 or a web browser from which a user can log in to the MILOS system. A participating agent can also access a message window providing him with a list of mes- sages which have been sent to him during a project. Messages are sent automatically by the MILOS system to propagate changes made within a project plan using a change notification concept which can use e.g., e-mails for the notification. This contributes to the flexible nature of software projects resulting in plan changes during its execu- tion. We do not elaborate further more on the change notification, the interested reader can refer to [Dellen98].
FIGURE 1
Abbildung in dieser Leseprobe nicht enthalten
The MILOS workbench provides the environment from where to start tools like the process modeller, the project planer as done on the right, and an enactment environment as the user is about to do for the project ’MILOS’ by selecting the ’to do’ item in the pop-up menu.
The three main components of MILOS are the process modeller, the project planer, and the workflow enactment component. Concepts used within these three components are described in the following sections to provide a common understanding of terms.
3.2.1 Process modelling
A process model is an explicit, abstract representation of a develop- ment process which has to be performed during a project. The proc- ess model defines the activities to be performed and the products to be used or created by activities as part of a life cycle model. The main aspect of an explicit model is to define a common understanding of a complex development process which can and should be used as a guideline for projects. The basic notion of common process model- ling approaches is the process representing a real life activity.
The current MILOS system provides a process modelling component to define process models based on an object-oriented modelling lan- guage upon three basic object classes: processes, methods, and parameters. A MILOS process model defines relations upon instances of these classes to provide a description of what needs to be done in a project guided by such a process model.
Process A process is a description of an activity to be executed in order to contribute to fulfil a project goal. Any information needed for the execution is grouped around the process. Information which can be grouped around a MILOS process consists of a goal description, parameters which stand for products of a specific type and which are classified as input, output, or modify, context documents, and meth- ods which specify alternative ways to execute a process.
Along a set of processes, the information to successfully carry out the processes can be grouped. We call this view a process centred knowledge management view [Maurer99] which provides a natural view of software projects. People think in terms of tasks to be executed (processes which have been assigned to them) and can easily organize their work around them. This facilitates drawing a clear line among responsibilities of the project members.
Method
A method describes how the goal of a process can be achieved. For every process, the process model may contain a set of alternative methods. MILOS distinguishes between atomic (or elementary) and complex (or composed) methods. The first type of methods describes a single activity for the process, the latter type decomposes a process into one or more subprocesses.
Parameters
A parameter describes products used or created within a process. It consists of the products name and type, e.g., ClassDiagram, Word, URL. For each product type a tool binding can be specified within the MILOS workbench to provide automatic tool calling when opening a product. MILOS distinguishes between input, output, and modified products
These three object classes are the basic elements currently modelled in a MILOS process model. What is missing for our work is a way to represent required knowledge or information for the execution of a process which can not be modelled as parameter objects. An example can be the retrieval of helpful information items from a rational data- base. The concept of having an object-oriented process modelling approach is the central and interesting concept for our considerations in this work.
The following figure 2 shows an example MILOS process model with its three object classes and their relations. Process models can be created using the MILOS process modelling component which is currently based on a tree representation of a process model reflecting the schema of the process modelling language.
Abbildung in dieser Leseprobe nicht enthalten
FIGURE 2 A MILOS process model: the diagram illustrates a part of an example process model created with the MILOS process modelling component. The model defines a SW development process which is decomposed in to several subprocesses defined by the complex method ’Waterfall’. The subprocesses us parameter objects to define input and output products and have defined atomic methods to carry them out.
PM library
Explicit process models can be stored in a PM library often called experience base [Basili94]. A PM library holds several models of dif- ferent processes which can be used when planning a project which has to follow a certain process. Main purpose here is to provide reuse of models and to build a library of best practice processes. To be stor- able in a library for that purpose, process models have to be general, i.e. they should not define any context-specific information.
MILOS provides a PM experience base from which process models can be retrieved to be used as skeleton for a project plan. One aim of a PM library is to make it possible to combine different process mod- els to a new process model. A new process model can be a process model for the development of component-based systems based on iterative enhancement which uses a process model for component development based on a waterfall approach for the development of each component.
A process model is used within software projects as a skeleton to structure the flow of development activities. To be used within a project a process model needs to be instantiated from its general defi- nition (e.g., from a PM library) and extended with assignments of performing agents and schedule information. The next section describes how this can be done within the MILOS system.
3.2.2 Project planning
Project plans
Process models are generic, reusable descriptions of how to execute projects following a certain life cycle model and are part of the organ- izational knowledge. For a given project these models have to be adapted to project specific needs. These project specific models are generally called project plans. A project plan may be composed of several process models as described above using a PM library.
Project planning usually consists of setting up a project specific proc- ess model extended by schedule data and resource allocation. Conse- quently MILOS project plans capture additional project specific knowledge like the concrete project schedule and resource assign- ments. They are the basis for project enactment and coordination. Using a project plan enactment environment a project plan is the basis for actively guiding participating humans in their project work.
Within the MILOS project planer as shown in figure 3, a user can cre- ate a project plan either from the scratch by defining e.g., required tasks represented by plan process objects, or he can reference a proc- ess model as a projects’ skeleton from the PM experience base and tailor it for the current project context. A plan process object is the representation of a process object from a process model within the project planer and defines a project task. It has the same attributes as a process object like name, parameters, and defined methods and additional attributes required for storing project planning informa- tion. Consequently when referencing a process model from the PM experience base, plan process objects are created for each defined process object the PM using them as a definition template.
The MILOS project planer provides e.g., a UI for the agent assign- ment where a project planer can access a resource pool (as shown in figure 3) from which he assigns responsible agents to a task defined by a plan process object.
Agent
An agent is either a human actor or a machine who can be assigned to a task of a project plan and is further on responsible for its execu- tion to fulfil its defined goal, e.g., to create the output products.
For each plan process a pre- and postcondition can be defined that references certain attributes of plan objects. E.g., a condition might state that a preceding task has been finished.
[...]
1 Minimally Invasive Long-term Organizational Support