Software Metrics SAD ::: Fall 2015 Sabbir Muhammad Saleh.

Slides:



Advertisements
Similar presentations
SPEC Workshop 2008 Laboratory for Computer Architecture1/27/2008 On the Object Orientedness of C++ programs in SPEC CPU 2006 Ciji Isen & Lizy K. John University.
Advertisements

Software Metrics for Object Oriented Design
Software Metrics Software Engineering.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Prediction of fault-proneness at early phase in object-oriented development Toshihiro Kamiya †, Shinji Kusumoto † and Katsuro Inoue †‡ † Osaka University.
Figures – Chapter 24.
Metrics for Object Oriented Design Shyam R. Chidamber Chris F. Kemerer Presented by Ambikadevi Damodaran.
Applying and Interpreting Object Oriented Metrics
March 25, R. McFadyen1 Metrics Fan-in/fan-out Lines of code Cyclomatic complexity Comment percentage Length of identifiers Depth of conditional.
Nov R. McFadyen1 Metrics Fan-in/fan-out Lines of code Cyclomatic complexity* Comment percentage Length of identifiers Depth of conditional.
Page 1 Building Reliable Component-based Systems Chapter 7 - Role-Based Component Engineering Chapter 7 Role-Based Component Engineering.
Object-Oriented Metrics. Characteristics of OO ● Localization ● Encapsulation ● Information hiding ● Inheritence ● Object abstraction.
Design Metrics Software Engineering Fall 2003 Aditya P. Mathur Last update: October 28, 2003.
© S. Demeyer, S. Ducasse, O. Nierstrasz Duplication.1 7. Problem Detection Metrics  Software quality  Analyzing trends Duplicated Code  Detection techniques.
Object-Oriented Metrics
March R. McFadyen1 Software Metrics Software metrics help evaluate development and testing efforts needed, understandability, maintainability.
1 Complexity metrics  measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)  use these numbers as a criterion.
PVK-Ht061 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance.
Predicting Class Testability using Object-Oriented Metrics M. Bruntink and A. van Deursen Presented by Tom Chappell.
Object Oriented Metrics XP project group – Saskia Schmitz.
Chapter 9: Software Metrics
Comp 587 Parker Li Bobby Kolski. Automated testing tools assist software engineers to gauge the quality of software by automating the mechanical aspects.
Software Metrics.
Cyclomatic Complexity Dan Fleck Fall 2009 Dan Fleck Fall 2009.
University of Toronto Department of Computer Science © 2001, Steve Easterbrook CSC444 Lec22 1 Lecture 22: Software Measurement Basics of software measurement.
Lecture 17 Software Metrics
Object-Oriented Metrics Alex Evans Jonathan Jakse Cole Fleming Matt Keran Michael Ababio.
Chapter 6 : Software Metrics
SWEN 5430 Software Metrics Slide 1 Quality Management u Managing the quality of the software process and products using Software Metrics.
Software Measurement & Metrics
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15b: Product Metrics for Software Software Engineering: A Practitioner’s Approach, 6/e Chapter.
The CK Metrics Suite. Weighted Methods Per Class b To use this metric, the software engineer must repeat this process n times, where n is the number of.
The CK Metrics Suite. Weighted Methods Per Class b To use this metric, the software engineer must repeat this process n times, where n is the number of.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
Concepts of Software Quality Yonglei Tao 1. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Metrics and lessons learned for OO projects Kan Ch 12 Steve Chenoweth, RHIT Above – New chapter, same Halstead. He also predicted various other project.
An Automatic Software Quality Measurement System.
CSc 461/561 Information Systems Engineering Lecture 5 – Software Metrics.
Measurement and quality assessment Framework for product metrics – Measure, measurement, and metrics – Formulation, collection, analysis, interpretation,
Software Engineering 2004 Jyrki Nummenmaa 1 SOFTWARE PRODUCT QUALITY Today: - Software quality - Quality Components - ”Good” software properties.
Daniel Liu & Yigal Darsa - Presentation Early Estimation of Software Quality Using In-Process Testing Metrics: A Controlled Case Study Presenters: Yigal.
Object-Oriented (OO) estimation Martin Vigo Gabriel H. Lozano M.
Ontology Support for Abstraction Layer Modularization Hyun Cho, Jeff Gray Department of Computer Science University of Alabama
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Object Oriented Metrics
Cyclomatic complexity (or conditional complexity) is a software metric (measurement). Its gives the number of indepented paths through strongly connected.
Software Engineering Object Oriented Metrics. Objectives 1.To describe the distinguishing characteristics of Object-Oriented Metrics. 2.To introduce metrics.
CS223: Software Engineering Lecture 21: Unit Testing Metric.
Design Metrics CS 406 Software Engineering I Fall 2001 Aditya P. Mathur Last update: October 23, 2001.
Object Oriented Metrics
A Hierarchical Model for Object-Oriented Design Quality Assessment
Metrics of Software Quality
Chapter 24 - Quality Management
Software Metrics 1.
Course Notes Set 12: Object-Oriented Metrics
Design Characteristics and Metrics
Lecture 15: Technical Metrics
Object-Oriented Metrics
Software Project Sizing and Cost Estimation
CS427: Software Engineering I
Design Metrics Software Engineering Fall 2003
Design Metrics Software Engineering Fall 2003
Coupling and Cohesion By Bonnie Ngu.
Software Development & Project Management
Information flow-Test coverage measure
Mei-Huei Tang October 25, 2000 Computer Science Department SUNY Albany
Software metrics.
Software Metrics using EiffelStudio
Chapter 8: Design: Characteristics and Metrics
Presentation transcript:

Software Metrics SAD ::: Fall 2015 Sabbir Muhammad Saleh

Introduction

Introduction (contd.) Measurement: Metrics used to evaluate: enables objective evaluation can be applied to improve software process assists project management Metrics used to evaluate: Efficiency Complexity Understandability Reusability Testability / Maintainability Measurements enables us to evaluate the situation properly. It can also be applied to improve the software process and hence assist project management The common measurement entities are the software metrics, which helps us to evaluate :

LCOM = |P|-|Q|, if |P| > |Q| McCabe's Cyclomatic Complexity is the number of 'linearly independent' paths through the program (or flow graph) and this value is computed using the formula: v(F) =e-n+2 where n = total number of nodes; e = total number of edges or arcs; and v(F) is the cyclomatic number. Introduction (contd.) Metrics under research consideration: Cyclomatic code complexity (CCC) Weighted Methods per Class (WMC) Depth of Inheritance Tree (DIT) Number of Children (NOC) Coupling between Classes (CBC) Lack of Cohesion in Methods (LCOM) COCOMO II Suppose a class C has methods M1, M2... Mn defined on it. Let the complexity of the method M1 be c1, then WMC = Let Ii and Ij be the set of instance variables accessed by the methods M1 and M2, Q be the set of all cohesive pairs of methods, that is, all (Mi, Mj) such that Ii and Ij have a non-null intersection. Let P be the set of all non-cohesive pairs of methods, that is, pairs such that the intersection of sets of instance variables they access is null. Then LCOM is defined as LCOM = |P|-|Q|, if |P| > |Q| otherwise 0.

Cyclomatic Complexity: Threshold Values Risk evaluation 01 – 10 Simple Program, without much risk 11 – 20 More complex program, moderate risk 21 – 50 Complex program, high risk   50 Un-testable program, very high risk

Number of Complex Methods in a class Weighted Methods Per Class: Number of Complex Methods in a class Effect High - Potentially Error Prone - Impact on the children of the class - Reusability decreases Low Reusability Increases

Increase (  ) / Decrease (  ) Along with increasing DIT Depth of Inheritance Tree [DIT]: Attribute Increase (  ) / Decrease (  ) Along with increasing DIT Reusability Maintainability  Portability Functionality  Reliability Efficiency

Increase (  ) / Decrease (  ) along with increasing NOC Number of Children [NOC]: Attribute Increase (  ) / Decrease (  ) along with increasing NOC Reusability  Changeability Portability  Reliability Adaptability Maintainability

Coupling Between Classes [CBC]: CBC Nominal Range Analysis a class has no relationship to any other class in the system, not a part of the system 1 – 4 Good, the class is loosely coupled   4 the class is too tightly coupled, complicated testing and modification, and limited re-use possibilities.

Lack of Cohesion in Methods [LCOM]: Complexity ( Probable increase in error ) Cohesion in methods

Coefficient<Effort Factor> COCOMO (COnstructive COst MOdel) II: Based on SLOC (source lines of code) characteristic, and operates according to the following equations: Effort = PM = Coefficient<Effort Factor>*(SLOC/1000)^P Development time = DM = 2.50*(PM)^T Required number of people = ST = PM/DM where: PM : person-months needed for project SLOC : source lines of code P : project complexity (1.04-1.24) DM - duration time in months for project T : SLOC-dependent coefficient (0.32-0.38) ST : average staffing necessary Software Project Type Coefficient<Effort Factor> P T Organic 2.4 1.05 0.38 Semi-detached 3.0 1.12 0.35 Embedded 3.6 1.20 0.32

THE END

Depth of Inheritance Tree (DIT) The deeper a particular class is in a class hierarchy, the more methods it has available for reuse, thereby providing a larger reuse potential Inheritance increases coupling, which makes changing a class harder A class deep in the hierarchy has a lot of methods it can inherit, which makes it difficult to predict its behavior The DIT of a class C in an inheritance hierarchy is the depth from the root class in the inheritance tree It is the length of the shortest path from the root of the tree to the node representing C or the number of ancestors C has In case of multiple inheritance, the DIT metric is the maximum length from a root to C Statistical data suggests that most classes in applications tend to be close to the root, with the maximum DIT metric value being around 10 Most the classes have a DIT of 0 (that is, they are the root). The designers tend to keep the number of abstraction levels (reflected by the levels in the inheritance tree) small, presumably to aid understanding. In other words, designers might be giving upon reusability in favor of comprehensibility The experiments show that DIT is very significant in predicting defect-proneness of a class: the higher the DIT the higher is the probability that the class is defect-prone

Number of Children (NOC) The number of children (NOC) metric value of a class C is the number of immediate subclasses of C This metric can be used to evaluate the degree of reuse, as a higher NOC number reflects reuse of the definitions in the superclass by a larger number of subclasses It also gives an idea of the direct influence of a class on other elements of a design The larger the influence of a class, the more important the class is correctly designed In the empirical observations, it was found that classes generally had a small NOC metric value, with a vast majority of classes having no children This suggests that in the systems analyzed, inheritance was not used very heavily The data suggest that the larger the NOC, the lower the probability of detecting defects in a class The higher NOC classes are less defect-prone. The reasons for this are not very clear or definite.

Coupling between Classes (CBC) Coupling between classes of a system reduces modularity and make class modification harder It is desirable to reduce the coupling between classes The less coupling of a class with other classes, the more independent the class, and more easily modifiable Coupling between classes (CBC) is a metric that tries to quantify coupling that exists between classes The CBC value for a class C is the total number of other classes to which the class is coupled Two classes are considered coupled if methods of one class use methods or instance variables defined in the other class There are indirect forms of coupling (through pointers, etc.) that are hard to identify The experimental data indicates that most of the classes are self-contained and have low CBC value. Some types of classes, for example the ones that deal with managing interfaces, generally tend to have higher CBC values The data found that CBC is significant in predicting the fault-proneness of classes, particularly those that deal with user interfaces.