By Rick Kazman
Kazman likes multi-disciplinary subjects. Software architecture is such a subject. In 1994, he worked on SAAM, and papers at that time typically made claims about their software architecture. Instead, Kazman et al decided to try to measure these claims. That lead to ATAM in 1998, adding rigor, structure and repeatability to the methods. Still, the outputs of the methods highly depended on the qualities of the experts. ATAM is all about risks. Reality also puts in constraints, such as budget. That lead to CBAM in 2001. Bu still, these methods rely on expertise, and GIGO…
Measuring in SA is still underdeveloped. The main complaint of SE practitioners is that in many of our research, there is little relevance or usability for them. A study showed that from 61 interviewed practitioners only 19 read a scientific paper, and only three could name an author or title. In a discipline like medicine, this is completely the opposite. Kazman claims that this implies a gap, and requires work. He sees that SE researchers lack understanding of industry’s true needs, little knowledge of existing soluations, having unrealistic assumptions and SE research has an incentive misalignment: citations and grants rather than usability or impact.
Briand therefore addressed context-driven SE in last years IEEE Software. Applicability and scalability of SE solutions depend to a great extent on contextual factors. This all lead to Kazman’s current interest: measuring and managing technical debt. Current practice is like a leak boat, and you still try to peddle, due to 1) illusion of progress, and 2) lack of measurements. How do we measure the health of an architecture?
His approach is mainly based on generating DSMs: Design Structure Matrices, e.g. on structure, revisions etc. Based on this information, they construct an architectural view: the DRSpace, a meaningful subset of a system’s file and the architectural connections among these files. DRSpaces are visualized as DSMs. On these spaces they define metrics. One metric is the Decloupling Level (Mo et al, 2016 @ICSE). They created a healthchart of many projects, so that you can map your system on this map, and check how healthy your system is. In several studies they looked into the relation of files participating in architectural flaws and bugs. It turns out that in every study and system, this is highly correlated (e.g. WICSA 2015 & 2016).
As a next step, they use their toolsuite (Mo et al., ASE 2018) to calculate Return on Investment (Kazman et al, ICSE 2015), and evaluated whether the presented results help architects.