Quantify the project Quantifying schedule performance work effort project status Helps software to be compared and evaluated Better Estimates Use the measure of your current performance to improve your future work estimates Resolve Software crises Such as wrong cost estimates slow productivity rate and so on Estimate the cost schedule of future projects Evaluate the productivity impacts of new tools and techniques Establish productivity trends over time Improve software quality Forecast future staffing needs Anticipate and reduce future maintenance needs Software metrics are units of measurement of software product and the process by which it is developed Metrics and measures form the basis for numerous models of the software development process Products Explicit results of software development activities Requirement specifications documents design diagrams source code listings and the end product Processes Activities related to software development life cycle Time effort and cost Resources Available resources characteristics Number of developers their skills and hardware reliability and performance Hybrid Mixtures of product and process metrics Cost per function point and time to deliver and LOC Software Metrics Product Hybrid External Internal Dynamic Static Design Specification Object Oriented Structured Resource Process Code Object Oriented Procedural External metrics Properties visible to the users Not available till the late stages of the software development life cycle Functionality quality reliability maintainability Internal metrics Address properties visible only to the development team Cost effort LOC speed memory Static Collected from the static artifacts of the software such as specification Documents design diagrams and code listings Dynamic Collected during the run time of the software from its executable form Extent of class usage Dynamic Coupling and Dynamic Lack of Cohesion Specification Analyze the product specifications and provides early feedback about the developing software product De Marco s Bang metric would distinguish a system whether the system is function strong or data strong Design Measured at a bit later stage of the software development process Helps refining the design Henry and Kafura s information flow reuse ratio and coupling factor Properties of the written code Size Oriented Metrics Size of the software produced LOC Lines Of Code KLOC 1000 Lines Of Code SLOC Statement Lines of Code ignore whitespace Typical Measures Errors KLOC Defects KLOC Cost LOC Documentation Pages KLOC McCabe s Complexity Measures McCabe s metrics are based on a control flow representation of the program A program graph is used to depict control flow Nodes represent processing tasks one or more code statements Edges represent control flow between nodes Applied to individual functions modules methods or classes within a program Count of the number of linearly independent paths through the source code M E N 2P where M cyclomatic complexity E the number of edges of the graph N the number of nodes of the graph P the number of connected components For a single subroutine P is always equal to 1 and increases with the number of sub programs in question i 0 If i n 1 do j i 1 while j n do if A i A j then swap A i A j end do i i 1 end do 1 2 3 6 4 5 M 8 6 2 4 Basic Set 1 6 1 2 6 1 2 3 4 5 6 1 2 3 5 6 Helps in determining the number of test cases that are necessary to achieve thorough test coverage of a particular module M is the number of enclosed regions areas of the planar graph Number of regions increases with the number of decision paths and loops A quantitative measure of testing difficulty and an indication of ultimate reliability Experimental data shows value of M should be no more then 10 testing is very difficulty above this value Weighted Methods per Class Method Hiding Factor MHF Method Inheritance Factor MIF Polymorphism Factor PF Coupling Factor CF WMC ci is the complexity e g cyclomatic complexity of each method in a class How much time and effort is required to develop and maintain the object The larger the number of methods in an object the greater the potential impact on the children Objects with large number of methods are likely to be more application specific limiting the possible reuse Classes with a large Weighted Methods Per Class value can often be refactored into two or more classes Measure of the use of the information hiding concept that is supported by the encapsulation mechanism A very low MHF indicates an insufficiently abstracted implementation Conversely a high MHF would indicate very little functionality MHF Usage Helps to maintain the modularity of the code Reduce side effects due to implementation refinement Support a top down approach Test and integrate systems incrementally Measure of inheritance Depth of Inheritance Tree DIT is the maximum length from a node to the root base class Lower level subclasses inherit a number of methods making behavior harder to predict Deeper trees indicate greater design complexity Number Of Children NOC is the number of subclasses immediately subordinate to a class Viewpoints Depth is generally better than breadth in class hierarchy since it promotes reuse of methods through inheritance Classes higher up in the hierarchy should have more subclasses then those lower down NOC gives an idea of the potential influence a class has on the design classes with large number of children may require more testing MIF Mi Ci is the number of methods inherited and not overridden in Ci Ma Ci is the number of methods that can be invoked with Ci Polymorphism potential is measured The number of methods that redefines inherited methods divided by maximum number of possible distinct polymorphic situations PF Mn is the number of new methods Mo is the number of overriding methods DC number of descendent classes of a base class Allows refinement of the class taxonomy Coupling factor represents the number of collaborations between two classes fan out of a class the number of other classes that are referenced in the class As collaboration increases reuse decreases High fan outs represent class coupling to other classes objects and thus are undesirable High fan ins represent good object designs and high level of reuse Not possible to maintain high fan in and low fan outs across the entire system The Process Select appropriate metrics for problem Utilized metrics on problem Assessment and feedback Formulate Collect Analysis
View Full Document
Unlocking...