Software Product Lines: A market Need for Development

Over the last few years a new approach to software reuse has gained attention in both the software industry and academia. This approach is known as Software Product Lines, based on the systematic reuse of software artifacts by exploiting common points and managing variability between products established under the same architecture. This concept of product lines has been used by the manufacturing industry for years to reduce costs and increase productivity. However, it is relatively new to the software industry.

Studies have shown that companies have realized improvements in productivity by applying this approach. In this article, we’ll discuss some of the most important aspects of software product lines, such as variability, development processes and some of the tools to support Software Product Lines (SPL).

Overview of Software Product Lines

Experience has shown that projects that leverage reuse without proper planning can be more expensive than developing artifacts from scratch. It is essential to plan in advance which products will leverage a reuse strategy, along with the features that characterize these products. Planning for reuse continues throughout the development process. To facilitate mass customization, the platform must provide the means to meet the needs of different stakeholders. For this purpose, the concept of variability has been created to explore the characteristics that vary with the various products. As a consequence of applying this concept, artifacts that may be different in product line applications are modeled using variability.

Development Processes

The software product line paradigm is divided into two processes, domain engineering and application engineering.

Domain Engineering is responsible for establishing the reuse platform and defining the commonality and variability of the product line. The platform consists of all kinds of software artifacts (requirements, design, testing), also called asset base.

Application Engineering involves deriving concrete applications from the established platform in domain engineering. It explores the variability of the product line and ensures its correct instantiation according to the specific needs of the final applications.

The advantage of this division is that there is a separation of objectives, to build a robust platform and to build specific applications in a short time. To be effective, the two processes must interact in a way that is beneficial to both. In both domain engineering and application engineering, analysis, architecture, implementation and testing activities are performed to generate the products.

Traditional Software and Software Reuse Product Line

Developing an LPS involves “reuse” and, at first glance, this development may seem like just a reuse of traditional software. However developing a product line of software is much more elaborate.

In traditional software reuse, organizations have repositories where virtually every development effort is stored. This repository usually contains some reuse library of components, modules, and algorithms that developers are encouraged to use. The problem with this type of reuse is that it usually takes longer to find the desired functionality and adapt it to the current application than to build it again. This type of ad hoc reuse is not what characterizes the development of software product lines.

In developing product lines reuse is planned, automated and systematic.

The “repository of reuse” of a software product line is known as an asset base. These elements include all the artifacts that are the most expensive to develop, such as domain models, requirements, architecture, components, test cases, etc. In addition, these assets come from the beginning of the development cycle in order to be reused in several products. This means that asset customization for the current product typically does not include any new code, as it would in traditional approaches. Instead, an instantiation of the product occurs, using variability mechanisms incorporated into the base assets.

The products developed using this approach have a focus on the individual product; there is no focus on the family of software products and, therefore, does not implement the mechanisms of variability that characterize the development of the product family. So, when a new project is started, the development team tries to find another product within the organization that resembles the current product as much as possible. They then copy everything they can from that project, modify it and add what it takes to launch the new product. This approach can yield considerable savings, compared to the development of all products from scratch.

However, when comparing “clone and own” with the product line development approach, clone and own has some major drawbacks.

1. In product line development, all artifacts with the highest project costs are reused, not just the code that is the main focus of the clone and own approach.
2. In product line development, all base assets are developed keeping in mind the idea of ??reuse and variability. In the clone and own approach, everything is developed with a focus on the individual product, where the resources will not be spent in the development of mechanisms of variability that will not be used by this product. This implies that the “clone” will require a considerable customization effort to meet the requirements of the new product compared to another within a product line. The base assets of a product line will probably not require a high degree of customization to meet new product requirements, but rather an instantiation of built-in variability mechanisms previously built.
3. When we clone an existing product to create a new one, the links between these projects are non-existent and in the future individual maintenance will occur in both products. In the case of product line development, considerable savings can be realized throughout their life cycles, as the maintenance of base assets is a shared responsibility for all products in the family.

Important Aspects in the Adoption of Software Product Lines

The adoption of software product lines is different in some ways to the adoption of other types of technologies and processes. Its adoption requires a lot of time, especially in the early stages. This involves the change in the form of systems development that has the idea of ??a single system for the development of several products from one platform.

Adoption involves having an underlying asset base, supporting processes, and organizational structures; developing products from the asset base in a way that achieves business objectives; and institute mechanisms to improve and extend the software production effort as long as it makes sense. However, depending on the scenario, meeting adoption goals can become a complex activity.

In order to avoid additional complexities during the adoption phase, a company that wants to adopt a product line approach should have clear goals in mind. To achieve these objectives, the company selects one or more adoption strategies that specify how it will embrace product line practices. Then, an adoption plan shows, in detail, what activities should be undertaken to implement these strategies.

In this sense, the whole concept of product line adoption becomes very personal to the organization and the specific context seems to play a significant role in the adoption decision. Therefore, the transfer should be systematically and planned.

Advantages in Software Product Lines

Theories related to software product lines can generate several benefits classified into three types: organizational benefits, software engineering benefits and business benefits.

• Organizational benefits group advantages such as better understanding of the domain, greater ease of training people, a higher quality product and consequently customer trust.

• The benefits of software engineering include advantages such as reuse of requirements and their components, better requirements analysis, another view on requirements for the customer, quality control of software, setting of programming standards.

• Business benefits relate to reduced maintenance and test costs (thanks to re-use among several similar products).

In addition, product lines generate better process efficiencies and the ability to increase budget and improve time planning by having greater control of components that are part of the end product.

Essential Online Activities for Software Products

Software Product Lines combine three essential and highly interactive activities that blend business and technology practices.

Core Asset Development activity, where the goal is not to create the final product immediately, but to develop the assets to be reused in other later activities.

Product Development, which is part of the previously developed base assets that have been reused.

Management Activity includes technical and organizational management. Figure 1 shows this triad of essential activities, with each spinning circle representing one of the essential activities. All three are interconnected and in perpetual motion, showing that all three are essential and are closely connected, occurring in any order, and are highly iterative.

Development of Base Assets

Core Asset Development is an activity in the form of the  life cycle that results in asset base which together make up the platform of the product line. The purpose of this activity is to define the common aspects and variability of the product line and, thus, to obtain reusable artifacts and then to have a higher production capacity. Figure 2 shows the core of this activity along with its outputs and inputs.

The rotating circles in Figure 2 suggest there is no specific moment to add restrictions or new dates and these entries will not directly affect the process. In some contexts, the existing products will be based on the basis of these solutions so that they can be developed for zero future reuse.

Base assets include, but are not limited to, architecture and documentation, specifications, software components, tools, components, application models, performance models, schedules, orgaments, test plans, test plans, work plans and process descriptions. While it may be possible to create an asset base that can be used in all the products without any adaptations, in many cases, some adaptations are necessary to increase usability in the broader context of a product line.

Mechanisms of variation of the main active base used help to control the necessary adaptations and support the differences between the products of software. These adaptations should be planned before development.

Development of Produtos

In the course of product development, the products are developed from two basic sources, with no flat production base, to satisfy the requirements of the software product line. The essential inputs of product development are requirements, product line selection, basic products and production plan. Of course, you can find out how the base files will be used to build a product, or software source to assemble the parts of the product line. Figure 3 illustrates the product of development, together with its SaaS (News - Alert) and contextual factors.

As in Figure 1, the rotating circles are shown in Figure 3, indicating the parts involved. For example, the existence and availability of a certain product may affect the requirements of subsequent products. This episode is intended to provide feedback on problems or deficiencies found within basic assets.

Software Product Line Construction Approaches

There are three main approaches to developing online software products:

Proactive – This is an approach based on the first developed-for-future products. Here, all products are considered to have been made prior to full initial planning.

Reactive – In this, base active players already exist, as well as the version of the product line, or what happens in the evolution of this line, making increments at a minimum as new requirements appear.

Extractive – With this approach, we initially analyzed what products exist and how they are structured in order to extract the variabilities, so that an initial version of Product Line can be derived.

When applying the development of product lines, associated costs should be evaluated before starting the process.  Organizations have placed ad hoc projects on standby to leave free resources to build the active base of an LPS. But, many companies have benefitted from these processes and any company that develops software with a reasonably high level of maturity should at least make the feasibility study to understand if an SPL approach can be beneficial.