Software ontology development

For each property value, we created an ontology module. These ontology modules can then be combined with each other, like building blocks. When you have chosen the right property values of your envisioned platform, use the compliant ontology modules to create a full ontology model of your platform idea.

By organising the ontology into modules, it is possible to apply and combine modules, create new ones and increase the possible functionalities of the model. As a result, the ontology can accommodate the evolution of the digital platform domain and combine existing and emerging platform variations to model new types. As a proof-of-concept of how the ontology model helps understanding digital platforms and improve the communication, we shortly discuss Uber Eats, a platform for food delivery.

As you can see below, the process model is only capable of capturing the activities needed from the different user types to get the meal to the customer. On the other hand, the ontology model below not only captures the functionalities and events yellow and user types red but also relations arrows , constraints e. For example, the model defines the difference between offering, listing, listing description, listing overview and listing search.

It also shows that the transaction leads to both the preparation of the mail, related to the predefined listing, and the delivery of the meal by an automatically matched rider. We conclude with a short explanatory video. More videos can be found here. FDD was influenced by ideas of Peter Coad on object modelling. On the other end, more conventional methodologies rely heavier on processes, linear development cycles and waterfall like software development life cycles.

These processes are organized into two axes: into five process groups and into nine knowledge areas that will be described briefly in the following section. According to IPMA ICB three are the basic capabilities areas: a contextual project orientation, objective, portfolio; implementation of plans and portfolio; permanent organization; business; system, product and technology; personnel management; health, safety, security and environment; finance and legality ; b behavioural leadership, liability and motivation; self-control; self-confidence; relaxation; openness; creativity; outcome orientation; efficiency; consultation; negotiation; conflicts and crisis; reliability, appreciation values, etiquette ; c technical successful project management; interested parties; project requirements and objectives; risk and opportunity; quality; project organization; teamwork, problem resolution; project structure; scope, area and capability of fulfilment; time and project phases; resources; costs and finance; delivery and contract; changes of management and administration; information and documentation; communication; initialization; termination [2].

Software engineering community has recognized quite early, ontologies as a promising way to address current software engineering problems [17] [18]. For example, ontologies are proposed to be used in requirement engineering, software design, software maintenance, software reuse and knowledge management etc. Moreover, software engineering technologies have been proposed and developed for modelling and reasoning with the use of ontologies.

These synergies between ontologies and software engineering have also attracted attention of standardization bodies and have some on-going activities. In order to facilitate the work of researchers and practitioners Happel and Seedorf [18] defined a simple classification scheme that allows a better differentiation among the various software engineering ontologies.

They use two dimensions for ordering ontologies. Firstly, according to their position in the Software Engineering life cycle analysis, design, development, testing, etc. Ruiz and Jilera [19] in their survey presented the state of the art with regard to use of ontologies in software engineering and software technology.

They offered a taxonomy for software engineering ontologies and they presented representative cases of such ontologies.

On the same topic Zhao et al. According to Zhao, each ontology is characterised by:. In this paper, and according to the taxonomies presented, we utilize Zhao [20] classification to review various software development ontologies presented in the relevant literature, according to the project management approach used, the software process employed, and the software development phase used.

Having this as the main objective it becomes obvious that existing literature had to be reviewed in order to:. The examined area is quite wide since it refers to the intersection of project management, software engi- neering, software life cycle processes and knowledge management. In order to achieve these objectives, a systematic literature review, was conducted by the authors. This survey relied on surveying and using secondary sources [21]. The study consisted of two steps. The first step involved literature search, while the second step was focused on the taxonomy of the works and their critical analysis.

At the first step of the literature search, the authors attempted to locate and retrieve articles focused on ontologies that are related to:. The study was mainly conducted with the use of Google Scholar 4 , since this tool is indexing texts from all major on-line repositories e.

Table 1 presents all the terms that were used for this research along with the number of works that satisfied the research queries. Subsequently, the retrieved articles and materials were systematically and critically analysed.

The inclusion criteria were:. The study should be focused on software development or software maintenance processes other studies were excluded. The ontologies presented in this section are focusing on project management models without focusing software. Table 1. Search terms. A short introduction to the main concepts of each ontology along with possible applications is presented. It provides the basis of common vocabulary of terms and methods and thus enables better project management.

The produced ontology is used in checking the compliance of suppliers stated methods with standards. However, it presents difficulties for domain experts as its reasoning rules can be counter-intuitive.

Sheeba et al. This facilitates the search for learning materials within the given domain. Bodea et al. The learning material that was used was structured with the development of an ontology that modelled International Project Management Association Competence Baseline ICB [2]. The ontology developed in SinPers contained concepts, competences, learning objects, and various relationships. Ruiz-Bertol et al. They presented an example of different types of rules that can be applied on this specific ontology.

In this way, they demonstrate how further knowledge can be derived and, thus, decision-making for managing projects can be improved. Aramo-Immonen [27] explored project management by providing a PM ontology for managers. This ontology is a classification of management disciplines for project managers. The objective of this study is to help system integrators to manage the evolution of projects during their life-cycles in terms of this ontology. The disciplines defined in this ontology are project integration management, project scope management, project time management.

Dong et al. Their objective was to resolve the ambiguity issue in project monitoring processes produced by a number of factors.

This ontology is part of a framework that incorporates a series of ontologies for knowledge management and term disambiguation by focusing on project monitoring processes, and a number of metrics for assisting management of project organizations to monitor projects.

Wong et al. Its representation as the Business Project Management BProjM ontology and expedites the injection of this new domain knowledge into a software solution. The ontology has been defined in Unified Modelling Language UML ; and provides an example of how the resulting model can be used as the foundation to support the development of an integrated Project Management Information System PMIS for business projects. Instead of this, it focuses on providing an ontology that represents metrics for a specific project.

This allows for example to perform performance measurements of specific projects or sub-projects 5. It contains 32 different classes and an additional set of 26 properties 6 [30].

It provides a generic perspective for building scheduling systems and was used for configuring constraint-based scheduling systems.

Similarly, Rajpathak et al. Further, it takes into account cost related issues. On the subject area of human resource management, personnel selection, competence management, etc. HR-XML is a library of more than 75 interdependent XML schemes which define data components for various HR transactions, as well as options and constraints governing the use of these components.

Dorn et al. In their paper, they presented the requirements derived from these two projects and they describe the design of the ontology. This ontology is characterized by its integration of job descriptions, concepts for evaluating competencies on different levels and evidences for competencies.

Schmidt and Kunzmann [35] [36] describe an ontology that integrates concepts from skill management and learning. Their approach is similar to Dorn et al. In the same paper a holistic view of the organisation and of the HR problem area is presented showing how the ontology is covering different organizational aspects.

Peng and Nunes [38] systematically analysed research works and proposed a total of 40 ERP post-imple- mentation risks related to diverse operational, analytical, organization-wide and technical aspects. A risk ontology was subsequently established to highlight these ERP risks, as well as to present their potential causal relationships.

An overview of the project management ontologies, their focus and their application is presented in Table 2. Table 2. Project management related ontologies. A software process ontology [20] defines software activities, phases, and process models. Each phase is specified by a sequence of activities, each process model is described by process phases and each activity is associated with the artefacts it produces.

In the next paragraphs ontologies based on SDLCs are presented. Lin et al. K-CRIO ontology describes the key concepts and relationships of software development process and it illustrates the use of the ontology by taking the example of the Scrum development process. The main purpose according to the author for this ontology was to reuse project artefacts and to share tacit knowledge within organizations and project teams.

Zualkernan [42] presented an ontology for Generating Assessments for the Scrum Process. The motive is to create assessments for a correct understanding of a process that can be used in a software development com- pany. Similarly Valaski et al.

An alternative proposal for software process ontologies was made by Parson [46] , who designed an ontology based on an analysis of a number of commonly used agile methods like Scrum [41] , XP [13] , FDD [14] , etc. Such kind of methodologies would be preferred when the ontology to develop should be composed by a limited amount of ontological entities — while the use of highly-structured and strongly-founded methodologies remain valid and, maybe, mandatory to solve and model incredibly complex enterprise projects.

One of main characteristics that ontology development methodologies usually have is the use of exemplar data during the development process so as to:. Using real-world data, as exemplar of a particular scenario of the domain we are modelling, can definitely prevent this problem;.

This allows users to understand a model without spending a lot of effort in reading entity comments and the related documentation.

The use of real data as part of the ontology development obliges ontology engineers and developers to think about the possible ways users will understand and use the ontology they are developing, in particular the very first time they look at it;.

This kind of documentation, implicitly, allows users to apply a learn-by-example approach in understanding the model and during their initial skill acquisition phase. As already mentioned, several methodologies already propose the use of data during as part of the development. In particular, it would be important:. In order to address all the aforementioned desiderata, in this paper we introduce SAMOD Simplified Agile Methodology for Ontology Development , a novel agile methodology for the development of ontologies, partially inspired to the Test-Driven Development process in Software Engineering and to existing agile ontology development methodologies such as eXtreme Design XD.

In particular, SAMOD is organised in three simple steps within an iterative process that focuses on creating well-developed and documented models by using significative exemplars of data, so as to produce ontologies that are always ready-to-be-used and easily-understandable by humans i. SAMOD is the result of our dedication to the development of ontologies in the past six years.

While the first draft of the methodology has been proposed in as starting point for the development of the Semantic Publishing and Referencing Ontologies , it has been revised several times so as to come to the current version presented in this paper — which has been already used for developing several ontologies, such as the Vagueness Ontology , the F Entry Ontology , the OA Entry Ontology , and the Imperial Data Ontology. While a full introduction to SAMOD is provided in , in this paper we provide a summary of it and we discuss some outcomes of an user-based evaluation we have conducted in the past months.

The rest of the paper is organised as follows. In we introduce the entities involved in the methodology. In we discuss the outcomes of an experiment where we asked to subjects with limited knowledge about Semantic Web technologies and Ontology Engineering to use SAMOD for developing an ontology. In we present some of the most relevant related works in the area.

Finally, in we conclude the paper sketching out some future works. A domain expert , or DE , is a professional with expertise in the domain to be described by the ontology, and she is mainly responsible to define, often in natural language, a detailed description of the domain in consideration.

An ontology engineer , or OE , is a person who constructs meaningful and useful ontologies by using a particular formal language such as OWL 2 starting from an informal and precise description of a particular problem or domain provided by DEs. A motivating scenario MS is a small story problem that provides a short description and a set of informal and intuitive examples about it.

In SAMOD, a motivation scenario is composed by a name that characterises it, a natural language description that presents a problem to address, and one or more examples according to the description. An informal competency question CQ is a natural language question that represents an informal requirement within a particular domain.

In SAMOD, each informal competency question is composed by an unique identifier , a natural language question , the kind of outcome expected as answer, some exemplar answers considering the examples provided in the related motivating scenario , and a list of identifiers referring to higher-level informal competency questions that the question in consideration requires , if any.

A glossary of terms GoT is a list of term-definition pairs related to terms that are commonly used for talking about the domain in consideration. The term in each pair may be composed by one or more words or verbs, or even by a brief sentence, while the related definition is a natural language explanation of the meaning of such term. The terminology used for naming terms and for describing them must be as close as possible to the domain language. As anticipated in the introduction, SAMOD prescribes an iterative process which aims at building the final model through a series of small steps.

At the end of each iteration a particular preliminary version of the final model is released. Within a particular iteration i n , the current model is the version of the final model released at the end of the iteration i n Contrarily, a modelet is a stand-alone model describing a particular aspect of the domain in consideration which is used to provide a first conceptualisation of a motivating scenario, without caring about the current model available after the previous iteration of the process — it is similar to a microtheory as introduced in Cyc.

By definition, a modelet does not include entities from other models and it is not included in other models. A test case T n , produced in the n th iteration of the process, is a sextuple including a motivating scenario MS n , a list of scenario-related informal competency questions CQ n , a glossary of terms GoT n for the domain addressed by the motivating scenario, a TBox n of the ontology implementing the description introduced in the motivating scenario, an exemplar ABox n implementing all the examples described in the motivating scenario according to the TBox n , and a set of SPARQL queries SQ n formalising the informal competency questions.

A bag of test cases BoT is a set of test cases. Given as input MS n , TBox n and ABox n built according to TBox n , and considering the examples described in MS n , a data test aims at checking the validity of the model and the dataset and against specific requirements:.

SAMOD is based on the following three iterative steps briefly summarised in — where each step ends with the release of a snapshot of the current state of the process called milestone :. OEs collect all the information about a specific domain, with the help of DEs, in order to build a modelet formalising the domain in consideration, following certain ontology development principles. Then OEs create a new test case that includes the modelet.

If everything works fine i. OEs merge the modelet of the new test case with the current model produced by the end of the last iteration of the process, and consequently they update all the test cases in BoT specifying the new current model as TBox. OEs refactor the current model, in particular focussing on the last part added in the previous step, taking into account good practices for ontology development processes. In case there is another motivating scenario to be addressed, OEs iterate the process, otherwise the process ends.

The next sections elaborate on these steps introducing a real running example considering a generic iteration i n. OEs and DEs work together to write down a motivating scenario MS n , being as close as possible to the language DEs commonly use for talking about the domain.

An example of motivating scenario is illustrated in. Vagueness is a common human knowledge and language phenomenon, typically manifested by terms and concepts like High, Expert, Bad, Near etc.

In an OWL ontology vagueness may appear in the definitions of classes, properties, datatypes and individuals. Vagueness can be described according to at least two complementary types referring to quantitative or qualitative connotations respectively. The quantitative aspect of vagueness concerns the real or apparent lack of precise boundaries defining an entity along one or more specific dimensions.

The qualitative aspect of vagueness concerns the identification of such other discriminants of which boundaries are not quantifiable in any precise way. Multiple justifications are possible for the same description. The annotation of an entity with information about its vagueness is a particular act of tagging done by someone i.

Silvio Peroni thinks that the class TallPerson is vague since there is no way to define a crisp height threshold that may separate tall from non-tall people. Thus, for Panos, the class TallPerson is not vague. In an company ontology, the class StrategicClient is considered vague.

On the other hand, the Operations Manager believes that a client is strategic when he has a long-term commitment to the company. In other words, the vague class StrategicClient has quantitative vagueness and the dimension is the duration of the contract.

In particular, although there are several criteria one may consider necessary for being expert e. Given a motivating scenario, OEs and DEs should produce a set of informal competency questions CQ n , each of them identified appropriately. An example of an informal competency question, formulated starting from the motivating scenario in , is illustrated in. Now, having both a motivating scenario and a list of informal competency questions, OEs and DEs write down a glossary of terms GoT n.

An example of glossary of terms is illustrated in.