Design and Development of Ontology Suite for Software Risk Planning, Software Risk Tracking and Software Risk Control

,


INTRODUCTION
A teacher as the main knowledge provider can preserve the high quality of the knowledge taught, if the knowledge is created in the reusable and sharable form. From an Artificial Intelligence perspective, the knowledge engineering and knowledge representation communities concerned with knowledge elicitation methodologies and the formal notation used to represent knowledge and have dedicated little effort to visualization. Software Risk Management Ontology (SRMONTO) defines common sharable software risk management knowledge. SRMONTO basically provides software risk management concepts-what they are, how they are related and can be related to one another-for representing and communicating over software risk management knowledge. These concepts are widely accepted, thereby facilitating common understanding of the software risk management knowledge by all distributed members. This enables effective ways of sharing and reusing the knowledge for the learner of software risk management. SRMONTO can even assist software engineers to better understand the information. On the other side it creates a better awareness about software risk management among computer science graduates who have been taught the subject. Reaching a harmony of understanding is of benefit to team members in a distributed environment. Ultimately, machines in the form of e-learning applications or software agents provide semantic enabled web service for software risk management; can use the knowledge as well. The common software risk management knowledge is semantically shared not only among software engineers, but also among computer based learning systems or software agents.
Building and maintaining software is a risky business (Boehm, 1989). It is the responsibility of the academicians to create awareness among the students about Software Risk Management (SRM). In order to create more meaningful and effective teaching strategies as there is no predefined way to teach SRM, a formal ontology base knowledge base is required. The advantage of the ontology is that it attempts to unify different views on the domain. Knowledge sharing through the software risk management ontology eliminates misunderstandings, miscommunications and misinterpretations. Software risk management ontology presents explicit assumptions concerning the objects referring to the domain knowledge. A set of objects and interrelations and their constraints renders their agreed meanings and properties. SRMONTO consists of Software Risk Identification Ontology, Software Risk Analysis Ontology, Software Risk Planning Ontology, Software Risk Controlling Ontology and Software Risk Tracking Ontology. The authors have developed all the five ontologies and the former two ontologies have been addressed in (Robin and Uma, 2011). The Semantic representation of SRMONTO is described in (Robin and Uma, 2010). The semantic representation of a general ontology is addressed in (Mustapha et al., 2010). This study aims to present rest of the three ontolgies such as Software Risk Planning Ontology (SRP ONTO), Software Risk Controlling Ontology (SRC ONTO) and Software Risk Tracking Ontology (SRT ONTO). Its end users are software engineers sharing software risk management domain knowledge as well as learners of software risk management such as teachers and students.
Related work: Software Risk Management (Boehm, 1989) is a discipline whose objectives are to identify, address and eliminate software risk items before they become either threats to successful software operation or major sources of expensive software rework. This work uses, risk management paradigm introduced by Software Engineering Institute as our standard to construct the sub ontologies for the target ontology i.e. software risk management ontology. Risk is omnipresent in each and every step of the software development and all the interactions that software developers carry out. Software development project risk management (Fairley, 2002) should focus on reduction and prevention of risks, continuously assess possible problems, define potential risks, determine what risks are important and deal with them. So a whole project picture is required for successful risk management.
In both computer science and information science, an ontology (Shareha et al., 2009) is a data model that represents a set of concepts within a domain and the relationships between those concepts. Basically an ontology (Noy and McGuinness, 2001;Niles and Pease, 2001) defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions (semantics) of basic concepts in the domain and relations among them. Classes are the focus of most ontologies. Classes describe concepts in the domain. A class can have subclasses that represent concepts that are more specific than the superclass. Slots describe properties of classes and instances. So developing an ontology includes defining classes in the ontology, arranging the classes in a taxonomic hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances (Corcho et al., 2006). Despite efforts and experience in developing ontologies, there is no agreement on a methodology for building ontologies. The ontology development methodology problem has been investigated in several projects. First attempt was by Gruber (1995) that specifies some principles and criteria for the design of ontologies. We can create a knowledge base by defining individual instances of these classes filling in specific slot value information and additional slot restrictions.
Ontologies can be represented using various methods, in XML (Haw and Lee, 2008), RDF (Brickley and Guha, 2004), OWL (Mousavi et al., 2010), (Al-Safadi and Al-Abdullatif, 2010) with Topic Maps. However, these are text-based and usually rather voluminous. In addition, ontologies can also be visualized using UML (Muhairat et al., 2010), hyperbolic view, or as a tree, In Mobile Workforce Brokering System (Mousavi et al., 2010), the entire domain knowledge is represented semantically using OWL ontology is considered as one of the best examples of OWL ontologies by the authors.
The Protégé project (Musen, 1989a;1989b;Gennari, 2003) has come a long way since Mark Musen first built the Protégé meta tool for knowledge-based systems in 1987. Protégé is a flexible, well-supported and robust development environment. Using Protégé, developers and domain experts can easily build effective knowledge-based systems and researchers can explore ideas in a variety of knowledge-based domains.
Visualization (Katifori et al., 2007) is becoming increasingly important in Semantic Web tools. OWLViz is designed to be used with the Protege OWL plugin. OWLViz integrates with the Protege-OWL plugin, using the same colour scheme so that primitive and defined classes can be distinguished, computed changes to the class hierarchy may be clearly seen and inconsistent concepts are highlighted in red. OWLViz has the facility to save both the asserted and inferred views of the class hierarchy to various concrete graphics formats including png, jpeg and svg. It is used to visualize light-weight ontologies that describe a domain through a set of classes (concepts) and their hierarchical relationships. Also known as taxonomies, such ontologies are frequently used in several domains as classification systems.

MATERIALS AND METHODS
Design architecture of ontologies: Tracking consists of monitoring the status of risks and actions taken to ameliorate risks. Figure 1 shows the design architecture of software risk tracking ontology. In Risk Tracking Ontology there are four properties such as "PartOf", "IsA", "Tracks" and "Has" used to relate the identified concepts. "RiskTracking" concept is at the highest level of the this ontology. Since Risk Manager will do the actual tracking work, "tracks" relationship is used to relate Risk_Manager concept is related with its parent concept "Risk_Tracking".
The goal of risk control is to decide which risk control activities are necessary to take. Figure 3 shows the design architecture of software risk control ontology. In the Software Risk Control Ontology "Risk_Controlling" concept is at top level. It has five subclasses such as Risk_Avoidance, No_Risk_Reducing_Action, Contingency_Plan, Reduce_Loss and Reduce_Event_Probability. All the subclasses are related with main concept by "isA" relationship. In this ontology we used three distinct type of properties such as "isA", "typeOf" and "usedTo". Hence N(Property) is three. Figure 4 shows the ontology construction process using Protégé. At the left hand side the hierarchal arrangement of risk identification ontology is displayed. When the required concept is highlighted, its semantic, properties and all the other attributes will be displayed at the right side of the editor.

Development of ontologies using protégé:
Sir Jorge Cardoso carried a survey on most widely used ontology editors and most widely used domain for ontology development and found that Protégé tool, an effective tool for ontology engineering (Malik et al., 2010) In this study Protégé is used to construct the target ontologies such as SRP ONTO, SRT ONTO and SRC ONTO. It is good to have our ontologies in OWL format to access description logic reasoned and to acquire instances for semantic markup. Figure 5 shows the part of software risk control ontology in OWL format.

Visualization of ontology using ONTOVIZ:
The OntoViz Tab configured in protégé tool is used to visualize SRMONTO with the help of a highly sophisticated graph visualization software called Graphviz. The types of visualizations are highly configurable and include picking a set of classes or instances to visualize part of an ontology, displaying slots and slot edges, specifying colors for nodes and edges and when picking only a few classes or instances, you can apply various closure operators (e.g., subclasses, superclasses) to visualize their vicinity. In Fig. 6-8, the constructed ontologies such as software risk planning ontology, software risk tracking ontology and software risk controlling ontology are visualized using protégé editor. The visualizations are captured by OntoViz embedded in Protégé. The entire portion of the visualized ontology can be stored as image files by specifying the required path. The Fig. 9-11 show the visual representation of the three ontologies.

RESULTS
The metrics used for quantitative evaluation (Vijay and Manoharan, 2009), (Longo and Oreste, 2010), are classified into four categories such as class metrics property metrics ratio metrics and axiom metrics. Each category has a set of parameters. Table 1 shows the results of quantitative analysis made for class metrics. Similarly the results for property metrics, ratio metrics and axiom metrics are shown in Table 2-4 respectively.     The constructed ontology suite is compared with three existing educational ontologies such as Cryptography Ontology (Takahashi et al., 2005), Software Testing Ontology (Zhu and Huo, 2004) and E-R Model Ontology (Boyce and Pahl, 2007). The comparison result of SRIONTO with above said educational ontologies is presented in Table 5.

DISCUSSION
The statistical analysis says SRP ONTO has concepts four times than the number of its properties. SRT ONTO has the number of concepts more than three times higher than the number of its properties. Similarly SRC ONTO has the number of concepts more than five times higher than the number of its properties. Hence in the resultant ontology, NoC will be higher than NoP and is presumed to be a concept oriented ontology.
The concept and property analysis shown in Fig. 12 says SRP ONTO has concepts five times than its number of properties, SRT ONTO has concepts six times than the number of its properties and SRC ONTO has concepts thirteen times than its number of properties. Since in all cases, NoC is higher than NoP,  Figure 13 shows the analysis of ratio metrics. The reusability ratio of the constructed ontologies is linear because all the sub ontologies have the reuse ratio more that 95%. It shows that the constructed ontologies are highly cohesive.
The cohesion metrics (Yao et al., 2005) examine the fundamental quality of cohesion as it relates to ontologies.
The following inferences have been made from the comparison presented in Table 5. The number of classes, subclasses and superclasses of the developed ontology suite is considerably higher than the existing educational ontologies. The developed ontology suite has a higher level of reusability than the existing three educational ontologies taken for comparison. Finally, it makes better use of specialization of its classes, indicated by its higher specialization ratio.

CONCLUSION
The complex, abstract and interrelated contents yet represented verbally are transformed into visual representations through the proposed work. It includes design, development and visualization of three sub ontologies of SRMONTO which serves as the knowledge repository of software risk management. The ontology suite has been constructed based on the information available in the literature and the experience of various software developers. The main objective of this ontology suite is to use it as a content ontology to express formal domain model in e-learning to teach software risk management subject. The general e-learning system is discuss in (Jabr and Omari, 2010). As the knowledge representation mechanism this ontology suite facilitates visualizing intellectual structures based on widely available sources and augments knowledge visualization approaches that focus on documents and concepts. Users can use this visual representation to discover patterns and make valuable connections between data. In another follow on study we will describe the creation of a student interface for an educational system that is one of the authors' primary goals. The identified metrics are categorized into class metrics, property metrics, ratio metrics and axiom metrics. The reusability of each sub ontology is calculated separately and found that the ontology is ready to use for the intended applications.