Search for: All records

In this paper, we introduce CIDER, a Concept-based Interactive DE-sign Recovery tool that recovers a software design in the form of hierarchically organized concepts. In addition to facilitating design comprehension, it also enables designers to assess design quality and identify design problems. It integrates multiple clustering algorithms to reduce the complexity of the recovered design structure, leverages information retrieval techniques to name each cluster using the most relevant topic terms to ease design comprehension, and identifies and labels highly-coupled file clusters to reveal possible design problems. It enables interactive selection of concepts of interest and recovers partial design structures accordingly. The user can also interactively change the levels of recovered hierarchical structure to visualize the design at different granularities. 

Architecture debt is a form of technical debt that derives from the gap between the intended and the actual architecture design. In this study we measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architecture flaws. In recent research it was shown that the amount of architecture debt has a huge impact on software maintainability and evolution. Consequently, reducing debt is expected to make software less costly and more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by BrightSquid Secure Communications Corp. This young company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and- dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the “before” system, which showed the impacts of change requests. This initial study motivated a more in-depth analysis of architecture debt. The results of this debt analysis were used in the second stage of the work to motivate a comprehensive refactoring of the software system. The third stage was a follow-on architecture debt analysis which quantified the improvements realized. Using this quantitative evidence, augmented by qualitative evidence gathered from in- depth interviews with BrightSquid’s architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.