Software Metrics.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Design Concepts and Principles
Project Estimation: Metrics and Measurement
Metrics for Process and Projects
Software Engineering II - Topic: Software Process Metrics and Project Metrics Instructor: Dr. Jerry Gao San Jose State University
Software Metrics II Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
R&D SDM 1 Metrics How to measure and assess software engineering? 2009 Theo Schouten.
Software Requirements
CSC 395 – Software Engineering
Testing an individual module
SE 555 – Software Requirements & Specifications Introduction
Software Process and Product Metrics
Non-functional requirements
Software Metrics.
University of Toronto Department of Computer Science © 2001, Steve Easterbrook CSC444 Lec22 1 Lecture 22: Software Measurement Basics of software measurement.
Software Project Management Fifth Edition
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Refactoring.
1 Software Quality CIS 375 Bruce R. Maxim UM-Dearborn.
Software Engineering Software Process and Project Metrics.
Chapter 6 : Software Metrics
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Chapter 23 Software Cost Estimation.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Ranga Rodrigo. The purpose of software engineering is to find ways of building quality software.
Software Measurement & Metrics
Software cost estimation Predicting the resources required for a software development process 1.
Product Metrics An overview. What are metrics? “ A quantitative measure of the degree to which a system, component, or process possesses a given attribute.”
Version control – Project repository, version management capability, make facility, issue/bug tracking Change control Configuration audit – compliments.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
Software Quality Metrics
Concepts of Software Quality Yonglei Tao 1. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability.
Lecture 4 Software Metrics
Software Testing and Quality Assurance Software Quality Assurance 1.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Estimation - Software Metrics Managers frequently have to measure the productivity of software engineers.
SEG3300 A&B W2004R.L. Probert1 COCOMO Models Ognian Kabranov.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Chapter 13 Multiple Regression
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 26Slide 1 Software cost estimation l Predicting the resources required for a software development.
CSc 461/561 Information Systems Engineering Lecture 5 – Software Metrics.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15a: Product Metrics for Software Software Engineering: A Practitioner’s Approach, 6/e Chapter.
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.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Advanced Software Engineering Lecture 4: Process & Project Metrics.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.
1 Software Requirements Descriptions and specifications of a system.
Cost9b 1 Living with Function Points Bernstein and Lubashevsky Text pp
Object Oriented Systems Design
A Hierarchical Model for Object-Oriented Design Quality Assessment
Classifications of Software Requirements
Software Metrics 1.
Software Metrics.
Course Notes Set 12: Object-Oriented Metrics
McCall’s Quality Factors
Lecture 15: Technical Metrics
Object-Oriented Metrics
Lecture 17 Software Metrics
Software Development & Project Management
Personal Software Process Software Estimation
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Software metrics.
Software Metrics SAD ::: Fall 2015 Sabbir Muhammad Saleh.
Software Effort Estimation
COCOMO MODEL.
Presentation transcript:

Software Metrics

Engineering Engineering is a discipline based on quantitative approaches All branches of engineering rely upon the use measurements Software Engineering is not an exception SE uses measurements to evaluate the quality of software products

Software Metrics Software metrics are an attempt to quantify the quality of the software Measures are expressed in terms of computable formulas or expressions Elements of these expressions are derived from source code, design and other artifacts used in software development

Quality Measurement Direct measurement Indirect measurement Are values calculated directly from known sources (source code, design diagram etc.) E.g. number of software failures over some time period Indirect measurement Cannot be so accurately defined nor directly realized E.g. reliability, maintainability, usability

Advantages of Metrics Metrics are a tool for comparing certain aspects of software Sometimes metrics provide guidance for evaluating complexity, time and cost of a future product Metrics can be used to evaluate software engineers Metrics can even be applied to the creation of development teams

Example A general rule in allocating project time: 25%: Analysis & Design 50%: Coding & Unit Test 25%: Integration/System/Acceptance Test

Weyuker’s Properties of Metrics Two programs for the same application need not have the same metrics values If a program P consists of modules Q and R, the complexity of P is generally not the sum of the complexities of Q and R

GOM (Goal Oriented Metrics) General metrics equation F = c1× m1+c2× m2+…+cn× mn Cj is a regression coefficient and mk is a primitive metric (those that are directly observable from software artifacts) Metric F is found by computing all mk and then evaluating the expression for predefined cj

Some Quality Factors Accuracy Completeness Consistency Expandability Accuracy refers to the precision of computations and control Completeness Completeness is the degree to which full implementation of required functionality has been achieved Consistency Consistency refers to the degree to which requirements are continued (i.e., not changed) throughout the development process Expandability Expandability is the degree to which a product can be extended to include additional features Hardware Independence Hardware independence is the degree to which a product depends on the underlying hardware

ISO 9126 Quality Factors Reliability Portability Reliability refers to the amount of time software is available for use Reliability can be measured by the frequency of failure, the severity of failure, the accuracy of output results, the ability to recover from failure and mean-time –to-failure Portability Portability is the degree to which software can be ported to another platform or environment Portability is measured by adaptability, installability, conformance, hardware and software dependences

What makes a software metric effective? It must be easy to derive, calculate and understand It must be useful for improving some aspect of software engineering It should be independent of any programming language It should be platform and environment independent

Function-point Metrics Function-point metrics are intended to measure the size complexity of a software system They can be evaluating using a data flow diagram, and counting any of the following: The number of user inputs The number of outputs to user The number of user inquiries The number of files or data stores The number of external interfaces

Sample formula for function-point metrics Fp = total of primitive metrics × (0.65 + 0.01 × ) Where Fj is a value to be chosen by the developer to indicate the complexity of this product with regard to other competitive products. Typical values for Fj range from 1 to 50

Function-point Example Function Points: Application requirements are examined to determine project/code size: Count number of inputs, outputs, inquiries, master files, interfaces the program will require. Measures product size for the user's point of view Feature Points: Includes # of complex algorithms

Example Continued  Step 1: To estimate Function Points count the number of:

Example Continued Step 2: Multiply each category count by its’ weight: ________________ UnadjustedFunctionPoints (UFP) = SUM(I=0..6) [#AttributeTypeI ComplexityFactor]

Example Continued Step 3: Calculate the Degree of Influence: DegreeOfInfluence (DI): Determine complexity of 14 factors: Each factor is rated on a scale from 0 (no influence) to 5 (high influence)

Example Continued Sum the Degree of Influence factors and solve the below equation. Function Points = UFP * (0.65 + 0.01 * DegreeOfInfluence) _____________

A metric for specification quality Specificity is the opposite of ambiguity Specificity = Where nui refers to the number of functional requirements that are interpreted identically by all reviewers and nr refers to the total number of requirements (both functional and non-functional) in the requirements document Completeness can be measured as follows: Completeness = Where nu refers to the number of unique functional requirements that do not depend on any other requirement, nj refers to the number of external inputs and ns number of states of the system

A metric for measuring coupling between two modules in imperative paradigm Coupling = k / M Where M = di + (a×ci)+do+(b×co)+gd+(c×gc)+w+r di the number of input data parameters ci number of input control parameters do number of output data parameters co number of output control parameter gd number of global data varials gc number of global control variables w number of modules called r number of modules calling this module k =1, a =b= c=2(all these can be adjusted)

Metrics for O-O Systems Like testing, metric equation for procedural paradigm have been found to be inadequate for O-O paradigm Several OO metrics have been published in the literature: C&K metrics(1994), Kim’s metrics(1994,1996), MOOD’s metrics(1995), Liu’s metrics(1999)

Metrics for O-O Systems DOR(C )= Where r( C ) denotes the number of subclasses of C t denotes the total number of classes in the program tr denotes the sum of all subclasses in the program

Object Oriented Class Estimation Object Oriented Class Estimation A. Estimate the number of classes in code to be developed/modified: ________ B. Categorize the type of user interface and assign weight: No UI: 2.0 Simple text-based UI: 2.25 Simple GUI 2.5 Complex GUI 3.0 C. Multiply # Classes by UI Weight: ________ D. Add A + C to get estimate of total number of classes: ________ E. Multiply D (total # classes) by # person days/class (15-20) ________

Calculation of ‘Lack of Cohesion’ metrics Lack of Cohesion (LCOM) for a class is defined as follows: Let ‘C’ denote the class for which LCOM is computed. Let ‘m’ denote the number of methods in C. Let ‘a’ denote the attributes of C. Let ‘m(a)’ denote the methods of C that access the attribute ‘a’ in C. Let ‘Sum(m(a))’ denote the sum of all ‘m(a)’ over all the attributes in C. Now, LCOM( C ) is defined as ( m – Sum (m(a)) / a) / (m – 1)

Cohesion Metrics If class C has only one method or no method, LCOM is undefined. If there are no attributes in C, then also LCOM is undefined. In both situations, for computational purposes, LCOM is set to zero. Normally, LCOM value is expected to be between 0 and 2. A value greater than 1 is an indication that the class must be redesigned. The higher is the value of LCOM, the lower is the cohesion and hence the need for redesign.

Example

Calculation The class ‘Account’ (without constructor) ‘Account’ (with constructor) m = 4, a = 3 m = 5, a = 3 m(Account#) = 1 m(Account#) = 2 m(UserID) = 1 m(UserID) = 2 m(Balance) = 3 m(Balance) = 3 sum(m(a)) = 5 sum(m(a)) = 7 LCOM (Account) = (4 – 5 / 3) / (3 – 1) = 1.667 LCOM(Account) = (5 – 7 / 3) (5 – 1) = 0.667

Calculation m = 1, a = 2 m = 2, a = 2 m(UserID) = 0 m(UserID) = 1 The class ‘LoginAccount’ (without constructor) ‘LoginAccount’ (with constructor) m = 1, a = 2 m = 2, a = 2 m(UserID) = 0 m(UserID) = 1 m(Password) = 1 m(Password) = 2 sum(m(a)) = 1 sum(m(a)) = 3 LCOM (LoginAccount) = (1 – 1 / 2) / (1- 1) LCOM(LoginAccount) = (2 = 0 (set to zero because m = 1) – 3 / 2) (2 – 1) = 0.5

Calculation m = 4, a = 1 m = 5, a = 1 m(Accounts) = 4 m(Accounts) = 5 The class ‘AccountsDatabase’ (without constructor) ‘AccountsDatabase’ (with constructor) m = 4, a = 1 m = 5, a = 1 m(Accounts) = 4 m(Accounts) = 5 sum(m(a)) = 4 sum(m(a)) = 5 LCOM (AccountsDatabase) = (4 – 4 / 1) / (4 – 1) LCOM(AccountsDatabase) = (5 – 5/1)(5-1) = 0 = 0 / 3 = 0

Calculation The class ‘Login Accounts Database’ Exactly similar to ‘Accounts Database’ and hence LCOM (Login Accounts Database) = 0, both for with constructor and without constructor.

MOOD’s Metric for Measure of Polymorphism Polymorphism factor = Where TC denotes the number of classes in the system DC(Ci ) denotes the number of subclasses of Ci Mo(Ci ) denotes the number of overriding methods in Ci Mn(Ci ) denotes the number of new methods in Ci

MOOD’s Metric on Degree of Coupling between Classes Coupling factor = Where Is_client(Ci, Cj) = 1 if client Ci has at least one non-inheritance reference to supplier classes Cj; otherwise, it is 0 denotes the maximum number of coupling due to inheritance

Problem with metrics Defining metrics formulas is difficult No standards and no guidelines: each equation defines a metric for a particular application Correctness of the metrics formulas must be established before using them Metrics measure a product, too late to predict the complexity of the product