Software Product Lines: A succulent Minestrone with lots of Flavours (original) (raw)
Related papers
Software Engineering is an art of designing software products for users' consumption. This is an enduring knowledge area due to growing computational needs. Nobody succeed re-inventing the wheel. Re-usability is a key concept in software design. To an extent, the concept of software reuse has helped developers in meeting up with the market demands. Common reuse method includes using developed components, modules etc. to build new products. Yet, the traditional software engineering reuse patterns have not successfully addressed development challenges in terms of delivery time, cost and quality. This paper considers a new approach to reuse called Software Product Line Engineering (SPLE). This is described as "Industrial/Massive re-use". While traditional software engineering focuses on developing individual products, software product line practice focuses on developing product family. To gain significant reduction in development time, reduced cost (both in development and products) and increase software quality, development is channeled towards SPLE.
Emergence of Software Product Line
IJCA Proceedings on International …, 2012
Software Product line is emerging as an important paradigm and has provided competitive and various other benefits to organizations. This can help to overcome problems caused by resource shortages. The approach promotes asset re-use throughout the ...
Software product lines: organizational alternatives
icse, 2001
Software product lines enjoy increasingly wide adoption in the software industry. Most authors focus on the technical and process aspects and assume an organizational model consisting of a domain engineering unit and several application engineering units. In our cooperation with several software development organizations applying software product line principles, we have identified several other organizational models that are employed as well. In this article, we present a number of organizational alternatives, organized around four main models, i.e. development department, business units, domain engineering unit and hierarchical domain engineering units. For each model, its characteristics, applicability and advantages and disadvantages are discussed, as well as an example. Based on an analysis of these models, we present three factors that influence the choice of the organizational model, i.e. productline assets, the responsibility levels and the type of organizational units.
Software product lines evolution for valuable reusability
2015
Nowadays, adopting software product line (SPL) development approach becomes a successful strategic decision in software development since the rapid time to market necessity is guaranteed by SPLs due to assets reusability [1,2]. However, the expansion of the market segment implies a boost of user's requirements that should be satisfied by quickly developing new products [1]. Thus, an agile evolution of SPLs becomes a necessity. The general purpose of a SPL is the automated construction of a new product based on the reusability of existing features [2]. A feature is a characteristic defined by the domain experts [3] that abstracts a set of software-related resources called assets. Thus, a feature model (FM) represents all the products of the SPL and permits capturing products commonalities and variability [3]. To generate a new product, a user selects a set of features via a process called configuration by respecting the constraints defined in the FM [2]. Despite that SPLs permit ...
Widening the scope of software product lines���from variation to composition
2002
Architecture, components and reuse form the key elements to build a large variety of complex, high-quality products with a short lead-time. But the balance between an architecture-driven and a component-driven approach is influenced by the scope of the product line and the characteristics of the development organization. This paper discusses this balance and claims that a paradigm shift from variation to composition is necessary to cope with an increasing diversity of products created by an ever-larger part of an organization. We illustrate our claim with various examples.