Research trends in structural software complexity
📝 Abstract
There are many dimensions of software complexity. In this article, we explore how structural complexity is measured and used to study and control evolving software systems. We also present the current research challenges and emerging trends in this domain that has remained active for nearly four decades, and continues to evolve.
💡 Analysis
There are many dimensions of software complexity. In this article, we explore how structural complexity is measured and used to study and control evolving software systems. We also present the current research challenges and emerging trends in this domain that has remained active for nearly four decades, and continues to evolve.
📄 Content
Research trends in structural software complexity Tom Mens Abstract. There are many dimensions of software complexity. In this article, we explore how structural complexity is measured and used to study and control evolving software systems. We also present the current research challenges and emerging trends in this domain that has remained active for nearly four decades, and continues to evolve. 1 Introduction Software systems are among the most intellectually complex artefacts ever created by humans [Brooks1986]. But what is it that makes software systems complex? Despite several decades of research on the topic, there is no consensus on how to define software complexity. The IEEE standard 610.12-1990 defines software complexity as “the degree to which a system or component has a design or implementation that is difficult to understand and verify”. Basili defines complexity in a more general way as “a measure of the resources expended by a system while interacting with a piece of software to perform a given task” [Basili1990]. Basili’s definition reveals that there are many different dimensions of complexity. If the system that interacts with the software is a computer, then complexity is defined by the execution time and memory resources required to perform the computation. We call it algorithmic complexity if we are concerned by the time and storage required to execute a particular algorithm. We call it computational complexity, if we are interested in the theoretical complexity or difficulty (in time or space) of the computational problem to be solved, regardless of the algorithm used to solve it. Algorithmic and computational complexity theory are very important and well-developed, with lots of theoretical models of computation (e.g. Turing machines, recursive functions) and complexity classes (e.g. polynomial time complexity, logarithmic space complexity, and so on). One could argue that computational complexity corresponds to what Fred Brooks calls the essential complexity, which is intrinsic to the characteristics of the problem to be solved and therefore cannot be reduced. The algorithmic complexity then relates to Brooks’ notion of accidental complexity, which is introduced by the way in which the problem is implemented. It depends on the chosen algorithm, but also on the software engineering tools used to implement the problem (such as programming language, compilers and other technical characteristics). Brooks argues that the essential complexity cannot be reduced, and removing accidental complexity (e.g. by using higher-level programming languages) can never lead to an order of magnitude productivity improvement. If the interacting system is a user, then complexity is defined by the difficulty of using the software, which can be expressed as the number of different ways the user can or needs to interact with the software. This complexity of use refers to the software quality characteristic of usability. It is also related to the functional complexity, i.e., the amount of functionality the software provides to the user [Tran- Cao2001]. Albrecht’s function points metric [Albrecht1979] and related functional size measurements have been widely used to measure this kind of complexity. If the interacting system is a software developer, then complexity is assessed by the difficulty of performing tasks such as coding, debugging, testing or modifying the software. We refer to this type of complexity as structural software complexity [Darcy2005]. It reflects how the software is structured and organized in different interacting parts (both at fine-grained and coarse-grained level), because this structure has a direct effect on other quality characteristics such as understandability and maintainability. The correlations between software complexity metrics and maintenance aspects have been widely studied. Strong relationships have been found between complexity and increased maintenance effort, number of bugs and amount of changes [Kemerer1995]. Large chunks of “spaghetti code” require more effort to read and maintain than well- modularized software composed of weakly coupled modules. Structural complexity is different from computational complexity because it focuses on the solution (the software itself) as opposed to the computational problem to be solved. It is also different from the algorithmic complexity, which focuses on the machine resources (time and memory consumption) required to solve the problem. Finally, if the interacting system is the organization or team producing the software, then the complexity is defined by the way in which team members interact, collaborate and communicate to develop and maintain the software product over time. We will refer to this as the organizational complexity [Bird2009b]. Such organizational complexity can be an important cause of structural software complexity: manag
This content is AI-processed based on ArXiv data.