Product line development (software)

from Wikipedia, the free encyclopedia

Product line development represents a methodical approach to software development, the aim of which is to create software product lines ( software product lines , sometimes also software families ).

Both the reuse and the variability are organized on the basis of a common so-called platform .

The term Software Product Lines was introduced by the Software Engineering Institute (SEI) at Carnegie Mellon University .

Basic principles

Product line development is based essentially on two basic principles:

  1. The description of the variability of the product line.
  2. The separation of domain development and application development.

Modeling the variability

The most important basic methodology in product line development is the modeling of variability. This is determined, held and changed orthogonally in all development phases of a product line project. The development phases of a product line project are roughly outlined

  • the requirements phase;
  • the architecture phase and
  • the implementation phase.

The variants identified in the requirements phase are taken into account in the products of the architecture phase . In particular, these will be variants in the scope of functions that arise based on customer requirements or business goals. In addition , variants can be identified during the architecture phase. For example, the integration with software from other manufacturers could develop variants. Finally, the variants from the requirements phase and from the architecture phase are taken into account in the implementation phase, in which further variants can arise, such as B. the individualized consideration of certain database systems . The development towards product lines that are developed beyond company boundaries leads to a complex software ecosystem in which customer wishes have an even greater influence on development than product lines that are driven purely by individual companies.

Advantages of the orthogonal variability modeling are that variants and their dependencies across among other trackable are. The reusability of already identified variants is also retained. Finally, the implementation effort for a specific product line can be drastically reduced in some cases: Since normally only a subset of the possible variants is implemented, only the variants identified for the product line need to be implemented. These implementations, or at least the domain artifacts of the platforms, can usually also be reused.

Separate domain and application development

In order to be able to identify variants of product lines, it must first be determined which components of a software actually need not only be created once (e.g. to meet a customer request), but can be used multiple times. This process is called scoping .

This reuse analysis is the starting point of a product line project. Scoping normally takes place after there is clarity about the product lines to be developed, ie a "product portfolio " or a "product roadmap " has been created by the business side.

Based on this, the domain-specific reusable artifacts are developed (e.g. requirements and architecture documents, test cases) that are decisive for the implementation phase. As a methodical approach, the product line development can therefore also be described as architecture-centered (see software architecture ).

literature

  • Böckle, Knauber, Pohl, Schmid (eds.): Software product lines. dpunkt, 2004, ISBN 3-89864-257-7 .
  • Van der Linden, Schmid, Rommes: Software Product Lines in Action. Springer-Verlag, 2007, ISBN 978-3-540-71436-1 .

Web links

Individual evidence

  1. ^ Jan Bosch: Keynote presentation at the Brazilian Symposium on Software Quality (SBQS 2009). ( Memento of the original from May 5, 2014 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. (PDF; 2.0 MB), June 2009, Ouro Preto, Brazil. @1@ 2Template: Webachiv / IABot / www.janbosch.com