In Software Engineering, Software Metrics are quantitative measures of the degree to which a software system or process possesses a given attribute. If you can't measure it, you can't manage it. Metrics allow managers and developers to track progress, predict costs, and improve quality.
📉 Types of Metrics
We generally categorize metrics into three "P's":
Product Metrics: Describe the characteristics of the software itself (size, complexity, reliability).
Process Metrics: Describe the effectiveness and efficiency of the software process (how long it takes to fix a bug, average time to code a feature).
Project Metrics: Describe the project's status (cost, schedule, staffing).
🚦 Size-Oriented Metrics
These are based on the direct measure of the software's output.
Lines of Code (LOC): The most traditional metric. It measures the total number of lines in the source code.
Pros: Easy to calculate.
Cons: Language dependent (100 lines of Assembly ≠ 100 lines of Python). It rewards "verbose" or "messy" coding.
KLOC: Thousands of lines of code.
🔄 Function-Oriented Metrics
These focus on the functionality provided by the software rather than the lines of code. The most common is Function Point (FP) Analysis.
FP is calculated based on five characteristics:
External Inputs: (e.g., input screens, forms).
External Outputs: (e.g., reports, data files).
External Inquiries: (e.g., online searches).
Internal Logical Files: (e.g., databases managed by the system).
External Interface Files: (e.g., data shared with other systems).
💡 Quality Metrics
These measure how "good" the software is and how many defects it contains.
Defect Density: The number of confirmed defects divided by the size of the software (e.g., bugs per KLOC).
Mean Time to Failure (MTTF): The average time the system runs before crashing.
Cyclomatic Complexity: A structural metric that measures the number of linearly independent paths through a program's source code.
High complexity = Harder to test and maintain.
📊 Summary Table: Common Metrics
Metric | Category | Use Case |
|---|---|---|
MTTR (Mean Time to Repair) | Process | Measures how fast the team fixes bugs. |
Code Coverage | Product/Test | Percentage of code executed during testing. |
Velocity | Project (Agile) | Amount of work a team completes in a single sprint. |
Churn | Process | How often code is being rewritten or deleted. |
⚠️ The Danger of Metrics
Metrics are powerful, but they can be abused. This is known as Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."
If you reward developers for writing more Lines of Code, they will write inefficient, bloated code.
If you reward testers for finding more bugs, they might report tiny, insignificant UI issues instead of focusing on critical crashes.