An Evaluation of Design Rule Spaces as Risk Containers

Abstract

Abstract-It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone [1, 2]. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk.

Risk Containers - A Help or Hindrance to Practitioners?

“…The work in [1] [2] describes DR Containers derived from the Design Rule Spaces (DRSpaces) proposed by Xiao et al [3]. DRSpaces are graphs based on design rules (key interfaces) that split an architecture into independent modules.…”

“…Risk containers are defined as architecture subsets that can be used to separate areas of low and high risk within an overall architecture. The work in [1] [2] suggests that risk containers based on design rules support the isolation of error-proneness risks at design time. The ability to isolate risks does not mitigate the risk by itself.…”

Software Architecture Risk Containers

“…DR Containers were constructed using the method described in Leigh et al (2016). Each design rule class was used as a container basis before expansion with subordinate classes by consulting design relationships.…”

“…We used again the 75th percentile of bugs per KLOC as the threshold (Leigh et al 2016). Bug identifiers were extracted from the Subversion commit messages for each implementation file.…”

“…In Leigh et al (2016) we asked developers to nominate areas of the API that were difficult to implement and maintain. We observed that 2 of 3 nominations fitted neatly inside a DR Container.…”