Software Engineering Chapter 7 Software Measurement and Metrics

Software Engineering Chapter 7: Software Measurement and Metrics Eng. Sultan M. Al-Rushdan 1

Software Measurement • Measurement is the process by which numbers or symbols are assigned to attributes of entities in such way to describe them according to clearly defined unambiguous rules. • Metrics and measurements are necessary for effective monitoring: – How – The far it is progressed. much development has taken place. far behind schedule it is. quality of development so far. 2

Software Measurement Two types of measurements: 1. Direct measures: includes cost, effort applied, lines of code, execution speed, memory size. 2. Indirect measures: includes functionality, quality, complexity, efficiency, reliability, maitaiability. 3

Software Metrics Software metrics are numerical data related to software development. They are related to four function of management: 1. Planning: metrics are bases for cost estimation, training planning, resource planning, scheduling and budget. 2. Organization: size and schedule metrics influence project metrics. 3. Controlling: used for status and track development. 4. Improving: used as a tool for process improvement and to identify where improvement should be concentrated. 4

Categories of Metrics • Product metrics: describe the characteristics of the product such as size, complexity, design features, performance, efficiency, reliability and quality level. • Process Metrics: To measure the efficiency and effectiveness of the software process, examples are: – Effort required in process. – Time to produce a product. – Number of defect found during testing. – Effectiveness of defect removal. – Maturity of the process. 5

Categories of Metrics • Project metrics: describes the project characteristics and execution: – Number of software developers. – Staffing pattern over the life cycle of software. – Cost and schedule. – Productivity. 6

Attributes of Effective software Metrics Attributes that should be encompassed be effective software metric: 1. Simple and computable. 2. Empirically and intuitively persuasive. 3. Consistent and objective. 4. Consistent in the use of units and dimension. 5. Programming language independent. 6. An effective mechanism for high quality feedback. 7

Halstead’s Software Science Metrics • 8

Halstead’s Software Science Metrics • 9

Halstead’s Software Science Metrics • 10

Halstead’s Software Science Metrics • 11

Halstead’s Software Science Metrics Example: proc(x, y) int z=0; while x>0 z=z+y; x=x-1; end while; peint z; operator count operand count = 3 X 3 ; 5 Y 2 While end 1 -while Z 4 > 1 0 2 + 1 1 1 - 1 print 1 () 1 12

Halstead’s Software Science Metrics • operator count operand count = 3 X 3 ; 5 Y 2 While end 1 -while Z 4 > 1 0 2 + 1 1 1 - 1 print 1 () 1 13

Metrics for Software Project Size Estimation • Project size is a measure of problem complexity in term of the effort and time required to develop the product. • Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of software produced. • Examples: – – – Line of code (LOC). Token Metrics. Function Point (FP) Metric. Feature Point Metric. Complexity Metric. 14

Lines of Code (LOC) • Is the simplest metric to estimate project size. • Project size is estimated by counting the number of source code instruction in the delivered program. • Versions of LOC: – LOC is used as DSI(Delivered source Instruction). – LOC is used as KDSI(Thousand of Delivered source Instruction) 15

Lines of Code (LOC) DSI is defined as following: • Only Source lines that are delivered as part of product are included. • Source code created by application generator are excluded. • Code instruction is one line of code. • Declaration are counted as instruction. • Comments are not counted as instruction. 16

Lines of Code (LOC) • Determining LOC at the end of project is a very simple job. • However accurate estimation of LOC at the beginning of project is very difficult. • To estimate LOC at the beginning of project, project managers divide the problem to modules, and modules to sub modules and so on until the size of leaflevel module can be approximated. • To be able to do this, past experience in developing similar product is helpful. 17

Lines of Code (LOC) Advantages: – Simple to measure. Disadvantages: – It is language dependent. – Bad software design may cause excessive line of code. – It is defined on code. – User cannot easily understand it. 18

Token Metrics • LOC give numerical value on problem size can vary widely with individual coding style (different programmer write different code for same problem) • This problem can be overcome by counting token not LOC. • Token Metric can be calculated by counting Token in source code. • Token is a simple entity that make up a prigram (e. g. if, for, switch, etc. are token in C language). 19

Function Point(FP) Metric • The conceptual idea behind FP metric is that the size of code is directly dependent on the number of different functions or features it support. • A software product support many features would certainly be of larger size. • Also the size of software product depend on the number of files and the number of interfaces it uses. 20

Function Point(FP) Metric FP metric is computed in 2 steps: 1. Compute the Unadjusted Function Point (UFP). 2. Compute the Technical Complexity Factor (TCF) 21

Function Point(FP) Metric Unadjusted Function Point (UFP). The UFP is calculated by: The sum of all occurrence is computed by multiplying each function count with a weighting and adding up all values. The weights are based on the complexity of the function. 22

Function Point(FP) Metric Unadjusted Function Point (UFP). Weighting Factor Measurement Parameter Number of user Input Number of user Output Number of user Inquiries Number of Files Number of external Interfaces count Simple average complex ˟ ˟ ˟ 3 4 6 = 4 5 7 = 3 4 6 = 7 10 15 = 5 7 10 = Count Total = 23

Function Point(FP) Metric Unadjusted Function Point (UFP). • Number of Inputs: each data inputs is counted, not individual input is counted but group related input for example name, age, sex, salary, address of an employee considered single input. • Number of Outputs: refer to report printed, screen output, error messages, etc. the individual data items are not counted but group data items. 24

Function Point(FP) Metric Unadjusted Function Point (UFP). • Number of Inquiries: number of distinct interactive inquiries done by user which are user command that require certain action by system. • Number of Files: Each logical file is counted. • Number of Interfaces: the interfaces used to exchange information with other systems. 25

Function Point(FP) Metric Technical Complexity Factor (TCF) • 26

Function Point(FP) Metric Technical Complexity Factor (TCF) 1. Data Communication 9. Reusability. 2. Performance 10. Installation ease. 3. Heavily used 11. Operation ease. configuration. 4. Transaction rate. 12. Multiple site. 5. Online data entry. 13. Facilitate change. 14. Distributed 6. End user Function. efficiency. 7. Online update. 8. Complex Processing. 27

Function Point(FP) Metric • 28

Function Point(FP) Metric Advantages of Function Point 1. Language Independent. 2. More Accurate than LOC. 3. It is not restricted to Code. 4. The necessary data is available early in project. 29

Feature Point Metric • A major shortcoming of function point metric is that it does not take into account the algorithm. • An extension to Function point metric proposed (Feature Point Metric). • Feature Point Metric incorporate an extra parameter algorithm complexity, which ensure that the more complex the algorithm the greater effort required to develop. 30

Complexity Metrics • Measure the complexity of executable code within procedure. • This include the internal complexity of a single procedure and the complexity of data structure in and out of a procedure. • High complexity may result in bad understandability and more errors. • Complex procedure need more time to develop and test. • So excessive complexity should be avoided. • Complex procedures should be rewrite or divided to several procedures. 31

Complexity Metrics • Complexity often have positive correlation to code size(big program of function is likely to be complex as well). • Some time small functions can be very complex so a combination of LOC and complexity metric is recommended to use. • Shortcoming of complex code are: – – – Harder to understand. More likely will have defects. Harder to change. Require longer time produce. More difficult to be reused. 32

Cyclomatic Complexity • The most widely used complexity metric in software engineering. – It is easy to understand. – easy to calculate. – it gives a useful results. • It is a measure of structure complexity. • It measure the number of linearly independent path in source code. • In practice it count the number of test condition in a program. 33

Cyclomatic Complexity • 34

Cyclomatic Complexity • 35

Cyclomatic Complexity 3. Cyclomatic complexity of program can be computed by computing the number of decision statement in a program if π is the number of decision statement of a program then cyclomatic complexity is π+1. 36

Cyclomatic Complexity • 37

Object Oriented Metrics • OO metric are measurements on OO application used to determine the success of a process, and to quantify improvements through out the software process. • These metrics can be used to reinforce good OO programming techniques which lead to more reliable code. 38

Object Oriented Metrics • Object Oriented Software Engineering OOSE) metric are units of measurements that are used to characterize: – Object oriented software engineering product(e. g. design source code and test case). – Object oriented software engineering processes(e. g. the activity of analysis, designing, and coding) – Object oriented software engineering people(e. g. the efficiency of individual tester, or the productivity of individual designer) 39

Why OOP Metrics Different? OOSE metrics are deferent because: 1. Localization: in OO localization is about object so metrics must recognize objects as bases of decomposition rather functions. Also the localization between objects and functions is not one -to-one. 40

Why OOP Metrics Different? 2. Encapsulation: is the packaging or binding together a collection of item and in case of OO encapsulation includes data and functions and: a) Knowledge of state. b) Advertising capability. c) Other objects(in case of composite objects). d) Exception(optionally). e) Constants(optionally). f) Concepts. 41

Why OOP Metrics Different? 3. Information hiding: object hides some of its data and function from outside only a part is exposed in a magnitude that is necessary to accomplish its goals. 42

Why OOP Metrics Different? 4. Inheritance: in which an object acquire characteristics from one or more other objects. 5. Abstraction: which mean focusing on behavior rather than implementation. Moving up in hierarchy means more abstraction less implementation. 43

Measuring on Class Level The following measurements is performed on class level: 1. Coupling. 2. Inheritance. 3. Methods. 4. Attributes. 5. Cohesion. 44

Measuring on System Level The following metrics are implemented on system level: 1. Number of methods per class(NOM) 2. Number of Attributes per class (NOA) 3. Weighted number methods in class (WMC): is the sum of all complexities of all methods in a class(complexity measured using cyclomatic complexity) 4. Response for a class (RFC): Number of method (Internal or External) in a class. 45

Coupling Metrics Coupling in OO increase complexity, reduce encapsulation and limit understanding and maintainability, metrics to measure coupling are: 1. Data Abstraction Coupling(DAC): count the references to abstract data types. 2. Coupling between objects(CBO): number of other classes to which it is coupled 3. Message Passing Coupling (MPC): Number of send statement defined in a class 4. Coupling Factor (CF) ratio of actual number of coupling in the system to the maximum possible coupling 46

Cohesion Metrics Cohesion is a measure of the degree to which the elements of a class are functionally related to each other. Cohesion metrics are: 1. Lack of cohesion in methods (LCOM): measure the dissimilarity of methods in a class by instance variable or attributes. 47

Cohesion Metrics • 48

Cohesion Metrics 2. Tight Class Cohesion(TCC): the percentage of pairs of public methods of the class with direct common attributes usage. 3. Loose class cohesion(LCC): same as TCC but it consider the indirect use. 4. Information based cohesion(ICH): the number of invocations of other methods of the same class, weighted by the number of parameters of invoked method. 49

Inheritance Metrics 1. Depth of Inheritance Tree(DIT): the maximum number of steps from class node to root class. 2. Number Of Children(NOC): the number of immediate subclass of a class in hierarchy. 50

Inheritance Metrics 3. Attribute Inheritance Factor (AIF): Ratio of the sum of inherited attributes in all classes of the system to the total number of attributes for all classes. 4. Method Inheritance Factor(MIF): Ratio of the sum of inherited methods in all classes of the system to the total number of methods for all classes. 51

Chapter 7: END OF CHAPTER 52