Setting up architectural SW health builds in a new product line generation

Abstract

Setting up a new product line generation in a mature domain, typically does not start from scratch but takes into consideration the architecture and assets of the former product line generation. Being able to accommodate legacy and 3rd party code is one of the major product line qualities to be met. On the other side, product line qualities like reusability, maintainability and alterability, i.e. being able to cope up with a large amount of variability, with configurability and fast integratability are major drivers. While setting up a new product line generation and thus a new corresponding architecture, we this time focused on architectural software (SW) health and tracking of architectural metrics from the very beginning. Taking the definition of "architecture being a set of design decisions" [18] literally, we attempt to implement an architectural check for every design decision taken. Architectural design decisions in our understanding do not only - and even not mainly - deal with the definition of components and their interaction but with patterns and rules or anti-patterns. The rules and anti-patterns, "what not to do" or more often also "what not to do any more", is even more important in setting up a new product line generation because developers are not only used to the old style of developing and the old architecture, but also still have to develop assets for both generations. In this article we describe selected architectural checks that we have implemented, the layered architecture check and the check for usage of obsolete services. Additionally we discuss selected architectural metrics: the coupling coefficient metrics and the instability metrics. In the summary and outlook we describe our experiences and still open topics in setting up architectural SW health checks for a large-scale product line. The real-world examples are taken from the domain of Engine Control Unit development at Robert Bosch GmbH.