A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.
%0 Journal Article
%1 sangwan2008structural
%A Sangwan, R. S.
%A Vercellone-Smith, P.
%A Laplante, P. A.
%D 2008
%J IEEE Software
%K diss forschungsdaten software
%N 4
%P 66-73
%R 10.1109/MS.2008.96
%T Structural Epochs in the Complexity of Software over Time
%V 25
%X A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.
@article{sangwan2008structural,
abstract = {A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.},
added-at = {2020-01-25T12:26:35.000+0100},
author = {{Sangwan}, R. S. and {Vercellone-Smith}, P. and {Laplante}, P. A.},
biburl = {https://puma.ub.uni-stuttgart.de/bibtex/25d41756724c0d2dbb956ceb2ebb7ac72/hermann},
doi = {10.1109/MS.2008.96},
interhash = {7a69d6426d290327ff91fa8af2d5d058},
intrahash = {5d41756724c0d2dbb956ceb2ebb7ac72},
issn = {1937-4194},
journal = {IEEE Software},
keywords = {diss forschungsdaten software},
month = {July},
number = 4,
pages = {66-73},
timestamp = {2020-01-25T11:26:53.000+0100},
title = {Structural Epochs in the Complexity of Software over Time},
volume = 25,
year = 2008
}
