Measurement and Models

Measurement and Models in Software Quality

In software engineering, models help us understand, predict, and improve processes and products. Measurement provides the quantitative data needed to build and validate these models. Effective measurement involves identifying relevant attributes of software entities (like processes, products, or resources) and mapping them to numerical values.

A structured approach like Goal-Question-Metric (GQM) is often recommended for selecting relevant metrics. This involves defining your goals (e.g., improve code maintainability), formulating questions that address these goals (e.g., which modules are hardest to change?), and identifying metrics that can answer those questions (e.g., cyclomatic complexity, code churn).

Measurements can be broadly categorized into two types:

• Direct measurement
• Indirect measurement

Direct Measurement

Direct measurements quantify an attribute of an entity independently, without needing to measure other attributes. These are often counts or simple timings.

Common examples in modern software engineering include:

• Effort spent on a task (e.g., person-hours)
• Time duration (e.g., testing phase duration in days, cycle time for a feature)
• Number of defects found (e.g., during code review, testing, or post-release)
• Code size (e.g., Lines of Code (LOC), number of classes/functions - use LOC with caution as its value varies greatly by language and context)
• Number of test cases executed or automated
• Deployment frequency (e.g., number of deployments per week)

Indirect Measurement

Indirect measurements are derived by combining two or more direct measurements. They often represent ratios, percentages, or rates, providing insights into efficiency, quality, or productivity.

Common examples include:

$\small Team:Velocity :(Agile) = \frac{Sum :of:Story:Points:completed}{Sprint:Duration}$ (Note: Velocity is team-specific and primarily for planning, not comparing teams)

$\small Defect:Density = \frac{Number :of:defects}{Code :size :(e.g., KLOC :or:Function:Points)}$

$\small Defect:Detection:Percentage :(DDP) = \frac{Number :of:defects:found:before:release}{Total :number :of:defects :(pre :+ :post:release)} \times 100%$

$\small Test:Coverage = \frac{Number :of:items:(e.g.,:code:lines,:branches,:requirements):covered:by:tests}{Total :number :of :items} \times 100%$

$\small Change:Failure:Rate :(DORA:Metric) = \frac{Number :of:deployments:causing:failures}{Total :number :of:deployments} \times 100%$

$\small Lead:Time:for:Changes :(DORA:Metric) = Average:time:from:code:commit:to:production:release$

$\small Rework:Effort:Ratio = \frac{Effort :spent:fixing:defects}{Total :project :effort} \times 100%$

It’s crucial to understand the context and limitations of each metric. No single metric tells the whole story. Use a balanced set of metrics relevant to your specific goals and context.

Measurement for Prediction

Measurements are essential for building predictive models. By analyzing historical data, we can forecast future outcomes like project effort, duration, cost, or potential defect rates. For example, historical velocity data can help predict how much work a team can complete in future sprints (within the same context).

Prediction systems typically involve:

• A mathematical or statistical model (ranging from simple regressions to complex machine learning models) relating predictor variables (current measurements) to the variable being predicted.
• Sufficient historical data to train and validate the model.
• Procedures for applying the model, interpreting the results, and understanding its accuracy and limitations.

Common areas for prediction include effort estimation (e.g., using Agile estimation techniques like story points, or algorithmic models if applicable), defect prediction (identifying defect-prone modules), and project schedule forecasting.