• The Journal of Society for e-Business Studies
• /
• v.22 no.2
• /
• pp.39-60
• /
• 2017

Software product line engineering is widely recognized as an effective way for systematic software reuse, and many studies have been conducted to convert existing software development practices and processes into software product line. In order to convert existing software development into product line, a lot of investments are required such as dedicated development units, appropriate process selection and adaptation, and tool support. In particular, small businesses need business cases and specific practices for applying software product line engineering before its full-scale adoption. In this paper, we present a practical case of applying software product line engineering to the development of web system families and a process of systematically building and reusing software assets. To do this, we analyzed a number of web development projects and presented the experiences and various considerations of small software companies adopting software product line.

• Journal of Software Engineering Society
• /
• v.29 no.2
• /
• pp.1-6
• /
• 2020

Software product line development is a development paradigm that efficiently develops a product family by avoiding redundant development based on separation of the common part and the variable part of the product family. In software product line development, the source code that is used to produce a product family is called a product line code base, and when the product line code base is changed and the products of the product family are affected by the change, the activity of testing the affected products is called a product line regression testing. For product line regression testing, instead of conducting regression testing individually on each product of the product family, a more efficient regression testing would be possible if unnecessary testing that are irrelevant to the change can be avoided. This paper introduces SRTS, which is an automated method to efficiently perform software product line regression testing. SRTS divides the product line code base and test cases based on commonality and variability. Then SRTS identifies and selects the test cases affected by the change. Finally, it reduces unnecessary testing by rerunning only the selected test cases.

• Journal of Software Engineering Society
• /
• v.24 no.3
• /
• pp.77-89
• /
• 2011

Software product line engineering is a software reuse paradigm that helps organizations improve software productivity and quality by developing software products from reusable core assets. For the satisfaction of common and variable requirements among products in the product line, the core assets must be configurable according to the selection of variable features. Therefore, unlike software architecture model of a single product, product line architecture model must embed and express variabilities among the products. Many researches have proposed methods of embedding and expressing variabilities in the product line architecture models, but there are few comparative studies on the proposed methods. In this paper we discuss strong points and weak points of the proposed methods and compare expressiveness of the methods, which helps select a proper method.

• KIPS Transactions on Software and Data Engineering
• /
• v.2 no.6
• /
• pp.377-382
• /
• 2013

A convergence software development methodology based on product line engineering provides an architecture model for application development and it also provides workflow as a behavior specification of control component development to develop transaction centric application. To effect a change on software development based on product line engineering it has to be supported by a tool. But almost workflow modeling tools dose not support product line engineering concept. So we need new workflow modeling tool to support the convergence software development methodology. In this paper, we introduce a toolset for workflow modeling that consists of eclipse plug-in applications and open source tool and describe the relationships of tools through example.

• KIPS Transactions on Software and Data Engineering
• /
• v.11 no.7
• /
• pp.273-282
• /
• 2022

Testing approaches for configurable software product lines differs significantly from a single software testing, as it requires consideration of common parts used by all member products of a product line and variable parts shared by some or a single product. Test coverage is a measure of the adequacy of testing performed. Test coverage measurements are important to evaluate the adequacy of testing at the software product line level, as there can be hundreds of member products produced from configurable software product lines. This paper proposes a method for measuring code coverage at the product line level in configurable software product lines. The proposed method tests the member products of a product line after hierarchizing member products based on the inclusion relationship of the selected features, and quantifies SPL(Software Product Line) test coverage by synthesizing the test coverage of each product. As a result of applying the proposed method to 11 configurable software product line cases, we confirmed that the proposed method could quantitatively visualize how thoroughly the SPL testing was performed to help verify the adequacy of the SPL testing. In addition, we could check whether the newly performed testing for a member product covers the newly added code parts of a feature.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2012.11a
• /
• pp.1515-1518
• /
• 2012

제품라인공학 기반의 융합소프트웨어 개발 방법론에서는 어플리케이션 개발을 위해 아키텍처 모델을 제안하고 있다. 개발 모델에서는 명세를 이용하여 제어컴포넌트를 개발하도록 제안하는데 워크플로우는 트랜잭션을 주로 처리하는 어플리케이션 개발을 위해 제안되었다. 제품라인 공학 기반의 소프트웨어 개발이 효과를 발휘하기 위해서는 도구의 지원이 반드시 필요하다. 하지만 기존의 워크플로우 모델링 도구들은 제품라인 공학 개념을 지원하지 않기 때문에 워크플로우 기반의 제품 라인 소프트웨어 개발을 지원할 수 있는 도구의 개발이 필요했다. 본 논문에서는 워크플로우 기반의 제품라인 소프트웨어 개발을 지원하기 위해서 개발된 도구를 소개하고 개발된 도구의 활용 가능성을 확인하기 위해서 간단한 활용예제를 소개한다.

• Journal of KIISE:Software and Applications
• /
• v.36 no.7
• /
• pp.539-547
• /
• 2009

Software product line (SPL) engineering is an emerging paradigm for successful software reuse and has been adopted for various industrial and consumer products to improve their productivity and quality. However, most SPL methods require high initial costs and long development time, which makes many companies hesitate to adopt the SPL paradigm. In this paper we introduce a method to construct an SPL by extracting core assets from legacy components based on the feature model, which requires less initial time and effort. We also present a case study on cable set-top box software to illustrate the applicability of this method, and lessons learned that will provide guidelines for many companies to adopt the SPL paradigm.

• KIPS Transactions on Software and Data Engineering
• /
• v.3 no.1
• /
• pp.1-6
• /
• 2014

Many companies have tried to adopt Software Product Line Engineering for improving the quality and productivity of information systems and software product. There are several models defined in software product line methodology and each model has different abstraction level. Therefor it is important to maintain the traceability and consistency between models. In this paper, consistency checking rules are suggested by traceability matrix of work products.

• Journal of KIISE:Software and Applications
• /
• v.41 no.7
• /
• pp.469-480
• /
• 2014

Software Product Line (SPL) is a software development paradigm that guarantees high productivity, reduced cost, and shorter time-to-market by systematically planning and reusing commonality and variability. In order to maximize the benefits of SPL engineering, testing should be integrated into the SPL engineering lifecycle processes that consist of domain engineering and application engineering and should be performed with as little test efforts as possible. This paper proposes a systematic software product line test cases derivation method using combinatorial test design. By applying combinatorial test design to product line test cases derivation and exploiting commonality between products at the same time, the number of generated test cases is dramatically reduced with the result that they can be effectively reused by the products of the given product line. Case studies conducted in this paper show the efficacy of our method compared with other methods that use only commonality or combinatorial design or neither of them in terms of the number of derived test cases.

• KIPS Transactions on Software and Data Engineering
• /
• v.4 no.11
• /
• pp.487-498
• /
• 2015

Traceability enables software developers to trace up the changes occurring in software artifacts. In software product line, traceability is more complex than traceability in a single product as commonality and variability should be considered. Modeling traceability between features and requirements has been proposed in the past. However, traceability between requirements and architecture has more factors to consider, including many-to-many mappings and hierarchical structure of architectures. This paper proposes a method of systematically constructing platform traceability between platform requirements and platform architecture. This paper also shows the efficacy of the proposed mechanism through case studies.