The Impact of Complexity

In software development complexity is defined as the effort for understanding a program or algorithm. Consequently the effort for the new or further development of software is not only reliant on the number of user functions, data structures, data elements, etc. (depending of the measuring method) but also of the complexity. However it is necessary to distinguish between different types of complexity.

The Complexity of an Implementation represents the effort for understanding the code and design of an application. It is important for estimating the costs for the maintenance and further development of existing systems. There are multiple metrics measuring different aspects of the complexity inherent in the code: The McCabe metric measures the cyclomatic complexity, the metric of Halstead the textual-lexical complexity, the RfC metric the class complexity, etc. For the cost estimation of a planned new development project this type of complexity has no significance because it accrues from the development process. Furthermore different implementations of the same use case can have different levels of complexity.

The complexity of an implementation has no significance for functional measurement, but the interactional Complexity has. It represents the effort for understanding and implementing the steps of the use case scenarios. The Function Point Analysis derives it from structural parameters as e.g. the number of data element types and record element types related to user functions. The Data Interaction Point Method considers the complexity related to use cases according to the usage of the counted data elements, e.g. for input/output, persistence or read-only access, etc. The COSMIC Method does not consider complexity at all, which is a disadvantage.

All functional size metrics which are conformal to the standard ISO/IEC 14143 ignore the algorithmic Complexity of the business logic lying in processes and functions of the system. They all are based on the assumption that algorithmic complexity has secondary importance towards the functional size. Actually at most systems the algorithmic complexity is limited to input validations, data inquiries, output processing, less complex logical operations and calculations, etc. Usually the number of such functions correlates with the number of interactions with the system's actors. Hence the error due to ignoring the algorithmic complexity is generally negligible. However this does not apply for systems with primarily algorithmic processing, e.g. a route planning program: Its input is a start location and a destination, the output a list of route segments. Every functional size metric would consider only the user interactions and measure a small functional size. Since the development of the undoubtedly highly complex planning algorithms requires high expenditures, the calculation of productivity on basis of the small functional size would indicate a very low productivity compared with other systems - which is incorrect. Conclusion: Functional size measurement is not suitable for systems with an above-average algorithmic complexity.