Properties of control-flow complexity measures

Lakshmanan, K.; Jayaprakash, S.; Sinha, Parasnath

doi:10.1109/32.106989

Cited by 44 publications

(16 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The properties we define for complexity are, to a limited extent, a generalization of the properties several authors have already provided in the literature (see [LJS91,TZ92,W88]) for software code complexity, usually for control flow graphs. We generalize them because we may want to use them on artifacts other than software code and on abstractions other than control flow graphs.…”

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

confidence: 99%

“…This work has been discussed by many authors [CK94,F91,LJS91,TZ92,Z91] and is still a point of reference and comparison for anyone investigating the topic of software complexity.…”

Section: Comparison With Related Workmentioning

confidence: 99%

“…Lakshmanian et al [LJS91] have attempted to define necessary properties for software complexity measures based on control flow graphs. In order to make these properties comparable to ours, we will use a notation similar to the one used to introduce Weyuker's properties.…”

Section: Lakshmanian Et Almentioning

confidence: 99%

“…Lakshmanian et al [LJS91] introduce nine properties. However, only five out of them can be considered basic, since the remaining four can be derived from them.…”

Section: Lakshmanian Et Almentioning

confidence: 99%

See 3 more Smart Citations

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%

“…This work has been discussed by many authors [CK94,F91,LJS91,TZ92,Z91] and is still a point of reference and comparison for anyone investigating the topic of software complexity.…”

Section: Comparison With Related Workmentioning

confidence: 99%

Section: Lakshmanian Et Almentioning

confidence: 99%

“…Lakshmanian et al [LJS91] introduce nine properties. However, only five out of them can be considered basic, since the remaining four can be derived from them.…”

Section: Lakshmanian Et Almentioning

confidence: 99%

See 2 more Smart Citations

Software Process Improvement

2002

Kybernetes

View full text Add to dashboard Cite

show abstract

“…However, only a few studies have been conducted to test the relationship between the proposed complexity metrics and their applicability in the real world. To identify the effectiveness and the practicality of a metric a number of evaluation frameworks have been proposed in the past [12][13][14][15].…”

Section: Introductionmentioning

confidence: 99%

Measuring Complexity, Development Time and Understandability of a Program: A Cognitive Approach

Jakhar¹,

Rajnish²

2014

IJITCS

View full text Add to dashboard Cite

Abstract-One of the central problems in software engineering is the inherent complexity. Since software is the result of human creative activity and cognitive informatics plays an important role in understanding its fundamental characteristics. This paper models one of the fundamental characteristics of software complexity by examining the cognitive weights of basic software control structures. Cognitive weights are the degree of the difficulty or relative time and effort required for comprehending a given piece of software, which satisfy the definition of complexity. Based on this approach a new concept of New Weighted Method Complexity (NWMC) of software is developed. Twenty programs are distributed among 5 PG students and development time is noted of all of them and mean is considered as the actual time needed time to develop the programs and Understandability (UA) is also measured of all the programs means how much time needed to understand the code. This paper considers Jingqiu Shao et al Cognitive Functional Size (CFS) of software for study. In order to validate the new complexity metrics we have calculated the correlation between proposed metric and CFS with respect to actual development time and performed analysis of NWMC with CFS with Mean Relative Error (MRE) and Standard Deviation (Std.). Finally, the authors found that the accuracy to estimate the development time with proposed measure is far better than CFS.

show abstract

Measurement Theory and Software Measures

Zuse

Bollmann-Sdorra

1992

Formal Aspects of Measurement

View full text Add to dashboard Cite

Properties of control-flow complexity measures

Cited by 44 publications

References 15 publications

Software Process Improvement

Software Process Improvement

Measuring Complexity, Development Time and Understandability of a Program: A Cognitive Approach

Measurement Theory and Software Measures

Contact Info

Product

Resources

About