Model of the System’s Evolution Through Structural Erosion and Reorganization

Alexander Prutzkow

Abstract


A program system is created based on a problem solution using a model. The program system changes, including due to changes in its structure. The purpose of the study is to clarify the evolution of a system with a modifiable structure, which is necessary for understanding the program life cycle. We introduce a model of the system’s evolution in aspect of changes in its structure. During the life cycle, the system exists in states of structured and unstructured. Erosion makes the system unstructured, and reorganization makes it structured. Some modifications don’t change the state of the system. The measure of structuredness determines the state of the system. The measure can be the difference between the current and intended structures, structure parameters – the number of components, the relationships between them, the target indicator of the structure – for example, the complexity of changing the system or its structure. Technical debt and structural erosion negatively affect the structuredness of the system. Technical debt occurs after a change of a target and distortion of a system. Technical debt must be eliminated after the value of the measure of the system’s structuredness critically exceeds the specified threshold. The causes of structural erosion are technical debt, lack of understanding of the system’s structure, lack of experience in changing the system or its structure, and substituting the target indicator after the environment change. There are a number of approaches to measuring structural erosion, but none are accurate.


Full Text:

PDF

References


Yourdon E., Constantine L. (1978) Structured Design. Fundamentals of a Discipline of Computer Program and Systems Design // Yourdon Press.

James K.L. (2016) Software Engineering // PHI Learning.

Rajlich V. (2014) Software Evolution and Maintenance // Software Engineering / DOI: 10.1145/2593882.2593893.

Lehman M. (1996) Laws of Software Evolution Revisited // Software Process Technology.

Herraiz I. et al. (2013) The Evolution of the Laws of Software Evolution // ACM Computing Surveys (CSUR), 46(2) / DOI: 10.1145/2543581.2543595.

Jazayeri M. (2002) On Architectural Stability and Evolution // Reliable Software Technologies.

Breivold H.P. et al. (2012) A Systematic Review of Software Architecture Evolution Research // Information and Software Technology, 54 / DOI: 10.1016/j.infsof.2011.06.002.

Li R. et al. (2022) Understanding Software Architecture Erosion: A Systematic Mapping Study // Journal of Software: Evolution and Process, e2423 / DOI: 10.1002/smr.2423.

de Silva L., Balasubramaniam D. (2012) Controlling Software Architecture Erosion: A Survey // Journal of Systems and Software, 85(1) / DOI: 10.1016/j.jss.2011.07.036.

Perry D.E., Wolf A.L. (1992) Foundations for the Study of Software Architecture // ACM SIGSOFT Software Engineering Notes, 17(4).

Zazworka N. et al. (2014) Comparing Four Approaches for Technical Debt Identification // Software Quality Journal, 2(3).

Cunningham W. (1992) The WyCash Portfolio Management System // Object-Oriented Programming Systems, Languages, and Applications / DOI: 10.1145/157710.157715.

Li Z. et al. (2015) A Systematic Mapping Study on Technical Debt and Its Management // Journal of Systems and Software, 101 / DOI: 10.1016/j.jss.2014.12.027.

Lilienthal C. (2022) Improve Your Architecture with the Modularity Maturity Index // Software Architecture Metrics.

Kruchten P. et al. (2013) Technical Debt: Towards a Crisper Definition // ACM SIGSOFT Software Engineering Notes, 38(5).

Tom E. et al. (2012) A Consolidated Understanding of Technical Debt // Information Systems.

Prutzkow A. (2026) What Is a Good Program? A Space Way // System Engineering and Information Technologies, 8(2) / DOI: 10.54708/SIIT-2026-no2-p29.

Merkle B. (2010) Stop the Software Architecture Erosion // Systems Programming Languages and Applications: Software for Humanity / DOI: 10.1145/1869542.1869621.

Jaktman C.B. et al. (1999) Structural Analysis of the Software Architecture – A Maintenance Assessment Case Study // Software Architecture / DOI: 10.1007/978-0-387-35563-4 35.

Guo Y. et al. (2014) Exploring the Costs of Technical Debt Management – A Case Study // Empirical Software Engineering Journal, (1) / DOI: 10.1007/s10664-014-9351-7.

Lavazza L. et al. (2018) Technical Debt as an External Software Attribute // Technical Debt / DOI: 10.1145/3194164.3194168.

Ahmad N. et al. (2025) Architectural Degradation: Definition, Motivations, Measurement, and Remediation Approaches // arXiv, 2507.

Alves N.S.R. et al. (2016) Identification and Management of Technical Debt: A Systematic Mapping Study // Information and Software Technology, (70).

Pérez B. (2021) Technical Debt Payment and Prevention Through the Lenses of Software Architects // Information and Software Technology, (140) / DOI: 10.1016/j.infsof.2021.106692.

Bandara V., Perera I. (2018) Identifying Software Architecture Erosion Through Code Comments // Advances in ICT for Emerging Regions.

Parnas D.L. (1994) Software Aging // Software Engineering.

van Gurp J., Bosch J. (2002) Design Erosion: Problems and Causes // Journal of Systems and Software, 61(2).

Baabad A. (2025) An Empirical Analysis of Approach-Based Metrics Model for Architectural Erosion Detection // Software: Practice and Experience, 55(9).

Prutzkow A.V. (2024) Teaching Java Programming at the University: Pedagogical Aspects [Prepodavanie yazyka Java v Vuze: Pedagogicheskie Aspekty] // Humanitarian Studies of Central Russia [Gumanitarnye Issledovaniya Tsentralnoy Rossii], (4 (33)) / DOI: 10.24412/2541-9056-2024-433-62-68.

Conway M. (1968) How Do Committees Invent? // Datamation, 14(4).

Shneiderman B. (1980) Software Psychology. Human Factors in Computer and Information Systems // Winthrop Publishers.


Refbacks

  • There are currently no refbacks.


Abava  Кибербезопасность Monetec 2026 СНЭ

ISSN: 2307-8162