application of formal concept analysis

ISSN: 2278 7798

International Journal of Science, Engineering and Technology Research (IJSETR)

Volume 2, Issue 1, January 2013

220 All Rights Reserved 2013 IJSETR

Abstract Risk Matrix is a matrix that is used during Risk

Assessment to define the various levels of risk as the product of

the harm probability categories and harm severity categories.

This is a simple mechanism to increase visibility of risks and

assist management decision making. Risk matrix is presented

for use in identifying and assessing project risks quickly and

cost effectively. It assists project managers with few resources

to perform project risk analysis. Risk matrix (GRM) contains a

broad set of risks that are categorized and ranked according to

their potential impact and probability of occurrence. The

matrix assists PMs in quickly identifying risks and can serve as

a basis for contingency planning to minimize cost and schedule

overruns. But how risks are related and visualized at various

phases becomes very difficult to be seen as the activity becomes

many and complex with software projects.

Formal Concept Analysis (FCA) has typically been applied in

the eld of software engineering to support software

maintenance and object-oriented class identication tasks. This

paper proposes a new evaluation, analysis and visualization of

the Assessment Evaluation of Risks Matrix in software

engineering based on Formal Concept Analysis, or Galois

Lattices, a data analysis technique grounded on Lattice Theory

and Propositional Calculus. This method considered the set of

common and distinct attributes of risks levels assessment in

such a way that categorization are done based on risk types.

This will help in building a more defined and conceptual

systems for Evaluation of risk Levels that can easily be

visualized in software engineering projects.

Index Terms Formal Concept Analysis, Risk Matrix,

Software engineering, Projects.

I. INTRODUCTION

The ability of any industry survive is driven by the

successful nature of projects that are engineered on board.

However, the success of any project depends on several

influencing areas, which require reliable and regular attention

by the project manager. Some of these areas are schedule

management, finance management, change management,

conflict management, etc. It is important to understand that

each of the abovementioned areas come into view as risk if

not managed in righteous way.

Risk is a probability for occurrence of an unlikely event,

which would result with highly unacceptable consequences.

Software acquisition and development are two of the most

risk prone challenges of this decade. Risk factors are always

Quist-Aphetsi Kester, Faculty of Informatics, Ghana Technology

University College, Accra, Ghana, +233 209822141

present that can negatively impact the development,

acquisition, or maintenance processes. If neglected, these

factors can tumble an unwitting program manager into

acquisition disaster. To succeed in software acquisitions and

development, one need to actively assess, control, and reduce

software risk on a routine basis [1].

In order to avoid risks within a project, an organized,

systematic decision-making process that efficiently identifies

risks, assesses or analyzes risks, tracks and communicates

risk and effectively reduces or eliminates risks is vital and

needed within every project. Thus, risk management is one of

the critical issues that need to be addressed in a skillful and

efficient manner in every project. It is therefore necessary to

take precautionary procedures to reduce the probability of

risk occurrences and to minimize its impact in realizing

effective project management.

The procedures taken in effective management of risk have

to start with the identification of risks and classification of

risks into different categories. Afterwards, every classified

risk has to be assessed with impact level, its probability of

occurrence and frequency of occurrence that enables one to

prioritize according to their severity. The methodical analysis

of risk aids project personnel in achieving an accurate

analytical estimation of the appropriate choice of process and

resources in the project.

Hooman Hoodat and Hassan Rashidi recommend the

classification of every identified risk in a risk based tree

structure in order to assess and resolve them efficiently. They

suggest probabilistic calculation approach for qualitative and

quantitative analysis and assessment of these risks [2]. On

the other hand, visualization of these risks and identification

of related risk in phases and tasks of projects needed to be

considered.

Formal Concept Analysis (FCA) is a mathematical theory

of data analysis using formal contexts and concept lattices.

[3]. It is a principled way of deriving a concept hierarchy or

formal ontology from a collection of objects and their

properties. Each concept in the hierarchy represents the set of

objects sharing the same values for a certain set of properties;

and each sub-concept in the hierarchy contains a subset of the

objects in the concepts above it [4] Its range of applications

can be found in information and knowledge processing

including visualization, data analysis and knowledge

management

This paper proposes a new classification of risk,

evaluation, analysis and as well as visualization of the

Application of Formal Concept Analysis to

Visualization of the Evaluation of Risks Matrix

in Software Engineering Projects

Quist-Aphetsi Kester

ISSN: 2278 7798




assessment evaluation of Risks Matrix in software

engineering based on Formal Concept Analysis, or Galois

Lattices, a data analysis technique grounded on Lattice

Theory and Propositional Calculus. This method will

consider the set of common and distinct attributes of risks

levels assessment in such a way that categorization are done

based on risk types.

The organization of this paper is as follows, section II of

this paper provides details of the related work in the domain

of risk management and application of FCA in software

engineering. Section III proposes how the FCA will be used

to classify and analyze risk. Section IV provides application

and results: provides matrix representation and using FCA to

analyze of the risk assessment. The last section of this paper,

section V, Concludes the paper.

II. RELATED WORKS

Ever since the advancement of software engineering has

evolved, risk management has become one of the key

challenges in everyday software development processes.

Management of risk in software processes is needed to

minimize or eradicate risk before it can harm the productivity

of a software project. [5]

Formal risk analysis and management in software

engineering is still an emerging part of project management.

Risk management for software projects is intended to

minimize the chances of unexpected events, or more

specifically to keep all possible outcomes under tight

management control. [6]

Risk management is a systematic approach for minimizing

exposure to potential losses. It provides a disciplined

environment for

continuously assessing what could go wrong (i.e.,

assessing risks)

determining which risks to address (i.e., setting

mitigation priorities)

implementing actions to address high-priority risks

and bring those risks within tolerance

There are three core risk management activities core that

are illustrated in Figure 1:

assess risktransform the concerns people have

into distinct, tangible risks that are explicitly

documented and analyzed

plan for risk mitigationdetermine an approach

for addressing or mitigating each risk; produce a

plan for implementing the approach

mitigate riskdeal with each risk by

implementing its defined mitigation plan and

tracking the plan to completion

These three activities form the foundation of the Risk

Management Framework.

Figure 1 Risk management Activities

A Risk Matrix is a matrix that is used during Risk

Assessment to define the various levels of risk as the product

of the harm probability categories and harm severity

categories. This is a simple mechanism to increase visibility

of risks and assist management decision making.[8]

Many standard risk matrices exist in different contexts (US

DoD, NASA, ISO), [9][10][11] individual projects and

organizations may create their own or tailor an existing risk

matrix to suite their need.

The harm severity can be categorized as:

Catastrophic - Multiple Deaths

Critical - One Death or Multiple Severe Injuries

Marginal - One Severe Injury or Multiple Minor

Injuries

Negligible - One Minor Injury

The probability of harm occurring might be categorized as

'Certain', 'Likely', 'Possible', 'Unlikely' and 'Rare'. However it

must be considered that very low probabilities may not be

very reliable.

The resulting Risk Matrix could be as shown in table 1

below:

Table 1Matrix Classification of risks

Negligibl

e

Marginal Critical Catastrophi

c

Certain High High Extreme Extreme

Likely Moderate High High

Possible Low Moderate High Extreme

Unlikely Low Low Moderate Extreme

Rare Low Low Moderate High

Tony Cox argues that risk matrices experience several

problematic mathematical features making it harder to assess

risks[12]. These are:

Poor Resolution: Typical risk matrices can correctly and

unambiguously compare only a small fraction (e.g., less than

10%) of randomly selected pairs of hazards. They can assign

identical ratings to quantitatively very different risks ("range

compression").

Errors: Risk matrices can mistakenly assign higher

qualitative ratings to quantitatively smaller risks. For risks

ISSN: 2278 7798




with negatively correlated frequencies and severities, they

can be "worse than useless," leading to worse-than-random

decisions.

Suboptimal Resource Allocation: Effective allocation of

resources to risk-reducing countermeasures cannot be based

on the categories provided by risk matrices.

Ambiguous Inputs and Outputs: Categorizations of

severity cannot be made objectively for uncertain

consequences. Inputs to risk matrices (e.g., frequency and

severity categorizations) and resulting outputs (i.e., risk

ratings) require subjective interpretation, and different users

may obtain opposite ratings of the same quantitative risks. He

further suggests that risk matrices should be used with

caution, and only with careful explanations of embedded

judgments.

In the field of software engineering, Formal Concept

Analysis (FCA) has generally been applied to support

software maintenance activities the refactoring or

medication of existing code and to the identication of

object-oriented (OO) structures.

There is also a body of literature reporting the application

of FCA to the identication and maintenance of class

hierarchies in database schemata [13, 14, 15]. And also

Simon Andrew sand Simon Polovina presented an outline of

a process by which operational Software requirements

specication can be written for Formal Concept Analysis

(FCA). The Z notation was issued to specify the FCA model

and the formal operations on it. They conceive a novel

approach where by key features of Z and FCA can be

integrated and put to work in contemporary software

development, thus promoting operational specication as a

useful application of conceptual structures.[16]

Module and Object Identication with FCA: Sahraoui et

al. [17] present a method that extracts objects from

procedural code using FCA. Important concepts are looked

for in the resultant lattices using heuristics. Another approach

compares the object identication capability of clustering

and FCA techniques [18]. A few heuristics are described to

interpret the concepts of the lattice. An approach to transform

a COBOL legacy system to a distributed component system

is proposed by Canfora et al. [19]. Siff and Reps explore the

relationship between program variables and procedures

through FCA for restructuring of C programs [20].

Modern police organizations and intelligence services are

adopting the use of FCA in crime pattern analysis for tracking

down criminal suspects through the integration of

heterogeneous data sources and visualizing this information

so that a human expert can gain insight in the data [21].

III. METHODOLOGY

Formal Concept Analysis, or Galois Lattices, is a data

analysis technique grounded on Lattice Theory and

Propositional Calculus. This paper proposes a new method

based on FCA method and considered the set of objects and

attributes of risks levels assessment in such a way that

categorization are done based on risk types. The risks are first

grouped into various types with their associate probability of

occurrences. The weighted importance values provide a

quick assessment of impact and probability of each risk.

In FCA a formal context consists of a set of objects, G, a

set of attributes, M, and a relation between G and M, I G M. A formal concept is a pair (A,B) where A G and B M. Every object in A has every attribute in B. For every object in

G that is not in A, there is an attribute in B that that object

does not have. For every attribute in M that is not in B there is

an object in A that does not have that attribute. A is called the

extent of the concept and B is called the intent of the concept.

If g A and m B then (g,m) I ,or gIm. A formal context is a tripel (G,M,I), where

G is a set of objects,

M is a set of attributes

and I is a relation between G and M.

(g,m) I is read as object g has attribute m.

For A G, we define A:= {m M | g A:(g,m) I }. For B M, we define dually B:= {g G | m B:(g,m) I }.

For A, A1, A2 G holds: A1 A2 A`2 A`1 A 1 A`` A`= A```

For B, B1, B2 M holds: B1 B2 B2 B1 B B`` B`= B```

A formal concept is a pair (A, B) where

A is a set of objects (the extent of the concept),

B is a set of attributes (the intent of the concept),

A`= B and B`= A.

The concept lattice of a formal context (G, M, I) is the set of

all formal concepts of (G, M, I), together with the partial

order

(A1, B1) (A2, B2): A1 A2 ( B1 B2).

The concept lattice is denoted by (G,M,I) . Theorem: The concept lattice is a lattice, i.e. for two

concepts (A1, B1) and (A2, B2), there is always

a greatest common subconcept: (A1A2, (B1 B2) ) and a least common superconcept: ((A1 A2) , B1B2)

More general, it is even a complete lattice, i.e. the greatest

common subconcept and the least common superconcept

exist for all (finite and infinite) sets of concepts.

Corollary: The set of all concept intents of a formal context

is a closure system. The corresponding closure operator is

h(X):= X``.

An implication XY holds in a context, if every object

having all attributes in X also has all attributes in Y.

Def.: Let X M. The attributes in X are independent, if there are no trivial dependencies between them.

ISSN: 2278 7798




IV. APPLICATIONS AND RESULTS

Consider a project that involves trying to develop safety

critical software on cutting-edge hardware. The risks are

classified as follows: project (1), technical (2), business (3),

Common (4) and as Special (5) to all projects or special to

this project. The properties of the risks are listed as follows:

Hardware not available (a), Requirements incomplete (b),

Use of specialized methodologies (c), Problems achieving

required reliability (d), Retention of key people (e), Under

estimating required eorts(f), The single potential customer Goes bankrupt(g)

From the above G= {1, 2, 3, 4, 5} and M= {a, b, c, d, e, f, g}

Table 2 Matrix Classification of risks

Risk a b c d e f g

1 x x x

2 x x x

3 x

4 x x x

5 x x x x

The table one was transformed into xml code below was

written and run in Galicia, Galois Lattice builder Software.

-

0.0

-

1

2

3

4

5

-

a

b

c

d

e

f

g

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

ISSN: 2278 7798




-

-

-

Figure 2 Galois lattices of intents and extents

Figure 3 Galois lattice of (G, M, I)

The concept lattice of a formal context (G, M, I) as shown in

figure 3, is the set of all formal concepts of (G, M, I), together

with the partial order (A1, B1) (A2, B2): A1 A2 ( B1 B2). It is clearly seen visually from figure 2 as well as figure 3 that the attributes of belonging to concept & and 11

in figure 2 and concept 98 and 102 in figure 3 are subsumed

by concept 13 and 104 respectively. This means that if

business risk and common risk are present in the project

according to the example, then there exists a special risk as

well.

V. CONCLUSION

A formal concept analysis was used to evaluate and

visualize risk matrix in software engineering projects. This

method considered the set of common and distinct attributes

of risks levels assessment in such a way that categorization

was done based on risk types. This has helped in building a

more defined and conceptual systems for evaluation and

visualization of risk matrix in software engineering projects.

REFERENCES

[1] Risk Management Guide for DoD Acquisition Defense Acquisition

Management College (DSMC) Press P6-5 retrieved from

http:www.stsc.hill.af.mil/resources/tech_docs/gsam3/chap6.pdf

[2] Hooman Hoodat and Hassan Rashidi, Classification and Analysis of

Risks in Software Engineering, World Academy of Science,

Engineering and Technology 56, 2009.

[3] Formal Concept Analysis Homepage from :

http://www.upriss.org.uk/fca/fca.html

[4] Formal concept analysis retrieved from :

http://en.wikipedia.org/wiki/Formal_concept_analysis /

ISSN: 2278 7798




[5] Software Engineering. Risk Management. retrieved from :

http://openseminar.org/se/modules/21/index/screen.do

[6] Roy, G.G.; , "A risk management framework for software engineering

practice," Software Engineering Conference, 2004. Proceedings. 2004

Australian , vol., no., pp. 60- 67, 2004

[7] C. Alberts, and A. Dorofee, "Risk Management Framework," Software

Engineering Institute, Carnegie Mellon University, Pittsburgh,

Pennsylvania, Technical Report CMU/SEI-2010-TR-017, 2010.

http://www.sei.cmu.edu/library/abstracts/reports/10tr017.cfm

[8] Risk matrix retrieved from : http://en.wikipedia.org/wiki/Risk_Matrix

[9] United States Department of Defense, Risk Management Guide for DoD

Acquisition, August 2006

[10] Goddard Space Flight Center, NASA, Risk Management Reporting,

GSFC-STD-0002, 8 May 2009

[11] International Standards Organization, Space Systems Risk Management,

ISO 17666,

[12] Cox, L.A. Jr., 'What's Wrong with Risk Matrices?', Risk Analysis, Vol.

28, No. 2, 2008, doi:10.1111/j.1539-6924.2008.01030.x

[13] I. Schmitt and S. Conrad. Restructuring object-oriented database

schemata by concept analysis. In T. Polle, T. Ripke, and K.-D. Schewe,

editors, Fundamentals of Information Systems(Post-Proceedings 7th

International Workshop on Foundations of Models and Languages

forData and Objects FoMLaDO98), pages 177185, Boston, 1999.

Kluwer Academic Publish-ers.

[14] I. Schmitt and G. Saake. Merging inheritance hierarchies for database

integration. InProceedings of the 3rd International Conference on

Cooperative Information Systems(CoopIS98), New York, August

1998.

[15] H. Dicky, C. Dony, M. Huchard, and T. Libourel. ARES, adding a class

and restructuringinheritance hierarchy. In BDA : Onzi` emes Journ ees

Bases de Donn ees Avanc ees, pages 2542, 1995.

[16] ANDREWS, S. and POLOVINA, S. (2008). Operational specification for

FCA using. In: 16th International Conference on Conceptual Structures,

Toulouse, France,

[17] ]H. A. Sahraoui, H. Lounis, W. Melo ,and H.Mili. A concept formation

based approach to object identication in procedural code. Automated

Software Engineering Journal,6(4):387410,1999.

[18] A. Deursen and T. Kuipers. Identifying objects using cluster and concept

analysis. In Proceedings of ICSE99,pages246255.ACMPress,1999.

[19] U.Dekel and Y.Gil. Revealing class structure with concept lattices. In

WCRE, pages 353362. IEEE Press,Nov.2003.

[20] M.Siff and T.Reps. Identifying modules via concept analysis.

Transactions on Software Engineering,25(6):749768,Nov.1999.

[21] Security Informatics, Special issues on Formal Concept Analysis in Intelligence and Security Informatics Springer, 2012.

Quist-Aphetsi Kester: is a global award winner 2010

(First place Winner with Gold), in Canada Toronto, of

the NSBEs Consulting Design Olympiad Awards

and has been recognized as a Global Consulting

Design Engineer. He is a PhD student in Computer

Science. The PhD program is in collaboration between the

AWBC/USFC Academics Without Borders/Universitaires Sans

Frontieres (formerly AHED-Academics for Higher Education and

Development) Canada and the Department of Computer Science and

In-formation Technology (DCSIT), University of Cape Coast. He had a

Master of Software Engineering degree from the OUM, Malaysia and

BSC in Physics from the University of Cape Coast-UCC Ghana.

He has worked in various capacities as a peer reviewer for IEEE

ICAST Conference, Journal-IET Software, lecturer and Head of

Computer science department. He is currently a lecturer and Head of

Digital Forensic Laboratory Department at the Ghana Technology

University.

application of formal concept analysis

Documents