Knowledge Management in Software Development Environments Karina Villela1,2, Fábio Zlot1, Gleison Santos1, Claudio Bonfim2, Beatriz Salvador2, Káthia Oliveira3, Guilherme Travassos1, Ana Regina Rocha1 1
Federal University of Rio de Janeiro – COPPE Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brazil Phone: 0055-21-25628699 Fax: 0055-21-25628676 {kvillela, zlot, gleison, ght, darocha}@cos.ufrj.br 2
Federal University of Bahia Unit of Cardiology and Cardiovascular Surgery Rua Augusto Viana s/n – Canela CEP 40140-060 – Salvador, Brazil Phone: 0055-71-3390358 Fax: 0055-71-3390333
[email protected],
[email protected] 3
Catholic University of Brasilia SGAN 916 modulo B – Asa Norte CEP 70796-160 – Brasília, Brazil Phone-Fax: 0055-61-5405550
[email protected]
Abstract Knowledge has been thought to be the most important asset in a company having a significant impact on company competitiveness. Thus, the introduction of Knowledge Management in the software development practice is critical to companies engaged in software development. There are different kinds of relevant knowledge in this context, such as domain knowledge, organizational guidelines, best practices, software techniques and methods, prior experiences using these techniques, methods and the software process. These kinds of knowledge are accumulated by staff and can be useful in supporting software projects and organizational learning on software development. However, knowledge identification, organization, storage, usage and evolution are not trivial. In order to support Knowledge Management during the software development process, we propose a new family of software development environments: the Enterprise-Oriented Software Development Environments (EOSDE). They will provide an infrastructure to support software developers during the software development process by providing knowledge that has been acquired and improved by the company throughout time. The EOSDE approach is based on both Knowledge Management and Experience Factory concepts and is intended to support two types of Companies: Software Companies, in which software development is a business activity, and Non-Software Companies, in which software development is an activity that supports business activities. The identification of two types of companies that deal with software development led us to the definition of two different kinds of EOSDE with specific requirements and infrastructure. However, there are also some requirements and aspects of the infrastructure that are common to all EOSDE. This paper discusses common requirements and requirements that are specific for each kind of EOSDE, and then presents the architectures of the respective knowledge infrastructures. The components of these architectures are described and there are several components that are common to both architectures. Last, two tools which enable the representation and visualization of knowledge about a company, covering structure and behavior aspects, respectively, are presented. These tools also allow the representation and visualization of the distribution of knowledge and skills throughout the company. Both tools are generic, that is, independent from a specific company or domain. Other tools are also being developed to enable the provision of knowledge about software development and maintenance accumulated by a company in its previous projects. In order to build EOSDE we are using the infrastructure of TABA workstation, a meta-environment capable of generating, through instancing, software development environments adequate to the particularities of domains, development processes and specific projects.
Key-words Enterprise-Oriented Software Development Environment, Knowledge Management, Experience Factory, Software Development Environment, Ontology.
1/8
1. Introduction Knowledge has been thought to be the most important asset in a company having a significant impact on company competitiveness. Nevertheless, to make the competitive advantage provided by knowledge sustainable, knowledge must not remain at the individual level. Knowledge at the individual level is lost when individuals leave the company and it is often difficult to find it and access it. The organizational knowledge recorded in documents also represents a problem when it cannot be easily accessed, shared and updated. Besides, the more critical knowledge is to a company, the more important it is to renovate it. This would allow for a Learning Organization [6]. Knowledge Management can be defined as a systematic and active management of corporate knowledge resources, using appropriate technology and aiming at generating strategic benefits to the organization, which involves: i. Obtaining relevant knowledge from internal and/or external sources, ii. Making available and distributing obtained knowledge in a way which is appropriate to user needs, iii. Generating new knowledge, iv. Eliminating outdated knowledge. Hence, many organizations have been using Knowledge Management as a way of improving the flow of knowledge among their employees, getting knowledge into the organizational level and promoting the development of new knowledge. Software development is a knowledge-intensive activity. Several knowledge representations and transformations are required along the software development process, and different kinds of knowledge are important to software developers in this context, among which are: domain knowledge, organizational guidelines, best practices and previous experiences with techniques, methods and the software process. Generally, there are two types of software developing companies: Software Companies, in which the business activity consists of the development of software solutions for several clients, and Non-Software Companies, in which the software development activity aims at supporting business activities. The introduction of Knowledge Management in the practice of software development is critical to both types of companies, since, for the first type, software applications are in the critical path of almost all organizational activities, and for the second type, knowledge about software development accumulated throughout time is the basis for creativity and innovation in terms of software products and services. However, knowledge identification, organization, storage, usage and evolution are not trivial. In order to support Knowledge Management during the software development process, we propose a new family of Software Development Environments: the Enterprise-Oriented Software Development Environments (EOSDE). A Software Development Environment (SDE) is a computational system that provides support for the construction, management and maintenance of a software product, and comprises a repository that stores all information related to the software project throughout its life-cycle and a set of tools that supports technical and management activities. Domain-Oriented Software Development Environments (DOSDE) [8] arose as an extension of the traditional SDE which includes knowledge of a specific domain as the main factor for assistance during the software development process. However, we have realized that, besides the domain knowledge, other kinds of knowledge are also necessary and useful during a software project. This was the motivation for broadening the idea of DOSDE and defining EOSDE, which has the following goals: (a) to provide software developers with all relevant knowledge for software development accumulated by the company, and (b) to support organizational learning about software development. The objective is to enable the identification of previous mistakes and the reuse of pre-qualified solutions when performing identical or similar tasks, aiming at improving both productivity and quality as well as reducing software costs. The EOSDE approach is also based on the Experience Factory (EF) concept. Some related works are both Experience Management System [9] and Corporate Memory Management System [12]. The previous identification of two types of companies that deal with software development led us to the definition of two different kinds of EOSDE with specific requirements and infrastructure. However, there are some requirements and aspects of the infrastructure that are common to all EOSDE. The model for the construction of EOSDE is being defined and, at present, more attention is being given to its basic components, which are discussed in this paper. In section 2, the common requirements and the requirements that are specific for each kind of EOSDE are presented. Then, the aspects of each infrastructure are discussed in session 3. In session 4, two tools whose purpose is managing knowledge about a company are described. Finally, our conclusions and plans for future work are presented in session 5.
2. Requirements for EOSDE In order to achieve its goals, EOSDE must meet some common requirements: (i) provide the representation of the organizational structure and processes, and make it easy to find the experts whose knowledge and
2/8
experience may be useful in the solution of a certain problem; (ii) store specialized knowledge about software development and maintenance, and supply this knowledge to a project team when necessary; and (iii) support the continuous evolution of knowledge in the environment. If a project team has access to the organizational structure and to the staff assigned to it, it is easier to find the experts who can contribute to their project. The representation of organizational processes enables a better understanding of these processes and of the role of an expert in the company as well as provides the context for the use of a skill or knowledge. These are the reasons for including requirement (i). In order to address requirement (ii), EOSDE should include knowledge about software engineering activities that are always carried out regardless of specific clients or projects, which constitute the software process of the company. Moreover, EOSDE should contain knowledge about the experience on software development acquired by the company, which includes: standards and guidelines, updated news about the technologies used, best practices related to the software process, methods and languages, analysis of software engineering tools, deliverables with potential for reuse, lessons learned from previous projects and organizational performance measures. Knowledge and experience evolve with time and therefore it is important to support the evolution of knowledge in EOSDE (requirement (iii)). Software Companies usually have clients in several application domains. Having knowledge (even if only partially) about these domains can mean a strategic advantage in the competition for new projects. Thus, in addition to SDE requirements and the common requirements discussed above, EOSDE for Software Companies must: (i) provide the representation of organizational structure and processes of their clients and allow easier identification of useful experts for a certain purpose in clients' companies, and (ii) to store clients' domain knowledge and to supply the development team with this knowledge when necessary through a software project. EOSDE for a Non-Software Company can be seen as an extension of DOSDE, because only one specific domain is involved, the domain of the company’s own business. Hence, the common requirements for EOSDE were added to the requirements previously defined for DOSDE [8], which include: to store the knowledge about company business domain and to supply this knowledge to the development team when necessary through a software project.
3. Knowledge Infrastructures for EOSDE In order to meet the requirements, we propose an architecture for the knowledge infrastructure in each kind of EOSDE (Figure 1 e 2). Nevertheless, it is important to emphasize that just the parts of the architectures represented in gray are specific, the other components belong to the knowledge infrastructure which is common to all EOSDE. The use of ontologies in the EOSDE knowledge infrastructures is critical to make easier the communication between multiple users and the retrieval of knowledge stored in the environment. Considering communication, the defined ontologies have the purpose of reducing terminological and conceptual confusion in a company, making both shared understanding and communication between people with different points of view and needs easier. As to the retrieval of knowledge items, the purpose of the ontologies is to supply vocabularies whose terms are used as links between the contents of the multiple knowledge/data bases. Besides, when defining synonyms and acronyms for the concepts, the ontologies provide linguistic equivalents which may occur in text documents, and may be used to classify and access informal knowledge. SE Ontology
Task Ontology Domain Ontology
SE Theory
Task Description
Domain Theory Company Ontology Company Ontology
Company Description
Client Description
Company Knowledge/Data Bases
Client Knowledge/Data Bases
Information Ontology
Client’s Company Model
Organizational Memory
Knowledge Management Services Knowledge Acquisition
Knowledge Dissemination
User Feedback
Figure 1 – EOSDE knowledge infrastructure for Software Companies
3/8
Domain Ontology Domain Theory
SE Ontology
Task Ontology Task Description
SE Theory
Company Ontology Company Description Company Knowledge/Data Bases Information Ontology
Organizational Memory
Knowledge Management Services Knowledge Acquisition
Knowledge Dissemination
User Feedback
Figure 2 – EOSDE knowledge infrastructure for Non-Software Companies The components of knowledge infrastructures are described below: ⇒ SE Theory component The Software Engineering (SE) Theory component contains the SE Ontology component, which defines a common vocabulary to guide the registration/distribution of a company’s knowledge map and of software engineering knowledge by an EOSDE. A company’s knowledge map defines which are the skills and knowledge each employee has and to which degree these skills and knowledge are held. When the knowledge map is being recorded or updated, the knowledge about Software Engineering that a certain employee has is defined based on the terms of SE Ontology. The software engineering knowledge stored in the environment is also associated to SE Ontology terms. Each knowledge item is associated to one or more terms, which enables subsequent retrieval of different types of knowledge items based on SE Ontology terms, independently from the specific tool used to obtain or to record the knowledge items. SE Ontology will be formed by a set of sub-ontologies which will be developed or integrated. Among the ontologies to be integrated are: software process ontology defined by [4], which involves activity, procedure and resource at a generic level, and software process at a more specific level; and software maintenance ontology defined by [7], which involves maintained product, maintenance activity, maintenance procedure, maintenance organization procedure and peopleware. ⇒ Task Description component The Task Description component contains the description of generic tasks, that is, tasks applicable to different domains. Two examples of generic tasks are to reserve and make diagnosis, as a reservation may be for a book, a car or anything else, and diagnosis may be of a disease or an automotive fault, among others. A task description consists of a high-level description, a task ontology and bibliographic references. A task is a sequence of necessary steps for the solution of a problem, so a task is also described in terms of its sub-tasks. Task Ontology contains concepts and attributes associated with generic tasks. The objective of describing generic tasks is to obtain knowledge, regardless of domain, which helps software developers understand a problem through the understanding of the tasks that make it up. The understanding of the concepts of a domain can be made easier through the understanding of the tasks in which the concepts are used. Likewise, the understanding of the organizational processes of a company can be made easier through the understanding of the tasks that form it. A skill required or owned can be defined as a skill to perform a task. ⇒ Company Description component The Company Description component contains the description of a company, identifying the generic tasks that are performed and the software engineering knowledge necessary in the context of the organizational structure and processes. Hence organizational processes and the activities of these processes can be mapped for generic tasks and the description of a task can be used to help the company’s knowledge manager to define an organizational process. Software engineering concepts are mapped both for organizational process activities and for the positions of the organizational structure in which they are required, enabling a better understanding of organizational processes and structure and also of the role of knowledge in the company. If the company being described is a Non-Software Company, the concepts of its business domain are also mapped for its structure and its organizational processes. If the company is a Software Company, the concepts of the business domain of
4/8
client companies are mapped for the structure and for the organizational processes of such clients (Client's Company Model). The company’s knowledge map is also part of the Company Description component that describes it. The main component of Company Description is Company Ontology, which provides concepts and attributes related to the structural, behavioral and knowledge aspects of companies, defining a common vocabulary to guide the description of any company. Company Ontology is organized in Structure, Behavior, Strategy, Marketing, Resource and Intellectual Capital and is under development combining new concepts with the concepts defined by the Enterprise Ontology [11] and by the TOVE’s (TOronto Virtual Enterprise) ontologies [5]. ⇒ Domain Theory component The Domain Theory component organizes domain knowledge by using Domain Ontology. Domain Theory is broken-down into sub-theories and each sub-theory is mapped with potential tasks of the domain. Domain Ontology defines a vocabulary to represent domain knowledge, expressing concepts, properties and restrictions of this domain. Besides promoting the understanding of the domain, this ontology is used to guide the recording and the updating of the knowledge map regarding knowledge related to the domain. For Software Companies, a Domain Theory must be built each time there is a project involving an unknown domain. The first project involving an unknown domain provides basic knowledge about it, which grows with each new project related to such domain. In previous works we have built two DOSDE [8], one for the Marine Acoustics domain and another for the Cardiology domain, so the domain theory for these two domains has been defined. The remaining components are Information Ontology, Knowledge and Data Bases and Knowledge Management Services. Knowledge and Data Bases store the knowledge and data acquired through many software projects. Upon storage in these databases, knowledge items must be associated to terms of the existing ontologies in the environment in order to enable these knowledge items to be retrieved also from the exploration and/or selection of the concepts of the ontologies. Information Ontology involves all information and aspects of knowledge that are not specific to content. Last, Knowledge Management Services allow the storage of knowledge in the organizational memory and the dissemination and evolution of stored knowledge. Some of these components are mentioned in related works [1,2,8].
4. Two Important EOSDE’s Tools Knowledge can be so broad and grow so fast that it is often impossible to make it fully formal. Nevertheless, a critical issue which is relatively simple to solve is the identification of whom in a company has a certain skill or knowledge and in which activities of organizational processes this skill or knowledge is required. Thus, a pair of tools which enable the representation and visualization of knowledge about a company, covering structure and behavior aspects, respectively, were defined. Furthermore, these tools allow the representation and visualization of the distribution of knowledge and skills throughout the company. Both tools are generic, that is, independent from a specific company or domain, and have the purpose of making feasible the requirement (i) (section 2.1). 4.1. Tool for representing and visualizing the distribution of knowledge and skills throughout the organizational structure The purpose of this tool is to enable software developers to quickly identify, within a organizational structure, the most adequate professionals to perform a certain activity or to solve a given problem, as well as to supply knowledge about the organizational structure itself to software developers. To this end, such tool must enable: (i) organizational structure representation, that is, the definition of which are the units (boards, departments etc.) that form a company and how organizational units are related in terms of the distribution of authority and responsibility; (ii) the description of organizational units, which means specifying which are the positions existing in the organizational units and which skills and knowledge are required to enable good performance of respective functions; (iii) linking company professionals to the positions they hold in the company. Each professional has skills and knowledge acquired throughout his professional career; (iv) organizational structure visualization, and navigation in this structure, upon request supplying details about the organizational units and professionals assigned to them; (v) direct search revealing who in the company has a certain skill or knowledge;
5/8
(vi) indirect search enabling environment user to navigate among knowledge and skills available in the company searching for those who have skills or knowledge closer to the desired skill or knowledge. This may be necessary when no single individual in the company has the full skill or knowledge required and it is necessary to find somebody who meets their requirements even if only partially.
Figure 3 – Window of organizational structure definition and staff allocation, and window in which the organizational structure is displayed Despite the fact that a tree-type structure is used to record the organizational structure, it is possible to define whether the company enforces a hierarchical organizational model or not, and, then, the tree structure adapts to the adopted model. To cover requirement (vi), we intend to use a structure known as hyperbolic tree [10] and to enable a given text to be supplied as a starting point for the search. The tool can be used both during project planning and implementation, and it is expected that it will be broadly used to obtain information about the organizational structure and about company professionals. 4.2. Tool for representing and visualizing the distribution of knowledge and skills throughout the organizational processes Besides supplying software developers with knowledge about processes implemented by a company, this tool intends to provide the context in which a certain skill or knowledge is used, making it easier to understand a certain activity and also the knowledge required to implement it. For this purpose the tool must allow: (i) graphic representation of organizational processes, enabling the definition of which are the activities that are part of a process and how these activities are related regarding the order of implementation, as well as, the definition of actors involved in the implementation of the activities. To each activity it can be linked: the artifacts that serve as inputs, those which are generated as products and which knowledge is required to implement it, either formalized or not in the company; (ii) the description of organizational activities, which may involve graphic representation of how the activities are organized in terms of sub-activities, giving rise to a set of diagrams that together represent a process. An atomic activity may or may not be of a decision making nature; (iii) the description of actors, offering the possibility of linking them to positions in the organizational structure, to organizational units or to groups of positions or people in the company; (iv) the description of the artifacts that represent the inputs and the products of a given activity as well as of the required or produced knowledge. Knowledge which was formalized in the environment should be capable of being associate to its representation in a diagram. (v) the visualization of organizational processes and navigation between their different levels of abstraction, supplying, upon request, details about the elements represented in the diagrams and enabling access to formalized knowledge; (vi) the search for where a certain skill or knowledge is used throughout organizational processes.
6/8
Individuals need to understand their function within a larger process and companies need to understand their processes as a whole to be able to improve them. Increased attention has been also given to knowledge built in the processes that qualify the company to change resources into valuable products and services, seeking a smooth integration of knowledge management with business processes. These were the reasons for defining this tool.
Figure 4 – Window for graphic definition of organizational processes
5. Conclusion In order to build EOSDE we are using the infrastructure of TABA workstation [3], a meta-environment capable of generating, through instancing, software development environments adequate to the particularities of domains, development processes and specific projects. This is a long-term project developed at COPPE that was already extended to instantiate Domain-Oriented Software Development Environments (DOSDE) [8] and that is being extended to instantiate EOSDE. The definition of the model to build EOSDE is in progress and this paper has presented: (i) the EOSDE concept, establishing two basic types, (ii) the requirements for each EOSDE type with the respective knowledge infrastructures and (iii) two tools that have the purpose of managing knowledge about the company for which an EOSDE was built. Software developers need different kinds of knowledge throughout the software development process. The first extension of TABA workstation foresaw the provision of domain knowledge. Presented tools foresee the provision of knowledge about a company. The next step is the provision of knowledge about software development and maintenance accumulated by a company throughout its software projects. To this end some tools have already been defined: one to support software project cost estimates and another to support risk analysis, which consider company experience in previous projects; and a tool to support personnel management, with access to a detailed database containing the knowledge and the experience of a company’s software team. These and other tools which are being defined will add to the set of already available tools for SDE from TABA workstation. This way we intend to enable Enterprise-Oriented Software Development Environments (EOSDE) to achieve their purpose of providing software developers with the organizational knowledge necessary to software development and maintenance that has been acquired and improved by their companies throughout time. The contribution of this work, when considering relates ones [8,9,12], consists of the explicit introduction of knowledge about a company and, when appropriate, about its clients in its software development environment. We believe this knowledge to be vital for the grasp of a software to be developed or maintained as well as for the promotion of the flow of knowledge among staff. It’s worth highlighting the supply of tools for specific activities, such as risk analysis and cost estimates, which provide organizational knowledge related to them even if an explicit request has not been made.
7/8
6. Acknowledgements The authors wish thank CNPq and FINEP for the financial support granted to the project Enterprise Oriented Software Development Environments.
7. References [1] ABECKER, A., BERNARDI, A., HINKELMANN, K. et al., 1998, Toward a Technology for Organizational Memories, IEEE Intelligent Systems, v. 13, n. 3, pp. 40-48. [2] ALTHOFF, K., BIRK, A., HARTKOPF, S. et al., 1999, Managing Software Engineering Experience for Comprehensive Reuse, 11th International Conference on SE & KE, pp.10-19, Kaiserslautern, Jun. [3] da ROCHA, A. de SOUZA, J., de AGUIAR, T., 1990, TABA: A Heuristic Workstation for Software Development, COMPEURO’90, pp. 126-129. [4] FALBO, R., de MENEZES, C., da ROCHA, A., 1998, A Systematic Approach for Building Ontologies, Proceedings of the 6th Ibero-American Conference on AI, Lisbon, Oct. [5] FOX, M., BARBUCEANU, M., GRUNINGER, M., 1996, An Organization Ontology for Enterprise Modeling: Preliminary Concepts for Linking Structure and Behaviour”, Computers in Industry, v. 29, pp. 123-134. [6] IVES, B. GIFFORD, T., HANKS, D., 1998, Integrating Learning Through Knowledge (&Skills) Management, SIGGROUP Bulletin, v. 19, n. 1, pp. 51-55. [7] KITCHENHAM, B., TRAVASSOS, G., von MAYRHAUSER, A. et al., 1999, Towards an Ontology of Software Maintenance, Journal of Software Maintenance: Research and Practice, v. 19, n. 1, pp. 365-389. [8] OLIVEIRA, K., GALLOTA, C., da ROCHA, A. et al., 1999, Defining and Building Domain-Oriented Software Development Environments, 12th International Conference Software & Systems Engineering and their Applications, Paris, Dec. [9] MENDONÇA, M., SEAMAN, C., 2001, A Prototype Experience Management System for a Sofware Consulting Organization, 13th International Conference on SE & KE, pp. 29-36, Buenos Aires, Jun. [10] O’LEARY, D., 1998, Enterprise Knowledge Management, IEEE Computer, v. 31, n. 3, pp. 54-61. [11] USCHOLD, M., KING, M., MORALEE, S. et al., 1998, The Enterprise Ontology, The Knowledge Engineering Review, v.13, In: www.aiai.ed.ac.uk/project/enterprise/ enterprise/ontology.html. [12] VON WANGENHEIM, C. LICHTNOW, D., VON WANGENHEIM, C., 2001, A Hybrid Approach for Corporate Memory Management Systems in Software R&D Organizations, 13th International Conference on SE & KE, pp. 326-330, Buenos Aires, Jun.
8/8
