Software Metrics: Some degree of software measurement and analysis

Document Sample
Software Metrics: Some degree of software measurement and analysis Powered By Docstoc
					                                                                 (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.

                                                                                                                           F1

           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