Software metrics by Dr. B. J. Mohite
2 likes590 views
The document discusses software metrics, which are quantitative measurements used to improve software processes, assess quality, and aid in decision-making. It covers types of metrics including project management, process improvement, and product quality, along with methods for measuring attributes like complexity and defect rates. Additionally, the document outlines steps for selecting and applying effective software metrics to meet organizational and project goals.
![40
Step 12 – Consider Human Factors
The People Side of the Metrics Equation
• How measures affect people
• How people affect measures
“Don’t underestimate the intelligence of your
engineers. For any one metric you can come
up with, they will find at least two ways to
beat it.” [unknown]](https://image.slidesharecdn.com/bjmchapter2softwaremetrics-170909111354/85/Software-metrics-by-Dr-B-J-Mohite-40-320.jpg)
![42
Do
Select metrics
based on goals
Goal 1 Goal 2
Question 1 Question 2 Question 3 Question 4
Metrics 1 Metric 2 Metric 3 Metric 4 Metric 5
[Basili-88]
Focus on processes,
products & services
Processes,
Products &
Services
Provide feedback
Feedback
Data
Data Providers Metrics
Obtain “buy-in”](https://image.slidesharecdn.com/bjmchapter2softwaremetrics-170909111354/85/Software-metrics-by-Dr-B-J-Mohite-42-320.jpg)
Software metrics by Dr. B. J. Mohite
- 1. 1 Software Metrics • It refers to a broad range of quantitative measurements for computer software that enable to – improve the software process continuously – assist in quality control and productivity – assess the quality of technical products – assist in tactical decision-making By. Dr. B. J. Mohite 9850098225
- 2. 2 Measure, Metrics, Indicators • Measure. – provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attributes of a product or process. • Metrics. – relates the individual measures in some way. • Indicator. – a combination of metrics that provide insight into the software process or project or product itself.
- 3. 3 What Should Be Measured? measurement What do we use as a basis? • size? • function? project metrics process metrics process product product metrics
- 4. 4 Metrics of Process Improvement • Focus on Manageable Repeatable Process • Use of Statistical SQA on Process • Defect Removal Efficiency
- 5. 5 Statistical Software Process Improvement All errors and defects are categorized by origin The cost to correct each error and defect is recorded No. of errors and defects in each category is counted and ranked in descending order The overall cost in each category is computed Resultant data are analyzed and the “culprit” category is uncovered Plans are developed to eliminate the errors
- 6. 6 Causes and Origin of Defects Logic 20% Sofware Interface 6% Hardware Interface 8% User Interface 12% Data Handling 11% Error Checking 11% Standards 7% Specification 25%
- 7. 7 Metrics of Project Management • Budget • Schedule/ReResource Management • Risk Management • Project goals met or exceeded • Customer satisfaction
- 8. 8 Metrics of the Software Product • Focus on Deliverable Quality • Analysis Products • Design Product Complexity – algorithmic, architectural, data flow • Code Products • Production System
- 9. 9 How Is Quality Measured? • Analysis Metrics – Function-based Metrics: Function Points( Albrecht), Feature Points (C. Jones) – Bang Metric (DeMarco): Functional Primitives, Data Elements, Objects, Relationships, States, Transitions, External Manual Primitives, Input Data Elements, Output Data Elements, Persistent Data Elements, Data Tokens, Relationship Connections.
- 10. 10 Source Lines of Code (SLOC) • Measures the number of physical lines of active code • In general the higher the SLOC in a module the less understandable and maintainable the module is
- 11. 11 Function Oriented Metric - Function Points • Function Points are a measure of “how big” is the program, independently from the actual physical size of it • It is a weighted count of several features of the program • Dislikers claim FP make no sense wrt the representational theory of measurement • There are firms and institutions taking them very seriously
- 12. 12 complexity multiplier function points number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces measurement parameter 3 4 3 7 5 count weighting factor simple avg. complex 4 5 4 10 7 6 7 6 15 10 = = = = = count-total X X X X X Analyzing the Information Domain Assuming all inputs with the same weight, all output with the same weight, … Complete Formula for the Unadjusted Function Points: lesInternalFi terfacesExternalInInquiryOutputInputs WeiWifWinWoWi Unadjusted Function Points:
- 13. 13 Taking Complexity into Account Factors are rated on a scale of 0 (not important) to 5 (very important): data communications distributed functions heavily used configuration transaction rate on-line data entry end user efficiency on-line update complex processing installation ease operational ease multiple sites facilitate change MultiplierComplexity MultiplierComplexityFCM Formula:
- 14. 14 Typical Function-Oriented Metrics • errors per FP (thousand lines of code) • defects per FP • $ per FP • pages of documentation per FP • FP per person-month
- 15. 15 LOC vs. FP • Relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the design • Empirical studies show an approximate relationship between LOC and FP
- 16. 16 LOC/FP (average) Assembly language 320 C 128 COBOL, FORTRAN 106 C++ 64 Visual Basic 32 Smalltalk 22 SQL 12 Graphical languages (icons) 4
- 17. 17 How Is Quality Measured? • Design Metrics – Structural Complexity: fan-in, fan-out, morphology – System Complexity: – Data Complexity: – Component Metrics: Size, Modularity, Localization, Encapsulation, Information Hiding, Inheritance, Abstraction, Complexity, Coupling, Cohesion, Polymorphism • Implementation Metrics Size, Complexity, Efficiency, etc.
- 18. 18 Comment Percentage (CP) • Number of commented lines of code divided by the number of non-blank lines of code • Usually 20% indicates adequate commenting for C or Fortran code • The higher the CP value the more maintainable the module is
- 19. 19 Size Oriented Metric - Fan In and Fan Out • The Fan In of a module is the amount of information that “enters” the module • The Fan Out of a module is the amount of information that “exits” a module • We assume all the pieces of information with the same size • Fan In and Fan Out can be computed for functions, modules, objects, and also non-code components • Goal - Low Fan Out for ease of maintenance.
- 20. 20 Testing Metrics • Metrics that predict the likely number of tests required during various testing phases • Metrics that focus on test coverage for a given component
- 21. 21 Views on SE Measurement
- 22. 22 Views on SE Measurement
- 23. 23 Views on SE Measurement
- 24. 24 12 Steps to Useful Software Metrics Step 1 - Identify Metrics Customers Step 2 - Target Goals Step 3 - Ask Questions Step 4 - Select Metrics Step 5 - Standardize Definitions Step 6 - Choose a Model Step 7 - Establish Counting Criteria Step 8 - Decide On Decision Criteria Step 9 - Define Reporting Mechanisms Step 10 - Determine Additional Qualifiers Step 11 - Collect Data Step 12 - Consider Human Factors
- 25. 25 Step 1 - Identify Metrics Customers Who needs the information? Who’s going to use the metrics? If the metric does not have a customer -- do not use it.
- 26. 26 Step 2 - Target Goals Organizational goals – Be the low cost provider – Meet projected revenue targets Project goals – Deliver the product by June 1st – Finish the project within budget Task goals (entry & exit criteria) – Effectively inspect software module ABC – Obtain 100% statement coverage during testing
- 27. 27 Step 3 - Ask Questions Goal: Maintain a high level of customer satisfaction • What is our current level of customer satisfaction? • What attributes of our products and services are most important to our customers? • How do we compare with our competition?
- 28. 28 Step 4 - Select Metrics Select metrics that provide information to help answer the questions • Be practical, realistic, pragmatic • Consider current engineering environment • Start with the possible Metrics don’t solve problems -- people solve problems Metrics provide information so people can make better decisions
- 29. 29 Selecting Metrics Goal: Ensure all known defects are corrected before shipment • • • • • • •
- 30. 30 Metrics Objective Statement Template To understand evaluate control predict the attribute of the entity in order to goal(s) evaluate % defects found & corrected during testing To the in order to ensure all known defects are corrected before shipment Example - Metric: % defects corrected
- 31. 31 Step 5 - Standardize Definitions Developer User
- 32. 32 Step 6 - Choose a Measurement Models for code inspection metrics • Primitive Measurements: – Lines of Code Inspected = loc – Hours Spent Preparing = prep_hrs – Hours Spent Inspecting = in_hrs – Discovered Defects = defects • Other Measurements: – Preparation Rate = loc / prep_hrs – Inspection Rate = loc / in_hrs – Defect Detection Rate = defects / (prep_hrs + in_hrs)
- 33. 33 Step 7 - Establish Counting Criteria Lines of Code • Variations in counting • No industry accepted standard • SEI guideline - check sheets for criteria • Advice: use a tool
- 34. 34 Counting Criteria - Effort What is a Software Project? • When does it start / stop? • What activities does it include? • Who works on it?
- 35. 35 Step 8 - Decide On Decision Criteria Establish Baselines • Current value – Problem report backlog – Defect prone modules • Statistical analysis (mean & distribution) – Defect density – Fix response time – Cycle time – Variance from budget (e.g., cost, schedule)
- 36. 36 Step 9 - Define Reporting Mechanisms Open Fixed Resolved Jan-97 23 13 3 Feb-97 27 24 11 Mar-97 18 26 15 Apr-97 12 18 27 0 40 80 120 0 20 40 60 80 100 120 0 20 40 60 80 100 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr 1 2 3 4 5 6 7 8 9 10 11 12 0 20 40 60 80 100 Jan Mar May July 0 40 80 120 160 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr
- 37. 37 Step 10 - Determine Additional Qualifiers A good metric is a generic metric Additional qualifiers: • Provide demographic information • Allow detailed analysis at multiple levels • Define additional data requirements
- 38. 38 Step 11 – Collect Data What data to collect? • Metric primitives • Additional qualifiers Who should collect the data? • The data owner – Direct access to source of data – Responsible for generating data – Owners more likely to detect anomalies – Eliminates double data entry
- 39. 39 Examples of Data Ownership Owner Examples of Data Owned • Management • Schedule • Budget • Engineers • Time spent per task • Inspection data including defects found • Root cause of defects • Testers • Test Cases planned / executed / passed • Problems • Test coverage • Configuration management • Lines of code specialists • Modules changed • Users • Problems • Operation hours
- 40. 40 Step 12 – Consider Human Factors The People Side of the Metrics Equation • How measures affect people • How people affect measures “Don’t underestimate the intelligence of your engineers. For any one metric you can come up with, they will find at least two ways to beat it.” [unknown]
- 41. 41 Don’t Measure individuals Use metrics as a “stick” Ignore the data Use only one metric Cost Quality Schedule
- 42. 42 Do Select metrics based on goals Goal 1 Goal 2 Question 1 Question 2 Question 3 Question 4 Metrics 1 Metric 2 Metric 3 Metric 4 Metric 5 [Basili-88] Focus on processes, products & services Processes, Products & Services Provide feedback Feedback Data Data Providers Metrics Obtain “buy-in”