DOC PREVIEW
CU-Boulder CSCI 5828 - Software metrics

This preview shows page 1-2-15-16-17-32-33 out of 33 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

 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 LOCSoftware Metrics Product Process External Dynamic Internal Static Design Specification Code Hybrid Resource Structured Procedural Object Oriented Object Oriented 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 questioni = 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 3 5 4 6 2 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 sub-classes 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 testingMIF = .  Mi(Ci) is the number of methods inherited and not overridden in Ci  Ma(Ci) is the


View Full Document

CU-Boulder CSCI 5828 - Software metrics

Documents in this Course
Drupal

Drupal

31 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

22 pages

Load more
Download Software metrics
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Software metrics and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Software metrics 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?