Product lines to address increasing software variability

Home » Current Events »

Product lines to address increasing software variability
David Benavides

There are some trends in the software industry that are changing the landscape of production in this industry. On the one hand, the reuse of components and artifacts, which has always been pursued in software engineering, evolved from being an opportunistic and ad-hoc reuse to a planned reuse. Most mature companies plan how to reuse their assets and, although “copy and paste” remains one of the most frequent forms of reuse, other ways of reusing work done in other projects are planned, defining (micro) services, packages or other artifacts. Second, the variability of computer systems is moving in an accelerated way from hardware to software to the point of virtualizing hardware components such as sensors, actuators or even networks. The same product (for example a car) can have exactly the same hardware and a huge difference in value depending on the software it has configured. This leads naturally to the third trend, which is that the number of points of variability in systems grows by the thousands. If we think of a part of a computer system, for example, the Linux kernel, there are reports that place between 10,000 and 16,000 possible configuration values for this part of a system. If these configuration points were just boolean values, it would mean that we would have many more possible configurations of the Linux kernel than the total number of estimated atoms in the entire universe.

All of this brings us to one of the most complex tasks within software production, which is complexity management. Systems continue to grow in functionality, size, scope and also in complexity. One possible approach to addressing complexity, reuse, and variability in software engineering is software product lines. The idea is relatively simple, not so the implementation of the idea.

In the industrial revolution there was a shift from a paradigm of artisanal production to what is called mass production The idea was that the same standardized product could be produced repeatedly with great efficiency using assembly lines. The emergence of ICT and automation allowed the production process to move towards what is known asmass customizationwhich starts from producing goods or services with a high degree of customization but doing so with almost the same efficiency as mass production. An example could be the production of watches. In the beginning, watches were produced by hand, then they were mass-produced in a small number of models, and today countless customized models are produced with the ability to store information and run a multitude of applications. The engineering of software product lines would be nothing but the mass customization of software products.

To be able to address a software product line strategy in an organization requires a change of focus at the organizational level, which is challenging and often a barrier. That’s why you need to focus on an application domain or domains. We would no longer produce software generically for any kind of project, but within a certain domain, for example, we would make software for e-commerce stores.

Once you’ve determined the domain you’re producing in, you need to identify what your common parts are and what the variable parts are that you expect your products to have. This is where feature models can be used to determine which products will fall within the scope of the product line and which will not. These models are useful both for interacting with participants and for more technical aspects such as generating interactive configurators or enabling analysis or automatic reasoning with the models for production or debugging.

Product lines are an interesting approach if an organization produces similar products within the same domain. From the TASOVA PLUS research network, where up to 13 universities participate, we have detected, through a survey with more than 100 participants from the state’s industry, that there is more need for variability management than knowledge on software product lines. Therefore, we have a great challenge in the community to publicize technological advances in this field and continue research.