A mathematical perspective for software measure research

Melton, Austin; Gustafson, David A.; Bieman, James M.; Baker, Albert L.

doi:10.1049/sej.1990.0027

Cited by 63 publications

(25 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There are other factors that have a strong influence on understandability, such as the amount of available context information and knowledge about a system. In the literature [MGB90], it has been argued that the inner loop of the ShellSort algorithm, taken in isolation, is less understandable than the whole algorithm, since the role of the inner loop in the algorithm cannot be fully understood without the rest of the algorithm. This shows that understandability improves because a larger amount of context information is available, rather than because the complexity of the ShellSort algorithm is less than that of its inner loop.…”

Section: University Of Maryland Cs-tr-3368 -11mentioning

confidence: 99%

See 1 more Smart Citation

Software Process Improvement

2002

Kybernetes

View full text Add to dashboard Cite

Little theory exists in the field of software system measurement. Concepts such as complexity, coupling, cohesion or even size are very often subject to interpretation and appear to have inconsistent definitions in the literature. As a consequence, there is little guidance provided to the analyst attempting to define proper measures for specific problems. Many controversies in the literature are simply misunderstandings and stem from the fact that some people talk about different measurement concepts under the same label (complexity is the most common case).There is a need to define unambiguously the most important measurement concepts used in the measurement of software products. One way of doing so is to define precisely what mathematical properties characterize these concepts, regardless of the specific software artifacts to which these concepts are applied. Such a mathematical framework could generate a consensus in the software engineering community and provide a means for better communication among researchers, better guidelines for analysts, and better evaluation methods for commercial static analyzers for practitioners.In this paper, we propose a mathematical framework which is generic, because it is not specific to any particular software artifact, and rigorous, because it is based on precise mathematical concepts. This framework defines several important measurement concepts (size, length, complexity, cohesion, coupling . IntroductionMany concepts have been introduced through the years to define the characteristics of the artifacts produced during the software process. For instance, one speaks of size and complexity of software specification, design, and code, or cohesion and coupling of a software design or code. Several techniques have been introduced, with the goal of producing software which is better with respect to these concepts. As an example, Parnas [P72] design principles attempt to decrease coupling between modules, and increase cohesion within modules. These concepts are used as a guide to choose among alternative techniques or artifacts. For instance, a technique may be preferred over another because it yields artifacts that are less complex; an artifact may be preferred over another because it is less complex. University of Maryland CS-TR-3368 -2 definition of relevant concepts (i.e., classes of software characterization measures) is the first step towards quantitative assessment of software artifacts and techniques, which is needed to assess risk and find optimal trade-offs between software quality, schedule and cost of development.To capture these concepts in a quantitative fashion, hundreds of software measures have been defined in the literature. However, the vast majority of these measures did not survive the proposal phase, and did not manage to get accepted in the academic or industrial worlds. One reason for this is the fact that they have not been built using a clearly defined process for defining software measures. As we propose in [BMB94(b)], such a process should be...

show abstract

Section: University Of Maryland Cs-tr-3368 -11mentioning

confidence: 99%

“…TZ3 can be derived from our set of properties. TZ4 captures the basic purpose behind the definition of all measures: preserving an intuitive order on a set of software artifacts [MGB90].…”

Section: Tz1mentioning

confidence: 99%

Software Process Improvement

2002

Kybernetes

View full text Add to dashboard Cite

show abstract

“…can be extremely difficult, encompassing, as it does, problem characteristics, programmer characteristics and logical and syntactic structure within and between modules ( With the enormous gains in performance : price ratio in hardware technology in the last thirty years, execution efficiency is not normally a major issue over the entire life cycle when compared with the difficulties posed by specification, design and testing while developing and maintaining software (Brooks, 1987). Melton et al (1990) caution against equating structural complexity with the difficulty of understanding a piece of software. One may informally relate structural complexity with "synthesis': the creation of design and code; whilst psychological complexity relates to v analysis': dissection of existing code in order to comprehend as a prelude to maintenance.…”

Section: Complexitymentioning

confidence: 99%

“…(For present purposes, the words measure and metric are used interchangeably. For more precise definitions, see Melton et al 1990). A second type of module metric is semantic cohesion which is strongly influenced by human cognition and knowledge descriptors.…”

Section: Introductionmentioning

confidence: 99%

Cyclomatic Complexity: theme and variations

Henderson‐Sellers

Pant

Vemer

1993

AJIS

View full text Add to dashboard Cite

Focussing on the "McCabe family" of measures for the decision/logic structure of a program, leads to an evaluation of extensions to modularization, nesting and, potentially, to object-oriented program structures. A comparison of rated, operating and essential complexities of programs suggests two new metrics: 'inessential complexity" as a measure of unstructuredness and "product complexity" as a potential objective measure of structural complexity. Finally, nesting and abstraction levels are considered, especially as to how metrics from the "McCabe family" might be applied in an object-oriented systems development environment.

show abstract

“…We doubt that we can classify all shapes, and we doubt that we can impart an ordering on shapes to constitute an empirical relation system [7,9]. The development of a single ordinal shape measure would be similar to the difficult, if not impossible task, of finding a single complexity measure [8].…”

Section: Classifying Tree Shapesmentioning

confidence: 99%