When the developers and architects are claiming "We have to refactor parts of this system", management often responds: "That might be a good
idea, why don't you make a business case. You need to document why that increases the system's business value, what to start with, how to
report progress and find a way to avoid fallback".
Facing a challenge similar to this, we started looking for tools that could kick-start us. We tested different commercial products, open source tools and in-house developed analysis tools. They all gave us important information in terms of complexity, redundant code, code duplication, dependencies, cycles, test coverage, performance and so on. This bottom up view was helping but we needed one common top down view of the system - preferably with drilldown functionality within the various areas.
We also realized that another essential issue was not properly addressed in the tools we found. Imagine a stock market analyst making a recommendation on buying a stock. The analyst would seem somewhat ignorant if he only looked at the fundamentals supporting the stock. A lot of his attention would most likely on how the stock has traded back in time : its history. In reengineering we face the same challenge. A metric often gives little meaning before you look at how it has been developing.
Hence, we were led to the development of the XRadar - an analysis tool and plug-in framework for making cynical reengineering decisions.
Subjective arguments seldom convince a manager to invest in reengineering or refactoring. By providing hard facts about the system the problems are easier revealed and documented by objective reports. Developers, architects and project management all need information, preferably in a structured form. This motivateded the requirements to the system.
Software systems of some size need to show its different faces. All stakeholders (developers, architects and managers) need specialized reports within their areas. Combined and weighted metrics should give them advice on where to focus. Maintaining spreadsheets is time-consuming and boring. Spending some time configuring reports that can be automated and repeated at fixed intervals leaves more time for quality work.
When educating architects and developers it's important to be able to look at a system's history. Negative trends can be discovered early and corrected by proper education of the developers or by doing architectural changes. Furthermore, when reengineering, monitoring the progress over time is essential to make the right decisions.
When analysing a large system, you need to be able to see the system from various levels of detail. You have the obvious drilldown possibilities representing the logical properties of the system: total system, packages, classes and methods. But often these do not directly represent how one views the system as a set of entities. More often you speak of system areas, modules or subsystems, represented by a group of packages. In our drilldowns, we wanted to be able to view the system from this subsystem perspective as well.
Having split the system into subsystems, a second goal is to analyse the layering of the system. You want to define how the subsystems in their layers legally may interact and then analyse how the system actually fits this ideal picture. Some of these illegal dependencies causes cycles - a very bad symptom in an architecture. When a dependency error is detected, you also want to pinpoint what causes it to do a proper fix.
Due to changing system focus, it would be highly beneficiary to be flexible on the needs of the future. Furthermore, one systems key indicator may not be available for another system. Hence, flexibility is a key issue for our tool: