Software Metrics for Cooperative Scrum Based

2017 2nd International Conference on Knowledge Engineering and Applications

Software Metrics for Cooperative Scrum Based Ontology Analysis

Wa'el Mohsen

Mostafa Aref, Khaled ElBahnasy

Computer Science Department Ain Shames University Cairo, Egypt e-mail: [email protected]

Professor of Computer Science Ain Shames University Cairo, Egypt e-mail: [email protected], [email protected] software metrics are proposed over last years, ideal software metric is the one that is handy, effective, and efficient. Ontology development and evolution are no longer different from software development and evolution, especially inter-organizational ontologies. Assessing the quality of cooperative ontology development and evolution is important for several reasons. It is allowing the ontology Scrum teams [3] [4] [5] to recognize areas that might need more work, and it is allowing Knowledge Architect [5] to know what parts of the ontology might cause problems. Approaches used for evaluating ontologies can be divided into four main categories. The first category uses information about the class graph of an ontology to measure the complexity of the ontology. The second group analyzes the lexical structure of the content of an ontology to evaluate its quality indicators, such as clarity, interpretability, and redundancy. The third type exploits an external evaluation mechanism, such as Google’s PageRank, or uses human reviewers. The fourth approaches use a combination of the three methods. Most of those different formulas that have been defined in previous years are robust. However, when one comes to use those metrics, he will face many problems like; the output of all of those metrics is just a set of numbers that are hard to reflect real sense about the weight of the ontology metric or the effect of this metric's value on ontology performance or efficiency. Moreover, it will be too hard to apply and follow up those metrics over large ontologies that are distributed and evolve over the time. Another problem is that anyone may need many setup and configuration steps to integrate those metrics on our environment because those metrics are belonging to different tools or plugins. All of these problems and many others will be a challenge in case anyone wishes to apply a set of metrics at the same time and compare metrics' results with each other. Applying a set of metrics on ontology and compare its values will help knowledge architects to assimilate the whole problems of current ontology and to decide how he can solve all of these issues to make ontology metrics values more stable and within allowed threshold. This paper is organized into eight main sections. First, it provides quick information about previous work related to Ontology analysis to assets ontology quality. Then it provides quick information about collaborative ontology engineering using Scrum, and Nexus frameworks. Then it

Abstract—One can only control what he can measure. Measuring ontologies in general and inter-organizational ontologies in special is necessary to evaluate ontologies during cooperative development and evolution processes. A software metric is a standard of measuring the degree to which a software system and process possess some property. Metrics help to estimate the progress, quality, and health of a software and its development process. The availability of robust metrics in the early phases of the software development allows the better management of the later steps and a more efficient quality assessment when preventive or corrective actions can easily enhance quality. In this paper, we propose a set of cooperative Scrum based software metrics and architectural metrics that can be applied to cooperative ontology development and evolution process using Scrum framework. These metrics help improve cooperative teams' performance and improve the quality of development and evolution process of inter-organizational ontologies. Furthermore, most of these metrics can be applied easily to any daily ontology activities to ensure ontology reliability, maintainability, and usability. Keywords-ontology quality; performance; architectural metric

I.

software

metrics;

team

INTRODUCTION

Software metric is a standard of measuring a degree to which a software system or process possesses some property. Software metrics assess the effectiveness and quality of software process, determine the maturity of the process, the effort required in the process, effectiveness of defect removal during development, and so on. To improve any process, it is necessary to measure its specified attributes, develop useful metrics based on these attributes. Then use these metrics to obtain indicators to derive a strategy for process improvement [1]. Using software process metrics, software engineers can assess the efficiency of the software process that is performed using the process as a framework. The skills and motivation of the people, the complexity of the product and the level of technology employed in the software development has a significant influence on the quality and team performance [1], [2]. To measure the effectiveness and efficiency of the software process and developed software, a set of metrics is formulated based on in progress work during the process and the outcomes derived from the process. Although many

978-1-5386-2150-9/17/$31.00 ©2017 IEEE

60

investigation were density, name simplicity, popularity, and reference.

provides a set of Scrum metrics and rapid information about primary ontology analysis metrics. After that, it discusses how to exploit software architectural tools and techniques for large sustainable ontologies. Then it provides a case study and conclusion. II.

III.

COLLABORATIVE ONTOLOGY ENGINEERING

A leading software development process called Scrum is being applied to cooperative ontology development and evolution at [5]. Research at [5] is proposed Scrum & Nexus frameworks to handle those daily tasks of ontology development and evolution lifecycle management, especially at collaborative inter-organizational environments. In this environment, different organizations and teams collaboratively build a shared ground of the domain knowledge [6]. Furthermore, research [5] answered the peril questions that are asked when formulating a change request in a collaborative context [7][8]: x What are ontology engineering processes required to achieve the goal or resolve the communication breakdown? As many knowledge workers will collaborate, we need additional methods for integrating their divergent conceptualizations, including negotiation and argumentation. x How to conduct the activities? This question related to the epistemological dimension of knowledge: it examines to which extent tacit personal knowledge from multiple knowledge workers can be made explicit, and universally accepted by the community. x Who will be coordinating these activities? This question related to authority for the control of the process. Scrum [4] [9] is a framework which can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Nexus [10], [11] is scaled Scrum consisting of roles, artifacts, events, and techniques that bind together the work of three to nine Scrum Teams working on a single Product Backlog. Source control systems [5] are used to conduct Scrum and Nexus activities. Source Control Systems used to track changes to software projects and allow team members to change and collaborate on the same files. Version control systems allow members to work simultaneously on code and isolate their work through what are known as branches. Therefore, source control systems increase collaboration through team members and lower the risk of losing files and projects with automatic back-ups [12] [13] [14]–[17].

RELATED WORK

There is an extended set of tools and frameworks that have been developed during last years to analyzing and evaluating readymade ontologies. Nevertheless, a little work discussed how to monitor the development and evolution process of ontologies. Much less explored, however, are tools to analyze development and evolution of interorganizational ontologies. Following examples lists, some of the critical ontology quality and evolution tools developed during last years. For a wider area of ontology engineering, a framework of many metrics are provided by OntoMetric [11]. OntoMetric mentioned a long list of metrics into several different areas, like tools, languages, methodologies, costs, and content. They define the relations between the various metrics, their attributes, and the quality attributes they capture. OntoQA is a tool that implements some metrics [14]. It provides an automatic measurement of ontologies. It defines metrics like richness, population, or cohesion. OntoClean [9], currently the most popular ontology evaluation approach, is a philosophically inspired approach for the assessment of formal properties of a taxonomy. Many tools support the manual tagging with OntoClean properties (WebODE [2]), and OntoEdit [13]) in addition to recent work deals with the automation of OntoClean [15]. From a practical perspective, OntoClean provides means to derive measurable mismatches of an ideal taxonomy structure deals with the semantics of the “is-a” relationship. Such mismatches have a structural nature, e.g. one can derive that a certain concept should not be the sub-concept of another concept. Measures applied to ontologies of the Semantic Web are usually still in an elementary state [17]. We think that the most common hurdle to applying more semantic metrics on web ontologies is the actual lack of foundational work towards defining such measures and a subsequent lack of implementation. The work presented at [17] is a step towards measuring the web in several new dimensions. Preliminary work in the TOVE ontology by Fox et al. [11] epitomizes the inductive approach to ontology criteria selection. They proposed eight criteria for evaluating ontologies that include generality, competence, perspicuity, transformability, extensibility, granularity, scalability, and minimality. Of these eight, they considered competence to be the most important and explored their ontology in the context of answers to competency questions. Recent work by Ning et al. [24] discusses ontology summarization. Their work is a perfect exemplar of the inductive approach to ontology feature selection for evaluation. In that research, the importance of four ontology features is evaluated and ranked using Kendall’s tau coefficient [36,35]. The ontology features under

IV.

SCRUM PROCESS METRICS

A set of metrics is formulated based on in work progress during the process and the outcomes derived from the process to measure the efficiency and effectiveness of Scrum teams working on the inter-organizational ontology creation and evolution. Within Scrum, metrics are powerful tools for planning, inspecting, adapting, and understanding progress over time [1]. Rates of success and failure let Scrum team knows whether they need to make positive actions or keep up its good work. Cost and time numbers can highlight the benefits of Agile projects and provide support for an organization’s financial activities [1], [2].

61

team will need twenty iterations (give or take) to complete the required work.

The agile metrics discussed below emphasis on the delivery process of new ontology or evolved ontology. Each of these agile metrics will help the Scrum team better understand their development process, making releasing ontology easier. A. Sprint Burndown Scrum teams organize development into time-boxed sprints [4], [12], [13]. At the outset of the sprint, the team forecasts how much work they can complete during a sprint. A sprint burndown chart then tracks the completion of work throughout the sprint. Figure 1 explains a sample for burndown chart. The x-axis represents time, and the y-axis represents the number of work items left to finish sprint commitments. The goal is to have all the committed work completed by the end of the sprint [18]–[20].

Figure 2. Epic and release burndown.

It is important to monitor how velocity rate evolves. New teams can expect to see an increase in velocity rate as the team optimizes relationships along with the work process. Teams can track their velocity to ensure reliable performance over time and can confirm that a specific process change made improvements or not. A decrease in average velocity rate is a sign that some part of the team's development process has become unproductive and should be brought up at the next retrospective [18]–[20]. Figure 1. Sample burndown chart

B. Release Burndown Release burndown chart tracks the progress of the development within the whole project than the sprint burndown. Also, it guides the development of both Scrum and nexus teams. Since a sprint (for Scrum teams) may contain work from several epics and versions, it is important to track both the progress of individual sprints as well as releases and versions [12], [18], [21], [22]. "Scope creep" is the injection of new requirements into a previously defined project. As the team moves through the project, the product owner may decide to take on or remove work based on what they are learning. The epic and release burndown charts keep everyone aware of the epic and flow of work inside the epic and version [12], [13], [23].

Figure 3. Velocity chart.

C. Velocity Rate Velocity is the average amount of work items a Scrum team can complete during a sprint. It is handy for forecasting team commitments. The product owner can use velocity to anticipate how quickly a team can work on the backlog. The report tracks the forecasted work aginst the completed work over several iterations. The more iterations there are, the more accurate the forecast [12], [13], [23]. Let us say the product owner wants to complete 500 story points in the backlog. The development team completes 25 story points per iteration. The product owner can assume the

D. Control Chart Control charts take care of the cycle time of individual issues (The total time from "in progress" to "done.") [12], [21]. Scrum teams with shorter cycle times are probable to have higher throughput and Scrum teams with consistent cycle times along with many issues are more predictable in delivering work. Measuring cycle time is an efficient and elastic way to improve a team's processes because the results of changes are discernable almost immediately and allowing the team to make any further adjustments right away. The final goal is to

62

between most ontologies reflect their underlying complexity, and these variables were analyzed. The metrics defined are composed of fundamental metrics and complexity metrics. Primitive metrics measure a basic level of information, including the total number of classes, relations, and paths. Complex metrics measure the average relations per concept, the average paths per concept, and the ratio of maximum path length to the average path length of the ontology. These metrics examine the concept aggregation and coherence of an ontology. Yao et al. [34] proposed a set of ontology cohesion metrics as a measure of modular relatedness of OWL ontologies. They defined three cohesion metrics: the number of leaves (NoL), the number of roots (NoR), and an average depth of inheritance tree of leaf nodes (ADIT-LN). Like software cohesion metrics, these were used to measure the interrelation of elements in ontologies. These cohesion metrics are calculated based on predefined OWL primitives, which explicitly define tree-based semantic hierarchies in OWL ontologies [34]. Orme et al. [34], [35] defined ontology coupling metrics, the number of external classes (NEC), references to external classes (REC), and referenced includes (RI) to measure coupling between ontologies. REC is the number of references to external classes in ontology O. NEC is the sum of distinct external classes that are defined outside O but used to define new classes and properties in the ontology. RI is the count of includes on the top of the ontology definition file O, which the ontology uses to define ontology language primitives and ontology information defined by other ontology developers. In summary, existing ontology metrics are compared and summarized in following Table 1.

have a consistent and short cycle time, regardless of the type of work (new feature, technical debt, and so forth.) [13].

Figure 4. Control chart.

V.

ONTOLOGY EVALUATION METRICS

Assessing the quality of cooperative ontology is important for many reasons including allowing the knowledge architect to automatically recognize areas that need more work, allowing the knowledge architect to know what parts of the ontology may cause problems, and allow him/her to compare between different ontologies when only one is going to be used. Abundant researches have been performed in the field of software metrics. Many object-oriented software metrics and measures have been proposed, and some principal work has been done [24]. One of the most commonly cited metric suites is that suggested by Chidamber and Kemerer [25]– [27]. They proposed a lack of cohesion of methods (LCOM), the coupling between object classes (CBO), and response for class (RFC). Because the object-oriented conceptual model is closely associated with ontology representation [24], software measurement criteria, such as cohesion, coupling, and complexity, can be regarded as a candidate evaluation framework for ontology quality assessment [24], [28]. The purpose of many of the ontology evaluations is syntax evaluation to guarantee the correctness and completeness. Correctness and completeness are essential and basic factors to support the quality of ontologies, but metrics to check correctness and completeness rarely exist. Furthermore, their functions are included in evaluation tools such as Ontometric [24], [29], [30], Protégé [31] and OntoQA [32]. Existing evaluation metrics are to measure basic internal structure, such as size, depth, richness, and cohesion, and coupling, of an ontology to represent the structure of a given domain knowledge base. Previous metrics are proposed as follows. Yang et al. [33] proposed metrics to measure the complexity of ontologies, with an emphasis on the problem of increasing the complexity of maintenance and management as ontologies evolve. The concepts, the hierarchy in the conceptual model, and the common features

TABLE I: ONTOLOGY METRICS COMPARISON Objective

Acronym

Noc NoP Size

SOV DIT EOG CID COD

Richness NoF AFRC NoR Cohesion

NoL ADITLN

63

Metric

No. of classes

Entity

Ontology

No. of properties Size of vocabulary Depth of inheritance

Ontology

Entropy of graph

Ontology

Class in degree Class out degree Number of Fanout Fanout of root class No. of root classes No. of leaf classes Average depth of inheritance

Class

Ontology

Ontology Ontology Ontology Class Ontology Ontology Ontology

Reference

Orme et al. (2007) Orme et al. (2007) Zhang et al. (2010)[33] Zhang et al. (2010)[33] Doran et al. (2008)[36][37 ] Zhang et al. (2010)[33] Zhang et al. (2010)[33] Orme et al. (2007) Orme et al. (2007) Yao et al. (2005) Yao et al. (2005) Yao et al. (2005)

Objective

Acronym

Metric

Entity

to build it efficiently. In contrast, Knowledge Architect has to know ontologies on a macro level. Knowledge Architect has to not only analyze a large set of ontologies quickly, but also he has to identify and fix any problems and issues that will lead to future issues. Following sections describes a set of software insights and architectural analysis techniques that will have a great impact on ontology building, evolution, evaluation, and review process.

Reference

tree NOP

No. of ontology partitions

Partition

Ma et al. (2010)[28]

NMIS

No. of minimal inconsistent subsets

Partition

Ma et al. (2010)[28]

Partition

Ma et al. (2010)[28]

Compone nt

Tartir et al. (2005)[32]

Instance

Tartir et al. (2005)[32]

Ontology

Orme et al. (2006)

Ontology

Orme et al. (2006)

Ontology

Orme et al. (2006)

AVAI

Coh

Connecti vity

NEC

Coupling

REC

RI

VI.

Average value of axiom inconsistencie s No. of separate connected components in the instances No. of relationships between instances No. of external classes Reference to external classes Reference includes

A. Kiviat Matrix Graph Many times, it takes more than one metric to understand, evaluate or control a software product, process, service or project. One way to show a summary view of a set of metrics is to use a Kiviat chart, also called a polar graph, radar chart or spider chart [39]. Kiviat charts are versatile graphical display tool, which presents different metrics against maximum & minimum benchmarks (Figure 5, Figure 6).

SOFTWARE ARCHITECTURAL METRICS FOR SUSTAINABLE LARGE ONTOLOGIES

Knowledge Architect has to have tools to analyze the quality of ontologies generated in cooperation quickly. These tools should provide him with a set of metrics and charts that let him know which parts of the ontology has problems, how to enhance some other regions, what is the complexity and memory consumption in case anyone wishes to traverse this ontology with inference engine and so on. Also, knowledge expert has another pain to assimilate and understand large set of ontologies neither he was a member of its cooperation teams, nor he is not a member of its Nexus teams. Some techniques and tools are developed over time at software engineering to perform applications diagnostics and to visualize large code bases to understand its specs without digging down to small pieces of code and waste much time to form a complete imagination about code quality. As example, the Design Structure Matrix (DSM) (also referred to as, dependency structure matrix, dependency structure method, dependency source matrix, problem-solving matrix (PSM), incidence matrix and N2 matrix) is a simple, compact and visual representation of a system in the form of a square matrix [38]. These tools can be easily transferred to Ontology Engineering to let Knowledge Architect understands and assimilates a large set of ontologies quickly. Ontology developers know ontologies on a micro level and know how

Figure 5. Kiviat charts representation for software metrics.

When applying this architectural representation to Large Ontologies or Ontologies that are built in cooperation between teams, any knowledge architect will have detailed information about Ontology state and all of the ontology metrics problems. One more excellent step is to combine this chart with previous ontology versions controlled by source control system. Therefore, KA will have a visualization of timedependent, multivariate data sets for the ontology over ontology evolution age. Also, we will have a history of each ontology matrix that enables us to figure out when exactly some ontology matrix had a problem or when some matrix started the deviation of the standard known values for the specific matrix. Following diagram (Figure 7) explains 3D Kiviat Chart using Andreas and Ilir tools [40]. Andreas and Ilir [40] presented an interactive visualization approach for the analysis of software's metric trends that allows end users to deal with Kiviat diagrams on 2D planes in the space and to intuitively extends this visual representation into 3D if needed.

64

All of the discussed ontology metrics can be represented as a heat map. Once Knowledge Architect have a look at a heat map of specific ontology matrix, they can figure out quickly which parts have problems. This is a handy and helpful tool especially in a case of large ontologies or in a case of ontologies that are evolving continually in cooperation. C. Size and Complexity Pyramid The purpose of the size and complexity pyramid (also known as Overview Pyramid) is to provide a high-level overview of any system. It does this by gathering in one place some of the most important measurements of a software system (Size and Complexity, Coupling and Inheritance). The left part describes the Size and Complexity. The right part describes the System Coupling. The top part describes the inheritance usage [2], [41]. Figure 6. Spider chart represents software metrics for mobile application.

B. Heat Map A heat map (Figure 8) is a graphical representation of data where the individual values contained in a matrix are represented as colors.

Figure 9. Using colors to interpret the Overview Pyramid. BLUE means a low.

The basic idea behind the Overview Pyramid is to put together in one place the most important measurements of an object-oriented system so that an engineer can see and interpret in one shot everything that is needed to get a first impression of the system. D. Polymetric Views A Polymetric view or X-Ray is a metrics-enriched visualization of software entities and their relationships [2]. Their major advantage is that they can visually render numbers in a simple, yet efficient and highly condensed way that is directly interpretable by the viewer. A lightweight technique can be easily implemented into any development environments and has already been adopted by some research prototypes because of its simplicity.

Figure 7. A gradient helps the user to determine the directions.

Figure 10. The principles of a polymetric view.

Figure 8. Heat map sample for some application

65

x

The Polymetric view uses rectangles to display software entities or abstractions of them and uses edges to represent relationships between entities. This is a commonly used practice in information visualization and software visualization tools. This basic visualization technique can be enriched by rendering four metric measurements on a single node and two metrics on a single edge simultaneously, as we see in Figure 10. The strongest point of Polymetric views is that they can combine multiple metrics and produce different colored shapes that can be interpreted by the viewer: The viewer then has to look out for certain visual symptoms (depending on the view) and can thus visually detect interesting and disharmonious parts in the system.

The Number of Methods is mapped on the height of the buildings. x The Number of Attributes on the base size. x The Number of Lines of Code on the color of the buildings. CodeCity uses colors from dark gray (low) to intense blue (high) to visualize values of metrics entries. A new version of CodeCity provides more colored views called disharmony map (Figure 13).

Figure 13. Example of disharmony map. Figure 11. System Complexity view.

E. Code City CodeCity is an integrated tool for software analysis, in which software systems are visualized as interactive, navigable 3D cities [42]. The packages are represented as the districts in which the buildings reside, while classes are represented as buildings in the city. The visible characteristics of the city artifacts depict a set of chosen software metrics, as in the Polymetric views [2] of CodeCrawler [43].

The visualization allows us to easily see some patterns such as the two massive buildings (potential crosscutting classes or shared classes that are a bad design model), some antenna-shaped constructs, some classes looking like parking lots, in addition to a large number of small houses. The visualization is interactive and navigable using the keyboard. It is easy to zoom in on details of the city or to focus on one specific district. Another advantage is that using this visualization, system's versions can be compared to each other to get to know exactly which the ball of mud start to enlarge and the system loses its performance.

Figure 12. Code city sample.

Figure 14. Coarse-grained time travel through the history of the system.

In Figure 12 you can see a visualization of a system produced by CodeCity. CodeCity has developed and explored some approaches to comprehending software systems, to analyze and understand their evolution, and to display design problems [42], [44]–[47]. Similar to the Polymetric view approach, CodeCity maps a set of software metrics on the visual properties of artifacts.

Figure 14 explains how the system and in our case ontology is evolved from time to time. Therefore, any knowledge engineer or knowledge architect will have quick eyes on ontology state between different versions and to handle any issues as soon as possible. F. Toxicity Chart

66

Toxicity chart is a great technique to quickly get an idea of the general quality of a large existing code base. It is instrumental in helping managers and non-developers understand the internal quality of the code [2]. In a toxicity chart, each bar reflects a class, and the height of the bar reflects the toxicity score for that class. The score is based on many metrics, and the higher the score, the more toxic the class. The individual components of the score are colored. This makes it possible to see at a glance not only how toxic a code is but also how the problems are distributed. If there is a lot of orange and purple in the chart, this means long and complex methods, which indicates that the code is probably hard to test on a unit level.

Figure 16. Sample dependency structure matrix.

Figure 17 and Figure 18 describes examples for graph based DSM.

Figure 15. Toxicity chart sample.

The calculation of the toxicity score is based on a set of metrics and threshold for each metric. G. Dependency Graph All previously mentioned tools in addition to many other traditional tools like (Gantt, CPM, PERT, and IDEF methods, e.g. see [48]) do not address problems stemming from system complexity. They allow software engineers to model sequential and parallel components but not interdependent components, where a set of elements are dependent on one another. The Dependency and Structure Modeling (DSM) (also referred to as dependency graph) provides this representation capability straightforwardly and elegantly. DSM offers network modeling environment that represent the elements of a system and their interactions, thereby highlighting the system’s architecture (or designed structure). DSM methods (matrix-based and graph based) have proven to be very valuable in understanding, designing, and optimizing complex system architectures [38].

Figure 17. Graph-based DSM sample.

Another interesting representation is by using circular graphs. Circular graphs are visualizing data and information in a circular layout; this makes circular graphs ideal for exploring relationships between objects or positions. Circos [49]–[52] is a sample software package for circular graphs. It is creating publication-quality infographics and illustrations with a high data-to-ink ratio, richly layered data, and pleasant symmetries. Figure 19 and Figure 20 shows samples for Circos output DSM. Although Circos is originally designed for visualizing genomic data, it is used to create figures from data in any other fields—from genomics to visualizing migration to mathematical art. Figure 21 explains the relation between normal graph representation and circular graph representation.

67

Figure 21. Comparison between graphs.

VII. CASE STUDY This section will describe briefly specific scenarios that we encountered in a collaborative project, which members work in close collaboration with the Protégé group. This project focuses on developing an ontology in the interorganizational domain and thus represents a scenario that occurs when domain experts develop ontology collaboratively. Tasleem IT Systems 1 provides technology solutions for organizations and governments sections. In one of our projects, we have developed an ontology for Enterprise Architecture of Ministry of Labors (MoL), Ministry of Interiors (MoI) and Ministry of Foreign Affairs (MoFA) using Protégé. There are almost 20 editors involved in ontology development per each Ministry. These editors use a client–server version of Protégé. At first, the ontology resides on a central server that all editors access remotely. Changes made by one user are directly visible to everyone. Therefore, there is no separate conflict-resolution stage or maintenance of various archived versions. Teams regularly publish baseline versions of the Thesaurus along with a Web Services enables users to access the Thesaurus. Intermediate versions between the baselines are dedicated for internal editing only. Based on this scenario, many issues happened to manage teams' daily tasks, teams' progress, teams' conflicts, ontology versions and history, manage collaborative ontology tools, and control ontology inconsistency happened because all editors directly access the central ontology. As Knowledge Architects, we decided to use Scrum and Nexus frameworks to manage the whole teams and teams' tasks. We applied all techniques mentioned at previous sections to solve all problems we faced. We had Scrum teams, integration team, regular sprints, sprints tasks, daily meetings, retrospective and so on [5]. In addition, we started to develop a new tool or a plugin integrates with Protégé called (OntoHealthMonitor) to analyze the developed or evolved ontologies. This tool will include all of the previously mentioned visualizations along with flexible configuration board to configure which metrics to be applied on ontology and will be presented on which

Figure 18. Graph-based DSM sample.

Figure 19. Circos circular graph sample.

Figure 20. Circos circular graph sample. 1

68

http://tasleem-it.com/

visualization technique. Moreover, OntoHealthMonitor will use flexible software architecture to easily integrate more new metrics plugins into the tool dynamically without the need to modify OntoHealthMonitor source code to support those new metrics. The main advantage of this tool is that it provides all metrics and visualizations in a very tightly integrated product. Hence, it overcomes all of the problems mentioned above. Meanwhile, we currently calculate and visualize the most common metrics and visualizations manually using MS Excel 2016 until we finish the development of that plugin.

[11] M. Paasivaara and C. Lassenius, “Scaling Scrum in a Large Distributed Project,” 2011 Int. Symp. Empir. Softw. Eng. Meas., pp. 363–367, 2011. [12] Microsoft, “Application Lifecycle Management with Visual Studio Team Foundation Server,” Microsoft, 2017. [Online]. Available: https://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.120).aspx. [13] B. Harrys, “Team Foundation Server 2010 Key Concepts,” Brian Harris’s blog. 2009. [14] J. McCullough, “Getting Started with Git,” RefCardz, pp. 1–6, 2010. [15] L. Vogel, “Git version control with Eclipse (EGit) - Tutorial,” www.vogella.com, 2016. [Online]. Available: http://www.vogella.com/tutorials/EclipseGit/article.html. [16] Y. Perez-Riverol et al., “Ten Simple Rules for Taking Advantage of Git and GitHub,” PLoS Computational Biology, vol. 12, no. 7, 2016. [17] D. Spinellis, “Git,” Software, IEEE, vol. 29, no. 3, pp. 100–101, 2012. [18] V. Mahnic, “A case study on agile estimating and planning using scrum,” Elektronika ir Elektrotechnika, no. 5. pp. 123–128, 2011. [19] P. Owner et al., “Scrum ( software development ),” Wikipedia, 2015. . [20] J. Bowes, “Scrum in practice: sprint zero,” MANIFESTO, 2014. [Online]. Available: https://manifesto.co.uk/scrum-practice-sprintzero/. [21] K. S. Rubin, “Scrum Framework,” Essent. Scrum A Pract. Guid. to Most Pop. Agil. Process, pp. 13–28, 2012. [22] R. C. Lee, “The Success Factors of Running Scrum: A Qualitative Perspective,” J. Softw. Eng. Appl., vol. 5, no. 6, pp. 367–374, 2012. [23] K. Schwaber and J. Sutherland, “The Scrum Guide,” Scrum.Org and ScrumInc, no. July, p. 17, 2013. [24] S. Oh, H. Y. Yeom, and J. Ahn, “Cohesion and coupling metrics for ontology modules,” Inf. Technol. Manag., vol. 12, no. 2, pp. 81–96, 2011. [25] M. Hitz and B. Montazeri, “Chidamber and Kemerer’ s Metrics Suite: A Measurement Theory Perspective,” IEEE Trans. Softw. Eng., vol. 22, no. 4, pp. 267–271, 1996. [26] G. Succi, W. Pedrycz, S. Djokic, P. Zuliani, and B. Russo, “An empirical exploration of the distributions of the Chidamber and Kemerer object-oriented metrics suite,” Empir. Softw. Eng., vol. 10, no. 1, pp. 81–103, 2005. [27] L. Cheikhi, R. E. Al-Qutaish, A. Idri, and A. Sellami, “Chidamber and kemerer object-oriented measures: Analysis of their design from the metrology perspective,” Int. J. Softw. Eng. its Appl., vol. 8, no. 2, pp. 359–374, 2014. [28] Y. Ma, B. Jin, and Y. Feng, “Semantic oriented ontology cohesion metrics for ontology-based systems,” J. Syst. Softw., vol. 83, no. 1, pp. 143–152, 2010. [29] A. Lozano-Tello and A. Gómez-Pérez, “Ontometric: A method to choose the appropriate ontology,” J. Database Manag., vol. 2, no. 15, pp. 1–18, 2004. [30] S. Oh and H. Y. Yeom, “A comprehensive framework for the evaluation of ontology modularization,” Expert Syst. Appl., vol. 39, no. 10, pp. 8547–8556, 2012. [31] N. Noy and M. Musen, “Specifying ontology views by traversal,” Semant. Web–ISWC 2004, pp. 713–725, 2004. [32] S. Tartir, I. Arpinar, M. Moore, a Sheth, and B. Aleman-Meza, “OntoQA: Metric-Based Ontology Quality Analysis,” IEEE Work. Knowl. Acquis. from Distrib. Auton. Semant. Heterog. Data Knowl. Sources, pp. 45–53, 2005. [33] Z. Yang, D. Zhang, and C. Ye, “Evaluation metrics for ontology complexity and evolution analysis,” in Proceedings - IEEE International Conference on e-Business Engineering, ICEBE 2006, 2006, pp. 162–169. [34] S. Oh and J. Ahn, “Ontology module metrics,” in Proceedings - IEEE International Conference on e-Business Engineering, ICEBE 2009; IEEE Int. Workshops - AiR 2009; SOAIC 2009; SOKMBI 2009; ASOC 2009, 2009, pp. 11–18.

VIII. CONCLUSION This paper discussed a set of cooperative Scrum based software metrics and architectural metrics that can be applied to cooperative ontology development and evolution process using Scrum framework to control and measure ontologies in general and inter-organizational ontologies in special. These set of metrics ids necessary to evaluate ontologies during cooperative development and evolution processes. We proposed these set of metrics to help improve cooperative teams' performance and improve the quality of development and evolution process of inter-organizational ontologies. Furthermore, most of these metrics can be applied easily to any daily ontology activities to ensure ontology reliability, maintainability, and usability. A new under development Protégé plugin called (OntoHealthMonitor) will analyze the ontologies. This tool will include all of the mentioned visualizations along with flexible configuration board to configure which metrics to be applied on ontology and will be presented on which visualization technique. REFERENCES [1]

K. Nishizono, S. Morisaki, R. Vivanco, and K. Matsumoto, “Source code comprehension strategies and metrics to predict comprehension effort in software maintenance and evolution tasks - An empirical study with industry practitioners,” in IEEE International Conference on Software Maintenance, ICSM, 2011, pp. 473–481. [2] M. Lanza, R. Marinescu, and O. M. Practice, Object-Oriented Metrics in Practice. 2006. [3] J. Sutherland, “Scrum.org | The home of Scrum,” scrum.org, 2015. [Online]. Available: http://www.scrum.org/. [4] K. Schwaber and J. Sutherland, “The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game,” 2011. [5] M. A. and K. E. Wa’el Mohsen, “The Scrum Framework for Cooperative Ontology Evolution,” 2017. [6] R. Djedidi and M.-A. Aufaure, “Ontology Evolution: State of the Art and Future Directions,” Ontol. Theory, Manag. Des. Adv. Tools Model., vol. 7, pp. 179–207, 2010. [7] R. Djedidi and M.-A. Aufaure, “Ontology Evolution: State of the Art and Future Directions,” Ontol. Theory, Manag. Des. Adv. Tools Model., p. 179, 2010. [8] P. De Leenheer and T. Mens, “Ontology evolution: State of the Art and Future Directions,” in Ontology Management for the Semantic Web Semantic Web Services and Business Applications from Semantic Web and Beyond Computing for Human Experience, vol. 2, 2008, pp. 1–47. [9] ScrumAlliance, “Scrum Alliance,” 14112011, 2011. [Online]. Available: http://www.scrumalliance.org/pages/what_is_scrum. [10] R. Brenner and S. Wunder, “Scaled Agile Framework: Presentation and real world example,” 2015 IEEE Eighth Int. Conf. Softw. Testing, Verif. Valid. Work., pp. 1–2, 2015.

69

[45] R. Wettel and M. Lanza, “Visual exploration of large-scale system evolution,” in Proceedings - Working Conference on Reverse Engineering, WCRE, 2008, pp. 219–228. [46] R. Wettel, “Visual exploration of large-scale evolving software,” in 2009 31st International Conference on Software Engineering Companion Volume, ICSE 2009, 2009, pp. 391–394. [47] S. Alam, S. Boccuzzo, R. Wettel, P. Dugerdil, H. Gall, and M. Lanza, “EvoSpaces - Multi-dimensional navigation spaces for software evolution,” in Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2009, vol. 5440 LNCS, pp. 167–192. [48] A. Yassine and D. Braha, “Complex Concurrent Engineering and the Design Structure Matrix Method,” Concurr. Eng., vol. 11, no. 3, pp. 165–176, 2003. [49] W. H. Cheong, Y. C. Tan, S. J. Yap, and K. P. Ng, “ClicO FS: An interactive web-based service of Circos,” Bioinformatics, vol. 31, no. 22, pp. 3685–3687, 2015. [50] J. An, J. Lai, A. Sajjanhar, J. Batra, C. Wang, and C. C. Nelson, “JCircos: An interactive Circos plotter,” Bioinformatics, vol. 31, no. 9, pp. 1463–1465, 2015. [51] M. Krzywinski et al., “Circos: An information aesthetic for comparative genomics,” Genome Res., vol. 19, no. 9, pp. 1639–1645, 2009. [52] N. Darzentas, “Circoletto: Visualizing sequence similarity with Circos,” Bioinformatics, vol. 26, no. 20, pp. 2620–2621, 2010.

[35] A. M. Orme, H. Yao, and L. H. Etzkorn, “Coupling metrics for ontology-based systems,” IEEE Softw., vol. 23, no. 2, pp. 102–108, 2006. [36] M. D’Aquin, P. Doran, E. Motta, and V. Tamma, “Towards a parametric ontology modularization framework based on graph transformation,” in CEUR Workshop Proceedings, 2007, vol. 315. [37] P. Doran, V. Tamma, and L. Iannone, “Ontology Module Extraction for Ontology Reuse: An Ontology Engineering Perspective,” Proc. 16th ACM Conf. Inf. Knowl. Manag., pp. 61–70, 2007. [38] S. D. Eppinger and T. R. Browning, “Design Structure Matrix Methods and Applications,” MIT Press Books, vol. 1, 2012. [39] Wikipedia, “Radar chart,” 2016. [Online]. Available: https://en.wikipedia.org/wiki/Radar_chart. [40] A. Kerren and I. Jusufi, “3D kiviat diagrams for the interactive analysis of software metric trends,” Proc. 5th Int. Symp. Softw. Vis., pp. 203–204, 2010. [41] M. Lanza and R. Marinescu, Object-oriented metrics in practice: Using software metrics to characterize, evaluate, and improve the design of object-oriented systems. 2006. [42] R. Wettel, M. Lanza, and R. Robbes, “Software systems as cities: a controlled experiment,” 2011 33rd Int. Conf. Softw. Eng., pp. 551– 560, 2011. [43] M. Lanza, “CodeCrawler-lessons learned in building a software visualization tool,” in Proceedings of the European Conference on Software Maintenance and Reengineering, CSMR, 2003, pp. 409–418. [44] R. Wettel and M. Lanza, “Program comprehension through software habitability,” in IEEE International Conference on Program Comprehension, 2007, pp. 231–240.

70