Software Engineering

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

2. 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 far it is progressed. • How much development has taken place. • How far behind schedule it is. • The quality of development so far.

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

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

5. 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.

6. 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.

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

8. Halstead’s Software Science Metrics Is an analytical technique to measure size, development effort and development cost of software. A set of primitive program parameters used to develop metrics, those primitives are: • : number of unique operators used in program. • : number of unique operands used in program. • : total number of operators used in programs. • : total number of operands used in program. Operands and operators have intuitive meaning depending on programming language, the distinction is that operators work on operands.

9. Halstead’s Software Science Metrics Halstead’s metrics are: 1- Length and Vocabulary: the length of the program is the total usage of all operators and operands in the program The program vocabulary is the number of unique operators and operands used in the program . 2- Program Volume: the program length can vary from developer to another depending on programming style and programming language used, Program Volume V is the minimum number of bits needed to encode the program

10. Halstead’s Software Science Metrics Halstead’s metrics are: 3- Program length equation: the calculated program length is . 4- Potential Volume: The potential volume V* is defined as the volume of the most succinct program in which a problem can be coded :is the count of unique input and output parameters. 5- Program Level: is the relationship between potential volume and program volume.

11. Halstead’s Software Science Metrics Halstead’s metrics are: 4- Difficulty: is the inverse of program level 5- Effort Equation: Measures the amount of mental activity needed to translate the existing algorithm into implementation 6- Time Equation: Shows time needed to translate the existing algorithm into implementation in the specified program language.

12. 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;

13. Halstead’s Software Science Metrics

14. 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.

15. 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)

16. 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.

17. 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 leaf-level module can be approximated. • To be able to do this, past experience in developing similar product is helpful.

18. 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.

19. 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).

20. 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.

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

22. Function Point(FP) MetricUnadjusted 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.

23. Function Point(FP) MetricUnadjusted Function Point (UFP). Weighting Factor

24. Function Point(FP) MetricUnadjusted 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.

25. Function Point(FP) MetricUnadjusted 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.

26. Function Point(FP) MetricTechnical Complexity Factor (TCF) TCF is computed by considering 14 factor each one is given a number between 0 and 6 represent influence of factor on the software being developed then it multiplied by weight. Then these factor are summed to find the Total Degree of Influence DI. TCF can be computed by

27. Function Point(FP) MetricTechnical Complexity Factor (TCF) • Data Communication • Performance • Heavily used configuration. • Transaction rate. • Online data entry. • End user efficiency. • Online update. • Complex Processing. • Reusability. • Installation ease. • Operation ease. • Multiple site. • Facilitate change. • Distributed Function.

28. Function Point(FP) Metric Finally FP can be computed by: Several other metric could be computed based on FP

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

30. 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.

31. 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.

32. 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.

33. 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.

34. Cyclomatic Complexity • There are three different ways to calculate Cyclomatic Complexity. • Given a control flow graph G of a program, the cyclomatic complexity V(G) can be computed as Where N is the number of nodes E is the number of edges P the total number of connected components.

35. Cyclomatic Complexity • Given a control graph G the cyclomatic complexity of a program can be computed as Any region enclosed by nodes and edges can be called bounded area.

36. Cyclomatic Complexity • 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.

37. Cyclomatic Complexity Example:

38. 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.

39. 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)

40. Why OOP Metrics Different? OOSE metrics are deferent because: • 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.

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

42. Why OOP Metrics Different? • 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.

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

44. Measuring on Class Level The following measurements is performed on class level: • Coupling. • Inheritance. • Methods. • Attributes. • Cohesion.

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

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

47. 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: • Lack of cohesion in methods (LCOM): measure the dissimilarity of methods in a class by instance variable or attributes.

48. Cohesion Metrics • Lack of cohesion in methods(LCOM): Conceder a class ciwith n methods M1,M2,…,Mnand let Ii=set of all instance variables used by method Mi.and let and If all sets are 0 then

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

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