The knowledge-based content management application design methodology ICONS D25b - second edition

(1)

The knowledge-based content management

application design methodology

ICONS D25b - second edition

April 2004

(2)

IST-2001-32429

ICONS

Intelligent Content Management System

www.icons.rodan.pl

Project Partners

Rodan Systems (PL)

The Polish Academy of Sciences (PL)

Centro di Ingegneria Economica e Sociale (IT)

InfoVide (PL)

SchlumbergerSema (BE)

University Paris 9 Dauphine (FR)

University of Ulster (UK)

The knowledge-based content management application

design methodology

ICONS D25b - second edition

Project name

Intelligent Content Management System

Acronym

ICONS

Workpackage

WP7

Task

T7.3

Document type

Report

Title

The knowledge-based content management application design

methodology

Subtitle

ICONS D25b - second edition

Document acronym

ICONS D25b

Author(s)

Michal Smialek (INFOVIDE), Lukasz Balcerek (INFOVIDE),

Tomasz Biedka (INFOVIDE)

Reviewer(s)

Eliza Staniszkis (RODAN), Bartosz Nowicki (RODAN), Witold

Staniszkis (RODAN), Frank Vandebogard (SEMA), Sebastian Lisek

(INFOVIDE)

Accepting

Witold Staniszkis (RODAN)

Location

D:\Projects\ICONS\metodyka\ICONS WP7 T3 D25 0207.doc

Version

2.07 Date

April 2004

Status

final version

Distribution

public

(3)

History of changes April 2004

History of changes

Date Version Author Change description

26.04.04 2.07 M. Smialek, T. Biedka Official version of the document

31.03.04 2.06 M. Smialek, T. Biedka Version for consortium revision.

01.10.03-30.03.04 2.01-2.05 M. Smialek, T. Biedka Internal temporary versions.

20.06.03 1.34 M. Smialek, L. Balcerek Official version of the document.

15.06.03 1.33 M. Smialek, L. Balcerek, B.

Kiepuszewski Version for internal (Infovide) and consortium revision.

05.06.03-14.06.03 1.27-1.32 M. Smialek, L. Balcerek Internal temporary versions.

05.06.03 1.26 M. Smialek, L. Balcerek Official draft version of the document.

04.06.03 1.24 M. Smialek, L. Balcerek Third draft version for external review of structure and

contents. Description of roles and artefacts of SLC. Guidelines for the Concept Glossary.

01.11.02-25.05.03

1.04-1.23 M. Smialek, L. Balcerek Internal temporary versions.

30.10.02 1.03 M. Smialek, L. Balcerek Second draft version for external review

28.09.02 1.02 M. Smialek First draft version for internal review

(4)

Executive summary April 2004

Executive summary

The main objective of this document is to define the organization of the development life cycle of a software system based on the ICONS framework. The result of the work presented here is a methodology that allows for proper arrangement of the construction process. The basic assumption is that we use a ready set of configurable components that form an architectural framework. We assume that the individual elements of the architecture are supplied ready to be configured (to various extent) and linked into a coherent system. It has to be stressed that “configuration” of components is not a trivial task and requires knowledge of appropriate techniques, notations and knowledge of programming languages.

Additional objective of this paper is to describe the overall process associated with the flow of knowledge and the process of its transformation (meta-process). It is an important amendment to the software life cycle methodology. It allows the organisation that implements a knowledge management software system also to transform its processes to accommodate for the new system.

The paper is divided into nine chapters, twelve appendices and bibliography. The first chapter is a standard introduction. The following two chapters are the presentation of the general context for life cycle and management methodologies in the field of Knowledge Management and software development. In these chapters we introduce a division of the whole methodological area of KM into four sub-areas. These are: Knowledge Management Process (KMP), Knowledge Life Cycle Process (KLCP), Software Management Process (SMP) and Software Life Cycle Process (SLCP). We argue that the first two processes are important to be implemented in any organization. The SMP and SLCP should be introduced in organizations that produce software (and specifically – KM related software). We also argue that the description of SMP is outside of the scope of this paper. The following two chapters present the current state of the art in methodologies for KLCP, KMP and SLCP. We present several methodologies that were developed earlier and their results can be used to develop a novel methodology related strictly to the ICONS framework.

Chapter six introduces an important aspect of any methodology for the development of software systems, which is the notation and method of description. The methodology should be comprehensible by all, even inexperienced members of the process. The graphical notations are most communicative and thus we propose a notation based on UML (Unified Modelling Language). This graphical notation was used with success for business and system modelling purposes, and is understood by a growing (and already vast) number of system developers. Chapters seven to nine present the actual results of our effort for methodology development. We describe three methodologies for three already mentioned areas. Each of the methodologies is described in terms of roles that perform activities and produce artefacts. We use class diagrams to present static structure of relationships between roles and artefacts. We also use activity diagrams to show the dynamics of the flow of tasks in the process. Finally, we apply interaction (sequence) diagrams to present the message flow in the process.

Important parts of the document are the appendices which significantly extend chapter nine. They contain very important knowledge about the core architectural artefacts. This knowledge is based on a constantly updated (“living”) experience from the Structural Funds Portal project, and shall be further updated when appropriate new projects based on the ICONS framework commence. The appendices contain more detailed descriptions of sub-artefacts for consecutive ICONS components. This should be treated as a single place for the developers to find information relevant for the development of their specific modules. All the “good practices” are gathered constantly here for the future projects. References to appropriate other documentation when more technical details are needed are also included.

This document should be used as a handbook for process configuration. The processes described here should be used as the starting point to the definition of processes specific to the given organisation that uses the ICONS framework. The KLCP and KMP methodologies are general in nature and can be used by organisations not necessarily building an ICONS-based system.

Changes in the second version

Chapter nine was revised and amended according to the changes in the artefact and role list. Several new appendices were created and filled with descriptions of good practices gathered from the SFP project. Existing appendices were also revised accordingly. The structure of artefact presentation was also revised and specified in chapter six.

(5)

Table of contents April 2004

List of figures

Figure 1. Relations between four groups of processes in the Knowledge Management domain... 15

Figure 2. Knowledge life cycle process loop... 16

Figure 3. Phases of the On-To-Knowledge Methodology... 27

Figure 4. Adaptive life cycle by Jim Highsmith... 46

Figure 5. The ICONS architecture with Implementable and Configurable Components... 50

Figure 6. Knowledge Life Cycle Process diagram... 53

Figure 7. Associations between KLCP Methodology artefacts... 54

Figure 8. Information Gatherer with associated artefacts... 55

Figure 9. Knowledge Producer and associated artefacts... 56

Figure 10. State diagram for Knowledge Component... 57

Figure 11. Domain Expert and associated artefacts... 58

Figure 12. Knowledge Repository Editor and associated artefacts... 58

Figure 13. Knowledge Repository Engineer and associated artefacts... 59

Figure 14. Knowledge User and associated artefacts... 60

Figure 15. General flow of activities within the KLC Process... 61

Figure 16. Activities of the knowledge repository processing... 62

Figure 17. Collaboration diagram for Knowledge Production... 63

Figure 18. Collaboration diagram for Knowledge Validation... 64

Figure 19. Collaboration diagram for Knowledge Integration... 64

Figure 20. Collaboration diagram for Knowledge Usage... 65

Figure 21. Knowledge Management Process lifecycle diagram... 66

Figure 22. Associations between KMP Methodology artefacts... 68

Figure 23. KLCP Reviewer and KLCP Participant with associated artefacts... 69

Figure 24. KLCP Analyst with associated artefacts... 70

Figure 25. KLCP Change Body with associated artefacts... 71

Figure 26. KLCP Architect with associated artefacts... 71

Figure 27. KLCP Software Tool Specialist with associated artefacts... 72

Figure 28. KLCP Agent with associated artefacts... 73

Figure 29. KLCP Software Tool Administrator with associated artefacts... 74

Figure 30. KLCP Trainer with associated artefacts... 74

Figure 31. KLCP Change Disseminator with associated artefacts... 75

Figure 32. KLCP Change Manager with associated artefacts... 75

Figure 33. Activity diagram for the KLCP Assessment Workflow... 77

Figure 34. Collaboration diagram for the evaluation phase of KLCP Assessment... 78

Figure 35. Collaboration diagram for the formulation phase of KLCP Assessment... 79

Figure 36. Activity diagram for the KLCP Change Iteration Workflow... 80

Figure 37. Collaboration diagram for KLC Design... 81

Figure 38. Collaboration diagram for KLC Implementation... 82

Figure 39. Collaboration diagram for KLC Change Management... 83

Figure 40. General sequence of activities in an ICONS based project... 84

Figure 41. Software Life Cycle Process diagram... 85

Figure 42. Associations between main SLC Process artefacts... 86

Figure 43. Hierarchy of Implementable components... 87

Figure 44. Domain Expert with associated artefacts... 88

Figure 45. Profile Designer with associated artefacts... 88

Figure 46. Workflow Designer with associated artefacts... 89

Figure 47. Knowledge Requirements Designer with associated artefacts... 89

Figure 48. Functionality Designer with associated artefacts... 90

Figure 49. User Interface Designer with associated artefacts... 91

Figure 50. Knowledge Structure Designer with associated artefacts... 92

Figure 51. Content Structure Designer with associated artefacts... 93

Figure 52. Architect with associated artefacts... 94

Figure 53. Component Designer with associated artefacts... 95

Figure 54. Workflow Implementer with associated artefacts... 95

Figure 55. Profile Implementer with associated artefacts... 96

Figure 56. Knowledge Application Implementer with associated artefacts... 97

(9)

List of figures April 2004

Figure 58. Component Arranger with associated artefacts... 99

Figure 59. Component Implementer with associated artefacts... 100

Figure 60. System Integrator with associated artefacts... 101

Figure 61. Test Designer with associated artefacts... 101

Figure 62. Tester with associated artefacts... 102

Figure 63. Technical Writer with associated artefacts... 102

Figure 64. Project Manager with associated artefacts... 103

Figure 65. Activity diagram for the Inception Iteration... 104

Figure 66. Collaboration diagram for Functionality and knowledge design during Inception... 105

Figure 67. Collaboration diagram for Knowledge system design during Inception... 106

Figure 68. Collaboration diagram for Project management during Inception... 106

Figure 69. Activity diagram for the Construction Iteration... 108

Figure 70. Collaboration diagram for Functionality and knowledge design during Construction... 109

Figure 71. Collaboration diagram for Knowledge system design during Construction... 110

Figure 72. Collaboration diagram for Knowledge system implementation during Construction – knowledge structure components... 111

Figure 73. Collaboration diagram for Knowledge system implementation during Construction – profile, workflow and generic components... 111

Figure 74. Collaboration diagram for Knowledge system implementation during Construction - integration.... 112

Figure 75. Collaboration diagram for Quality assurance during Construction... 112

Figure 76. Collaboration diagram for Project management during Construction... 113

Figure 77. Sub-artefacts for the Concept Glossary component... 114

Figure 78. Sub-artefacts for the Intelligent Workflow component... 123

Figure 79. Sub-artefacts for the Personalization component... 130

Figure 80. Sub-artefacts of the Content Repository component... 135

Figure 81. Sub-artefacts for the Content Categorisation component... 147

Figure 82. Sub-artefacts for the Datalog Inference component... 158

Figure 83. Sub-artefacts for the Uncertainty Reasoning component... 161

Figure 84. Sub-artefacts for the External Content Integration... 164

Figure 85. Sub-artefacts of the Electronic Form Manager component... 167

Figure 86. Sub-artefacts for the IADE component... 170

Figure 87. Description of the Ontology Tables... 171

(10)

List of tables April 2004

List of tables

Table 1. Specification of main stages of KM implementation... 19

Table 2. Steps of the KM road map... 21

Table 3. Skeletal methodology for building ontologies... 25

Table 4. Phases of general KM implementation... 28

Table 5. Activities within the MOKA methodology... 32

Table 6. Elements of other methodologies that influenced the ICONS Methodology... 33

Table 7. Products identified by RUP... 37

Table 8. Products identified by ISO12207... 39

Table 9. XP techniques... 41

Table 10. Differences between Crystal Orange methodology and Crystal Clear methodology... 42

Table 11. Crystal Clear methodology project partition... 43

Table 12. Products identified by Crystal Clear methodology... 45

Table 13. Notations/formats proposed for Crystal Clear products... 45

Table 14. Products identified by ASD... 47

Table 15. Main activities within KLC Process... 62

Table 16. Summary of sub-artefacts for the Implementable Components... 88

Table 17. Cases for modification of the Content Repository UML Model... 136

Table 18. Class properties to be manually completed... 139

Table 19. Attribute properties to be manually completed... 140

Table 20. Guidelines for choosing the Knowledge Map materialization mode... 149

Table 21. Value domains for the example Path concept template... 152

Table 22. Example Path concepts... 152

Table 23. Possible ways of defining and implementing predicates... 153

(11)

Introduction April 2004

1. Introduction

1.1 Objectives

The main objective of this document is to define the organization of the development life cycle of a software system based on the ICONS framework. The result of the work presented here is a methodology that allows for proper arrangement of the construction process. The methodology is meant as being “living”. It gathers all the good practices from consecutive projects based on the ICONS architectural framework. In this second version of the methodology, experience taken from the Structural Funds Portal project is included. The basic assumption here is that we use a ready set of configurable components that form a framework. The ICONS framework is described in detail in [ICONS D09]. We thus do not describe the methods for building the individual elements of the architecture. We assume that they are supplied ready to be configured (to various extent) and linked into a coherent system. We also assume that all the components that are supplied (and those that are built from scratch) are made in a single technology based on Java (J2EE), and thus have a precisely defined communication protocol (XML-based custom interfaces).

Major effort during the construction of such a system is focused on defining functional requirements, creating an appropriate user interface, choosing adequate components from the framework and finally their skilful configuration. It has to be stressed that “configuration” of components is not a trivial task and requires knowledge of appropriate techniques, notations and knowledge of programming languages.

Additional objective of this paper is to describe the overall process associated with the flow of knowledge and the process of its transformation (meta-process). It is an important amendment to the software life cycle methodology. It allows the organisation that implements a knowledge management software system also to transform its processes to accommodate for the new system.

An important aspect of any methodology for the development of software systems is the notation and method of description. The methodology should be comprehensible by all, even inexperienced members of the process. The graphical notations are most communicative and thus we propose a notation based on UML (Unified Modelling Language). This graphical notation was used with success for business and system modelling purposes, and is understood by a growing (and already vast) number of system developers. The notation used for the purpose of this document is presented in one of the following chapters.

1.2 Scope

The scope of this paper can be divided into seven parts:

• Presentation of the general context for life cycle and management methodologies in the field of

Knowledge Management and software development.

• Presentation of the current state of the art in the area of Knowledge Life Cycle and Knowledge

Management methodologies.

• Presentation of the current state of the art in the area of Software Life Cycle methodologies.

• Detailed description of the proposed Knowledge Life Cycle methodology.

• Detailed description of the proposed Knowledge Management methodology.

• Detailed description of the proposed Software Life Cycle methodology for the ICONS frameworks.

• Description of all the good practices for appropriate components of the ICONS architecture based on a

real project experience.

1.3 Relations to Other Documents

This document is related to chapter 9.1 of [ICONS D03] (Project presentation) and to [ICONS D16] (Architecture). Some of the methodologies presented can be found in [ICONS D04] (Standards base for the ICONS project). The document also relates to [ICONS D35] (SFP KP conceptual analysis). The final version of this document, and especially the appendices, is based on [ICONS D21] (ICONS Software Technical Design Manual) and [ICONS D13] (ICONS Graphic Interface - Design Specification).

(12)

Introduction April 2004 systems based on the ICONS framework, to help in organizing their software development and knowledge lifecycle processes.

1.5 Usage Guidelines

This document should be used as a handbook for process configuration. The processes described here should be used as the starting point to the definition of processes specific to the given organisation that uses the ICONS framework. The KLCP and KMP methodologies are general in nature and can be used by organisations not necessarily building an ICONS-based system.

1.6 Notation Conventions

UML-based notation was used for the description of the life cycle processes. The notation is described in detail in the appropriate chapter (Chapter 6).

(13)

Processes for SFP KP April 2004

2. Processes for SFP KP

2.1 Processes and methodology

The Structural Fund Project Knowledge Portal (SFP KP) is planned to be a very important resource of knowledge for organizations associated with the access to the European Union (see chapter 9.1 of [ICONS D1]). As such it could play a key role in structuring processes in these organizations. We can discuss these processes on two levels. The first level contains all the business processes that involve manipulation of knowledge contained in the Portal. The second level encompasses the construction of SFP KP. Both levels contain very complex network of activities, techniques, tasks that produce specific products and are performed by specific workers. In order to define these networks we need appropriate methodologies. We have to note that we actually need at least two distinct methodologies. The first one is a Knowledge Life Cycle Methodology, and the second one is a Software Life Cycle Methodology. The Knowledge Life Cycle Methodology would be responsible for defining all the business processes associated with producing, integrating and applying knowledge. The Software Life Cycle Methodology would cover the production of a software system that would allow for the Knowledge Life Cycle Process to occur, i.e. would include the development process.

2.2 Business processes

Every organization, while processing knowledge, acts according to specific business processes. These processes could be codified in a methodology, or just performed in an unordered fashion. We can define the business process as a group of logically related activities that use the resources of the organization to provide defined results in support of the organization's objectives. This means also that an organization might perform business engineering, which can be defined as applying a set of techniques to design the business according to specific goals. Business engineering techniques can be used for business re-engineering, business improvement, and business creation. Engineering a business means that we take a comprehensive view of the entire existing business and think through why we do what we do. We question all existing business processes and try to find completely new ways of reconstructing them to achieve improvements.

SFP KP can be treated as a means for business process engineering. Its main objective is to supply the accessing organizations with a set of best practices (process descriptions) to engineer appropriately their businesses. SFP KP is thus an important element of the Knowledge Life Cycle (see [Firestone 2001]), which incorporates Knowledge Production and Knowledge Integration. The life cycle starts with activities of Knowledge Production, which result in the existence of Organizational Knowledge. This Organizational Knowledge is then used to produce an Organizational Knowledge Base during Knowledge Integration activities. For SFP KP, the life cycle is modified in that the two core processes of the Knowledge Life Cycle are distributed between the European Commission and the various accessing states’ organizations. This leads to greater complexity of the process than in the case of a single, but integrated organization (enterprise).

The Knowledge Life Cycle exists in all the organizations, regardless of their KM awareness. Those organizations that want to improve their knowledge management capabilities usually introduce a formal Knowledge Management Process. One of the main tasks of this process is to define a Knowledge Life Cycle Process. The need for a systematic methodology is quite obvious here. It can be argued that this methodology should be a part of the studies on the SFP KP development methodologies.

2.3 Development processes

One of the most important steps in improving an organization’s Knowledge Life Cycle is the development of a Knowledge Management Software System. In many cases this development means adaptation of an existing system to the organization’s needs in the area of knowledge management. Many organizations, however, build a completely new system. In case of the ICONS project and the SFP KP work package, we are not only building a new system, but also using a novel technology. This means that a special caution should be taken during preparation and execution of the development process.

(14)

Processes for SFP KP April 2004 was proposed by the Software Engineering Institute (SEI) and is called the Capability Maturity Model for Software (CMM-SW) [SEI 1995]. This model has five levels of maturity starting with “Initial”, going through “Repeatable”, “Defined” and “Managed”, and ending with “Optimising”. These five levels of maturity constitute a measure of quality of the software development processes in the given organization. It can be argued that an organization responsible for building SFP KP should be at least on the “Repeatable” level of CMM-SW. Somewhat more sophisticated is the maturity assessment methodology proposed in an ISO standard 15504 [ISO 1998]. The maturity of an organization is measured also on several levels. However, this maturity is specified separately for various disciplines of the software engineering process. This method shows a whole spectrum of given organizations’ capabilities.

Similarly to the Knowledge Management processes, also the KM software development processes exist in organizations producing KM software, however it can be poorly structured. Improving these processes means that an organization moves to a higher level of capability maturity. Unfortunately, this improvement is not an easy one-step transformation. This leads to the necessity of defining a “development process improvement” process (meta-process). For SFP KP specifically, this meta-process should include changes in handling complex architecture of the system, and changes that would cope with the diversity of the domain experts (users, sponsors, etc.).

(15)

Areas for applying the methodology April 2004

3. Areas for applying the methodology

3.1 Methodologies in the area of Knowledge Management

As it was said in the previous section, we can distinguish two groups of processes in the area of Knowledge Management. One of the groups is associated with managing knowledge itself, and the other one - with managing relevant KM software. In both groups we have a “life cycle” process and a “management” process. The life cycle processes encompass all the actions associated with doing everyday business. The management processes can be seen as those that attempt to transform the life cycle processes, and as such can be treated as meta-processes. We thus result in four separate processes as shown on Figure 1.

Figure 1. Relations between four groups of processes in the Knowledge Management domain.

Every process is composed of steps (phases) performed one after another and/or in parallel. An important element of the Knowledge Management Process (KMP) is the resulting Knowledge Life Cycle Process (KLCP). Another important (but not required) element of KMP is the Software Management Process (SMP). This is due to the fact that the process of changing the knowledge handling practices usually causes the need of changing the software development practices (in the area of KM software development). During the KMP it is almost obligatory to include some (or all) phases of the Software Life Cycle Process (SLCP). Changing the knowledge process most often means developing or sometimes only adapting a new or existing software system. Finally, the SLCP is part of the SMP. This is obvious, as the latter is the result of the first. Figure 1 shows the above described relations between the four Processes. On the diagram, KMP includes SMP and KLCP in whole and possibly only some parts of SLCP (hence the arrow pointing to just one the phases of SLCP).

In the following section we will explain the relations between four processes and associated methodologies in more detail.

3.2 Knowledge Life Cycle Process

The Knowledge Life Cycle Process is one of regular business processes of an organization. It has a significant impact on the rest of the organizational processes through a feedback loop based on knowledge production and knowledge integration (see [Firestone 2000]). Knowledge production is associated with solving various

Knowledge Management Process Software Management Process Knowledge Life Cycle

(16)

Figure 2. Knowledge life cycle process loop.

Knowledge production involves the creation of new knowledge, such as new ideas, insights and innovation caused by interaction between people or groups, and the acquisition of knowledge from outside sources. During the process of knowledge production people organize themselves to collaborate on an ad hoc, or more formal, basis. This collaboration is often supported by the technology, i.e. the information systems that people use to gather and share data. Knowledge validation is the next step, during which potential new knowledge is subjected to peer review and processes that test its value in practice. For some organizations, knowledge validation is a highly formalized process; for others, it is not. Knowledge that passes the test is then integrated, or implemented, within the organization. The new knowledge often displaces long-held knowledge - the discontinuation of how work is being done today in favour of new business processes, for example - and thus the cycle begins anew. This integration may be performed in personal non-electronic or electronic form. Knowledge integrated into organization forms an organizational knowledge base, which again may be formulated electronically or non-electronically. An example of such knowledge base is SFP KP. In our particular project, the KLCP can thus be treated as a process of using the Portal in everyday business of the accessing states’ organizations. This would influence the decision cycles in these organizations that include phases of planning, acting, monitoring, and evaluating, involving the above mentioned knowledge production and/or integration.

The Knowledge Life Cycle Methodology should define the KLCP by using appropriate notation. We can define business processes using business use cases, which show the expected behaviour of the business, and business use-case realizations, which show how that behaviour is realized by business workers and business entities.

3.3 Knowledge Management Process

The Knowledge Management Process is the process that manages the knowledge life cycle. Managing in this case means making decisions on the structure and resulting artefacts of the current Knowledge Life Cycle Process. These decisions often involve making significant changes in the methodology, according to which the knowledge cycles occur. The changes include changing knowledge process rules and implementing them, responding to current intelligence requests (crisis handling), building KM infrastructure, training, preparing agreements on the new KLCP execution, etc. In brief, the nature of knowledge management is that it is a complex process composed of the above task clusters broken down into task patterns, executed by agents through decision cycles composed of planning, acting, monitoring, and evaluating activities.

A methodology for the Knowledge Management Process should possess several features. Most of all it should allow for definition of the sequential process of developing and maintaining the changes in the Knowledge Life Cycle. It should clearly describe the workflows associated with capturing the requirements for knowledge handling. There should also be a description of the analysis and design activities associated with the new way the business shall handle its knowledge. The methodology needs also to define all the tasks in the field of implementing the designed solutions.

Knowledge Production - Individual and group interaction - Data / Info acquisition - Formulating new knowledge claims - Initial codification Knowledge Validation - Knowledge claim peer review - Defining validation criteria - Weighting of value in practice - Formal codification Knowledge Integration - Knowledge sharing and transfer - Teaching and training - Making new knowledge operational - Production of knowledge artefacts Knowledge Claims Validated Knowledge Organizational Knowledge Base

(17)

3.4 Software Life Cycle Process for Knowledge Management

A software life cycle process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (for instance, project plans, design documents, code, test cases, and user manuals). As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization (see: [Thayer 1997], p. 49, [Dorfman 2002]).

3.5 Software Management Process for Knowledge Management

Software process capability describes the range of expected results that can be achieved by following a software life cycle process. An organization’s software process capability is one way of predicting the most likely outcome to expect from the next software project the organization undertakes. Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. Maturity implies a potential for growth in capability and indicates both the richness of an organization’s software life cycle process and the consistency with which it is applied in projects throughout the organization. Here we will define the KM Software Management Process as a process of improving the organization’s software process maturity (in the area of KM solutions development). Organizational KSMP processes include management, infrastructure, improvement, and training. (See: [Thayer 2002]).

(18)

Analysis of existing KM and KLC methodologies April 2004

4. Analysis of existing KM and KLC methodologies

This chapter contains a review of selected methodologies supporting implementation of Knowledge Management practices and processes in an enterprise. Some of the approaches cover the whole process of KM development, while others only partially support it. The main goal of this chapter is to supply us with the knowledge of particular solutions, which may be adapted to the ICONS methodology. Second and not less important purpose is to identify all the areas within KM and KLC, which are not supported by other methodologies, to cover them in the designed methodology.

Description of each of the approaches is composed of the following sections:

• General information – information about solution’s origins, authors, date of creation etc.

• Scope – brief description of the problems addressed in the particular solution.

• Overview – more detailed description of the solution. It contains overall information about approach

and emphasis as well as thorough description of such elements defined or recommended by the approach as roles, artefacts, workflows, methods, techniques and tools. Also a schema of the approaches’ specification may be presented.

The last part contains some conclusions concerning relations between reviewed methodologies and the ICONS methodology.

4.1 APQC’s Road Map to Knowledge Management Results

4.1.1 General information

“Road Map to Knowledge Management Results: Stages of Implementation” is a framework, which presents

reference process of KM strategy implementation developed by the American Productivity & Quality Center (APQC). It is the result of APQC’s study of and collaboration with over three hundred of best practice organizations over a period of several years. It is a commercial product licensed by the APQC.

4.1.2 Scope

The framework spells out the essential steps to achieve knowledge management implementation. A set of steps constitutes a road through to develop KM strategies, design initiatives, and expand KM across the organization. The framework may serve as a navigation tool for organizations that have seen the glimmer of opportunity in KM to efficiently develop new products, beat the competition, motivate team members, and maximize profits and investments [APQC 2003]. It is primarily addressed for commercial enterprises, but may also be applied in non-profit organizations.

APQC’s solution focuses on definition of main stages of KM implementation. Within each stage key activities, their provoking events and objectives are identified. Solution refers primarily to organizational aspects of KM implementation and in basic version it does not contain detailed guidelines for the KM implementation teams or KM workers.

4.1.3 Overview

APQC’s proposition contains definitions of the main stages of KM implementation. Following stages, specified in the form of general prescriptions, are proposed:

• Get started.

• Develop a strategy.

• Design and launch a KM initiative.

• Expand and support.

• Institutionalise knowledge management.

Thorough description of stages is an essential part of the framework. Each stage is characterized by: • Provoking events that indicate the organization reached particular stage of KM implementation. • Objectives that define required state of KM implementation at the end of the stage.

• Key activities that should be performed on the particular stage of KM implementation to reach next stage.

The table below gathers the most important provoking events, objectives, key activities, and success factors for particular stages. Activities are also specified in the form of direct prescriptions.

(19)

Stage Objectives Provoking events Key activities

Get started Identification of individual path to knowledge management success.

•Knowledge management has emerged as a topic of interest in organization.

•At least a few employees have explored the benefits of KM for organization.

•Someone has had a personal stake in developing interest in KM. •The organization has created a

high-level rationale or vision for pursuing KM.

•Make the concepts of KM real for others in your organization. •Identify others to support the

development of KM. •Look for windows of

opportunity to introduce the benefits of KM.

•Capitalize on the Internet and enlist the IT department to provide tools and a balanced view of KM.

Develop

strategies Formulation of the KMstrategy that fits the business model.

•Organization has established a steering committee for KM. •Executive sponsor supports further

exploration of KM.

•IT in organization is interested in participation in KM activities.

•Formulate a KM task force. •Select pilots or identify current

activities that can work as pilots. Design and launch a KM initiative •Conduction of successful KM pilot. •Evidence of KM’s business value.

•Capture of lessons learned.

•Organization has designed pilot and implementation strategies. •Communities of practice, an

interactive KM Intranet site, or some other pilot initiative have been launched in the organization. •Pilot facilitators and leaders have

been enlisted and trained.

•Pilot measures and indicators have been established and system for tracking results has been developed. •Strategies for learning from KM

initiatives have been created. •Strategies for expanding pilot

initiatives across the organization have been mapped out.

•Fund the pilots.

•Develop methodologies that can be replicated.

•Capture lessons learned.

Expand and

support •Development and marketingof KM expansion strategy. •Effective management of the

KM growth.

•Other departments in the organization are expressing a demand for KM, based on pilot results.

•Entire organization is aware of KM.

•Resources necessary for expanding KM efforts have been identified.

•Develop an expansion strategy. •Communicate and market the

strategy. •Manage growth. Institutionalise knowledge management KM development and

maintenance. •KM is directly linked toorganization’s business model. •KM initiatives are widely deployed

throughout the organization. •Sharing knowledge is now the

norm in the organization.

•Embed KM in the business model.

•Realign the organization's structure and budget. •Monitor the health of KM. •Align performance evaluation

and rewards with KM strategy. •Balance an organizational KM

framework with local control.

Table 1. Specification of main stages of KM implementation.

(20)

4.2.2 Scope

[Tiwana 2000] focuses on definition and description of the 10-step KM road map that guides through the entire process of creating business-driven KM strategy, designing, developing and implementing a KM system and effecting the soft changes that are required to make them work. Each of the steps is described in details in terms of the activities, techniques, practices, tools and success factors.

4.2.3 Overview

10-Step KM road map proposed by the author may serve as general plan of KM implementation. Together with descriptions of supported processes, technological solutions, techniques and practices it can be viewed as the methodological approach to KM implementation. Here is a brief overview of this approach.

The steps of KM road map are grouped into four following phases:

• Infrastructural evaluation, which consists in analysing existing infrastructure and identifying steps that can be taken to leverage and build KM system. Also knowledge maps of the organization are created during the phase. These maps are used further to create high-level link between KM and business strategy.

• KM system analysis, design, and development, which aims at building and testing KM system. • System deployment, which consists in deploying the KM system that was built in the preceding phase. • Performance evaluation, which consists in measuring business value of KM.

Following table presents steps within each phase [Tiwana 2000].

Phase Step Objectives/activities

Analysing existing infrastructure _• Understanding the role of existing organization’s IT infrastructure (network, intranet, extranet, data warehousing, DSS, data mining systems) in KM. • Understanding the KM technology framework and

its components.

• Planning the integration of existing intranets, extranets and GroupWare systems into KM system.

• Understanding the limitations and gaps of existing technology infrastructure.

• Taking steps to leverage and build upon existing infrastructural investments.

Infrastructural evaluation

Aligning KM and business strategy _• Performing a knowledge-based SWOT analysis and creating knowledge maps for the organization and competitors.

• Analysing knowledge gaps and identifying how KM may fill these gaps; prioritising identified gaps.

• Determining the right diagnostic questions to ask designing KM system.

• Articulating and validating a direct link between KM strategy and KM system design.

• “Selling” KM project internally. KM system analysis,

design, and development

Designing the KM architecture and

integrating existing infrastructure • Comprehending various components of theknowledge infrastructure. • Identifying internal and external knowledge

sources that must be integrated.

• Choosing IT components to find, create, assemble and apply knowledge.

• Identifying interfaces within the designed system. • Deciding on the collaborative platform (Web,

Notes, other).

• Identifying the right mix of components for searching, indexing, retrieval, reasoning etc. • Creating knowledge tags and attributes (metadata). • Validating the choices.

(21)

Auditing and analysing existing

knowledge assets and systems • Measuring process knowledge (identification andrating of process knowledge on an 8-point scale). • Selecting an audit method.

• Assembling a knowledge audit team.

• Auditing and analysing existing organizational knowledge.

Designing the KM team _• Identifying key stakeholders (IT, management, end users).

• Identifying critical points of failure.

• Determining of team’s organizational construction and size.

Creating the KM blueprint _• Customizing the 7-layered KM architecture to particular organization.

• Understanding and selecting knowledge-processing components required by particular organization.

• Understanding and executing repository lifecycle management.

• Making the build-or-buy decision.

Developing the KM system _• Develop all the requisite layers (interface, access and authentication, collaborative filtering and intelligence, application, transport, middleware and integrating, repository layers)

Deploying, using results-driven

incremental methodology •_• Understanding the need for a pilot KM.Choosing the pilot application. • Identifying and isolating failure points in pilot

project.

• Understanding the scope of KM system deployment.

• Using the RDI (Results-Driven Incremental) methodology to deploy the system.

• Create releases. System deployment

Change management, culture, reward structure design, and the choice of CKO

• Understanding the role of CKO (Chief Knowledge Officer) in the organization.

• Determining the responsibilities of the CKO. • Choosing the CKO.

• Managing and implementing cultural and process changes to make KM system as well as KM strategy succeeds.

Performance evaluation Measuring results of KM, devising ROI metrics, and evaluating system performance

• Choosing right metrics to measure KM system performance.

• Calculating ROI for KM investments. • Selecting software tools for constant tracking

complex metrics etc.

Table 2. Steps of the KM road map.

Presented road map should guide to deployment of the system that supports the knowledge process. Knowledge process is defined as consisting of the following steps:

• Knowledge acquisition, which is the process of creation of knowledge items.

• Knowledge sharing, which is the process of disseminating and making available what is already known.

• Knowledge utilization, which is defined as integration of learning techniques and procedures into the organization.

(22)

• Determining the role of CKO in the organization.

• Choose the most suitable person for CKO role.

It also recommends some reference solutions (technological e.g. for KM architecture) and useful methods (e.g. for knowledge audit, for KM system deployment, for measure the KM benefits). Most of methods and techniques are not created by the author itself but adopted from other solutions.

Additionally the workbook contains a number of descriptions of software tools that may be utilized during KM assembling.

4.3 CommonKADS Methodology

4.3.1 General information

The CommonKADS (Knowledge Acquisition Data System) methodology for the KBS development is a result of the KADS-II project (“An Advanced and Comprehensive Methodology for Integrated KBS Development”), which was a part of ESPRIT 2 (European Strategic Programme for Research and Development in Information Technology) project. It has been developed over a period of 1990 – 1994, however some ideas were derived directly from the former KADS project (“A Methodology for the Development of Knowledge-Based Systems”; 1985 - 1990). At the moment it is one of the most widely used methodology for KBS development in both research and commercial applications. It now is the European de facto standard for knowledge analysis and knowledge-intensive system development [CommonKADS 2003].

4.3.2 Scope

CommonKADS methodology covers the lifecycle of KBS projects, provides standards both for project control and system development, and bridges the gap between KBS development methods and other methodologies [CommonKADS 2003]. It consists of two elements [Schreiber 2000a]:

• A framework for the implementation-independent specification of knowledge combined with a set of

reusable knowledge models for frequently occurring tasks (such as assessment and diagnosis).

• A lifecycle model indicating phases, activities, and products relevant for a KBS project.

CommonKADS is concerned with the development of knowledge-intensive systems; methodology itself helps to recognize knowledge-rich domains.

4.3.3 Overview

CommonKADS methodology supports whole process of knowledge-based system development, so it concerns both software development of such system and knowledge engineering. Here is a description of main concepts within the methodology.

CommonKADS defines the development of KBS as the continuous improvement of a set of models of different aspects of the system and its environment. CommonKADS defines four models to modelling organizational environment of KBS (organization, task, agent and communication models; they may be called conceptual models), which de facto illustrate a project-specific social context in which a KBS will operate. These models are:

• Organization model, which supports analysis of major features of organization to discover possible

problems and opportunities for KBS development and possible effects connected with KBS implementation; main components of this model: function, structure, computing resources, current problems, solution.

• Task model, which describes hierarchy of tasks that are or will be performed in the organization where

the KBS system will be installed; tasks are described by such elements as inputs, outputs, features, requirements, distribution over agents.

• Agent model, which describes capabilities of the agents; an agent is defined as the executor of the task

(human, computer software etc.).

• Communication model, which describes communication between several agents involved into single

task.

Other important and non-environmental models distinguished by the methodology are:

• Set of knowledge models (called also expertise models), which describe the knowledge used by the

system. Knowledge model operates on two types of knowledge: domain knowledge and control knowledge. Domain knowledge describes the structure and content of the domain, and is represented in the system through ontologies. Control knowledge may be divided into inference knowledge and task knowledge. Inference knowledge is modelled in terms of operations on domain knowledge (inferences)

(23)

Analysis of existing KM and KLC methodologies April 2004 and in the terms of roles (role is a label of a domain knowledge class which participates in particular inference operation). Task knowledge is modelled as a hierarchy of tasks.

• Design model, which describes the architecture and the detailed functions of the system to be

implemented.

During the KBS implementation process all these models have to be specified and implemented. Methodology includes not only descriptions of models, but also recipes of how to build them [Schreiber 1994].

In CommonKADS project management and development activities are separated [Schreiber 1994]. Project management is represented by a project management activity model that interacts with the development work through model states attached to the CommonKADS models. The development process is adopted from Boehm’s spiral model (cyclic, risk-driven). Methodology distinguishes two types of cycles: management and development. Each of the management cycles is based on the following schema:

• Specification of objectives (new for current cycle).

• Risk identification.

• Definition of required target model states.

• Planning of the development activities

Development cycle is composed of following sequence of overall steps:

• Exploration of the additional states that the target states (defined during appropriate management cycle)

depends on.

• Check of the quality of results.

• Review of the results achieved in the light of the overall objectives and risks.

Steps within the cycle may be repeated many times. Each step may be composed of a set of tasks. Two types of tasks are distinguished: analytic (e.g. classification, assessment, diagnosis, monitoring, prediction) and synthetic (e.g. configuration design, modelling, planning, scheduling, assignment). Templates for tasks are included. A template is similar to a design pattern used in software developments and provides characterization of the task and alternative methods of its realization.

Methodology uses UML diagrams to specify its models and processes. Following types of diagrams are used:

• Activity diagrams, which are used for specifying the organization model at a high level of abstraction,

and for modelling the structure of tasks.

• State diagrams, which are used in communication model to specify the communication plan control.

• Class diagrams, which are used to describe the static information structure of the application domain.

• Use-cases diagram, which are used for specifying the agent model.

Methodology also defines its own language called Conceptual Modelling Language (CML), which is a semi-formal notation for the specification of expertise models.

The book [Schreiber 2000b] is the main position that explains the methodology. It contains not only theoretical descriptions of main concepts, but also a number of case studies, which illustrate the use of methods recommended by and defined in the methodology, and practical procedural guidelines for knowledge modelling process (methods, techniques).

4.4 Knowledge Management Process Methodology by J. Firestone

4.4.1 General information

In 2001 Joseph M. Firestone, Ph.D., who is Vice-President and Chief Knowledge Officer (CKO) of Executive Information Systems (EIS), defined concept of The New Knowledge Management (TNKM). It focuses on enhancing all of knowledge processing, not just knowledge sharing, and uses concepts, tools, techniques, and methodology that promise to revolutionize KM practice [DKMS 2003]. Mentioned methodology is called KM Framework Methodology and supports both KM implementation and maintenance.

(24)

Analysis of existing KM and KLC methodologies April 2004 much shorter and less complex value networks (links between methodological tasks and intended results are much more direct) [Firestone 2001].

4.4.3 Overview

The methodology proposed by J. Firestone is defined as KM Framework Methodology (KMFM) and is seen as alternative to the broader KM Life Cycle Methodology, which is determined as a type of KMP Methodology, which is linear (adaptation of waterfall model; one task following another, no feedback loops, concurrent engineering, iterations or increments; its main phases are: strategic planning, analysing, designing, implementing, testing, monitoring, evaluating, and maintaining). KMFM begins with a conceptual framework (KM Framework) for developing a KM solution and iterates on this framework until a physical realization of it is implemented. KM Framework is a set of task patterns, tasks, knowledge-related business structures, and patterns of iterative/incremental solution development. Task pattern is defined as a set of linked activities initiated by an agent and performed by a system solution, producing a result of value for a particular agent.

KM Framework Lifecycle is divided itself into development cycles and maintenance cycles. Each of the development cycles is divided into four phases: inception, elaboration, construction and transition (the same as in RUP). Each of the maintenance cycles has only single maintenance and enhancement phase. Each phase is divided into iterations, which produce increments. These phases are:

• Inception phase, during which the basic idea of the solutions’ development project is developed, sufficiently to produce a business case that justifies moving into the elaboration phase.

• Elaboration phase, during which the architecture of the solution is defined, tasks and task patterns are detailed.

• Construction phase, during which the solution is implemented.

• Transition phase, during which the solution is tested, evaluated, and deployed.

Phases of the life cycle may be viewed through the perspective of workflows (which are similar to disciplines within RUP), which are: strategic planning, analysing, designing, implementing, testing, maintaining. Documentation of the methodology contains detailed overview of the workflows.

Development process in KMFM is not linear but is driven by the logic of implementing selected prioritised task patterns through iterations.

KMFM borrows from the RUP, but is different in a number of ways:

• Functional requirements in KMFM are not specified through use cases, but task patterns.

• KMFM focuses on modelling and implementation of enterprise systems and KM solutions (which are

often social), while RUP focuses on modelling and implementation of software application systems; also main concerns of KMFM are very different from RUP.

• KMFM is a superset of RUP in the sense that software development methodology is only a part of the

larger set of KMFM activities.

KMFM indicates some methods and tools, which may be useful during its application.

Amongst methods, most important are: communities of practice, story-telling, Group Decision Process Methods (such as Delphi Technique, Nominal Group Technique, Group Value Measurement Technique, Knowledge Café, Team Analytic Hierarchy Process, Joint Requirements Modelling, and Joint Application Design), cultural analysis, value network analysis, object modelling, causal modelling, neural network modelling, fuzzy systems modelling, Bayesian Belief Networks, influence network analysis, semantic network analysis, genetic algorithms and programming, process modelling, measurement modelling, systems modelling, system dynamics, balanced scorecard modelling, intangible asset analysis, and enterprise performance measurement.

Most useful tools are: Enterprise Information Portals, Enterprise Knowledge Portals, Intelligent Software Agents, XML and enhanced XML formats such as XML topic maps (XTM), and Scalable Vector Graphics (SVG), Stateless Application Servers Application servers and Business process Engines, full text indexing, content management, ROLAP and MOLAP Servers, Business Intelligence tools, Data Warehouses, Data Marts, Operational Data Stores, Knowledge Discovery in Databases/Data Mining tools, Data Staging areas, ETL Servers, Collaboration tools, Group Decision Process Tools, Analytical Modelling and Simulation tools, Computer-assisted learning, Semantic Network Analysis tools, querying and reporting, searching/retrieving, Packaged Analytical Applications, Balanced Scorecard applications, Object Modelling and related tools, Expert Assessment Capture (EAC), Content Publication and Broadcasting, and Personal Knowledge Management [Firestone 2001].

(25)

Analysis of existing KM and KLC methodologies April 2004 • Knowledge Management Process (KMP) - an ongoing, persistent, purposeful network of interactions among human-based agents through which the participating agents aim at managing other agents, components, and activities participating in the basic knowledge processes (knowledge production and knowledge integration), in order to produce a planned, directed, unified whole, producing, maintaining, enhancing, acquiring, and transmitting the enterprise's knowledge base. KMP is a business process, which may be broke down into three high-level task clusters: interpersonal behaviour (“ceremonial” KM activities, leadership, building external relationships), knowledge processing behaviour (knowledge production, knowledge integration), decision-making behaviour (changing knowledge process rules, crisis handling, allocating resources, negotiating agreements).

• Knowledge Management (KM) - a human activity that is part of KMP of an agent or collective. • KMP Methodology - a specification of normative process directed at achieving a goal within KM

domain. It is composed of activities, tasks, procedures, tools, and methods. It need not be linear, but can be structured as a collection of elements for guiding problem solving with respect to various KM-related issues.

4.5 Methodology for building ontologies by M. Uschold and M. King

4.5.1 General information

Purpose of the methodology for building ontologies is to structure tasks and activities, which are usually taken during ontology creation. This methodology was proposed by the researchers from Artificial Intelligence Applications Institute, University of Edinburgh, in 1995, and then adopted by a number of scientists who made an effort to build their own methodologies.

4.5.2 Scope

Methodology for building ontologies is a proposition of the general methodology, which supports such processes as ontology definition, design, representation, and building. So this solution covers only few aspects of KM implementation, those that are associated with knowledge sharing.

4.5.3 Overview

Methodology specification consists of two parts:

• Skeletal methodology, which specifies main stages of ontology creation at high level.

• Case study, which illustrates how skeletal methodology should be detailed and applied.

Skeletal methodology for building ontologies describes stages that are required in any comprehensive methodology. It is created on the basis of author’s experiences in the development of a significant ontology [Uschold 1995]. Following table presents main stages of the skeletal methodology:

Stage Objectives and activities

Identify purpose Identification of intended uses, range of intended users etc. Ontology capture _• Choosing an ontology capture method.

• Identification of the key concepts and relations within particular domain. • Production of text definitions for such concepts and relationships. • Identification of terms that refer to such concepts and relationships. • Ontology assessment.

Ontology coding _• Identification of criteria for representation language • Choosing a language for ontology representation

• Explicit representation of the conceptualisation captured during ontology capture Building the

ontology

Integrating existing ontologies

(26)

Analysis of existing KM and KLC methodologies April 2004 Case study completes the presentation of the methodology for building ontologies. It may be seen as guideline for ontology engineers, which shows how to set up the target ontology.

Specification of the methodology does not raise the problem of the ontology lifecycle, and ontology maintenance process. It also does not include any prescriptions of particular techniques, methods and tools useful for ontology creation.

4.6 On-To-Knowledge Methodology

4.6.1 Basic information

On-To-Knowledge Methodology (OTK Methodology) is one of the main deliverables of the IST-1999-10132 On-To-Knowledge project [Sure 2002], which aims at developing methods and tools for Knowledge Management, and at providing infrastructure for the Semantic Web. Process-oriented OTK Methodology supports introducing and maintaining ontology-based KM solutions into enterprises. It integrates well-known techniques and best practices from the field of knowledge engineering.

4.6.2 Scope

OTK project defines the KM implementation process as the set of activities from the field of software engineering, human resource management and knowledge resource management. OTK methodology supports only knowledge resource management. It covers aspects from the early stages of setting up a knowledge management project to the final roll out of the ontology-based KMS. It focuses on supporting application-driven development of ontologies during the introduction of ontology based knowledge management systems [Sure 2002].

4.6.3 Overview

The core elements of the OTK Methodology are processes, which guides to KM system implementation and effective usage (methodology is process-oriented). Following processes were defined:

• Knowledge Meta Process (KMP), which guides and supports the initial set up of ontology-based KM

application.

• Knowledge Process (KP), which illustrates the cyclic process of using ontology-based KM application.

Each process is described in the methodology specification. The focus is not on giving a detailed guidance on how to perform each step, but rather on depicting important elements of processes. A brief description of processes is placed below.

KMP is specified as a set of activities, which has to be performed in order to build the ontology and ontology-based KM application. These activities are grouped into phases. Following phases are defined:

• Feasibility study, which is thought as decision support for economical and technical project feasibility in order to select the most promising focus area, i.e. the domain for the ontology based system to be developed.

• Kickoff phase. The ontology requirements specification document (ORSD) is the main product of the phase. It describes what ontology will support and what are the areas of the ontology application. It also contains guidelines on designing target ontology for an ontology manager and analysis of the available knowledge sources (e.g. domain experts, reusable ontologies, business plans, dictionaries, index lists etc.). Baseline ontology is another important product of this phase.

• Refinement phase. During this phase a mature and application-oriented target ontology should be created according to the instructions contained in the ORSD. The phase is divided into two sub phases:

a. Knowledge elicitation process with domain experts based on the input of the kickoff phase,

b. Formalization process, which purpose is transferring the ontology into target ontology

expressed in chosen formal representation language (e.g. DAML+OIL).

• Evaluation phase, which aims at checking the usefulness of the developed ontology and the software environment. In a first step, correspondence between developed ontology and specification existed in the ORSD is checked by the ontology engineer. Next, the ontology is tested in existing application environment. If some defects of the target ontology are found (e.g. some of the areas of ontology are not used), back to the refinement phase is needed, to redesign it.

• Maintenance phase, which is a continuous process, during which all required changes of the target ontology are made. All the changes are made according to predefined rules, which define who are responsible for changes, how changes are performed and when the changes are taken [Sure 2002].