제품 계열 공학(Product Line Engineering, PLE)은 도메인에서 멤버들이 갖는 공통 휘처를 재사용 가능한 핵심 자산으로 만들고, 만들어진 핵심 자산을 이용해서 애플리케이션을 개발하는 방법론이다. PLE는 핵심 자산을 개발해서 재사용하므로, 개발비용을 감소시키며 자산의 재사용성을 증가시킬 수 있다. 지금까지 여러 개의 PLE 방법론이 소개되었으나, 표준화된 PLE 방법론이 존재하지 않기 때문에, 방법론이 제시하는 프로세스나 산출물 등에서 차이가 크며, 산업계에서는 PLE 방법론을 채택하는데 어려움이 있다. 이에 프로세스의 선택과 효율적인 활용을 위해서 기존의 여러 방법론을 비교 분석하는 작업이 요구된다. 본 논문에서는 FAST, SEI SPL, PuLSE, Bosch의 제품 계열 프로세스, FOPLE, ESAPS, KobrA/PoLITe, Alexandria COPA, QADA 방법론 등 대표적인 PLE 방법론을 프로세스, 산출물, 적용 지침 측면 별로 비교 기준을 나누고, 비교 기준에 따라서 비교 평가를 수행한다. 또한 방법론간 공통성이 큰 항목과 적은 항목을 확인해서, PLE 방법론이 포함해야 하는 요소와 각 방법론이 개선해야 하는 사항을 확인한다. 본 논문은 적절한 프로세스를 선택 또는 재정의하는 과정에서 활용할 수 있을 뿐만 아니라, 향후 PLE 개발 방범론의 표준을 정의하는 과정에서 기반이 될 수 있을 것이다.
제품 계열 공학(Product Line Engineering, PLE)은 도메인에서 멤버들이 갖는 공통 휘처를 재사용 가능한 핵심 자산으로 만들고, 만들어진 핵심 자산을 이용해서 애플리케이션을 개발하는 방법론이다. PLE는 핵심 자산을 개발해서 재사용하므로, 개발비용을 감소시키며 자산의 재사용성을 증가시킬 수 있다. 지금까지 여러 개의 PLE 방법론이 소개되었으나, 표준화된 PLE 방법론이 존재하지 않기 때문에, 방법론이 제시하는 프로세스나 산출물 등에서 차이가 크며, 산업계에서는 PLE 방법론을 채택하는데 어려움이 있다. 이에 프로세스의 선택과 효율적인 활용을 위해서 기존의 여러 방법론을 비교 분석하는 작업이 요구된다. 본 논문에서는 FAST, SEI SPL, PuLSE, Bosch의 제품 계열 프로세스, FOPLE, ESAPS, KobrA/PoLITe, Alexandria COPA, QADA 방법론 등 대표적인 PLE 방법론을 프로세스, 산출물, 적용 지침 측면 별로 비교 기준을 나누고, 비교 기준에 따라서 비교 평가를 수행한다. 또한 방법론간 공통성이 큰 항목과 적은 항목을 확인해서, PLE 방법론이 포함해야 하는 요소와 각 방법론이 개선해야 하는 사항을 확인한다. 본 논문은 적절한 프로세스를 선택 또는 재정의하는 과정에서 활용할 수 있을 뿐만 아니라, 향후 PLE 개발 방범론의 표준을 정의하는 과정에서 기반이 될 수 있을 것이다.
Product Line Engineering(PLE) is an effective software development technique which produces applications using core assets. Because of reusing the core assets, PLE can save cost for developing products in a domain but increase reusability. There are about ten PLE methodologies available, but there a...
Product Line Engineering(PLE) is an effective software development technique which produces applications using core assets. Because of reusing the core assets, PLE can save cost for developing products in a domain but increase reusability. There are about ten PLE methodologies available, but there are not yet common agreements on PLE process and artifacts. This makes developers harder to choose a methodology and to apply it in practice. A comprehensive technical evaluation and comparison on existing PLE methodologies would be essential for practitioners. In this paper, we present a technical assessment of representative PLE methodologies; FAST, SEI SPL, PuLSE, Bosch's PL proceis, FOPLE, ESAPS, KobrA/PoLITe, Alexandria, COPA, QADA. They are compared in the criteria of process, artifacts, instructions, and special features. And we identify common or variable elements between methodologies and confirm elements to be improved in each PLE methodology. The assessment result would be well utilized in defining a practical methodology for PLE projects and in choosing an appropriate methodology among available ones.
Product Line Engineering(PLE) is an effective software development technique which produces applications using core assets. Because of reusing the core assets, PLE can save cost for developing products in a domain but increase reusability. There are about ten PLE methodologies available, but there are not yet common agreements on PLE process and artifacts. This makes developers harder to choose a methodology and to apply it in practice. A comprehensive technical evaluation and comparison on existing PLE methodologies would be essential for practitioners. In this paper, we present a technical assessment of representative PLE methodologies; FAST, SEI SPL, PuLSE, Bosch's PL proceis, FOPLE, ESAPS, KobrA/PoLITe, Alexandria, COPA, QADA. They are compared in the criteria of process, artifacts, instructions, and special features. And we identify common or variable elements between methodologies and confirm elements to be improved in each PLE methodology. The assessment result would be well utilized in defining a practical methodology for PLE projects and in choosing an appropriate methodology among available ones.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
ES APS (Engineering Software Architectures, Processes and Platforms for System Families)는 21개 회사와 연구소가 협력한 유럽의 연구 프로젝트로 시스템 패밀리를 위해서 아키텍처, 프로세스, 플랫폼을 사용하며, 시스템 품질을 향상시키는 방법을 연구할 목적으로 수행되었다. ESAPS는 두 단계로 구분된다.
Matinlassi가 PLA 설계 방법을 평가하는 목적은 현재 발표된 방법론들의 등급을 매기기 위해서가 아니라 PLA 공학 방법들을 전반적으로 살펴보기 위해서며, 특정 애플리케이션 개발 시 PLA 가 제공하는 기능을 선택하기 위한 결정 도구(decision tool) 개발에 기반이 되는 연구를 하기 위해서이다. 그러나 Matinlassi의 논문은 현재 소개된 PLE 방법론 중 다섯 가지만을 비교했으며, 방법론 전체가 아닌 제품 계열 아키텍처 설계 방법만을 소개하고 비교한다는 한계를 가진다.
본 논문에서 제시한 비교 결과를 사용하면 PLE 개념과 필수 요소를 확인할 수 있으며, 각 방법론에서 부족한 개발 단계나 산출물을 확인한 비교 결과는 PLE 방법론을 선택할 때 기준이 되는 정보가 되기도 한다. 또한 기존의 PLE 방법론을 정제하는 과정에서 활용할 수 있으며 PLE 방법론을 표준화 시키는 부분에서도 기반이 되는 연구가 되고자 했다.
Alexandria는 산업계와 협력하는 프로젝트로, 프로젝트 과정에서 획득한 결과를 재적용하고 개발된 방법과 도구에 대해서 피드백을 제공한다. 방법론은 재사용 가능한 플랫폼을 기반으로 제품을 개발하는 재사용성, PL을 이용해서 제품을 만드는 유연성 (flexibility), PLA의 진화, 제품 개발 시 사용되는 인력, 시간, 비용 소비를 최소화 하는 효율성을 목표로 한다.
본 논문에서는 지금까지 발표된 PLE 방법론을 정해진 기준에 따라 비교함으로써 방법론 간 공통점 및 차이점과 특징을 확인했다.<표 5>는 5장의 방법론 비교 결과를 요약한 표이다.
또한 이 프로젝트 중에서 Alexandria, ESAPS, KobrA는 방법론으로 정립되는 등 많은 연구가 진행되고 있다. 본 논문에서는 현재 발표된 PLE 방법론들을 비교하여 방법론을 선택하는 사용자들이 좀 더 합리적인 결정을 할 수 있도록 방법론 평가를 수행했다. 방법론들을 비교하기 위해서 네 가지 비교 기준을 선정하고 각 비교 기준에 해당하는 구체적 항목을 고려해서 FAST, SEI SPL, PuLSE, Bosch의 프로세스, FOPLE, ESAPS, KobrA, Alexandria, COPA, QADA 방법론을 비교했다.
제안 방법
Vehkomaki와 Kansala는 범용 제품 계열 프로세스(Generic Product Line Process, GPLP) 프레임워크를 소개하고 GPLP를 기준으로 SEI FSPLP(Software Engineering Institute :Framework for Software Product Line Practice), Synthesis DsHDornain-spedfic Iwgineering based on Synthesis), RSEB(Reuse~driven SW Engineering Business), SPICE NRC SPF(Nokda Research Center Software Process Framework based on SPICE v2.0)를 비교한다[2]. 비교 결과에 따르면 NRC SPF만 시스템 공학 분야에 대한 고려를 하며, SEI.
위해서 다음과 같은 항목으로 나누었다. 각 항목은 기존의 방법론을 연구하는 과정에서 적용 지침을 비교하는데 중요한 측면이라고 판단되는 부분으로 결정하였다. 프로젝트 수행 시 적용 지침이 분명한 방법론을 선택해서 사용한다면 산출물이 명확하며 제품 개발도 용이하다.
도메인 공학 프로세스에서 지침 제공의 상세성은 개발자들이 방법론을 선택하는데 큰 영향을 미칠 수있으므로 도메인 공학을 위한 지침 제공 여부에 대한 비교작업을 한다. 그리고 아키텍처는 도메인 공학 프로세스에서 핵심 적인 산출물이며 도메인 공학 지침이 대체로 상세하게 제시되어 있다고 하더라고 아키텍처를 개발하는 설계 지침 부분이 명확하지 않으면 핵심 자산을 개발하기 어려울 것이라고 생각하여 아키텍처 설계 지침의 상세도를 도메인 공학을 위한 지침과 분리해서 비교한다. 애플리케이션 공학 프로세스를 위한 지침 제공의 상세성은 애플리케이션 개발자들이 방법론 선택을 결정하는데 영향을 주므로 비교한다.
범용 아키텍처는 PLE 방법론에서 핵심 자산 개발 과정의 대표적인 산출물이므로 지원 여부와 이에 대한 명칭을 비교하는 과정이 필요하다. 또한 컴포넌트를 표현하는 용어에 차이가 있어서 각 방법론간에 이를 지칭하는 용어를 비교한다. 핵심 자산개발 과정에서 결정되는 가변점과 해당 가변점에서 선택 가능한 해결 방법(resolution)을 제시해 놓은 의사 결정 모델 (decision model) 역시 중요하며, 각 방법론간 의사 결정 모델 지원 여부와 이를 지칭하는 명칭에 대한 비교 작업이 필요하다.
본 논문에서는 현재 발표된 PLE 방법론들을 비교하여 방법론을 선택하는 사용자들이 좀 더 합리적인 결정을 할 수 있도록 방법론 평가를 수행했다. 방법론들을 비교하기 위해서 네 가지 비교 기준을 선정하고 각 비교 기준에 해당하는 구체적 항목을 고려해서 FAST, SEI SPL, PuLSE, Bosch의 프로세스, FOPLE, ESAPS, KobrA, Alexandria, COPA, QADA 방법론을 비교했다. 본 논문에서 제시한 비교 결과를 사용하면 PLE 개념과 필수 요소를 확인할 수 있으며, 각 방법론에서 부족한 개발 단계나 산출물을 확인한 비교 결과는 PLE 방법론을 선택할 때 기준이 되는 정보가 되기도 한다.
각 PLE 방법론의 장단점 및 특징을 비교한 연구가 있다면 산업계와 학계에서 적절한 프로세스를 선택 또는 재정의하는 과정에서 활용할 수 있을 것이다. 본 논문에서는 FAST, SEI SPL, RUSE, , Bosch의 제품 계열 프로세스, FOPLE, ESAPS, KobrA/PoLITe, Alexandria, COPA, QADA 방법론 등 대표적인 PLE 방법론을 프로세스, 산출물, 적용 지침 측면 별로 비교 기준을 나누고, 비교기준에 따라서 비교 평가를 수행한다. 또한 방법론간 공통성이 큰 항목과 적은 항목을 확인해서, PLE 방법론이 포함해야 하는 요소와 각 방법론이 개선해야 하는 사항을 확인한다.
본 절에서는 앞에서 제시하고 있는 방법론간 비교 결과에는 포함되지 않는 특징을 중요도에 따라 비교한다.
본 절에서는 지금까지 발표된 PLE 방법론들을 제시한 비교 기준에 따라 산출물 측면으로 비교한다.
본 절에서는 지금까지 발표된 PLE 방법론들을 제시한 비교 기준에 따라 적용 지침 측면으로 비교한다.
본 절에서는 지금까지 발표된 PLE 방법론들을 제시한 비교 기준에 따라 프로세스 측면으로 비교한다.
아키텍처 설계 지침 항목에 있어서 Bosch의 프로세스, QADA가 자세한 지침을 제시하며 PuLSE, FOPLE, ESAPS, COPA가 지침의 일부를 제시한다. 그리고 KobrA는 지침과 관련된 의미만을 일부 내포하고 있다.
소프트웨어 개발 방법론들을 연구한 결과 각 방법론이 제공하는 Stepwise 진행 순서와 세부 업무 지침의 구체적인 정도가 정비례하는 것은 아니었다. 일부 방법론은 방법론을 적용하는 진행 단계에 대한 설명은 구체적이지만, 각 단계에서 적용해야 할 지침은 명확히 기술되어 있지 않은 경우도 있으므로 두 가지 기준으로 나누어 비교한다. 도메인 공학 프로세스에서 지침 제공의 상세성은 개발자들이 방법론을 선택하는데 큰 영향을 미칠 수있으므로 도메인 공학을 위한 지침 제공 여부에 대한 비교작업을 한다.
적용 지침 측면의 비교는 각 방법론이 비교 기준을 얼마나 상세하게 표현하고 있는가를 강하게 지원, 지원, 약하게 지원, 의미 함축, 지원 안함으로 등급을 나누어 표현하였다. 강하게 지원은 Stepwise 진행 순서나 지침을 구체적이며 상세하게 제공하고 있는 경우이며 지원은 Stepwise 진행 순서나 지침을 전반적으로 지원은 하고 있지만 구체적이며 직접적으로 제공하지 않는 경우이다.
특징 측면의 비교는 각 방법론의 프로세스 측면, 산출물 측면, 적용 지침 측면에서 언급하지 않은 부분과 다른 방법론과 구별되는 고유한 특징을 비교한다. 그리고 특징이 해당 프로세스에서 의미적으로 중요한 부분인지 아닌지를 확인한다.
이론/모형
개발되었다[6]. KobrA 프로세스는 프레임워크 공학과 애플리케이션 공학으로 구성되며 산출물 외적인 품질에 대한 예측을 위해서 품질 모델(quality model)을 사용한다. KobrA는 PLE 개념 자체가 복잡하므로 방법론 자체는 간단해야 하며 확실하고 자세한 가이드 라인을 제시하는 등 체계적인 성격을 가져야 한다고 주장한다.
성능/효과
그 밖에 SEI SPLe 메커니즘 목록을 통해서 도메인 공학을 위한 지침을 약하게 지원하고 있고, 对SE와 Bosch의 프로세스 역시 도메인 공학을 위한 지침을 일부 제공하고 있다. FAST PASTA는 도메인 공학을 위한 지침을 도메인 전문가에게 의지하고 있으며, FOPLEe 휘처 모델링에 지침의 의미를 함축하고 있음을 확인할 수 있다.
PLE 방법론을 산출물 측면으로 비교해보면 SEI SPL, PuLSE, Bosch의 프로세스, FOPLE, ESAPS, Alexandria, COPA, QADA가 범용 또는 참조 아키텍처라는 이름으로 범용 아키텍처를 대체적으로 잘 표현하고 있었으며, FAST PASTA는 범용 아키텍처에 관한 언급을 하지 않고, KobrA 는 범용 아키텍처의 의미만을 함축하고 있음을 확인할 수 있다.
그 밖에 PLE 방법론들이 제시하는 특징적 산출물들은 FAST PASTA의 애플리케이션 모델링 언어(AML)와 개발도구를 제시하는 것, SEI SPL이 SE뿐만 아니라 기술적으로 일반적인 분야에 대한 언급을 하고 있다는 점, PuLSE가 발전을 위한 기준(baseline) 프로파일을 정의하는 것, Bosch의 프로세스가 휘처 그래프를 사용하고 있다는 점, FOPLE이품질 특성을 포함한 휘처 모델을 사용하는 것, ESAPS가 도메인 전문 용어와 참조 요구사항을 사용하며 개발 도구를 지원한다는 점, KobrA가 진화 그래프를 사용하는 것과 컴포넌트를 KCOMPONENT라고 지칭한다는 점, Alexandria 가 개발 도구를 지원 한다는 점, COPA와 QADA가 아키텍처 관련 산출물을 포함하고 있다는 것 등을 들 수 있다.
것을 확인할 수 있다. 그러나 각 방법론은 컴포넌트를 지칭하는 부분에서 차이가 있는데 FOPLE의 컴포넌트가 서브 시스템 프로세스, 모듈 단위로 나뉜다는 것과 KobrA에서 말하는 KOMPONENT 단계가 명세, 실체화 (realization) 단계, 구현 단계로 나뉘는 것, COPA에서 컴포넌트를 제품 패밀리 플랫폼이라고 언급하며 서브 시스템과 인터페이스를 가진다는 점이 특징적이다.
방법론들을 비교하기 위해서 네 가지 비교 기준을 선정하고 각 비교 기준에 해당하는 구체적 항목을 고려해서 FAST, SEI SPL, PuLSE, Bosch의 프로세스, FOPLE, ESAPS, KobrA, Alexandria, COPA, QADA 방법론을 비교했다. 본 논문에서 제시한 비교 결과를 사용하면 PLE 개념과 필수 요소를 확인할 수 있으며, 각 방법론에서 부족한 개발 단계나 산출물을 확인한 비교 결과는 PLE 방법론을 선택할 때 기준이 되는 정보가 되기도 한다. 또한 기존의 PLE 방법론을 정제하는 과정에서 활용할 수 있으며 PLE 방법론을 표준화 시키는 부분에서도 기반이 되는 연구가 되고자 했다.
본 논문의 비교 결과를 프로세스 측면에서 살펴보면, 대부분의 PLE 방법론들이 프로젝트 결과물에 대한 시장성을 전망하는 비즈니스 케이스 분석이나 프로젝트 도메인 영역을 설정하는 PL 범위 설정 단계를 가지고 있음을 확인할 수 있다.
세부 업무 지침을 제시하는 정도는 ESAPS가 체계적이지는 않지만 지침을 강하게 지원한다고 판단되며 FOPLE, KobrA는 ESAPS 보다는 부족하지만 대부분 제시한다. 그 외의 방법론들은 지침을 일부 제시하거나 또는 거의 지원하지 않는다고 본다.
애플리케이션 개발의 경우 핵심 자산의 개발 단계와 마찬가지로 대부분의 방법론이 지원하고 있으나 PuLSE 가 RIXE-I라는 명칭을 사용하는 것과, 방법론에서 제품 공학 또는 애플리케이션 공학이라는 용어를 일반적으로 사용하고 있는 점, QADA가 애플리케이션 개발 단계를 지원하지 않는다는 것을 확인할 수 있다.
컴포넌트가 존재하는지를 비교하는 항목에서는 PLE가 컴포넌트 기반 개발의 확장 개념이라는 부분에서 예상 가능하듯, 모든 PLE 방법론이 설계와 구현 단계에 컴포넌트를 포함한다는 것을 확인할 수 있다. 그러나 각 방법론은 컴포넌트를 지칭하는 부분에서 차이가 있는데 FOPLE의 컴포넌트가 서브 시스템 프로세스, 모듈 단위로 나뉜다는 것과 KobrA에서 말하는 KOMPONENT 단계가 명세, 실체화 (realization) 단계, 구현 단계로 나뉘는 것, COPA에서 컴포넌트를 제품 패밀리 플랫폼이라고 언급하며 서브 시스템과 인터페이스를 가진다는 점이 특징적이다.
후속연구
이에 프로세스의 선택과 효율적인 활용을 위해서 기존에 발표된 방법론을 비교 분석하는 작업이 요구된다. 각 PLE 방법론의 장단점 및 특징을 비교한 연구가 있다면 산업계와 학계에서 적절한 프로세스를 선택 또는 재정의하는 과정에서 활용할 수 있을 것이다. 본 논문에서는 FAST, SEI SPL, RUSE, , Bosch의 제품 계열 프로세스, FOPLE, ESAPS, KobrA/PoLITe, Alexandria, COPA, QADA 방법론 등 대표적인 PLE 방법론을 프로세스, 산출물, 적용 지침 측면 별로 비교 기준을 나누고, 비교기준에 따라서 비교 평가를 수행한다.
그리고 ESAPS와 KobrA가 메타 모델을 제시하고 있는 점과 ESAPS와 Alexandria/} 핵심 자산을 구현 수준으로 언급하는 것도 특징적이다. 그 밖에 PLE 개발 단계에 기본적으로 포함되지는 않지만 각 방법론이 고유하게 제시하고 있는 특징들이 있는데, 그 중에서 FAST PASTA가 제시하는 도메인 특정 애플리케이션 공학 프로세스, PuLSE가 제시하는 프로세스 특화 방법, FOPLE이 제시하는 휘처 모델, KobrA가 제시하는 메타 모델 활용 방법 등의 특징들이 PLE 방법론을 사용하는 제품개발에 전반적으로 활용되면 유용할 것이다. 본 논문에서 제시한 비교 결과를 통해서 PLE 방법론에 필요한 요소임에도 불구하고 표현되어 있지 않은 단계와 활동을 비교할 수 있으며, 각 방법론을 정제하거나 표준 방법론을 표현할 때, 이 부분을 참고해서 활용 할 수 있을 것으로 예상한다.
본 논문에서는 FAST, SEI SPL, RUSE, , Bosch의 제품 계열 프로세스, FOPLE, ESAPS, KobrA/PoLITe, Alexandria, COPA, QADA 방법론 등 대표적인 PLE 방법론을 프로세스, 산출물, 적용 지침 측면 별로 비교 기준을 나누고, 비교기준에 따라서 비교 평가를 수행한다. 또한 방법론간 공통성이 큰 항목과 적은 항목을 확인해서, PLE 방법론이 포함해야 하는 요소와 각 방법론이 개선해야 하는 사항을 확인한다.
그러므로 방법론에서 제시하는 Stepwise 진행 순서가 중요하다. 또한 방법론에서 세부 업무 지침을 제공하면 프로젝트를 수행하는데 혼란이 줄어들 것이며 프로젝트 성공 가능성도 증가할 것이다. 소프트웨어 개발 방법론들을 연구한 결과 각 방법론이 제공하는 Stepwise 진행 순서와 세부 업무 지침의 구체적인 정도가 정비례하는 것은 아니었다.
현재 PLE 기반의 개발을 지원하는 여러 방법론이 존재하고 있지만 아직까지 방법론 표준화는 이루어지지 않고 있다. 본 논문에서 제시하고 있는 방법론의 공통항목들은 PLE 방법론의 필수 요소로, 표준 방법론을 개발하는데 있어서 기본 프로세스와 산출물을 정하는데 도움이 될 수 있을 것이다.
그 밖에 PLE 개발 단계에 기본적으로 포함되지는 않지만 각 방법론이 고유하게 제시하고 있는 특징들이 있는데, 그 중에서 FAST PASTA가 제시하는 도메인 특정 애플리케이션 공학 프로세스, PuLSE가 제시하는 프로세스 특화 방법, FOPLE이 제시하는 휘처 모델, KobrA가 제시하는 메타 모델 활용 방법 등의 특징들이 PLE 방법론을 사용하는 제품개발에 전반적으로 활용되면 유용할 것이다. 본 논문에서 제시한 비교 결과를 통해서 PLE 방법론에 필요한 요소임에도 불구하고 표현되어 있지 않은 단계와 활동을 비교할 수 있으며, 각 방법론을 정제하거나 표준 방법론을 표현할 때, 이 부분을 참고해서 활용 할 수 있을 것으로 예상한다.
Synthesis는 도메인 공학 활동이 구체적으로 제시되어 있으며, RSEB는 COTS등의 활용에 대한 구체적인 언급은 없지만, 제품 계열로 변화하는 부분이 상세하게 제시되어 있다. 이 논문은 비교를 통해서 실제 SE 활동 분야와 프레임워크를 정의하고 있지만, 일부 프레임워크만을 비교하는 한계점을 갖는다.
참고문헌 (18)
Matinlassi, M., 'Comparison of Software Product Line Design Methods: COPA, FAST, FORM, KobrA and QADA,' icse, 5, pp.127-136, 2004
Vehkomaki, T. Kansala, K., 'A Comparison of Software Product Family Process Frameworks,' LNCS 1951, pp. 135-145, 2000
Weiss, D. et al., Software Product-Line Engineering, Addison-Wesley, 1999
Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns, Addison Wesley, Aug., 2001
Bayer, J. et al., 'PuLSE: A Methodology to Develop Software Product Lines,' Proceeding of Symposium on Software Reusability '99, May, 1999
Atkinson, C., Bayer, J., Bunse, C., Kamsties, E., Laitenberger, O., Laqua, R., Muthig, D., Paech, B., Wust, J. and Zettel, J., Component-Based Product Line Engineering with UML, Addison Wesley, 2002
Jan, B., Design and use of software architectures, Addson-Wesley, 2000
이재준, 강교철, '프로덕트 라인 소프트웨어 개발 프로세스,' 정보과학회지, Vol.20, No.3, pp.23-30, 3, 2002
Streitferdt, D. et al., 'Details of Formalized Relations in Feature Models Using OCL,' Engineering of Computer-Based Systems, 2003. Proceedings. 10th IEEE International Conference and Workshop on the, 7-10 April, 2003
Jaejoon L., Kyo K., and Sagoong K., 'A Feature-Based Approach to Product Line Production Planning,' SPLC2004, LNCS3154, pp.183-196, 2004
Knauber, P., and Succi, G., 'Perspective on Software Product Lines, ' Workshop #15 at 22nd ICSE
ITEA, Web Site for ESAPS, at URL: http://www.esi.es/en/Projects/esaps/esaps.html
Philips Research, 'COPA-A Component-Oriented Platform Architecting Method for Families of Software-Intensive Electronic Products,' Presentation Material (in PowerPoint/PDF), SPLC, 2000
Matinlassi, M., Niemela, E., and Dobrica, L., 'Quality-driven architecture design and quality analysis method: A revolutionary initiation approach to a product line architecture,' VTT Technical Research Center of Finland, ESPOO2002, 2002
Kettemann, S., Muthig, D., and Anastasopoulos, M., Product Line Implementation Technologies: Component Technology View, Technical Report, No. 015.03/E, IESE, March, 2003
ILMENAU, Web Site for Alexandria, at URL : http://www.theoinf.tu-ilmenau.de/-ricbisch/pld/indcx.html
ESS, Web Site, at URL: http://www.ess.co.at/ECOSIM/development.html
Bosch, F., 'Evaluation of Sofware Development Life Cycle Methodology Implementation,' ACM'SIGSOFT, SOFTWARE ENGINEERING NOTES, Vol.7 No.1, pp.45, Jan, 1982
※ AI-Helper는 부적절한 답변을 할 수 있습니다.