Experiences Adopting Software Product Line Development without a Product Line Architecture

Abstract

Many organizations used Software Product Line Development to improve development efficiency, time-tomarket, and product quality. However, a perceived barrier to entry for Product Line Development is that a Product Line Architecture is required to handle variation across the product set. We describe qualitative evidence from industrial experiences with an approach that has allowed the adoption of Product Line Development for a pre-existing product set, without the use of a Product Line Architecture. The approach relies on file-level reuse and variation mechanisms provided by a Configuration Management infrastructure. The approach can reduce the risks and up-front costs of adopting Product Line Development. Although not requiring a Product Line Architecture, the approach is not inconsistent with architectural-level variation mechanisms. It has allowed previously-reported "reactive" and "proactive" styles of architectural evolution to support variation, and also a new "retroactive" style of architectural evolution. Additionally, the approach has provided new options for "working around" change control conflicts on reused Product Line core assets.

Experiences with Software Product Line Development in Risk Management Software

“…Staples and Hill report similar experiences with SPL development in a small company that does not have a defined SPL architecture [8]. In Blade also, the architecture has evolved based on the needs of the customers.…”

“…Many success stories exist that testify to the benefits of SPL development and the introduction of SPL methodologies [1], [7], [8], [11]. These stories highlight the benefits in terms of costs efficiencies, decreases in development time and quicker time to market.…”

Guaranteeing Syntactic Correctness for All Product Line Variants: A Language-Independent Approach

“…In contrast, compositional approaches -favored in academia -implement features in physically separated modules and compose them to generate variants; examples include frameworks [19] and different forms of components, aspects or feature modules [27,3,24,2,1]. Furthermore, several other implementation mechanisms like generators [8,16] or version control systems [33] exist. All approaches have different advantages and disadvantages, e.g., regarding SPL adoption or expressiveness as discussed in [6] and [22], which justifies research on error detection for all of them.…”

Architectural Evolution of a Software Product Line: an experience report

“…features that may not fit into the initial design of the SPLA [12]. In our experience, this has often meant that some of the core components of the SPL must be altered to make use of this new feature, which in some cases could imply in changes to the SPLA.…”