• 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.

• Annual Conference of KIPS
• /
• 2021.11a
• /
• pp.437-439
• /
• 2021

SPL 방법론을 적용하여 개발한 제품군 시험은 모든 제품에서 사용되는 공통 부분과 일부 또는 단일 제품에서만 사용되는 가변 부분을 종합적으로 고려해야 하기 때문에 단일 소프트웨어 시험과는 상당히 다르다. 시험 커버리지는 작성된 시험에 대한 적절성을 측정하는 데에 사용되는 동시에 적절한 시험을 작성하기 위한 가이드로 사용되기 때문에 중요하다. SPL 시험에서 시험 커버리지 측정은 제품군을 구성하는 멤버제품 별로 측정될 수도 있지만, 이는 재사용을 기반으로 중복된 개발관련 활동의 최소화를 지향하는 SPL 의 원칙에 맞지 않다. 따라서 개별 제품이 아닌 SPL 수준에서 시험 커버리지 기준을 측정하고 시험의 적절성을 평가하기 위해서는 다른 방법이 필요하다. 이 논문에서는 구성가능한 소프트웨어 시스템(highly configurable software system)에 SPL 시험 방법을 적용하여 SPL 기반 제품군을 위한 시험 커버리지의 측정 방법을 제안하고 실험의 수행 결과를 기술하여 제안한 방법의 적절성을 검증한다.

• The KIPS Transactions:PartD
• /
• v.10D no.4
• /
• pp.697-708
• /
• 2003

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.

• 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.

• Proceedings of the Korean Information Science Society Conference
• /
• 2004.10b
• /
• pp.382-384
• /
• 2004

동일 제품군에 대한 소프트웨어 재사용 요구와 디지털 복합 제품군의 등장으로 임베디드 소프트웨어에 대한 아키텍처 중요성은 날로 증가하는 추세에 있다. 하지만 임베디드 시스템 개발이 하드웨어 중심으로 이루어지는 특성상 소프트웨어 아키텍처에 대한 연구는 미비한 현실이다. 이에 본 연구에서는 임베디드 시스템의 핵심 아키텍처 요소를 서비스로 보고, 서비스 제공을 위해 기능 중심의 아키텍처 스타일 및 프레임워크 개발 방법을 제시하고 인버터 제품에 대한 사례연구를 통해 임베디드 시스템 개발에 효과적인을 확인하였다.

• KIPS Transactions on Software and Data Engineering
• /
• v.6 no.7
• /
• pp.337-352
• /
• 2017

Clone-and-own reuse is an approach to creating new software variants by copying and modifying existing software products. A family of legacy software products developed by clone-and-own reuse often requires high maintenance cost and tends to be error-prone due to patch-ups without refactoring and structural degradation. To overcome these problems, many organizations that have used clone-and-own reuse now want to migrate their legacy products to software product line (SPL) for more systematic reuse and management of software asset. However, with most of existing methods, variation points are embedded directly into design and code rather than modeled and managed separately; variation points are not created ("engineered") systematically based on a variability model. This approach causes the following problems: it is difficult to understand the relationships between variation points, thus it is hard to maintain such code and the asset tends to become error-prone as it evolves. Also, when SPL evolves, design/code assets tend to be modified directly in an ad-hoc manner rather than engineered systematically with appropriate refactoring. To address these problems, we propose a feature-oriented method for extracting a SPL asset from a family of legacy applications. With the approach, we identify and model variation points and their relationships in a feature model separate from implementation, and then extract and manage a SPL asset from legacy applications based on the feature model. We have applied the method to a family of legacy Notepad++ products and demonstrated the feasibility of the method.

• Annual Conference of KIPS
• /
• 2003.11c
• /
• pp.1609-1612
• /
• 2003

사용자 인터페이스 명세에 사용되는 스토리보드 기법은 네비게이션 구조와 운영 시나리오를 효과적으로 표현할 수 있으나 멤버 시스템들의 변화를 표현할 수 있는 언어적 요소가 없어 소프트웨어 제품 군의 인터페이스 설계 명세에 그대로 적용하기에는 문제가 따른다. 본 논문에서는 기존의 스토리보드 기법을 제품 군에 사용할 수 있도록 확장하고 실제 시스템의 개발에 적용해 보았다.

• the USERS
• /
• s.45
• /
• pp.50-53
• /
• 2005

인성디지탈은 기업 정보시스템의 인프라가 되는 주요 업무용 소프트웨어, 그래픽, 보안, 백업 솔루션 제품군, 그리고 하드웨어 제품군 등 IT 전 부문에 걸쳐 고객이 필요로 하는 토탈 솔루션을 제공하고 있다. 소프트웨어와 네트워크 사업으로 시장 경험을 쌓아왔던 인성디지탈은 하드웨어 사업으로 그 영역을 확장함으로써 더욱 경쟁력있는 e-솔루션 사업 영역을 갖추고 IT 사업을 위한 새로운 도약을 준비하고 있다.

• KIPS Transactions on Software and Data Engineering
• /
• v.12 no.1
• /
• pp.1-18
• /
• 2023

Similar software is often developed with the Clone-And-Own (CAO) approach that copies and modifies existing artifacts. The CAO approach is considered as a bad practice because it makes maintenance difficult as the number of cloned products increases. Software product line engineering is a methodology that can solve the issue of the CAO approach by developing a product family through systematic reuse. Migrating product families that have been developed with the CAO approach to the product line engineering begins with finding, integrating, and building them as reusable assets. However, cloning occurs at various levels from directories to code lines, and their structures can be changed. This makes it difficult to build product line code base simply by finding clones. Successful migration thus requires unifying the source code's file path, class name, and method signature. This paper proposes a clustering method that identifies a set of similar codes scattered across product variants and some of their method full paths are different, so path unification is necessary. In order to show the effectiveness of the proposed method, we conducted an experiment using the Apo Games product line, which has evolved with the CAO approach. As a result, the average precision of clustering performed without preprocessing was 0.91 and the number of identified common clusters was 0, whereas our method showed 0.98 and 15 respectively.

• Annual Conference of KIPS
• /
• 2004.05a
• /
• pp.261-264
• /
• 2004

소프트웨어 제품 군 개발 방법은 모든 멤버 시스템에 대한 공통점과 차이점을 분석하여 공통된 소프트웨어 구조들과 요소들을 개발한다. 소프트웨어 제품 군 방법에서는 멤버를 구성하는 모든 시스템들의 공통점과 차이점을 동시에 관리해야 하므로 시스템 멤버들의 변화를 효과적으로 표현할 수 있는 방법이 필요하다. 이 논문에서 우리는, 요구 사양서와 변경 가능성을 기록하는 요구 변경 사양서를 바탕으로 시스템 운영 시나리오와 시스템 운영 변경 시나리오를 효과적으로 작성하는 방법을 제안하고, 이를 실제 시스템 개발에 적용해 보았다.