Publications (2)0 Total impact
- [Show abstract] [Hide abstract]
ABSTRACT: The ability of a software system to survive is not only dependent on a good architectural design, but also the effective management of architectural changes as the system evolves over time. With the emergence of incremental and evolutionary development approaches, this evolution is no longer restricted to the maintenance phase of development, but now manifests itself during system elaboration and construction. Structural complexity is often inadvertently introduced as the number of interdependencies between parts of the system grows and design goals are violated. Such increasing complexity may paradoxically impede its survivability. Software architects must, therefore, learn to track, manage, and mitigate software complexity since, left unchecked, it can lead to systems that are difficult to maintain and evolve. There are two key aspects of software systems that must be monitored in order to effectively manage the inherent complexity that is systematically introduced in evolving systems: the stability of intermediate forms must be preserved, and structural complexity must be monitored to prevent incidental (excessive) complexity from being introduced. While these key aspects of software architecture are often monitored independently in evolving systems, an integrative metric-based approach would provide a more comprehensive means of assessing the impact that architectural changes have on overall system quality. In this study, an integrative, multidimensional approach was used to examine the evolutionary changes that occurred in the architectural stability and structural complexity over 21 releases of Hibernate, a large-scale open source software system. KeywordsSoftware architecture-Structural complexity-Software evolution-Open source softwareInnovations in Systems and Software Engineering 01/2010; 6(4):299-310.
- [Show abstract] [Hide abstract]
ABSTRACT: Due to the intricacies in the algorithms involved, the design of imaging software is considered to be more complex than non-image processing software (Sangwan et al, 2005). A recent investigation (Larsson and Laplante, 2006) examined the complexity of several image processing and non-image processing software packages along a wide variety of metrics, including those postulated by McCabe (1976), Chidamber and Kemerer (1994), and Martin (2003). This work found that it was not always possible to quantitatively compare the complexity between imaging applications and nonimage processing systems. Newer research and an accompanying tool (Structure 101, 2006), however, provides a greatly simplified approach to measuring software complexity. Therefore it may be possible to definitively quantify the complexity differences between imaging and non-imaging software, between imaging and real-time imaging software, and between software programs of the same application type. In this paper, we review prior results and describe the methodology for measuring complexity in imaging systems. We then apply a new complexity measurement methodology to several sets of imaging and non-imaging code in order to compare the complexity differences between the two types of applications. The benefit of such quantification is far reaching, for example, leading to more easily measured performance improvement and quality in real-time imaging code.Proc SPIE 02/2007;
William Penn UniversityUniversity Park, Florida, United States