Software Metrics: Some degree of software measurement and analysis

Shared by: ijcsiseditor

Stats

views:: 150
posted:: 6/11/2010
language:: English
pages:: 7

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

Software Metrics: Some degree of Software Measurement
and Analysis
Rakesh.L Dr.Manoranjan Kumar Singh Dr.Gunaseelan Devaraj
Department of Computer-Science PG Dept of Mathematics Department of Information Technology
SCT Institute of Technology Magadh University Ibri College of Technology
Bangalore - 560075, India Bodhgaya- 824234, India Sultanate of Oman- 516
rakeshsct@yahoo.co.in drmksingh_gaya@yahoo.com dgseela@yahoo.com

Abstract— Measurement lies at the heart of many systems that and voltage in the circuit. But the laws of electrical behaviour
govern our lives. Measurement is essential to our daily life and have evolved by using the scientific method, stating a
measuring has become a common place and well accepted. hypothesis, designing and running an experiment to test its
Engineering discipline use methods that are based on models and truth and analysing the results. Underpinning the scientific
theories. Methodological improvements alone do not make an
process is measurement, measuring the variables to
engineering discipline. Measurement encourages us to improve
our processes and products. This paper examines the realm of differentiate cases, measuring the changes in behaviour, and
software engineering to see why measurement is needed and also measuring the causes and effects. Once the scientific method
set the scene for new perspective on software reliability metrics suggests the validity of the model or the truth of a theory, we
and its improvement. Software measurement is not a mainstream continue to use measurement to apply the theory to practice. It
topic within software engineering rather it is a diverse collection is difficult to imagine electrical, mechanical and civil
of fringe topics. Unlike other engineering discipline measurement engineering without a central role of measurement. Indeed,
must become an integral part of software engineering practice. science and engineering can be neither effective nor practical
without measurement. But measurement has been considered
Keywords- External Attribute, Reliability model, Fault tolerance. a luxury in software engineering. For most development
projects we fail to set measurable targets for our software
I. INTRODUCTION products. For example, we promise that the product will be
user friendly, reliable and maintainable without specifying
clearly and objectively what these terms mean. As a result
Measurement is a process by which numbers or symbols are when the project is complete, we cannot tell if we have met
assigned to attributes of entities in the real world in such a way our goals. This situation has prompted Tom Gilb to state
as to describe them accordingly to clearly defined rules. “projects without clear goals will not achieve their goals
Software engineering describes the collection of techniques clearly”. We do not quantify or predict the quality of the
that apply an engineering approach to the development and products we produce. Thus, we cannot tell a potential user
support of products. Software engineering activities include how reliable a product will be in terms of likelihood of failure
specifying, analysing, designing, implementing, testing and in a given period of use, or how much work will be needed to
maintaining. By engineering approach we mean that each port the product to a different machine environment [1]. We
activity is understood and controlled, so that there are few allow anecdotal evidence to convince us to try yet another
surprises as the software is specified, designed, built, and revolutionary new development technology, without doing a
maintained. Whereas computer science provides the carefully controlled study to determine if the technology is
theoretical foundations for building for building the software, efficient and effective. When measurements are made, they are
software engineering focuses on implementing the software in often done infrequently, inconsistently and incompletely. The
controlled and scientific way. The importance of software incompleteness can be frustrating to those who make use of
engineering cannot be understated, since software pervades the results. For instance a tester may say that there are on a
our lives. From oven control to airbags, from banking average 55 faults in every 1000 lines of software code. But we
transactions to air traffic control, and from sophisticated are not always told how these results were obtained, how
power plants to sophisticated weapons, our lives and quality of experiments were designed and executed, which entities were
life depend on software. Such a young discipline has done an measured and how and what were the realistic error margins.
admirable job or providing safe, useful, and reliable Without this information we remain skeptical and unable to
functionality. But there is a room for great deal of decide whether to apply the results to our own situations. Thus,
improvement. Engineering discipline use techniques that are the lack of measurement in software engineering is
based on models which are theoretical in nature. For example, compounded by the lack of a rigorous approach. We have set a
in designing electrical circuits we appeal to theories like Ohms new perspective on software measurement on solid foundation.
law, which describes the relation between resistance, current

138 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

II. MOTIVATION

In mathematical analysis a metric has a very specific Where E is effort in person months, S is the size in lines of
meaning .It is a rule used to describe how far apart two points code of the system to be developed, and a and b are constants.
are. More formally, a metric is a function m defined on pairs There are numerous examples can be represented as
of objects x and y such that m(x,y) represents the distance “mathematical” metrics for software [3]. We can hope that
between x and y. Such metrics must satisfy certain properties: every program satisfies its specification completely, but this is
rarely the case. Thus, we can view program correctness as a
 m(x,x) = 0 for all x : that is, the distance from point x to measure of the extent to which a program satisfies its
itself is zero; specification, and define a metric m(S,P) where the entities
S(Specification ) and P(Program) are both products. Let us
 m(x,y) = m(y,x) for all x and y: that is, the distance from elaborate this idea to classical fault tolerant technique like N-
x to y is same as the distance from y to x; Version programming which is quite popular in safety critical
systems. The approach involves developing N different
 m(x,z) ≤ m(x,y)+m(y,z) for all x,y and z: that is, the versions of critical software components independently.
distance from x to z is no larger than the distance measured Theoretically, by having each of the N-different teams solving
by stopping through an intermediate point. the same problem without knowledge of what the other teams
are doing , the probability that all the teams , or even majority,
A prediction system consists of a mathematical model together will make same error is kept small. When the behaviour of the
with a set of prediction procedures for determining unknown different versions differs, a voting procedure accepts the
parameters and interpreting the results. When we talk about behaviour of the majority systems. The assumptions, then is
measuring something, we usually mean that we wish to assess that the correct behaviour will always be chosen. However,
some entity that already exists. This measurement for there may be problems in assuring genuine design
assessment is very helpful in understanding what exist now or independence, so we may be interested in measuring the level
what happened in the past [2]. However, in many of diversity between two designs, or algorithms or programs.
circumstances, we would like to predict an attribute of some We can define a metric m, where m(P1, P2) measures the
entity that does not yet exist. For instance, suppose we are diversity between two programs P1 and P2. In this case, the
building a software system that must be highly reliable, such entities being measured are products. We can use a similar
as the control software for an aircraft, power plant, or X-ray metric to measure the level of diversity between two methods
machine. The software development may take some time and applied during design, we would be measuring attributes of
we want to provide early assurance that the system will meet process entities. To reconcile these mathematically precise
reliability targets. To provide reliability indicators before the metrics with framework we have Proposed, we can consider
system is complete, we can build a model of the factors that pairs of entities as a single entity. For instance, having
affect reliability, and then predict the likely reliability based produced two programs satisfying the same specification, we
on our understanding of the system while it is still under consider the pair of programs to be a single product system,
development. In general, measurement for prediction always itself having a level of diversity. This approach is consistent
requires some kind of mathematical model that relates the with systems view of N-version programming. Where we have
attributes to be predicted to some other attributes that we can implemented N versions of a program, the diversity of the
measure. The model need not be complex to be useful. system may be viewed as an indirect measure of the pair wise
Suppose we want to predict the number of pages, M, that will program diversity. Many attributes of interest in software
print out as a source code program, so that we can order engineering are not directly measurable. This situation forces
sufficient paper or estimate the time it will take to do the to use vectors of measures, with rules of combining the vector
printing. We can use the very simple model, elements into a larger, indirect measure [4]. That is indirect
measure is defined to be combination of other measures, both
M = x/a (1) direct and indirect. An indirect measure of testing efficiency T
is D/E, where D is the number of defects discovered and E is
Where x is a variable representing a measure of source code effort in person months. Here D is an absolute scale measure,
program length in lines of code, and a is constant representing while E is on the ratio scale measure. Since absolute is
the average number of lines per page. Effort predication is stronger than ratio scale, it follows that T is a ratio scale
essential and universally needed. A common generic model measure. Consequently the acceptable rescalings of T arise
for predicting the effort required in software projects has the from rescaling of E into other measures of effort like person
form, days, person years etc. Many of the measures we have used in
our examples are assessment measures. But indirect measures
E = aSb (2) proliferate as prediction measures also.

139 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010
III. SOFTWARE FOUNDATION

Metrics are standards that are commonly accepted scales that An entity in a software measurement can be any artifacts,
define measurable attributes of entities, their units and their design and development activity, verification, quality
scope. Measurement is process by which numbers or symbols assurance and resources [5]. An attribute is a feature property
are assigned to attributes of entities (objects) in the real world of an entity for instance blood pressure of person, cost of a
in such a way as to ascribe them according to define rules. Journey, duration of the software specification process. There
Measure is a relation between an attribute and a measurement are two general types of attributes internal attributes and
scale. In any measurement activity, there are rules to be external attributes. Internal attributes are measured only based
followed. The rules help us to be consistent in our on the entity itself. If we say entity as a code, the internal
measurement, as well as providing a basis for interpreting data. attributes are size, modularity and coupling. External attributes
Measurement theory tells us the rules, laying the ground work can be measured with respect to how the entity relates to its
for developing and reasoning about all kinds of measurement. environment. If we take for instance code as an entity its
This rule based approach is common in many sciences. For external attributes are reliability and maintainability. The first
example recall that mathematicians learned about the world by obligation of any software measurement activity is identifying
defining axioms of geometry. Then by combining axioms and the entities and attributes we wish to measure. In software
using their results to support or refute their observations, they there are three such classes process, products and resources.
expanded their understanding and the set of rules that govern Processes are collections of software related activities.
the behaviour of objects. In the same way, we can use rules Products are any artifacts, deliverables or documents that
about measurement to codify our initial understanding, and result from a process activity. Resources are entities required
expand our horizons as we analyse our software. The by a process activity. The principal objective of software
representational theory is depicted in Figure 1. engineering is to improve the quality of software products. But
quality, like beauty, is very much in the eyes of beholder. In
the philosophical debate about the meaning of software quality,
proposed definitions include fitness for purpose, conformance
Measurement
to specification, degree of excellence and timeliness. However,
from the measurement perspective, we must be able to define
quality in terms of specific software product attribute of
interest to the user. That is, we want to know how to measure
the extent to which these attributes are present in our software
Empirical World products. This knowledge will enable us to specify and sets
Real World target for quality attributes in measurable form. For many
years, the user community sought a single model for depicting
and expressing quality. The advantage of universal model is
clear, it makes easier the comparison of one product with
another. In 1992 McCall model was proposed as the basis for
an international standard for software quality measurement
called, Software product evaluation, Quality characteristics
and Guidelines for their use, the standard is more commonly
referenced by its assigned standard number, ISO 9126. In this
Model and Formal World
standard software quality is defined to be, “The totality of
Verification
Mapping features and characteristics of a software product that bear on
its ability to satisfy stated or implied needs”. Then quality is
decomposed into six factors. Functionality, reliability,
Fig. 1 Mathematical Logical Model efficiency, usability, maintainability, portability. The standard
claims that these six are comprehensive that is any component
The representational theory of measurement seeks to formalize of software quality can be described in terms of some aspect
our intuition about the way the world works. That is, the data of one or more of the six factors. In turn each of the six is
we obtain as measures should represent attributes of the defined as set of attributes that bear on as relevant aspect of
entities we observe, and manipulation of the data should software and each can be refined through multiple levels of
preserve relationships that we observe among the entities. sub characteristics. Most of the software quality models
Thus, our intuition is the starting point for all our identified software reliability as a key high level attribute. So
measurement. Formally, we define measurement as a mapping it is not surprising that software reliability has been the most
from the empirical world to the formal, relational world. expensively studied of all the quality attributes. Quantitative
Consequently, a measure is the number or symbol assigned to methods for its assessment date back to early 1970s, evolving
an entity by this mapping in order to characterize an attribute. from theory of hardware reliability.

140 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

IV . RELIABILITY METRICS

within specification, i.e. up, thus we have,
Software reliability is the probability or failure free software
operation for a specified period of time in a specified Availability = Total up time / test Interval
environment. Software reliability is also an important factor = Total up time/ Total up time + total down time (4)
affecting system reliability. It differs from hardware reliability
in that it reflects the design perfection, rather than Unavailability U is similarly defined as the fraction of the total
manufacturing perfection. The high complexity of software is test interval that it is not performing to specification, i.e. failed
the major contributing factor of software reliability problems. or down, thus we have,
Measurement in software is still in its infancy, no good
quantitative methods have been developed to represent Unavailability = Total down time/Test Interval (5)
software reliability without excessive limitations. Software
reliability is an important attribute of software quality, As availability depends on reliability, availability can
together with functionality, usability, performance, therefore be increased by increasing mean time between
serviceability, capability, installability, maintainability and failures (MTBF), i.e. reducing mean failure rate. Availability
documentation. The word reliability is commonly used in depend on mean down time, we can increase availability by
everyday life. When a product such as a car or washing reducing mean down time, MDT. Thus availability also
machine breaks down, the user is forcibly made aware of the depends on maintainability, i.e. how quickly the product can
limited reliability of the product [6]. The reliability R of the be repaired and put back into service. Computers are now
product can therefore be defined as the probability that the widely used in all branches of engineering. Many industrial
product continues to meet the specification, over a given time processes, steel, chemicals, food, gas and electricity
period, subject to given environmental conditions. If however, generation, rely on computers to monitor and control critical
as the time goes on the product fails to meet its specification, process variables. The reliability of this control is therefore
then it is considered to have failed. The unreliability F of the dependent on the reliability of the computer [7]. Furthermore
product can be defined as the probability that the product fails microcomputers form an integral part of a wide range of
to meet the specification, over a given period of time. Both electronic systems. These embedded microcomputers use
reliability and unreliability vary with time. Reliability R(t) computer programs, i.e. software to perform functions
decreases with time, an item that has just been tested and previously performed by electronic circuits, i.e. hardware. For
shown to meet specification has a reliability of 1 when first example the calculation of a square root can be implemented
placed in service. One year later this may have decreased to using either hardware that is the complex electronic circuit or
0.5. Unreliability F(t) increases with time, an item that has just software, a single statement in a high level programming
been tested and shown to meet specification has an language. Performing functions in software rather than
unreliability of 0 when first placed in service, increasing to say hardware can therefore lead to a simpler, more robust overall
0.5 after one year. Since, at any time t, the product has either system. Since software is vital to the performance of a large
survived or failed, the sum of reliability and unreliability must number of engineering functions, its reliability should be
be 1, that is the events are complementary and given by, closely studied. Each copy of a computer program is identical
to the original, so that failures due to product variability, often
R(t) + F(t) = 1 (3) common with hardware, cannot occur with software. Also,
unlike, hardware, software cannot usually degrade with time,
We can now discuss the relationship between quality and in the few special cases that degradation does occur it is easy
reliability. The reliability of a product is its ability to retain its to restore to the original standard [9]. However, software can
quality as time progresses. Thus a product can only have high fail to perform the required function due to undetected errors
quality if it also has high reliability. High initial quality is of in the program. If a software error exists in the original
little use if it is soon lost. The opposite is, however, not true, a program then the same error exists in all copies. If this error
product with high reliability does not necessarily have high produces a failure in a certain set of circumstances, then
quality, but may be merely retaining low quality over a long failure will always occur under these circumstances with
period of time. When a product is up that is working possibly serious consequences. Many programs consist of a
satisfactorily, it is available for use. When the product is down, large number of individual statements and logical paths so that
i.e. being repaired, it is unavailable for use. It is important to the probability of a significant number of errors being present
have average measure of the degree to which the product is is high. A software reliability effort is therefore required to
either available or unavailable. The availability of the product minimize the number of errors present by the use of systematic
is the fraction of the total test interval that is performing programming methods, checking and testing.

141 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

V. RESULTS AND DISCUSSION

Reliability can be quantified in terms of failure probability, approximate equation for unreliabilities of series system with
failure rate, and mean time between failures. Many branches small F’s. The system unreliability is approximately the sum
of engineering are concerned with the development and of the element unreliabilites.
production of systems which are made up of several simpler
elements or components [8]. B. Quantifying Reliability for Parallel System

A. Quantifying Reliability for Series System The Figure 3 shows an overall system consisting of n
individual elements or systems in parallel with individual
In the Figure 2 a system of m elements in series or cascade unreliabilities F1, F2 . . . Fj, . . .Fn respectively.
with individual reliabilities R1, R2, . . . ,Ri, . . ., Rm respectively.

R1 R2 Ri Rm
1

1 2 i m F2
i/p o/p
2
Fig. 2 Reliability of Series System

The system will only survive if every element survives, if one Fj
element fails then the system fails. Assuming that the
reliability of the other elements, then the probability that the
system survives is the probability that element 1 survives and j
the probability that 2 survives and the probability that element
3 survives, etc. The system reliability RSYST is therefore the Fn
product of the individual element reliabilities i.e.,

RSYST = R1R2 . . . Ri n
. . . Rm (5)

It is the reliability of the series system. If we further assume Fig. 3 Reliability of parallel System
that each of the elements can be described by a constant
failure rate λ, and λi is the failure rate of the ith, element, the All of the elements are expected to be working normally, i.e.
failure rate of system of m elements in series is given by, to be active, and each one is capable of meeting the functional
requirements placed on the overall system. However, only one
λSYST = λ1 + λ2 + . . . λ i + . . . + λm (6) element/system is necessary to meet these requirements, the
remainder increase the reliability of the overall system. This is
This means that the overall failure rate for a series system is termed active redundancy. The overall system will only fail if
the sum of the individual element or component failures rates. every element or system fails, if one element or system
From the equation (6), it is evident that, keeping the number of survives the overall system survives. Assuming that the
elements in a series system minimum, the system failure rate reliability of each element or system is independent of the
will be minimum and the reliability is maximum. Protective reliability of the other elements, then the probability that the
systems are characterized by having element and system overall system fails is the probability that element/system 1
unreliabilities F that are very small. The corresponding fails and the probability that 2 fails and the probability that 3
element and system reliabilities R are therefore very close to 1, fails, etc. The overall system unreliability FSYST is therefore
for example, 0.9999 may be typical. In this situation the product of the individual element system unreliabilities.
calculation of system reliability may be unwieldy and an
alternative equation involving unreliabilities may be more FSYST = F1F2 . . . Fj . . . Fn (7)
useful.If the individual Fi are small, i.e. Fi << 1, the terms
involving the products of Fs can be neglected giving the This is the unreliability of parallel system. Comparing, we see

142 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

that for series systems, system reliability is the product of This model for software reliability is an attempt to quantify
element reliabilities, whereas for parallel systems, system reliability for software.
unreliability is the product of element unreliabilities. Often the
individual elements are identical, so that F1 = F2 = . . . = Fi D. Methods of improving software reliability
= . . . = Fn = F, this gives,
Specification: Many of the errors recorded during software
FSYST = Fn (8) development originate in the specification. The software
specification must describe fully and accurately the
Thus if F = 0.1 and there are four channels in parallel we FSYST requirements of the program. There are no safety margins in
= 10 -4 . We see, therefore, that increasing the number of software design as in hardware design. The specification must
individual elements in parallel system increases the overall be logically complete, i.e. must cover all possible input
system reliability. conditions and output requirements.

C. Reliability model applied to software Software systems design: This follows the specification and
is often a flow chart which defines the program structure, test
In spite of all efforts to ensure that the software is free from points, limits, etc. To be reliable a program must be robust, i.e.
errors, some residual errors or bugs often persist [10]. The it should be able to survive error conditions without serious
reliability model presented assumes that the average rate at effect such as crashing or becoming locked in a loop.
which software bugs are detected and corrected from similar
programs is approximately constant. The software failure rate Structure: Structured programming is a methodology that
will then be proportional to the number of remaining bugs. forces the programmer to use certain clear, well defined
Thus if we assume no new bugs are created during the methods of program design, rather than allow complete
debugging process and all detected errors are corrected then freedom to design intricate, complex programs which are
we have, prone to error and difficult to understand and debug.

Fractional number of residual bugs = Fractional number of Modularity: Modular programming breaks a program down
total bugs – Fractional number of corrected bugs.i.e. into smaller, individual blocks or modules each one of which
can be separately specified, written and tested. This makes the
єr(ҭ) = {ET / IT } – єc (ҭ) (9) program much easier to understand and check.

where ҭ = debugging time in months Fault tolerance: Programs should be written so that if an error
ET = Total number of errors. does occur, the program should be able to find its way out of
IT = Total number of Instructions the error condition and indicate the source of the error. In
application where safety is vital, for example where a
In this model the fractional number of corrected bugs єc (ҭ) is computer is used to control an industrial process, if an error
proportional to ҭ, i.e. does occur the program should be first detect it, send an alarm
message and then move the process to known safe conditions.
єc (ҭ) = ρҭ (10) Fault tolerance can also be provided using program
redundancy.
where ρ = fractional rate at which errors are removed per
month. Languages: The reliability of software also depends on the
computer language used. Assembly level programs are faster
If the debugging process is concluded at time ҭ0, єc (ҭ) will to run and require less memory than high level programs and
therefore remain at the constant value єc (ҭ0) and єr(ҭ0) will may be preferred for real time systems. High level languages,
remain at a constant value, for example, Fortran, basic, Ada, Pascal, C++, Java are
processor independent and operate using advanced compilers.
єr(ҭ0) = {ET / IT } – єc (ҭ0) (11) The newer high level languages strongly encourage structured
programming.
The failure rate λ of the software is then proportional to єr(ҭ0),
the fractional number of bugs left in the program, i.e. Software checking: Modern high level language compilers
have error detection capability so that errors of logic, syntax
and other coding errors can be detected and corrected before
λ = K єr(ҭ0) (12) an attempt is made to load the program.

The values of (ET/ IT), ρ and K must be found by experimental The above methods and practice in each and every phase of
testing before a value of λ can be established. software development cycle improves system reliability.

143 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 2, 2010

AUTHORS PROFILE
VI . CONCLUSION

In this paper authors are interested in software quality and
L.Rakesh received his M.Tech in Software Engineering
reliability metrics which are two faces on the same coin for a from Sri Jayachamarajendra College of Engineering,
software product measurement. Software reliability is a key Mysore, India in 2001 as an honour student. He is a
concern of many users and developers of software, because member of International Association of Computer
Science and Information Technology, Singapore. He is
reliability is defined in terms of failures, it is impossible to
also a member of International Association of Engineers,
measure before development is complete. The approach to Hong Kong. He is pursuing his Ph.D degree from
quantify reliability metrics is computationally intensive than Magadh University, India. Presently he is working as a
simply adopting a single techniques. We explained new Assistant professor and Head of the Department in
Computer Science & Engineering, SCT Institute of Technology, Bangalore,
methods intuitively by calculating the reliability and India. He has presented and published research papers in various National,
availability of a range of practical systems given the reliability International conferences and Journals. His research interests are Formal
of the constituent elements and components. The authors also Methods in Software Engineering, 3G-Wireless Communication, Mobile
explained novel concepts to improve the software reliability. Computing, Fuzzy Logic and Artificial agents.
The ultimate outcome is a trustworthy, worthwhile, a state of
art approach to reliability assessment for complex computer Dr.Manoranjan Kumar Singh received his Ph.D
systems. degree from Magadh University, India in 1986. This
author is Young Scientist awardee from Indian
Science Congress Association in 1989. A life
REFERENCES member of Indian Mathematical society, Indian
Science congress and Bihar Mathematical society. He
is also the member of Society of Fuzzy Mathematics
[1] Chapin N, A measure of software complexity , Proceedings of the and Information Science, I.S.I. Kolkata. He was
National Computer conference, pp. 728- 789, Nov 2005. awarded best lecturer award in 2005. He is currently
working as a Senior Reader in post graduation Department of Mathematics,
[2] Courteny R.E, Shortgun correlations in software measures, Software Magadh University. He is having overall teaching experience of 26 years
Engineering Journal, vol.8 (1), pp. 5-13, Aug 2003. including professional colleges. His major research Interests are in Fuzzy
logic, Expert systems, Artificial Intelligence and Computer-Engineering. He
has completed successfully Research Project entitled, Some contribution to
[3] Fenton N.E, Metrics and Software structure, Journal of Information and
the theory of Fuzzy Algebraic Structure funded by University Grants
software technology, vol 5, pp. 20-23, 2006
Commission, Kolkata region, India. His ongoing work includes Fuzzification
of various Mathematical concepts to solve real world problems.
[4] Haslehust M, Manufacturing Technology, English Universities Press,
London, pp. 355-362, 2004

Dr. Gunaseelan Devaraj received his PhD degree
[5] Kolarik W. J, Creating quality: Concepts and Systems, McGraw-Hill, New
from PSG College of Technology, Bharathiar
York, pp. 879-82, 2003.
University, Coimbatore, India in 2001. He is a
member in more than 10 International and National
[6] National Semiconductor Corporation, The reliability Handbook, 3rd edition, associations in the field Computer science and
NSC California, pp.18-33, 2000 Information Technology. Presently he is working as
Professor and Head, Department of Information
Technology, Ibri College of Technology, Sultanate of
[7] Smith D.J, Reliability and Maintainability in perspective, 3rd edition, Oman since September 2007. He has more than 22
Macmillan, Basingstoke, pp.9-11, Jan 2002. years of teaching, research and administrative
experiences in Tamilnadu State Government College, Central Government
[8] Taguchi G, Experimental designs, 3rd edition, 2 Vols,Maruzen, Tokyo, pp. University, India and Technical College in Sultanate of Oman. He has
25, May 2005 successesfully completed many research projects in State Government and
Central Government, India. He has presented and published research papers in
various National, International conferences and Referred Journals. His area of
[9] Thomson J.R, Engineering Saftey assessment, Longman Scientific and research is Software Engineering, Algorithms in Data Mining, Bioinformatics
Technical Manual, Harlow, pp. 10-13, 2001 and Computational Molecular Biology.

[10] Weyuker E.J, Evaluating software complexity measures , IEEE
Transactions on Software Engineering, SE-14(9), pp. 56 -78, 2002.

144 http://sites.google.com/site/ijcsis/
ISSN 1947-5500