Product Line Approach Research Articles

A product-line approach to database reporting

Reporting for analysis is a common demand to database programmers. Unlike dynamic data analysis, reporting tend to be foreseeable. Despite this fact, staff waste their time programming similar reports time and again, where reports are often built from scratch with little if any reuse at all. Based on the predictability and similarity among reports, this work presents a product-line approach to database reporting. The feature model, core assets and production plan of the product line are sketched, and the architecture discussed. The work was conducted under a main requirement: data warehouse technology was not available. Either the cost or the lack of appropriate staff makes small-and-medium companies reluctant to use these sophisticated tools while simple reporting is all they need. In this scenario, the product-line approach can be a cost-effective solution to achieve reuse.

A software product line process simulator

Organizations are moving towards the use of software product line approaches to build product families. Cases have shown that software product line approaches can reduce time-to-market (TTM), costs, and resource usage. However, those benefits are not guaranteed in all situations, as they are affected by many factors including the number of available resources, market demands, reuse rates, and product line adoption and evolution strategies. Before initiating a software product line, an organization needs to evaluate available process options in order to see which ones best fit its goals. The aim of this research is to help this decision-making process by providing practical approaches and tools. In this article, a process evaluation approach is proposed, a process meta-model is introduced, and a product line process simulator is presented. The approach contains three steps: process definition, simulation, and evaluation. The process meta-model is used for defining software product line processes. The simulator can predict the development costs, schedule, and resource usage rates for a selected software product line process at a high level. The simulator uses DEVSJAVA as the modeling and simulation formalism and COPLOMO as the cost model. An example is also given and some simulation results are discussed. Copyright © 2006 John Wiley & Sons, Ltd.

PLFaultCAT: A Product-Line Software Fault Tree Analysis Tool

Industry currently employs a product line approach to software development and deployment as a means to enhance quality while reducing development cost and time. This effort has created a climate where safety-critical software product lines are being developed without the full range of accompanying safety analysis tools available to software engineers. Software Fault Tree Analysis (SFTA) is a technique that has been used successfully to investigate contributing causes to potential hazards in safety-critical applications. This paper further extends the adaptation of SFTA to product lines of systems by describing a software safety analysis tool called PLFaultCAT. PLFaultCAT is an interactive, partially-automated support tool to aid software engineers in the application of product-line software SFTA. The paper describes the integration of product-line SFTA and PLFaultCAT with the software development life cycle. The description includes the initial construction of the product-line SFTA as well as the automated derivation of software fault trees for product line members. The technique and tool are illustrated with a small case study throughout the paper.

Portlet syndication

A Portlet is a multistep, user-facing application delivered through a Web application (e.g., a portal). OASIS approved standard, WSRP, is an attempt to standardize the interface between the provider and the consumer of the Portlet. This initiative promotes Portlet interoperability, componentware practices, and the existence of a Portlet market. This work argues that the diversity of the settings where a Portlet might be syndicated recommends that Portlets be instrumented for variability, and this, in turn, demands a product-line approach. This work introduces a new source of variability, the “interaction lifecycle”, a description of the visible flow of a Portlet, and shows how this feature can be adapted to cater to the idiosyncrasies of the hosting application. Distinct variants are identified that permit the consumer to customize the presentation, content, and links of the Portlet markup in a controlled way. The use of product-line techniques allow the consumer to cope with this variability in a cost-effective manner. The article ends by illustrating how the extensible capabilities of WSRP are used to accomodate this process.

Aspect‐oriented re‐engineering of e‐learning courseware

Purpose – This paper proposes solutions to problems related to the maintenance and update of already existing e‐learning courseware.Design/methodology/approach – A structured approach in form of a reference model for the re‐engineering of existing educational material is presented. In this context, concepts already established in the area of aspect‐oriented programming are applied to deal with crosscutting concerns in e‐learning material. Finally, a software product line approach is proposed for the creation of new courseware using re‐engineered components.Findings – It turns out that some aspects of the methodology developed for aspect‐oriented programming can also be used to restructure the existing e‐learning material in such a way that maintenance is eased and redundancy is significantly reduced. In addition, software product lines for e‐learning material provide a global framework for coordinating the re‐engineering and reuse of components.Practical implications – The advantage of the proposed approa...

Tool-Supported Verification of Product Line Requirements

A recurring difficulty for organizations that employ a product-line approach to development is that when a new product is added to an existing product line, there is currently no automated way to verify the completeness and consistency of the new product's requirements in terms of the product line. In this paper we address the issue of requirements verification for product lines. We have implemented our approach in a requirements engineering tool called DECIMAL (DECIsion Modeling AppLication). DECIMAL is a requirements verification tool with a rich graphical user interface that automatically checks for completeness and consistency between a new product and the product line to which it belongs. The verification uses an SQL database server as the underlying analysis engine. The paper describes the tool and evaluates it in two applications: a virtual-reality, positional device-driver product line and the feature-interaction resolution problem.

Project Management in a Software Product Line Organization

In traditional software engineering management, managers provide focused guidance to a team responsible for producing a specific result in a specified amount of time. Today, however, organizations are increasingly taking a product line approach to software to exploit product commonalities. Software product line organizations have unique practices and definitions. These unconventional features offer new challenges and directions for traditional management. How does the traditional concept of a - a temporary endeavor aimed at creating a unique product or service - hold up under this new paradigm? In this article, we discuss this question, along with how the idea of a project and management techniques must expand to fit a product line context. In particular, we show how the overall guidelines, policies, and procedures that Thayer and Pyster spoke of some years ago remain crucially important in product line organizations today.

Reuse and variability in large software applications

Reuse has always been a major goal in software engineering, since it promises large gains in productivity, quality and time to market reduction. Practical experience has shown that substantial reuse has only successfully happened in two cases: libraries, where many generic and small components can be found; and product lines, where domains-specific components can be assembled in different ways to produce variations of a given product.In this paper we examine how product lines have successfully achieved reuse of coarse-grained components, and the underlying factors limiting this approach to narrowly scoped domains. We then build on this insight to present an approach, called software federation, which proposes a mechanism to overcome the identified limitations, and therefore makes reuse of coarse-grained components possible over a larger range of applications. Our approach extends and generalizes the product line approach, extending the concepts and mechanisms available to manage variability. The system is in use in different companies, validating the claims made in this paper.

Experience with the architectural design of a modest product family

AbstractMany product families are modest in the sense that they consist of a sequence of incremental products with, at any point in time, only a few distinct products available and minimal variations among the products. Such product families, nevertheless, are often large, complex systems, widely deployed, and possessing stringent safety and performance requirements. This paper describes a case study that tends to confirm the value of using a product‐line approach for the architectural design of a modest product family. The paper describes the process, design alternatives, and lessons learned, both positive and negative, from the architectural design of one such family of medical image analysis products. Realized benefits included identifying previously unrecognized common behavior and sets of features that were likely to change together, aligning the architecture with specific market needs and with the organization, and reducing unplanned dependencies. Most interesting were the unanticipated benefits, including decoupling the product‐family architecture from the order of implementation of features, and using the product‐family architecture as a ‘guiding star’ with subsequent releases moving toward, rather than away from, the planned architecture. Copyright © 2004 John Wiley & Sons, Ltd.

Modeling variability in software product lines with the variation point model

A major challenge for software reuse is developing components that can be reused in several applications. This paper describes a systematic method for providing components that can be extended through variation points, as initially specified in the software requirements. Allowing the reuser or application engineer to extend components at pre-specified variation points creates a more flexible set of components. The existing variation point methods do not provide enough design detail for the reuser. This paper introduces a method called the Variation Point Model (VPM), which models variation points at the design level, beginning with the common requirements. The product line approach provides a systematic approach for software reuse. A challenge with the product line approach is to model the variability between the core assets and the applications. This paper describes the VPM and how it is used for modeling four different approaches to variability, modeling variability using parameterization, modeling variability using information hiding, modeling variability using inheritance, and modeling variability using variation points. VPM allows a reuser or application engineer to extend components at pre-specified variation points. For this to be possible, a variation point must be modeled such that the reuser has enough knowledge to build a variant.

Behavioural inheritance in the UML to model software product lines

Traditional product line approaches struggle with complexity and weak evolution support. We propose an evolutionary software product line modelling approach based on controllable inheritance of product line members specifications. Instead of a predefined product line architecture we use hierarchies of implemented product specifications plus correctness control of product model transformations. The approach is supported by an appropriate tool prototype.

Calculating ROI for software product lines

Product line engineering has become an important and widely used approach for efficiently developing portfolios of software products. The idea is to develop a set of products as a single, coherent development task from a core asset base (sometimes called a platform), a collection of artifacts specifically designed for use across a portfolio. This approach produces order-of-magnitude economic improvements compared to one-at-a-time software system development. Because the product line approach isn't limited to specific technical properties of the planned software but rather focuses on economic characteristics, high return on investment has become the anthem of the approach's protagonists. Our software product line cost model can calculate the costs and benefits (and hence the ROI) that we can expect to accrue from various product line development situations. It's also straightforward and intuitive.

Software product lines

The software product line approach is a strategy for producing software-intensive products. The strategy encompasses organizational management, technical management, and software engineering aspects of product production. Object technology can make an important contribution to the success of a product line organization. In this paper these contributions are described in terms of an example product line.

Software Product Lines.

The software product line approach is a strategy for producing software-intensive products. The strategy encompasses organizational management, technical management, and software engineering aspects of product production. Object technology can make an important contribution to the success of a product line organization. In this paper these contributions are described in terms of an example product line.

소프트웨어 제품 군을 개발하기 위한 점진적 방법

소프트웨어 제품 군 개발 방법은 모든 멤버 시스템에 대한 공통점과 차이점들을 분석하여 표준 소프트웨어 구조와 컴포넌트들을 개발하여 생산라인을 갖추고, 제품 개발 조직에서 여러 버전을 병행하여 생산하고 관리하는 방법이다. 기존의 제품 군 방법은 성공하였을 경우에 경제적 이익은 크나, 초기 투자비가 매우 크다는 것과 첫 제품이 늦게 나온다는 것이 문제점으로 지적되고 있다. 이 논문에서 우리는 초기 비용을 적게 들이면서 궁극적으로 제품군 개발 방법을 조직에 적용할 수 있는 점진적 방법을 제안한다. 이 방법은 초기 버전을 개발할 때부터 변화 가능성에 관한 정보를 기록하여 차기 버전의 개발에 활용한다. 이 변화 분석의 결과는 본격 제품 군 개발로의 전환을 쉽게 해 준다. 변화 가능성을 기록하는 변경 사양서의 생성과 개선 기법을 중심으로 우리의 방법을 설명하고, YBS 시스템 개발을 예로 그 적용을 보인다. 우리가 제안한 방법은 초기에 많은 투자를 할 수 없거나 초기버전을 빨리 시장에 내 놓아야 하는 경우에 적용할 수 있는 저 위험 제품 군 개발 방법이다. In a software product line approach, developers first develop common software architecture and components by analyzing the characteristics of all software members, and then produce each application by integrating components. The approach is considered very effective means for developing and maintaining in parallel a software product family. Main disadvantage of this approach is that it requires a big up-front investment in preparing product line. Therefore, it takes time to deliver the first version. In this paper, we present an incremental method to develop software families, which requires small additional cost for initial versions and allows an organization to move smoothly to full-scale product line. We present our method by explaining how to record and upgrade the results of variations analysis, and show the application of our method by developing a family of YBS. Our method is a low-risk approach that can be effectively applied to an organization that starts developing software systems but has to deliver the first versions quickly to the market.

Structuring product family requirements for n-dimensional and hierarchical product lines

The software product-line approach (for software product families) is one of the success stories of software reuse. When applied, it can result in cost savings and increases in productivity. In addition, in safety-critical systems the approach has the potential for reuse of analysis and testing results, which can lead to a safer system. Nevertheless, there are times when it seems like a product family approach should work when, in fact, there are difficulties in properly defining the boundaries of the product family. In this paper, we draw on our experiences in applying the software product-line approach to a family of mobile robots, a family of flight guidance systems, and a family of cardiac pacemakers, as well as case studies done by others to (1) illustrate how domain structure can currently limit applicability of product-line approaches to certain domains and (2) demonstrate our progress towards a solution using a set-theoretic approach to reason about domains of what we call n-dimensional and hierarchical product families.

The economic impact of product line adoption and evolution

An organization faces many challenging decisions when transitioning to product line development: What is the best way to adopt a product line approach? How can we avoid disrupting regular product development? Once adopted, how should we evolve the product line? The article discusses how to optimize a product line's economic benefits by considering the adoption context and using product line scoping techniques.

Modelling and using product line variability in automotive systems

Although the product line approach for automotive systems is promising because it gains significant economies of scope, it requires systematic planning and continuous management of variability throughout the development process. The authors discuss the value of variability in product lines and describe their approach to modeling and using variability, which evolved from their work at Bosch.

Perspectives on Software Product Lines

Product line engineering is a recent concept and one of the hottest topics in software engineering aiming at synergy effects in software development. Diverse benefits like cost reduction, decreased time-to-market, and quality improvement can be expected from reuse of domain-specific software assets, several successful product line projects have been performed and documented [3]. Also non-technical benefits as result of network externalities, product branding, and sharing organizational costs have been observed.Following the remarkable success of the "First International Workshop on Software Product Lines: Economics, Architectures, and Implications" held at ICSE 2000 in Limerick [1], this second workshop stresses more the non-technical, that is, business and organizational aspects of product line adoption and institutionalization. Another major topic of interest are product line tools, as tool support seems to become more and more critical for the success of product line approaches. Different tool concepts have been proposed and discussed during the workshop. Requirements for tools and respective solutions seem to become more concrete, maybe resulting from the fact that the technical concepts and solutions of product line approaches are better understood and can therefore be better supported with tools.The strong emphasis on establishing contacts and giving experts and practitioners from academia and industry a platform for discussion has been continued during this second workshop.Section 2 of this workshop summary describes the formal structure of the workshop. In Section 3, a short summary of the invited talk on issues and opportunities in product line research is given. Section 4 summarizes key points of the presentations of the workshop participants that were given based on their submitted papers that are fully available at [2]. In Section 5, the plenary discussion is described and its major lessons learned are summarized. Section 6 concludes this paper.

Product line software engineering of embedded systems

In order to be able to determine whether the product line approach is suitable, a company needs to analyse its business drivers, commonality of existing products, domain knowledge owned by the engineering staff, and quality of the representations of existing software artefacts. In this paper we present evaluation criteria for the development of a product line and give an overview of the current state of practices in the embedded software area. Evaluation criteria are divided into three classes. Business drivers of a product line are defined by analysing product assortment and business manners. Domains and personnel are considered in the analysis of the preconditions and targets of a product line. In the development of core assets, elements that affect assets engineering are considered as well as the mechanisms needed in their maintenance. A product line architecture that brings about a balance between sub- domains and their most important properties is an investment that must be looked after. However, the subdomains need flexibility to use, change and manage their own technologies, and evolve separately, but in a controlled way.