Introduction Software architects have to make sure that the communicated software architecture blueprints exist in the real world. For this, manual inspections as well as automated measurements are needed to avoid surprises. In this notebook, I want to show how
Introduction This blog is a three-part series. See part 2 for calculation of test similarity and part 3 (upcoming) for visualization. In an upcoming analysis, we want to calculate the structural similarity between test cases. For this, we need the
Some months ago, I did some redocumentation work of a mid-sized legacy system (~1 Mio. LOC). Among other things, the system lacked homogeneity, that means there were many terms that were differently interpreted from different teams over the time…
In this blog post, I want to show how you can get a first impression on how you can cut a monolithic application into separated components that make sense from a business’ perspective. This method can help you to identify meaningful Bounded Contexts…
All the work before was just there to get a nice graph model that feels more natural. Now comes the analysis part: As mentioned in the introduction, we don’t only want the hotspots that signal that something awkward happened, but also
the trigger in our application of the hotspot combined with
the information about the entry point (e. g. where in our application does the problem happen) and
(optionally) the request that causes the problem (to be able to localize the problem)…