Metrology software metrics pdf

Moreover, for those who have to design new software measures, what must they do to build sound ones? Software Metrics and Software Metrology looks at the fundamentals of the design of a measurement method, which forms the foundation of the measures available in the sciences and in engineering. Alain Abran provides a step-by-step approach to both analyzing the design of current software measures and designing new, robust software measures for a specific business or engineering need.

He draws upon years of experience to ensure that software engineers and managers will apply the best practices in software measurement—and therefore be equipped to respond to the most demanding customers and feel supported by senior executives. Presents the key concepts that dictate whether a software measure's design is sufficiently strong.

Features several case studies analyzing strengths and weaknesses in the design of some of the software measures most widely used or quoted. Describes how lessons learned led to the design of the COSMIC — ISO method for the measurement of the functional size of software, from its initial prototype to its adoption by the ISO as an international standard.

Value number and reference together expressing magnitude of a quantity To illustrate the use of these terms, Figure 1 below describes the metrology terms used to collect data collection section and prepare data data preparation section in the measurement information model.

A derived measure is a composition of two or more base measures. However, in order to obtain a derived measure we have to: o Collect the different base measures composing the derived measure depends on the information needs.

In fact a derived measure is the product of a set of measurement units properly combined through a measurement function. This paper analyzes the design of the well-known suite of Object-Oriented measures proposed by Chidamber and Kemerer [5, 6]. Chidamber and Kemerer Measures: Overview Understanding the object-oriented approach concepts is important to define Object- Oriented measures and therefore analyze the design of the proposed measures.

Thus, these concepts are presented so that the terminology used to describe the Chidamber and Kemerer object-oriented measures is as uniform as possible [22]. Object-Oriented Concepts According to object-oriented approach, the basic concept in an object-oriented system is an object. An object is characterized by a state a set of properties characterizing the object as well as the value of each property and a behavior a set of operations of the object.

A class is the specification of the object; it is the basic model or prototype from which the objects are created. The classes are defined by the public services offered to the users by the intermediary of the methods and public attributes. The methods implement the operations that can be carried out in a class the logic of programming. The attributes represent the properties of a class. The Coupling is defined as the degree of interdependence between the components of the system.

Two classes are coupled if a method of one class uses an attribute or method of the other class [5]. Whereas, the Cohesion reflects the degree to which the methods within a class are related to one another. The more is the cohesion of a class, the more it is coherent and constitutes a whole entity inseparable, and the more simple maintainability.

According to Li and Offut by another class via the exchange of messages through the following dependence links: [24], it is a capacity relationship. A derived class inherits the structure and the behavior of the basic class and can be used as a basic class for a later derivation, giving rise to a hierarchy of classes called an inheritance tree. Chidamber and Kemerer Measures Chidamber and Kemerer [5] stated that the measures suite of object-oriented design is built upon projects that used Object Oriented design approach, and the aim of this was to propose a set of measures which are not based on the language syntax.

However, Chidamber and Kemerer measures can be applied during the later-design and implementation coding phases of the software development life cycle, for example, they can be applied on the class diagram during the later-design phase and on the source code during the implementation phase [26].

The definitions and theoretical basis for the Chidamber and Kemerer measures are illustrated in Table 2 [5, 6, 27]. Furthermore, the following explains these measures: 1 Coupling Between Object CBO : It is related to the number of non-inherited classes with which a particular class is coupled. Such number reflects the degree of interdependence between the object-oriented system components. However, class X is coupled to class Y if and only if X sends a message to Y; that is, a method of one class use methods or instances variables of another class.

It measures the degree of communication between the classes of the system. If all the complexities of all methods are ones, then WMC is the number of class methods. DIT of the root class in the inheritance tree is equal to zero. Moreover, if the subclasses are dependent of their superclass methods or instance variables , any changes to the superclass may affect the subclasses, and therefore, the harder is the superclass maintainability.

Theoretical basis: CBO relates to the notion that an object is coupled to another object if two objects act upon each other, i. Assumption s : The higher the CBO of a class is, the more difficult is reusing in another application and the more complex is the testing of that class. Assumption s : - The larger the RFC is the more complex is the class, and the harder is its maintainability difficult to trace an error. Theoretical basis: This uses the notion of degree of similarity of methods. If there are no common instance variables, the degree of similarity is zero.

However, this does not distinguish between the case where each of the methods operates on unique sets of instance variables and the case where only one method operates on a unique set of variables. The number of disjoint sets provides a measure for the disparate nature of methods in the class. Fewer disjoint sets imply greater similarity of methods. LCOM is intimately tied to the instance variables and methods of an object, and therefore is a measure of the attributes of an object.

Assumption s : - The Lack of cohesion implies that the classes should be split into more sub-classes. Let Cl, Cn be the static complexity of the methods.

Theoretical basis: WMC relates directly to the definition of complexity of an object, since methods are properties of objects and complexity of an object is determined by the cardinality of its set of properties. The number of methods is, therefore, a measure of object definition as well as being attributes of an object, since attributes correspond to properties. Assumption s : The larger the WMC is, the more complex is the class and the greater the potential impact on children. Theoretical basis: DIT relates to the notion of scope of properties.

DIT is a measure of how many ancestor classes can potentially affect this class. Assumption s : The lower the class is; the more are its superclasses and the larger is its DIT, and therefore, the harder is the class maintainability. Theoretical basis: NOC relates to the notion of scope of properties. It is a measure of how many sub-classes are going to inherit the methods of the parent class. Assumption s : The more a superclass has subclasses, the larger is its NOC.

Inheritance implies dependence implicitly. In fact, DIT indicates the number of superclasses that a class has, that is, on which the class may depend on, while NOC indicates the number of direct subclasses that a class has, that is, those which may be affected by a change in the class. Since their appearance, Chidamber and Kemerer object-oriented measures are interesting for both researchers and practitioners.

Several studies have been undertaken to validate Chidamber and Kemerer measures both theoretically and empirically [28, 29, 30, 31, 32, 33]. For example, Chidamber and Kemerer measures were analyzed empirically in order to assess their usefulness for practicing managers and investigate the relation between the measures and productivity, rework effort, and design effort [30], and to find out the nature of relationship of these measures with defects [33].

All the studies focus on using Chidamber and Kemerer measures in empirical studies to validate their usefulness in evaluating the object-oriented design, and none of them focuses on analyzing their design from metrology perspectives.

Analysis of the Chidamber and Kemerer Measures using the Metrology As a rule of thumb, any given number does not make sense without its unit of measurement. As this example illustrates, measurements without units are meaningless and may lead to serious misunderstandings.

Everything that can be measured must be expressed with appropriate units [34]. The objective of Chidamber and Kemerer measures is to measure the design of object- oriented program; that is, to measure coupling between object, response for a class, lack of cohesion in methods, weighted methods per class, depth of inheritance tree, and number of children during the later-design and implementation phases. The entities that can be used to apply Chidamber and Kemerer measures are the source code itself, the algorithm of that source code, or the class diagram.

The CBO measures the coupling between object classes. It includes inheritance-based coupling, that is, coupling between classes related via inheritance. Therefore, the basic measure of CBO is completely based in checking if the object is coupled or not, so it is a logical decision and based on true or false results. So, if the result is true add one otherwise add zero, thus, there is no base unit of measurement since the value is logical i. Cosmic: Design of an Initial Prototype -- Other Issues in the Design of Software Measures -- Convertibility Across Measurement Methods -- List of Acronyms -- Appendix B.

Summary: "Hundreds of software measures have been proposed to the industry over the past forty years, but limitations in their design mean that most of them are of insufficient use to practitioners.

So how can practitioners recognize which measures are sound and useful for decision-making? Moreover, for those who have to design new software measures, what must they do to build sound ones?

Alain Abran provides a step-by-step approach to both analyzing the design of current software measures and designing new, robust software measures for a specific business or engineering need.