On Weyuker's axioms for software complexity measures

Cherniavsky, John C.; Smith, Carl H.

doi:10.1109/32.87287

Cited by 54 publications

(18 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Zweben and Gourlay [9] discusses about the fundamental nature of property and precision for the structural and mutant adequacy of a complexity measure. Chariniavsky and Smith [10] proposes complexity metric for mapping of program, tokens, variables and constants to estimates final complexity measure based on a recursive function. Halstead [11] proposes a measure for the estimation of difficulty based on the principle of count of operators and operands and their respective occurrences in the code for the length, vocabulary, volume, potential volume, estimated program length, difficulty and finally the estimation of effort and time.…”

Section: Literature Review For Estimation Of Software Complexitymentioning

confidence: 99%

An empirical approach for early estimation of software testing effort using SRS document

Sharma

Kushwaha

2012

CSIT

View full text Add to dashboard Cite

Section: Literature Review For Estimation Of Software Complexitymentioning

confidence: 99%

An empirical approach for early estimation of software testing effort using SRS document

Sharma

Kushwaha

2012

CSIT

View full text Add to dashboard Cite

“…Both Prather and Weyuker proposed that traditional software complexity metrics do not possess appropriate mathematical properties, and consequently fail to display what might be termed normal predictable behavior. [7] The second category of criticisms is more specific to OO design and development. The OO approach centers on modeling the real world in terms of its objects, which is in contrast to older, more traditional approaches that emphasize a function-oriented view that separates data and procedures.…”

Section: Research Problemmentioning

confidence: 99%

“…[4] Six design metrics are developed, and then analytically evaluated against Weyuker's proposed set of measurement principles. [7] An automated data collection tool was then developed and implemented to collect an empirical sample of these metrics at two field sites in order to demonstrate their feasibility and suggest ways in which project managers may use these metrics for process improvement.…”

Section: Introductionmentioning

confidence: 99%

Significance of Software Metrics to Quantify Design and Code Quality

Kumar¹,

Kumar²,

Swarnalatha³

2010

IJCA

View full text Add to dashboard Cite

The vital role of software process improvement is ability to measure the current state of system process and establishing improvement priorities. In addition, the focus on process improvement has increased the demand for software measures, or metrics with which to manage the software process. The need for such metrics is particularly acute when an organization is adopting new technologies and establishing best practices for the organization. This paper mainly addresses the needs of development and implementation of a new suite of metrics for OO design. Metrics developed based on literature survey, while contributing the software development processes, having serious criticisms, which includes the lack of a theoretical base this suggests that software metrics need to be constructed with a stronger degree of theoretical and mathematical rigor. Given the extant software metrics literature, this paper has a three fold agenda: 1) To propose metrics that are constructed with a firm basis in theoretical concepts in measurement and the ontology of objects, and which incorporate the experiences of professional software developers; 2) Evaluate the proposed metrics against established criteria for validity 3) Present empirical data from commercial projects to illustrate the characteristics of these metrics on real applications, and suggest ways in which these metrics may be used.

show abstract

“…We think that properties should be used to check whether a measure actually addresses a given concept (e.g., complexity). However, given any set of properties, it is almost always possible to build a measure that satisfies them, but is of no practical interest (see [CS91]). At any rate, this is not a sensible reason to reject a set of properties associated with a concept (how many sensless measures could be defined that satisfy the three properties that characterize distance!).…”

Section: W8mentioning

confidence: 99%

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

On Weyuker's axioms for software complexity measures

Cited by 54 publications

References 7 publications

An empirical approach for early estimation of software testing effort using SRS document

An empirical approach for early estimation of software testing effort using SRS document

Significance of Software Metrics to Quantify Design and Code Quality

Software Process Improvement

Contact Info

Product

Resources

About