Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
17Activity
0 of .
Results for:
No results containing your search query
P. 1
Software Metrics: Some degree of software measurement and analysis

Software Metrics: Some degree of software measurement and analysis

Ratings: (0)|Views: 582 |Likes:
Published by ijcsis

More info:

Published by: ijcsis on Jun 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/10/2013

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 2, 2010
Software Metrics: Some degree of Software Measurementand Analysis
Rakesh.L Dr.Manoranjan Kumar Singh Dr.Gunaseelan Devaraj
Department of Computer-Science PG Dept of Mathematics Department of Information TechnologySCT Institute of Technology Magadh University Ibri College of TechnologyBangalore - 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 thatgovern our lives. Measurement is essential to our daily life andmeasuring has become a common place and well accepted.Engineering discipline use methods that are based on models andtheories. Methodological improvements alone do not make anengineering discipline. Measurement encourages us to improveour processes and products. This paper examines the realm of software engineering to see why measurement is needed and alsoset the scene for new perspective on software reliability metricsand its improvement. Software measurement is not a mainstreamtopic within software engineering rather it is a diverse collectionof fringe topics. Unlike other engineering discipline measurementmust become an integral part of software engineering practice.
 Keywords-
External Attribute, Reliability model, Fault tolerance
.
 
I
.
INTRODUCTION
 Measurement is a process by which numbers or symbols areassigned to attributes of entities in the real world in such a wayas to describe them accordingly to clearly defined rules.Software engineering describes the collection of techniquesthat apply an engineering approach to the development andsupport of products. Software engineering activities includespecifying, analysing, designing, implementing, testing andmaintaining. By engineering approach we mean that eachactivity is understood and controlled, so that there are fewsurprises as the software is specified, designed, built, andmaintained. Whereas computer science provides thetheoretical foundations for building for building the software,software engineering focuses on implementing the software incontrolled and scientific way. The importance of softwareengineering cannot be understated, since software pervadesour lives. From oven control to airbags, from bankingtransactions to air traffic control, and from sophisticatedpower plants to sophisticated weapons, our lives and quality of life depend on software. Such a young discipline has done anadmirable job or providing safe, useful, and reliablefunctionality. But there is a room for great deal of improvement. Engineering discipline use techniques that arebased on models which are theoretical in nature. For example,in designing electrical circuits we appeal to theories like Ohmslaw, which describes the relation between resistance, currentand voltage in the circuit. But the laws of electrical behaviourhave evolved by using the scientific method, stating ahypothesis, designing and running an experiment to test itstruth and analysing the results. Underpinning the scientificprocess is measurement, measuring the variables todifferentiate cases, measuring the changes in behaviour, andmeasuring the causes and effects. Once the scientific methodsuggests the validity of the model or the truth of a theory, wecontinue to use measurement to apply the theory to practice. Itis difficult to imagine electrical, mechanical and civilengineering without a central role of measurement. Indeed,science and engineering can be neither effective nor practicalwithout measurement. But measurement has been considereda luxury in software engineering. For most developmentprojects we fail to set measurable targets for our softwareproducts. For example, we promise that the product will beuser friendly, reliable and maintainable without specifyingclearly and objectively what these terms mean. As a resultwhen the project is complete, we cannot tell if we have metour goals. This situation has prompted Tom Gilb to state“projects without clear goals will not achieve their goalsclearly”. We do not quantify or predict the quality of theproducts we produce. Thus, we cannot tell a potential userhow reliable a product will be in terms of likelihood of failurein a given period of use, or how much work will be needed toport the product to a different machine environment [1]. Weallow anecdotal evidence to convince us to try yet anotherrevolutionary new development technology, without doing acarefully controlled study to determine if the technology isefficient and effective. When measurements are made, they areoften done infrequently, inconsistently and incompletely. Theincompleteness can be frustrating to those who make use of the results. For instance a tester may say that there are on aaverage 55 faults in every 1000 lines of software code. But weare not always told how these results were obtained, howexperiments were designed and executed, which entities weremeasured and how and what were the realistic error margins.Without this information we remain skeptical and unable todecide whether to apply the results to our own situations. Thus,the lack of measurement in software engineering iscompounded by the lack of a rigorous approach. We have set anew perspective on software measurement on solid foundation.
138http://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 specificmeaning .It is a rule used to describe how far apart two pointsare. More formally, a metric is a function m defined on pairsof objects x and y such that m(x,y) represents the distancebetween x and y. Such metrics must satisfy certain properties:
 
m(x,x) = 0 for all x : that is, the distance from point x toitself is zero;
 
m(x,y) = m(y,x) for all x and y: that is, the distance fromx to y is same as the distance from y to x;
 
m(x,z)
≤ m(x,y)+m(y,z) for all x,y and z: that is, the
distance from x to z is no larger than the distance measuredby stopping through an intermediate point.A prediction system consists of a mathematical model togetherwith a set of prediction procedures for determining unknownparameters and interpreting the results. When we talk aboutmeasuring something, we usually mean that we wish to assesssome entity that already exists. This measurement forassessment is very helpful in understanding what exist now orwhat happened in the past [2]. However, in manycircumstances, we would like to predict an attribute of someentity that does not yet exist. For instance, suppose we arebuilding a software system that must be highly reliable, suchas the control software for an aircraft, power plant, or X-raymachine. The software development may take some time andwe want to provide early assurance that the system will meetreliability targets. To provide reliability indicators before thesystem is complete, we can build a model of the factors thataffect reliability, and then predict the likely reliability basedon our understanding of the system while it is still underdevelopment. In general, measurement for prediction alwaysrequires some kind of mathematical model that relates theattributes to be predicted to some other attributes that we canmeasure. The model need not be complex to be useful.Suppose we want to predict the number of pages, M, that willprint out as a source code program, so that we can ordersufficient paper or estimate the time it will take to do theprinting. We can use the very simple model,M = x/a (1)Where x is a variable representing a measure of source codeprogram length in lines of code, and a is constant representingthe average number of lines per page. Effort predication isessential and universally needed. A common generic modelfor predicting the effort required in software projects has theform,E = aS
b 
(2)Where E is effort in person months, S is the size in lines of code of the system to be developed, and a and b are constants.There are numerous examples can be represented as“mathematical” metrics for software [3]. We can hope thatevery program satisfies its specification completely, but this israrely the case. Thus, we can view program correctness as ameasure of the extent to which a program satisfies itsspecification, and define a metric m(S,P) where the entitiesS(Specification ) and P(Program) are both products. Let uselaborate this idea to classical fault tolerant technique like N-Version programming which is quite popular in safety criticalsystems. The approach involves developing N differentversions of critical software components independently.Theoretically, by having each of the N-different teams solvingthe same problem without knowledge of what the other teamsare doing , the probability that all the teams , or even majority,will make same error is kept small. When the behaviour of thedifferent versions differs, a voting procedure accepts thebehaviour of the majority systems. The assumptions, then isthat the correct behaviour will always be chosen. However,there may be problems in assuring genuine designindependence, so we may be interested in measuring the levelof diversity between two designs, or algorithms or programs.We can define a metric m, where m(P
1
, P
2
) measures thediversity between two programs P
1
and P
2
. In this case, theentities being measured are products. We can use a similarmetric to measure the level of diversity between two methodsapplied during design, we would be measuring attributes of process entities. To reconcile these mathematically precisemetrics with framework we have Proposed, we can considerpairs of entities as a single entity. For instance, havingproduced two programs satisfying the same specification, weconsider the pair of programs to be a single product system,itself having a level of diversity. This approach is consistentwith systems view of N-version programming. Where we haveimplemented N versions of a program, the diversity of thesystem may be viewed as an indirect measure of the pair wiseprogram diversity. Many attributes of interest in softwareengineering are not directly measurable. This situation forcesto use vectors of measures, with rules of combining the vectorelements into a larger, indirect measure [4]. That is indirectmeasure is defined to be combination of other measures, bothdirect and indirect. An indirect measure of testing efficiency Tis D/E, where D is the number of defects discovered and E iseffort in person months. Here D is an absolute scale measure,while E is on the ratio scale measure. Since absolute isstronger than ratio scale, it follows that T is a ratio scalemeasure. Consequently the acceptable rescalings of T arisefrom rescaling of E into other measures of effort like persondays, person years etc. Many of the measures we have used inour examples are assessment measures. But indirect measuresproliferate as prediction measures also.
139http://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 thatdefine measurable attributes of entities, their units and theirscope. Measurement is process by which numbers or symbolsare assigned to attributes of entities (objects) in the real worldin such a way as to ascribe them according to define rules.Measure is a relation between an attribute and a measurementscale. In any measurement activity, there are rules to befollowed. The rules help us to be consistent in ourmeasurement, as well as providing a basis for interpreting data.Measurement theory tells us the rules, laying the ground work for developing and reasoning about all kinds of measurement.This rule based approach is common in many sciences. Forexample recall that mathematicians learned about the world bydefining axioms of geometry. Then by combining axioms andusing their results to support or refute their observations, theyexpanded their understanding and the set of rules that governthe behaviour of objects. In the same way, we can use rulesabout measurement to codify our initial understanding, andexpand our horizons as we analyse our software. Therepresentational theory is depicted in Figure 1.Fig. 1 Mathematical Logical ModelThe representational theory of measurement seeks to formalizeour intuition about the way the world works. That is, the datawe obtain as measures should represent attributes of theentities we observe, and manipulation of the data shouldpreserve relationships that we observe among the entities.Thus, our intuition is the starting point for all ourmeasurement. Formally, we define measurement as a mappingfrom the empirical world to the formal, relational world.Consequently, a measure is the number or symbol assigned toan entity by this mapping in order to characterize an attribute.An entity in a software measurement can be any artifacts,design and development activity, verification, qualityassurance and resources [5]. An attribute is a feature propertyof an entity for instance blood pressure of person, cost of aJourney, duration of the software specification process. Thereare two general types of attributes internal attributes andexternal attributes. Internal attributes are measured only basedon the entity itself. If we say entity as a code, the internalattributes are size, modularity and coupling. External attributescan be measured with respect to how the entity relates to itsenvironment. If we take for instance code as an entity itsexternal attributes are reliability and maintainability. The firstobligation of any software measurement activity is identifyingthe entities and attributes we wish to measure. In softwarethere are three such classes process, products and resources.Processes are collections of software related activities.Products are any artifacts, deliverables or documents thatresult from a process activity. Resources are entities requiredby a process activity. The principal objective of softwareengineering is to improve the quality of software products. Butquality, like beauty, is very much in the eyes of beholder. Inthe philosophical debate about the meaning of software quality,proposed definitions include fitness for purpose, conformanceto specification, degree of excellence and timeliness. However,from the measurement perspective, we must be able to definequality in terms of specific software product attribute of interest to the user. That is, we want to know how to measurethe extent to which these attributes are present in our softwareproducts. This knowledge will enable us to specify and setstarget for quality attributes in measurable form. For manyyears, the user community sought a single model for depictingand expressing quality. The advantage of universal model isclear, it makes easier the comparison of one product withanother. In 1992 McCall model was proposed as the basis foran international standard for software quality measurementcalled, Software product evaluation, Quality characteristicsand Guidelines for their use, the standard is more commonlyreferenced by its assigned standard number, ISO 9126. In thisstandard software quality is defined to be, “The totality of features and characteristics of a software product that bear onits ability to satisfy stated or implied needs”. Then quality isdecomposed into six factors. Functionality, reliability,efficiency, usability, maintainability, portability. The standardclaims that these six are comprehensive that is any componentof software quality can be described in terms of some aspectof one or more of the six factors. In turn each of the six isdefined as set of attributes that bear on as relevant aspect of software and each can be refined through multiple levels of sub characteristics. Most of the software quality modelsidentified software reliability as a key high level attribute. Soit is not surprising that software reliability has been the mostexpensively studied of all the quality attributes. Quantitativemethods for its assessment date back to early 1970s, evolvingfrom theory of hardware reliability.
Real WorldEmpirical WorldFormal WorldMeasurementMappingModel andVerification
140http://sites.google.com/site/ijcsis/ISSN 1947-5500

Activity (17)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
harishpa liked this
RickBoss80 liked this
levieuxdjo liked this
Atiq Afridi liked this
Tan Chee Seng liked this
Thomas Wen liked this
shambhukjha liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->