Knowledge Maps and Software Agents to Facilitate ... - Google Sites

CiComp'06

Knowledge Maps and Software Agents to Facilitate Knowledge Sources Identification in a Software Maintenance Group Oscar M. Rodríguez-Elias1, 2, Ana I. Martínez-García2, Jesús Favela2, Aurora Vizcaíno3, Mario Piattini3 1

Universidad Autónoma de Baja California, Facultad de Ciencias, Ensenada, B.C., México. 2 CICESE, Depto. de Ciencias de la Computación, Ensenada, B.C., México. {orodrigu | martinea | favela}@cicese.mx 3 Universidad de Castilla-La Mancha, Escuela Superior de Informática, Ciudad Real, España. {Aurora.Vizcaíno | Mario.Piattini}@uclm.es Abstract— Workers performing knowledge intensive activities often do not have all the necessary knowledge at hand to accomplish such activities successfully; they require consulting different sources to obtain that knowledge. A frequent problem that arises while workers are searching knowledge sources is that they may not know exactly what to search for, or where to search; therefore, to identify and locate those knowledge sources might become difficult and a time consuming job. In this paper we illustrate how a knowledge map and software agents can be used to address this problem. We describe the design of a knowledge map for a software maintenance organization, and an agent based prototype that exploits that map to help software maintainers to identify and locate knowledge sources. Index Terms— Software Agents, Knowledge Management, Software Maintenance, Knowledge Sources Location

I. INTRODUCTION

S

OFTWARE engineering processes are knowledge intensive [1], where maintaining existing products may be more knowledge intensive than developing new ones [2]. Common problems in software maintenance are related to the knowledge that maintainers need for their jobs; problems such as unused knowledge, because the sources are unknown, inaccessible, difficult to locate, or because maintainers do not know what knowledge can be obtained from them [3]. Thus, providing mechanisms to facilitate maintainers to obtain the knowledge they require for their jobs is important to improve the maintenance process [4]. One way to address such problems is by constructing a knowledge map, which can help to easily find sources that can be used to obtain the information or knowledge required to perform a specific task; since these maps can be used to point out to the sources of specific information or knowledge [5]. However, providing a knowledge map might not be enough, particularly if it requires users to spend much time searching for sources; in fact, one of the main problems in the use of knowledge management systems in software organizations, is precisely that most of those systems require

much work from users, who often report that they do not have time even for searching knowledge [6]. Therefore, it is required to use techniques or technologies aimed to facilitate the use of the map, for instance by performing some activities on behalf of the users; thus we decided to explore the use of software agents to this end. There are several reasons why agents are a good alternative for developing systems for managing knowledge [7]. For instance, agents are proactive; this means they act automatically when it is necessary, they can capture and manage information automatically; for example, acting as a personal assistant [8]. Using these characteristics, it is possible to develop software agents capable of identifying the activities that are being performed by the users of a system, and provide mechanisms to help inferring the knowledge required for those activities. In that way, it could be possible for the agents to automatically use the knowledge map to search for sources where that knowledge can be obtained. In this paper, we describe how a knowledge map was constructed for a software maintenance group, and how software agents can help to facilitate the use of that map, enabling the identification of sources of knowledge that can be helpful for the members of the group in accomplishing specific tasks. II. CONSTRUCTING THE KNOWLEDGE MAP The map was designed following data obtained from a case study in a software maintenance group [9]. To construct the knowledge map we first defined a classification schema and structure of the types of knowledge and knowledge sources. The classification schema was used to define a metamodel which describes the relationships of the knowledge subjects and its sources. Then we defined a template to describe specific knowledge subjects and sources. These descriptions were used to construct the knowledge map by representing knowledge subjects and sources in a XML format. Next, we present this development.

A.L. Morán y Solares, E. Martínez Martínez (Eds.): Memorias del CiComp' 06 Ensenada, B.C., México, 6 al 8 de Noviembre de 2006, pp. 49-54.

49

CiComp'06

A. Classification of the types of knowledge and their sources 1) Knowledge subject classification The classification of knowledge subjects was done following a schema that consists of three levels of abstraction: categories, knowledge areas and knowledge subjects. At the first level are categories, which are structural elements of high level abstraction used to classify related areas of knowledge. A category can also contain more specialized categories. In the second level are the knowledge areas, which are subdivisions of the categories that are logically related with them, for example by aggregation or composition. An area can contain more specialized sub-areas or knowledge subjects. The subjects represent basic concepts with an explicit and well defined description. They are used to describe knowledge about a set of elements that can be considered as a unit. However, a subject can also be composed by more detailed subjects. Following the schema just described, we defined some general areas of knowledge grouped into three main categories: (I) the knowledge related to the software maintenance process; (II) the knowledge required for the organization’s life; (III) and the general knowledge that is not part of the other two categories. The knowledge category of the maintenance activities is the most important, and most of the areas of knowledge are grouped here. This category is composed by three subcategories: 1) Computing fundamentals contains areas of general knowledge about computing, such as operative systems, programming languages, etc.; 2) Software engineering considers the knowledge related with the phases of the software development life cycle, such as project management, analysis and design, etc.; and 3) Application knowledge category, groups the knowledge related with the applications maintained by the team, such as specific knowledge about the products, for instance the architecture, structure, functionality, history, etc.; and the knowledge of the domain that the applications support. The organization’s life knowledge category considers the knowledge that is not directly related to the activities of software maintenance, but that all employees must know, such as the structure, norms and policies, goals, etc. of the organization; and knowledge about other processes followed by the organization. Finally, in the general knowledge category, the knowledge and skills that are not part of the daily work, but can be useful for special purposes, are considered. For example, foreign languages speaking and writing, group work coordination, leadership, etc. Figure 1 illustrates an example of the knowledge subject’s classification schema. This example shows how a specific programming language, such as C++, has been classified into a programming languages area, which is grouped into the computing fundamentals subcategory that corresponds to a part of the knowledge required for the activities performed by the members of the organization, in our case, the software maintenance activities.

Maintenance activities knowledge

Programming languages

Computing fundamentals

C++

Ansi C++

C++ Builder

C++ Sintax

C++Semantics

Visual C++

Fig. 1. Knowledge subjects classification example.

2) Knowledge sources classification A schema composed of categories and types of sources was used for classifying the sources of information and knowledge. Sources of knowledge were divided into four categories: (I) documentation, (II) people, (III) the maintained systems’ elements, and (IV) support tools. Next we describe each of these categories. Documentation category groups all the types of documents that can be used by the maintenance group. These documents were classified in six main types: 1) System documentation, 2) Technical documentation, 3) User documentation, 4) Organizational documentation, 5) Maintenance process documentation, and 6) Other documents. The people category refers to all the persons that are consulted by the members of the maintenance group. This category has been divided into three: 1) Users/Clients (Even though users and clients play different roles [10], we have decided to take them as a single category since in the group studied there is not a clear separation between the roles played by users and clients [9]). 2) Staff members are all the persons working in the maintenance group; and 3) Other experts refers to all the persons that are not staff members or users, but that are consulted by maintainers to obtain specialized knowledge, such as knowledge about the application domain, a specific programming language, etc. These experts can be either internal or external to the organization. For example, some maintainers consulted friends that are not in the organization, or consulted experts through internet newsgroup or email lists. The system category refers to all the elements that constitute the products that are being maintained and that can be sources of information and knowledge. These elements have been divided into three types: 1) Executable system, 2) Source code, and 3) Data bases of the systems maintained. Finally, the support tools category is concerned with all the tools used by maintainers to obtain information or knowledge. These tools have been divided in two types: 1) Maintenance activities support tools are those used for supporting activities of the maintenance process; and 2) General support tools are those that are not directly related to the maintenance activities. For example, organizational memories or portals, content management systems, document repositories, etc. Figure 2 presents and example of the knowledge sources classification schema; where two types of documents with information directed to the users of the applications 50

CiComp'06

maintained (the user and installation manuals) are classified as user documentation; which is a subdivision of the documentation category. Documentation

User documentation

User manual

Installation manual

TABLE I. EXAMPLE OF A KNOWLEDGE SUBJECT DESCRIPTION.

Fig. 2. Knowledge sources classification example.

3) Knowledge topics and sources metamodel A metamodel was defined based on the classification schemas to help define the relationships between the topics of knowledge, their sources, and the activities where knowledge and sources are required, generated or modified. Figure 3 shows the general view of this metamodel. The topics and sources of knowledge are considered as knowledge concepts. These knowledge concepts are used and can be generated or modified in the processes, activities or tasks performed by maintainers; defined as work definitions (concept took from the SPEM specification, and that refers to a kind of operation that describes the work performed in a process [11].) Each work definition has a purpose, described as a goal. Each source of knowledge can also have information or knowledge about topics or other sources. The levels of experiences or details about the knowledge and information can be defined with KLevel elements. Finally, sources of information can have a location where they are consulted, such as physical address, email, electronic address, etc.; and a format, for example pdf, word, or excel for electronic files. LocationKind

Format 0..*

KSourceCategory

KSourceKind

1

Location 1..* locatedIn hasKind

KSource knowsAbout

Goal required

KConcept

has

+knownConcept

WorkDefinition generates/modifies KTopic

Klevel

Process KCategory Activity

Task KArea

identified by a name and a short description. Then, the main cognitive and technical knowledge related to the subject are defined. Cognitive knowledge refers to know what, for example, which activities we must do, what information is required to do these, where we can find that information, etc. Declarative or cognitive knowledge can be divided in two types [12]: 1) topic knowledge, that refers to knowledge about concepts, their definitions, properties, and relationships; and 2) episodic knowledge, that represents the experiences on the use of knowledge. Finally, procedural or technical knowledge helps to know how an activity should be done.

KSubject

Knowledge subject

Performing modifications to the check bills elaboration m odule in the finances system

Description

Knowledge about the check bills elaboration process in the finances system, and about how to modify the m odule W hich is the m odule of check bills elaboration

Topic Knowledge

W hich are the surce files of the module W here are those files Related modules W hich is the programm ing language used Experience using the check bills elaboration module

Episodic Knowledge

Experience developing the check bills elaboration module Experience modifying the check bills elaboration module How to access the module

Procedural Knowledge

How to make changes in the module How to identify problem s in the m odule How to correct problems in the module

The example of Table I refers to the knowledge related to an activity. The topic knowledge items can be used to identify sources that can help to obtain information about the topics defined. The episodic knowledge items establish the situations that can cause generation of knowledge related to the subject. These definitions can be used to identify people that have been involved in one or more of these situations. Procedural knowledge definitions can be used to identify sources of knowledge that can be useful to obtain information about how to do something related to the subject. TABLE II. EXAMPLE OF A KNOWLEDGE SOURCE DESCRIPTION. Source id:

p1230_requerimientos.doc

Category

Documentation

Kind

System documentation / Requirements

Description

Document containing the requirements specification of the finances system SIREFI

Decision

Located at

Fig. 3. Metamodel of knowledge and sources.

Following the metamodel, we defined two templates to describe specific topics and sources of knowledge. The templates and their use are described next.

Kind

Description

Physical support

Format

Directory: "c:\projects\p1230\doc Electronic file umentation\" on project files server

word 2000

Knows about

B. Describing knowledge subjects and their sources To describe knowledge subjects we followed the template exemplified in Table I. In this template, each subject is

Concept Requirements of SIREFI system

Level Advance

51

CiComp'06

The sources of information and knowledge are described by templates as the showed in Table II. Each source has a unique identification (id), a short description, and it is classified in a category and a kind. Each source can be consulted, at least, in one location. Locations are defined by its type and a description that is used to provide specific access data. Depending on the location, the source can have a physical support (such as paper, video tape, CD, etc.) and a format; for example, the source described in Table II is an electronic file, a word 2000 document. Finally, the main information and knowledge subjects that can be obtained from the source can be specified in the “knows about” list. This information is later used to identify in which activities the source can be helpful. C. XML representation of knowledge and sources The knowledge and sources metamodel was the basis for the structure of the knowledge map. This map was created by representing the elements of the metamodel in XML format. Figures 4 and 5 illustrate the document type definition (DTD) of the sources and types of knowledge respectively. ]>

Fig 4. DTD for the knowledge sources.

The description of each source enables to define the mechanisms through which the source may be located, or consulted, joined to the knowledge topics that can be consulted in that source. The description of the types of knowledge, enables to specify if they are related to other topics, whether because they are similar topics, or because, to apply a specific knowledge topic, there are other topics that must be known. Topics of knowledge may belong to more than one knowledge area; it is possible, therefore to classify each topic in alternative areas of knowledge. The knowledge map consists of the XML representation of knowledge topics and sources. Each knowledge source and topic is represented by a separate XML document. These documents are stored in an XML database. The resulted knowledge map has been used in a prototype of an agent based knowledge management system. An example of how

the system uses the map is presented in the next section. ]>

Fig 5. DTD for the types of knowledge.

III. USING THE MAP THROUGH SOFTWARE AGENTS To address the need for an active knowledge management system able to identify appropriate knowledge and knowledge sources, we have based our proposal on the use of software agents. Agents are proactive and autonomous [13]. This means that they can decide to act when they find it necessary to do so. Thanks to these features, agents can advise users when and how should look for information in the knowledge map. Thus, agents solve two problems about which users of this kind of systems often complain: What information should be introduced in the tool and how and when it should be consulted [6]. The prototype is composed of several types of agents that collaborate to assist the users, the two most important in the management of the knowledge map are the staff agents and the knowledge manager agents (KMA) (for a complete description of the rest of the agents, consult [14] or [15].) The staff agent is a mediator between the user (a maintenance engineer [ME]) and the system. It acts like an assistant to the ME. The staff agent monitors the ME activities and requests the KMA to search for knowledge sources that can help the ME to perform his/her job. This agent has information that could be used to identify the ME profile, such as which types of knowledge or expertise s/he has or which types of sources s/he often consults. The KMA is in charge of providing support in the generation of knowledge and the search of knowledge sources. This type of agent is in charge of managing the knowledge base. The KMA generates new knowledge from the information obtained from the MEs in their daily work. For example, if a ME is modifying a program developed in the Java language, the KMA can infer that the ME has knowledge of this language and add his/her name to the knowledge base as a possible source of knowledge about Java. Figure 6 shows how these two types of agents collaborate to help the user (ME) to search for knowledge sources in a 52

CiComp'06

knowledge base which was developed using the knowledge map. When the staff agent detects that the ME is performing an activity, it tries to identify the knowledge required by that activity. For example, if the ME wants to solve a problem reported, the agent obtains information from the problem report, such as the system and the module where the problem appeared, the type of problem, etc.; then, it tries to infer what knowledge can be required to solve that problem; for instance, which are the source code files of the module, where they are, etc. This information is obtained from the knowledge map, since it has been developed following the knowledge and sources metamodel, where it is possible to define what information, knowledge, or elements are required to perform a specific task (see figure 3). The staff agents search for this information in the map, and based on it, creates a list of subjects of knowledge required.

:ME

:GUI

:StaffAgent

:KMA

:KBase

Action performed An event has been trigered

[if the ME is working on a task of the project] Obtain information topics about the task

Request search of knowledge sources that know about the topics Message about sources that were found

Show message about sources that were found

[For each topic] Search sources that know about the topic

Inform sources that were found

Fig. 6. The staff agent and the KMA communicate each other to help the ME search knowledge sources relevant to the problem at hand.

General data about the source

Shows the diferent locations of the source

Shows the kind of knowledge that the source has

List of sources found

Fig. 7. Window that shows the list of knowledge sources found.

Once the agent finishes defining the list of subjects of knowledge, it sends a message to the KMA to start searching for knowledge sources that could have information about the subjects defined. When the search is finished, the KMA informs to the staff agent, which at a time informs the user that there are sources of information that can be relevant to the activity being done; since these sources can be used to obtain knowledge related to one or more of the subjects defined. If the user decides to consult those sources, the system shows a window with the sources found, grouped by types. When the user chooses one of the sources, the system shows information

such as how or where that source can be consulted, and the main subjects of knowledge related to the activity, that can be obtained from it, as is shown in figure 7. The example illustrates how the use of software agents, and the knowledge map can be used together to help search for knowledge sources that can be relevant to the work being done by the software maintainers. This can reduce some common problems presented in maintenance groups, such as unused knowledge because it sources are unknown, or difficult to locate. This is because the agents can help the users identifying relevant sources, even when the users do not know about their existence, or the knowledge that can be obtained from them. This information is provided by the agents once such sources have been identified. On the other hand, since the agents automatically can start the search of knowledge sources, it reduces the time that maintainers could spend searching by them self. IV. CONCLUSION Facilitating access to knowledge sources is of special interest in knowledge intensive activities. An important step on doing this is to provide means that enable knowing the sources available, the place they are in, and the knowledge that can be obtained from them. However, this may not be enough in some types of processes, such as software engineering processes; in these, employees often complain that they do not have time for searching knowledge sources. Therefore, some mechanisms must be available to facilitate their work. In this paper, we have illustrated how knowledge maps and software agents can be used to this end. Based on this work, we can state that these two technologies are a potential combination that can be used to facilitate and support knowledge sources identification and location, without increasing the work of users. We have also described the development of a knowledge map, and a prototype of an agent based KM system, to exemplify how this can be done. Both, the knowledge map and the prototype, were developed following information obtained from a group of software maintenance. The prototype has been tested following scenarios obtained from this group; according to this we can state that these two technologies can be helpful to address common problems presented in this type of groups. However, more work is required to develop a complete system capable of been used in the real work of a maintenance group, in order to evaluate the benefits that these two technologies can bring to the work being done in the group.

ACKNOWLEDGMENT This work is supported in part by CONACYT under grand C01-40799 and scholarship 164739 provided to the first author, in Mexico; and the MAS (TIC2003-02737-C02-02) and ENIGMAS (PIB-05-058) projects, from Junta de Comunidades de Castilla-La Mancha, Consejería de Educación y Ciencia, in Spain. 53

CiComp'06

REFERENCES [1]

[2] [3]

[4]

[5]

[6]

[7]

J. S. Edwards, "Managing Software Engineers and Their Knowledge," En: Managing Software Engineering Knowledge, A. Aurum, R. Jeffery, C. Wohlin, and M. Handzic, Eds. Springer, Berlin, 2003, pp. 5-27. N. Chapin, "The job of software maintenance", Proc. of the Conference on Software Maintenance-1987, 1987, pp. 4-12. C. Seaman, "The Information Gathering Strategies of Software Maintainers", Proc. of the International Conference on Software Maintenance (ICSM'2002), Montreal, Canada, 2002, pp. 141-149. N. Chapin, "Software Maintenance and Organizational Health and Fitness," En: Advances in Software Maintenance Management: Technologies and Solutions, M. Polo, M. Piattini, and F. Ruiz, Eds. Idea Group Inc., Hershey, PA. USA, 2003, pp. 1-31. T. H. Davenport and L. Prusak, Working Knowledge: How Organizations Manage What they Know. Harvard Business School Press, Boston, Massachusetts, USA, 2000. M. Lindvall and I. Rus, "Knowledge Management for Software Organizations," En: Managing Software Engineering Knowledge, A. Aurum, R. Jeffery, C. Wohlin, and M. Handzic, Eds. Springer, Berlin, 2003, pp. 73-94. L. van Elst, V. Dignum, and A. Abecker, "Towards Agent-Mediated Knowledge Management", Proc. of the International Symposium AMKM 2003, Stanford, CA, USA, 2003, pp. 1-30.

[8] [9]

[10]

[11] [12] [13] [14]

[15]

P. Maes, "Agents that reduce work and information overload," Communications of the ACM, vol. 37, num. 7, 1994, pp. 31-40. O. M. Rodríguez, A. I. Martínez, J. Favela, A. Vizcaíno, and M. Piattini, "Understanding and Supporting Knowledge Flows in a Community of Software Developers", Proc. of the 10th International Workshop on Groupware (CRIWG'2004), San Carlos, Costa Rica, 2004, pp. 52-66. M. Polo, M. Piattini, F. Ruiz, and C. Calero, "Roles in the Maintenance Process," Software Engineering Notes, Special Interest Group on Software Engineering, ACM, vol. 24, Nº4, 1999, pp. 84-86. OMG, "Software Process Engineering Metamodel Specification (SPEM)," vol. 2004. Object Management Group, 2002. P. N. Robillard, "The Role of Knowledge in Software Development," Communications of the ACM, vol. 42, num. 1, 1999, pp. 87-92. H. S. Nwana, "Software Agents: An Overview," Knowledge Engineering Review, vol. 11, num. 3, 1996, pp. 205-244. O. M. Rodríguez, A. Vizcaino, A. I. Martínez, J. Favela, and M. Piattini, "Applying Agents to Knowledge Management in Software Maintenance Organizations", Proc. of the Workshop on Agent-Mediated Knowledge Management (AMKM 2004), Valencia, Spain, 2004, pp. 39-45. O. M. Rodríguez, A. Vizcaino, A. I. Martínez, M. Piattini, and J. Favela, "Using a Multi-Agent Architecture to Manage Knowledge in the Software Maintenance Process", Proc. of the International Conference on Knowledge-Based Intelligent Information & Engineering Systems, Wellington, New Zealand, 2004, pp. 1181-1187.

54