Formal methods and metrics
Grigori Yourganov
In Software Engineering, metrics are the properties of our software (or the software
development process) that we can use to make reasonable judgements about our software.
Metrics must be quantitative (measurable in numbers) and objective.
Especially useful for the management!
Using metrics, we can estimate such parameters of the development process as
- number of people that should be involved
- structure of the development team
- progress
- cost
- time it would take to develop the product
To get these results from our metrics, we must use some model, for example
(from “Software Metrics: a Roadmap”, by N. Fenton and M. Neil)
Problem Complexity
Size
Effort
Schedule
Resource Quality
Product Quality
Size of the problem can be roughly estimated by
- Size of the specification (# of functions / classes)
- Complexity of functions / classes (# of parameters)
Size of the software can be estimated by # of lines of code
Better estimate: number of schemas (if we use Z), complexity of the schemas (number of
parameters, depth of schema nesting)
If the algorithm is described as a graph (a flowchart for example), the complexity can be
estimated with cyclomatic number of the graph:
# of edges - # of nodes + # of connected components
In object-oriented design, we can estimate complexity by:
- methods per class
- depth of inheritance tree
-
coupling between classes
Halstead’s measure of the complexity of a module:
n1 - # of unique operators
n2 - # of unique operands
N1 – total occurrence of the operators
N2 – total occurrence of the operators
Vocabulary size: n = n1 + n2
Length of the module: N = N1 + N2
Then, effort to generate this module can be approximated by
n1 * N2 * N log N / 2 n2