Ontology for knowledge condensation to support expertise location in the code phase during software development process

IET SoftwareVolume 14, Issue 3 p. 234-241 ArticleOpen Access Ontology for knowledge condensation to support expertise location in the code phase during software development process Jose R. Martínez-García, orcid.org/0000-0002-7322-0990 Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this authorFrancisco-Edgar Castillo-Barrera, Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this authorRamon R. Palacio, Corresponding Author ramon.palacio@itson.edu.mx Unidad Navojoa, Instituto Tecnológico de Sonora, Navojoa, MexicoSearch for more papers by this authorGilberto Borrego, orcid.org/0000-0001-7315-5693 Computación y Diseño, Instituto Tecnológico de Sonora, Cd. Obregón, MexicoSearch for more papers by this authorJuan C. Cuevas-Tello, Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this author Jose R. Martínez-García, orcid.org/0000-0002-7322-0990 Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this authorFrancisco-Edgar Castillo-Barrera, Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this authorRamon R. Palacio, Corresponding Author ramon.palacio@itson.edu.mx Unidad Navojoa, Instituto Tecnológico de Sonora, Navojoa, MexicoSearch for more papers by this authorGilberto Borrego, orcid.org/0000-0001-7315-5693 Computación y Diseño, Instituto Tecnológico de Sonora, Cd. Obregón, MexicoSearch for more papers by this authorJuan C. Cuevas-Tello, Computer Science, Autonomous University of San Luis Potosi, San Luis Potosí, MexicoSearch for more papers by this author First published: 01 June 2020 https://doi.org/10.1049/iet-sen.2019.0272Citations: 3AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onEmailFacebookTwitterLinked InRedditWechat Abstract Software Development is a complex process, in which every software product is a knowledge representation of all the involved people. In agile software development, knowledge is prone to vaporise, because documentation is not a priority as indicated in the agile manifesto. This condition generates problems such as poor understanding of the requirements, knowledge transfer deficiency among developers, time wasted by developers while searching for knowledge. The objective of this work is to reduce architectural knowledge vaporisation by means of knowledge condensation to support expertise location (high-level knowledge at a given time). This through an ontology that will condensate the knowledge in the code phase. This study presents the description of an ontology development process following the Methontology Framework. Results show that the proposed ontology does not present incongruence or inconsistency and answers the competency questions correctly. The main contribution of this study is the ontology which brings several benefits such as a shared concept of the knowledge in the code phase and a way to link the artefacts (resources used by developers in the project) and the experts (artefacts provider). 1 Introduction Software Development is considered a complex process, in which every software product is a representation of the knowledge of all the involved people, due to this knowledge is used to solve client's needs by generating a computer application [1, 2]. For this reason, development teams require constant interaction with the project's stakeholders, since the teams are integrated by people working in different phases and activities. Particularly, coding is a phase of the software development cycle, aimed to translate the system design into code in a given programming language. During this phase, a lot of knowledge can be shared among the team members [3], for example, programmers and testers. In software companies, knowledge can be found in two sources [4]: (i) artefacts such as documentation [5] (e.g. requirements document, vision document), source code [6], repositories where developers store and consult digital (e.g. blogs [7, 8], bookmarks) or physical documents (e.g. manuals) and project management tools; (ii) persons with a certain level of knowledge in a specific area that could be useful to solve problems during development tasks [9, 10]. Therefore, anyone in a company could be a potential source of knowledge. In agile software development, documentation is not a priority, as expressed in agile manifesto [11], thus, it is reflected in agile software projects with minimal documentation. This situation is caused because the face to face interaction is preferred by developers to clarify doubts or to solve problems. Hence, knowledge is prone to vaporise due to the manifest's principles [12, 13]. Borrego et al. [13] define architectural knowledge vaporisation as the loss of artefacts and architectural documents owed to poor documentation. The fact of not having this knowledge generates the following problems [14, 15]: (i) poor understanding of the requirements and technical solutions; (ii) knowledge transfer deficiency among developers; (iii) evolution and maintenance drawbacks; and (iv) time wasted by developers while searching for artefacts or experts. These problems cause the increase of time and cost in software development projects [16]. To address these problems, developers seek high-level knowledge at a given time (expertise) [10], through which developers could resolve problems or doubts that arise daily during their workday to help them fulfil their activities [17]. However, developer teams generally do not benefit from this knowledge (artefacts and experts), generated during the software development process. Artefacts usually are not linked with their creators, moreover each person labels or stores knowledge in different ways. In this case, artefacts become hard to identify, because they are not available or they get lost (when the provider/creator leaves the company) [18-21]. Therefore, it is necessary to link the artefacts generated during the coding phase with the creator (experts). The goal is that artefacts can be easier to find (expertise) and accessible to everyone, even when the knowledge provider or the expert is not present in the company. Thus, knowledge needs to be condensate. Borrego et al. [13] define the knowledge condensation as the process of capturing and classifying knowledge before it loses, where the objective is to ease knowledge retrieval. This is an important issue because to make good decisions when having a doubt or problem developers need reliable and precise information (expertise) [22], developers have an expertise need and this can be found in different sources as mentioned before. In our approach, the knowledge condensation is done by using ontologies, which are a formal description of a shared concept [23], and they allow to define a vocabulary to share information in a certain domain. Moreover, in addition, to help with the decision making, ontologies could mitigate the problems caused by the knowledge vaporisation mentioned before, and also could prevent constant questions to experts which sometimes lead to an erosion in interpersonal relationships, affecting the knowledge flow. Additionally, ontologies present a visual way to share a common understanding of an information structure between several people or computer systems [24], and also they allow to reuse knowledge through ambiguities clarification [25]. As we can notice, an ontology can provide benefits in software development through an information structure that can do automated reasoning about knowledge in the software development life cycle (e.g. project management [26], software measurement [27], maintenance [28]). In this sense, the challenge is getting a described content capable of: (i) distinguish among different word meanings; (ii) infer relations between words on a specific thematic context; and (iii) retrieve information according to the user needs. Thus, information must be described and classified in a way that it can be understandable for a computer or any user within an organisation. In Fig. 1, we present automata to illustrate a scenario of the expertise location. The transitions are objective reached (OR), artefact seeking (AS), expert seeking (ES), identifying availability (IA), resource need (RN), expert unavailable (EU), a resource founded (RF). The automata have six states {q0, …, q5}. This scenario starts with a developer having the need of expertise to solve a problem or doubt (q0). Then, the developer can choose between an expert search (q2) or an artefact search (q1). The developer searches for all available artefacts, in the case of choosing an artefact search (q1). An artefact verification is done to see if it is fulfilled the objective (q3). If the need for expertise is satisfied, the problem is solved (q5). On the contrary, if the need for expertise is not satisfied the developer must check more artefacts to solve the problem (q1). On the other hand, in the case of choosing an expert search (q2), the developer does a search looking for someone with the knowledge to solve the problem or doubt, once the right person is found, his/her availability must be checked (q4). Fig. 1Open in figure viewerPowerPoint Initial state is q0, which represent the need of expertise to solve a doubt or problem, and q5 is the final state, representing when a doubt or problem was solved Finally, if the expert fulfilled the objective, the problem is solved (q5). Otherwise, another expert search is needed (q2). Sometimes an expert can lead the requester to an artefact (q1) and vice-versa (q2). As we can see, expertise location is a complex process, since despite that expertise exists in an organisation, this is not always accessible. Sometimes an expert is unavailable for diverse reasons, skips the day, is on vacation, leaves the company etc. Therefore, artefacts used or created by an expert may not be accessible. From the above, the main objective of this work is to describe the development process and validation of a domain ontology, which is focused on the coding phase of a software development process. The aim is to link artefacts and experts through an information structure (ontology). The rest of the paper is structured as follows: Section 2 shows the related works of software engineer ontologies; Section 3 presents the methodology followed to develop the ontology; in Section 4 we present the results obtained following the methodology; Section 5 presents the validity threats of this work; finally, in Section 6 we present the discussion and conclusion of our results and we present our acknowledgments in Section 7. 2 Related work Recently, Software Engineers have had an interest in the use of ontologies to identify and share knowledge on the different phases of the software development cycle as presented in the works by Bathia et al. [29] and de Souza et al. [30]. In the literature, we can find different methodologies to develop ontologies including Diligent [31], On-To-Knowledge [32], Neon [33], OntoDocMan [34] and Methontology Framework [35], where each one follows a different approach. The Methontology Framework is widely used because its resemblances the software development process in software engineering. Since the approach is focused on software engineering, it will easy to follow by software developers. Some authors refer to the Methontology Framework, e.g. an ontology was developed to represent college graduation screening process [36], the development of STIFIn Ontology Finger Personality Solution [37], among others. The Methontology Framework consists of the following phases: (i) Specification: identification of the domain, goal, relevant terms, and objectives; (ii) Conceptualisation: creates a glossary of terms and from this create a taxonomy; and (iii) Formalisation: creates a formal computational model using a tool (e.g. Protégé [38]). Previous to the ontology development, we conducted a literature review of ontologies in the software development process. The ontologies found during the literature review have addressed some problems related to some specific development phase. These are: Requirements, Design, Implementation, Testing and Maintenance. These phases are the same regardless of the methodology used and are known as the software development life cycle [39, 40]. Table 1 shows the ontologies found as a result of a literature review. These ontologies were classified based on the software development cycle phase in which they are focus and how much progress they achieve based on the Methontology Framework. Almost all the ontologies work on the requirements phase, targeting activities such as requirement analysis. In [41-45] proposals seek to enhance the software quality by improving the elicitation and administration of the user's needs. Their objective was to eliminate ambiguities and language mistakes. Additionally, they elicit the requirements in a faster way and obtain an output in different formats (e.g. UML, data models, and diagrams). Table 1. Ontologies supporting software development activities Stage/Ontology Specification Conceptualisation Formalisation requirements documentation of experiments in distributed software [46] documentation of term and concepts in GSD [47, 48] human resources assign [26] sutomatic software documentation [49] effort Estimation [50] effort estimation [51] software requirements [42, 43] documentation of terms and concepts in multisite development [52, 53] software requirements [41, 44, 45] documentation for task allocation [54] documentation to support distributed teams [5] software measurement [27] service management [55] design modelling software process [56] coding testing maintenance knowledge management [28] software artefacts traceability [57] Another activity performed in the requirements phase is effort estimation. Hamdan et al. [50] seek to eliminate mistakes or misunderstandings through the use of ontologies in a system, which enables project managers to obtain characteristics and terms of previous projects. Adnan and Afzal [51] present an ontology for knowledge about effort estimation, which has the objective of mitigate problems of distributed teams (e.g. inaccurate estimation of effort and time) by making an estimation based on previous projects. Pre-established terms are used to describe the project. Documentation is another activity addressed in the requirements phase. Rocha and Meira [46] present a literature review of ontologies focused on documentation in distributed software development (DSD). Their objective is to propose a recommendation system, based on the issues founded in the literature review. Addressing the same activity, Bathia et al. [49] present a conceptual description of an ontology, to get automatic documentation through a system that uses an ontology. This ontology establishes terms and concepts to be used across projects. There are ontologies which work with documentation activities [47, 48, 52, 53, 58], which try to create a semantic (generalised interpretation) between concepts and terms used either in Global Software Development (GSD) or DSD. Their objective is to describe GSD o DSD projects. Finally, Marques et al. [54] present an ontology to document task allocation in distributed software development teams. This ontology offers a reference to concepts and terms used in distributed software development, and also tasks and information of the developers (e.g. projects, country, time zone, experience). Another activity included in the requirements phase is human resources assign. Paredes-Valverde et al. [26] present an ontology that broadly describes user data (developers). The aim is to assign developers into projects according to their experience and the needs of the project. On the other hand, Fonseca et al. [27] present an ontology for software measurement activity (e.g. measure source code, effort estimation, number of sprints). This ontology aims to unify the outputs of different tools that measure software. The goal was to have a better measurement using the data from all the measurement tools. Finally, Valiente et al. [55] present an integration model between Software Engineering and technology administration service. This model uses an ontology to integrate terms and concepts involved within these areas. The purpose was to make clear to the client his options, and the client's needs to the developer. Regarding the design phase, Martinho et al. [56] present an ontology for modelling software processes. The ontology was designed using knowledge modelling tools (Cmpas & CmapsTools). The ontology is focused on the project flexibility design (information that the developers want to use based on their experience). Finally, in the maintenance phase, Serna and Serna [28] present a conceptual analysis of applying ontologies for knowledge management in the maintenance phase during software development. Instead of conceptual analysis, Zhang et al. [57] present a maintenance ontology for tracking artefacts to link them with the software requirements, with the main purpose of differentiate a code mistake from a requirement mistake. Undoubtedly, there are many software development activities that can be benefited with the support of ontologies, but most of these have not been formalised, in consequence, these ontologies are not properly appreciated. In Table 1, it can be noticed that there exists an area of opportunity to build ontologies in the testing and coding phases. Particularly, an ontology in coding phase could bring several benefits, such as support to the expertise location by generating concepts and terms of the knowledge in this phase with the purpose of linking the artefacts with their provider. Furthermore, the ontology could generate knowledge representation, this representation will help to identify resources used in a project and their providers. In this way, the information (expertise) will be more accessible, which will reduce the time invested in the expertise location process (see Fig. 1). In addition to this, most of the work presented in this section is not focused on the code phase. In some cases, these ontologies are presented as a conceptual model. The next section presents the formal methodology that was used to define our ontology. 3 Method This research followed the Methontology Framework [35] which is an accepted methodology to define the development life cycle in Ontological Engineering (from requirements specification to maintenance). The Methontology Framework life cycle (Fig. 2) includes five phases: (i) Specification; (ii) Conceptualisation; (iii) Formalisation; (iv) Evaluation; and (v) Maintenance. The next subsections describe the phases and activities needed for the development of our ontology. Fig. 2Open in figure viewerPowerPoint Methontology Framework life cycle 3.1 Specification phase Specification phase establishes a document covering the ontology's purpose (i), scope (ii), implementation language (iii), intended End-Users (iv) and Intended Uses (v). This document is done by doing the following task. 3.1.1 Knowledge acquisition activity In software development, the key to project success lies in the software specification [39]. Suarez-Figueroa et al. [59] present guidelines based on the use of the Competency Questions (CQ) and the existing methodologies to build ontologies. These guidelines help to capture knowledge from users and to produce the Ontology Requirement Specification Document (ORSD). The ORSD document helps to identify the knowledge that the ontology contains, and it is useful to define the requirements the ontology must cover. For the knowledge acquisition activity, we come up with three approaches: (i) interviews; (ii) focus group; (iii) survey form. Three different groups were selected to cover different approaches. The participants were developers from different organisations (e.g. software organisations and organisations with a software developer department). The first approach carried out was the interviews, the objective was to know the way developer teams work, (e.g. communication, challenges or problems). The interviews contained questions related to general information (role, activities and organisation), project administration, version control, coordination and team mindset. The objective of the focus group was to know the process of searching for expertise within the software development teams either to store it or to share it, as well as the process of finding an expert for consulting. The participants were asked about the process of individual search, knowledge sharing and expert search. Finally, the last approach, survey form, was applied to group developers. The objective was to obtain examples of problem or doubts that the developers usually try to solve. The survey contains the following fields: search keywords, type of search (expert or artefacts) and time invested trying to solve a doubt or problem. 3.2 Conceptualisation phase Once all the needed knowledge has been acquired, it must be organised. Conceptualisation phase is focused on organising and structuring the acquired knowledge using external representations (e.g. UML, IDEF5) which are independent of the ontology implementation languages. The organising and structuring tasks are as follows. 3.2.1 Integration activity To avoid redundant information, it must be considered the reuse of ontologies (definitions already built). The Ontologies were consulted in the following databases: Swoogle [60]. DAML Ontology Library [61]. ONKI Ontology Library Service [62]. Linked Open Vocabularies [63]. These databases were searched on the internet and some of them are the most commonly cited in research articles available. In addition, we searched for ontologies of the same domain in academic databases (e.g. IEEE Xplore, ScienceDirect), like the one trying to build in this work in academic databases. 3.2.2 Knowledge modelling activity This task consists of storing statements about facts by building meaningful information structures through multiple representations (e.g. mind maps). 3.3 Formalisation phase Formalisation phase converts a conceptual model (taxonomy) to a formal model (computable). Specifically, for this work we took the taxonomy created in the conceptualisation phase, it was converted using to a computation model using Protégé tool [38]. This activity is known as Implementation activity. 3.4 Evaluation phase In the traditional Methontology Framework the evaluation is considered as an activity which is carried out during all the phases. In our work, this activity is considered as another phase in the proposed methodology, which consists of carrying out a technical judgement of the ontology, according to the ORSD, by doing the following tasks. 3.4.1 Verification activity This activity is a technical process which is done to guarantee the correctness of the ontology, according to the specification requirements. The verification activity was being done using the Pellet plugin reasoner on Protégé. An ontology reasoner is a piece of software able to infer logical consequences from a set of asserted facts or axioms. 3.4.2 Validation activity It is the process done to ensure that the ontology fulfils the purpose for which it was built. The validation was being done by using CQ [64], which consists in a set of questions defined in the ORSD in a natural language, the ontology must answer these questions correctly. The CQs were based on the survey form that the developers fill with examples of doubts of problems that they try to solve. Finally, at the end of all the phases, there is the maintenance phase, which consists of tasks covering from erasing obsolete instances or adding new ones over time. This phase was considered because the scope of we were focused only on ontology development. 4 Results Here, we present our results obtained by following the phases and activities defined above. 4.1 Specification phase results The knowledge acquired was collected following three approaches: interview, focus group and survey form (see Section 3.1). In the interview participated 6 developers and 2 project managers from 6 different software development companies. In the focus group participated 4 developers and 1 designer from the same company. Finally, in the survey form participated 12 developers from 3 different companies. The data were extracted from the interviews, focus group and survey from using affinity diagrams, which is a tool that synthesises a set of verbal data (e.g. ideas, opinions, expressions) grouping them according to the relationship they have with each other. This process begins with the transcription of the interviews to find the key data of the participants' responses. From that, the data of the answers that appeared most recurrently were classified. Later we continue with the analysis of the data to identify the relationships between the processes of the search for expertise. Finally, from the affinity diagram and the defined categories, conclusions were obtained. With the collected information as part of the specification phase, we create a document following the ORSD guidelines. Table 2 shows a fragment of the developed ORSD. Table 2. ORSD Fragment Ontology Requirements Specification Document Template 1 Purpose the integration of the artefacts, projects and experts in the code phase of the software development process 2 Scope the ontology has a focus just on the code phase of the software development process domain. The level of granularity is directly related to the competency questions and terms defined 3 Implementation Language the ontology must be implemented in OWL language using protégé ontology tool. 4 Intended End-Users user 1. Programmer searching for resources to solve a problem (e.g. requirements, bugs, or doubts with a process) user 2. Programmer searching for an expert to ask for help user 3. Programmer searching for information about a project and his participants user 4. Programmer updating or registering his expertise (projects or resources) 4.2 Conceptualisation phase results As a result of the integration task, it was not found any ontology with the same domain as the one trying to build in this work, neither in ontology databases nor in the literature review. Based on the terms and concepts identified from interviews, focus and a survey form, we created a taxonomy (see Fig. 3). Fig. 3 shows a taxonomy of the knowledge produced in the code phase of the software development (programming knowledge). The main elements of the taxonomy are (i) profile; (ii) projects; and (iii) artefacts. Fig. 3Open in figure viewerPowerPoint Taxonomy of Knowledge Expertise in code phase The Profile entity represents a description of a programmer in an organisation with information such as name, role, skills, projects has worked or is working currently. The Project entity represents information about the developer's current project. In this way, you can know the developers' skills based on the project history and the artefacts used in those projects. So, developers create artefacts by working on projects, and those are used by others to solve problems. In summary, programmers have a profile and work assigned in a project, which is developed in a certain platform (e.g. web, database, desktop and mobile) which has layers (e.g. backend and frontend) and a programming language (e.g. JavaScript). 4.3 Formalisation phase results Protégé tool [38] was used to convert the conceptual model to a computable model. This tool uses Ontology Web Language (OWL) [65] to define an Ontology. Using the taxonomy (see Fig. 3), we defined the classes' names (in OWL, classes are interpreted as a set of individuals or objects), properties, and instances. The principal class that represents a set of all individuals is 'Thing', thus all classes are subclasses of that one (see Fig. 4). Fig. 4 shows the main classes of our ontology: Team, Artefacts, Project, Layers. Team class represents a developer team in an organisation. Artefact class represents the resources used by developers to solve a doubt or a problem. Project class represents a description of the work and activities done by developers. Fig. 4Open in figure viewerPowerPoint Coding phase expertise ontology: screenshot of main classes developed in Protégé In conclusion, developers (members of a Team class) work in a Project in an organisation, and when a developer has a doubt or problem uses Artefacts. Properties in OWL represent a relationship between two individuals. There are two types of properties: object and data type properties. The object properties link an individual to another individual. The datatype properties link an individual to a data value expressed in Extensible Markup Language (XML) or Resource Description Framework. The properties defined to our ontology are shown in Table 3. The property 'isUsedBy' help to link a programmer (a subclass of a team class) to the artefacts that have been used to solve problems or doubts in a project. The 'isMemberOf' and 'hasWorked' property helps to identify in which Programmer has worked or which project is currently wor