소프트웨어 공학: Software Product Line (SPL)

 

예전에 정리했던 SPL (소프트웨어 제품 라인)에 대해 업데이트를 해 보려고 합니다.

어려운 개념은 아니지만, 적용하기는 쉽지 않은거 같아요.

수년동안 노력을 했지만, 정말 어려운거 같은데요.

이번 포스팅을 통해 다시 정리도 하고, 마음도 다잡는 기회가 되면 좋겠습니다.

 

 

출처: https://www.samares-engineering.com/en/2021/07/19/product-line-engineering-and-model-based-systems-engineering-overview/

 

제품 라인 (Product Line)과 소프트웨어 제품 라인(Software Product Line)의 정의

"제품 라인(Product Line)"이란 특정 마켓 세그먼트 혹은 미션의 구체적인 니즈를 충족시키고, 특정한 방식에서 핵심 자산의 공통집합을 이용하여 개발된 공통의 피처(Feature) 집합을 공유하는 소프트웨어 집약적인 시스템들의 집합입니다.

"소프트웨어 제품 라인(Software Product Line)" 이란 플랫폼과 대량의 고객 맞춤(Mass Customization)을 이용하여 소프트웨어 어플리케이션을 개발하는 패러다임 입니다.

그리고 이들을 이용한 "소프트웨어 제품 라인 공학(Software Product Line Engineering)"이란 소프트웨어 개발을 위한 전략적 접근 방법으로, 비즈니스, 조직, 그리고 개발 기술 모두에 영향을 미치며, 넓은 범위의 소프트웨어 집약적인 시스템들을 빠르게 낮은 비용으로 개발하면서도 높은 품질의 소프트웨어를 제공할 수 있는 검증된 방법이라 할 수 있습니다.

따라서, 이를 하나로 정의하면 제품 라인이란 재사용 가능한 공통된 자산을 바탕으로 구성된 시스템들의 조합(집합)이며, 이를 기반으로 소프트웨어를 개발하는 방법론이 소프트웨어 제품 라인이고, 이를 체계적으로 정리한 전략적 접근이 소프트웨어 제품 라인 공학이라 라고 볼 수 있을거 같습니다.

 

소프트웨어 제품 라인 주요 개념

소프트웨어 제품 라인(Software Product Line, SPL)은 여러 제품이 비슷한 기능이나 구조를 공유하면서도 각 제품의 특수 요구 사항을 만족하도록 유연하게 확장될 수 있습니다. 소프트웨어 제품 라인은 대규모 소프트웨어 개발에서 시간과 비용을 절약하고, 품질을 높이는 데 중요한 역할을 합니다. 주요 개념은 다음과 같습니다:

개념	설명
핵심 자산 (Core Assets)	다양한 소프트웨어 제품들이 공통으로 사용하는 재사용 가능한 구성 요소, 아키텍처, 모델, 설계 패턴 등을 포함합니다.
변동성과 공통성 (Variability and Commonality)	공통성(Commonality): 모든 제품에 공통적으로 적용되는 부분을 나타냅니다. 변동성(Variability): 각 제품이 특정 요구 사항에 맞춰 변경될 수 있는 부분을 나타냅니다. 제품 라인의 성공적인 구현은 변동성을 효율적으로 관리하고 활용하는 데 달려 있습니다.
핵심 아키텍처 (Core Architecture)	핵심 아키텍처는 제품 라인의 중심 구조를 정의합니다. 이 아키텍처는 여러 제품에서 재사용할 수 있는 공통된 구조를 제공하며, 각 제품의 특정 요구 사항에 따라 쉽게 확장하거나 수정할 수 있도록 설계됩니다. 코어 아키텍처는 시스템의 유연성과 확장성을 보장하기 위한 중요한 요소입니다.
제품 구성 (Product Configuration)	제품 라인 내의 개별 제품은 핵심 자산과 변동성 관리 메커니즘을 통해 구성(Confugure)됩니다. 이를 제품 구성(Product Configuration)이라고 하며, 각 제품의 요구 사항에 따라 선택된 기능, 구성 요소, 그리고 설정 값이 적용됩니다. 제품 구성은 다양한 도구를 통해 자동화되기도 하며, 이를 통해 여러 제품을 신속하고 일관되게 개발할 수 있습니다.
제품 라인 관리 (Product Line Management)	소프트웨어 제품 라인은 관리가 필수적입니다. 이는 코어 자산과 제품 간의 관계, 변동성 관리, 제품 라인의 진화 등을 체계적으로 관리하는 프로세스를 포함합니다. 제품 라인 관리에서는 각 제품의 요구 사항을 분석하고, 그에 맞는 변형을 적용하며, 모든 제품에서 품질을 유지하기 위한 조치를 취합니다.
재사용 기반 개발 (Reuse-Based Development)	소프트웨어 제품 라인의 가장 중요한 목적 중 하나는 재사용(Reusability)입니다. 기존의 코어 자산을 재사용함으로써 개발 시간을 단축하고, 비용을 절감하며, 품질을 향상시킬 수 있습니다. 이를 통해 소프트웨어 개발의 효율성을 크게 높일 수 있습니다.
도메인 엔지니어링 (Domain Engineering)	도메인 엔지니어링은 소프트웨어 제품 라인에서 공통의 요구 사항과 변동성을 분석하고 모델링하는 단계입니다. 이는 제품 라인의 코어 자산을 정의하는 데 중요한 역할을 하며, 제품 라인 내에서 발생할 수 있는 다양한 요구 사항을 관리하는 기초가 됩니다.
애플리케이션 엔지니어링 (Application Engineering)	애플리케이션 엔지니어링은 핵심 자산을 이용해 구체적인 제품을 개발하는 과정입니다. 이는 도메인 엔지니어링에서 정의된 공통 자산과 변동성을 기반으로 특정 제품을 구성하고, 이를 고객의 요구에 맞게 조정하는 역할을 합니다.
변동성 모델링 (Variability Modeling)	변동성 모델링은 소프트웨어 제품 라인에서 다양한 변동성을 관리하는 도구 및 기법을 정의하는 것을 의미합니다. 이는 각 제품의 요구 사항에 맞게 소프트웨어의 기능을 선택하고 조정할 수 있도록 돕습니다. 이를 통해 제품 라인의 유연성을 극대화하고, 다양한 시장 요구에 대응할 수 있습니다.

 

 

소프트웨어 제품 라인 프로세스

1. 도메인 엔지니어링 (Domain Engineering)

1.1 범위 설정 (PL Scoping)

초기 범위 설정은 소프트웨어 제품 라인 프로젝트에서 다음과 같은 중요한 목적을 달성하는 데 필수적입니다:

• 제품 라인의 포함될 제품 식별: 어떤 기능이 모든 제품에 공통으로 사용되는지, 어떤 기능이 제품마다 달라질 수 있는지를 명확하게 정의합니다.
• 시장 및 고객 요구 사항 파악: 제품 라인이 타겟으로 하는 시장의 요구 사항을 이해하고, 이를 기반으로 제품을 정의합니다.
• 주요 공통 피처 및 가변 피처 정의: 제품 라인의 코어 자산을 효과적으로 정의하고, 재사용을 극대화할 수 있는 자산을 선정합니다.
• 프로젝트 일정과 비용 산정: 범위를 명확히 정의함으로써 프로젝트 일정과 비용을 정확하게 산정할 수 있습니다.
• 위험 요소 식별: 범위 설정 과정에서 발생할 수 있는 기술적, 관리적 위험 요소를 조기에 식별하고 대처할 수 있습니다.

범위 설정에 대한 자세한 내용은 별도로 정리해 두었습니다. 참고 해 주세요.

SPL: 범위 설정 (PL Scoping) - 포트폴리오, 도메인, 자산

 

 

1.2 도메인 요구 공학 (Domain Requirements Engineering)

도메인 요구사항 엔지니어링(Domain Requirements Engineering)은 제품 라인 내에서 공통적으로 사용될 기능과 변동성을 명확히 정의하는 과정입니다. 이 과정은 다양한 제품군에서 재사용 가능한 요구사항을 식별하고 이를 체계적으로 관리하는 것이 목적입니다. 도메인 요구사항 엔지니어링은 제품 라인 전체의 공통성과 변동성을 결정하는 기반이 되며, 이후 단계에서 개발될 소프트웨어 아키텍처, 설계, 구현에 큰 영향을 미칩니다.

• 공통 요구사항(Common Requirements)과 변동 요구사항(Variable Requirements)을 식별.
• 여러 제품에서 재사용 가능한 요구사항을 체계적으로 관리.
• 제품군 간 변동성을 효율적으로 다루기 위한 변동성 관리 기법을 도입.
• 도메인의 시장 요구사항과 기술적 요구사항을 충족하는 요구사항을 정의.

1.3 도메인 설계 (Domain Design)

소프트웨어 제품 라인(SPL) 프로세스의 도메인 설계(Domain Design)는 도메인 요구사항 엔지니어링에서 도출된 공통성과 변동성을 바탕으로, 제품 라인 전체에서 사용할 공통 아키텍처와 재사용 가능한 자산을 설계하는 단계입니다. 도메인 설계는 이후 각 개별 제품의 개발을 위한 기초를 제공하며, 이를 통해 여러 제품이 신속하고 효율적으로 개발될 수 있도록 준비하는 중요한 과정입니다.

• 공통 요구사항을 만족시키는 공통 아키텍처를 설계.
• 다양한 제품 간의 변동성을 처리할 수 있는 구조를 설계.
• 재사용 가능한 코어 자산(핵심 자산)을 식별하고 설계.
• 핵심 자산 저장소에 저장할 설계 및 구현 자산을 정의.
• 각 제품에서 구성 가능한 시스템 설계를 제공.

1.4 도메인 실현 (Domain Realization)

도메인 실현(Domain Realization)은 소프트웨어 제품 라인(SPL) 프로세스에서 도메인 요구사항과 설계에서 도출된 개념을 실제로 구현하는 단계입니다. 이 단계는 소프트웨어 제품 라인 내에서 정의된 아키텍처, 설계, 재사용 가능한 자산을 구체적인 코드와 실행 가능한 소프트웨어 구성 요소로 변환하는 중요한 과정입니다. 도메인 실현 단계는 다양한 소프트웨어 제품에서 재사용할 수 있는 핵심 자산을 개발하고, 이를 핵심 자산 저장소(Core Asset Repository)에 저장하여 관리하게 됩니다.

• 도메인 설계 단계에서 정의된 아키텍처와 재사용 가능한 컴포넌트를 구현.
• 여러 제품에서 재사용할 수 있도록 변동성 관리 메커니즘을 구현.
• 핵심 자산을 구체적인 코드, 라이브러리, 모듈로 개발하여 핵심 자산 저장소에 저장.
• 각 제품의 특성에 맞게 조정 가능한 구성 요소를 포함한 재사용 가능한 자산을 생성.

1.5 도메인 테스팅 (Domain Testing)

도메인 테스트(Domain Testing) 단계는 도메인 실현에서 개발된 공통 아키텍처와 재사용 가능한 컴포넌트, 그리고 변동성 관리 메커니즘이 제대로 동작하는지 검증하는 중요한 과정입니다. 도메인 테스트는 소프트웨어 제품 라인의 품질을 보장하기 위한 핵심적인 단계로, 여러 제품에서 재사용될 자산들이 각각의 요구사항을 만족하고, 변동성에 따라 다양한 구성이 올바르게 동작하는지를 확인합니다.

• 도메인 설계에서 정의된 공통 아키텍처와 컴포넌트가 제대로 구현되었는지 검증.
• 변동성 관리 메커니즘이 각 제품의 특성에 맞춰 올바르게 동작하는지 확인.
• 재사용 가능한 자산들이 모든 제품에서 일관된 품질을 제공하는지 확인.
• 구현된 자산들이 핵심 자산 저장소(Core Asset Repository)에 적합하게 저장되고 관리되는지 검토.

 

2. 어플리케이션 엔지니어링 (Application Engineering)

2.1 어플리케이션 요구 공학 (Application Requirements Engineering)

어플리케이션 요구공학(Application Requirements Engineering) 단계는 소프트웨어 제품 라인(SPL) 프로세스에서 특정 제품의 요구 사항을 분석하고 정의하는 중요한 과정입니다. 이 단계는 도메인 요구 사항 엔지니어링(Domain Requirements Engineering)에서 정의된 공통 자산과 변동성을 바탕으로, 각 제품의 특수한 요구 사항을 수집하고 조정하여 제품을 구성하는 데 필요한 요구 사항을 명확히 합니다. 이 단계는 특히 특정 시장이나 고객의 요구 사항을 충족하는 개별 제품을 설계하는 데 필수적입니다.

• 각 개별 제품의 요구 사항을 명확히 정의.
• 도메인 요구 사항에서 도출된 공통 자산과 변동성을 구체적인 제품 요구 사항에 반영.
• 핵심 자산 저장소에 저장된 자산과 연계하여 제품의 요구 사항을 충족하는 최적의 솔루션을 찾음.
• 제품이 만족해야 할 기능적 요구 사항과 비기능적 요구 사항을 식별하고 명세화.

2.2 어플리케이션 설계 (Application Design)

어플리케이션 설계(Application Design) 단계는 소프트웨어 제품 라인(SPL) 프로세스에서 특정 제품의 구체적인 설계를 수행하는 중요한 단계입니다. 이 단계는 어플리케이션 요구공학(Application Requirements Engineering) 단계에서 정의된 요구 사항을 기반으로, 개별 제품을 어떻게 구현할지에 대한 상세한 설계를 진행합니다. 소프트웨어 제품 라인의 핵심 자산 저장소(Core Asset Repository)에 저장된 재사용 가능한 자산을 활용하여 설계를 최적화하고, 제품 간 변동성을 관리하며 각 제품의 특수 요구 사항을 충족하도록 설계하는 것이 이 단계의 핵심입니다.

• 제품 요구 사항을 충족하는 상세한 소프트웨어 설계 수행.
• 핵심 자산 저장소에서 재사용 가능한 아키텍처와 컴포넌트를 활용하여 설계 최적화.
• 변동성 관리를 통해 각 제품에 맞는 기능과 구조를 설계.
• 각 제품이 요구하는 기능적 및 비기능적 요구 사항을 설계에 반영.

2.3 어플리케이션 실현 (Application Realization)

어플리케이션 실행(Application Realization) 단계는 소프트웨어 제품 라인(SPL) 프로세스에서 개별 제품의 설계를 실제로 구현하는 과정입니다. 어플리케이션 요구공학(Application Requirements Engineering)과 어플리케이션 설계(Application Design) 단계에서 정의된 요구 사항과 설계를 바탕으로, 구체적인 소프트웨어 코드, 시스템 구성 요소, 실행 가능한 기능들을 구현합니다. 이 과정에서는 핵심 자산 저장소(Core Asset Repository)에 저장된 재사용 가능한 자산을 활용하여 효율적으로 제품을 구현하고, 개별 제품에 맞는 변동성도 처리합니다.

• Application Design에서 정의된 설계를 바탕으로 구체적인 제품 구현을 수행.
• 핵심 자산 저장소에서 재사용 가능한 자산을 활용하여 구현 효율성 극대화.
• 변동성 관리를 적용하여 각 제품의 요구 사항을 충족하는 맞춤형 소프트웨어 구현.
• 소프트웨어의 일관성, 품질 및 성능을 보장하는 구현 절차 수행.

2.4 어플리케이션 테스팅 (Application Testing)

어플리케이션 테스팅(Application Testing) 단계는 소프트웨어 제품 라인(SPL) 프로세스에서 개별 제품이 구현된 이후, 이를 검증하고 평가하는 중요한 단계입니다. 이 단계에서는 어플리케이션 실현(Application Realization) 단계에서 구현된 소프트웨어가 요구 사항에 맞게 올바르게 동작하는지, 기능적 및 비기능적 요구 사항을 충족하는지 검증합니다. 또한, 핵심 자산 저장소(Core Asset Repository)에서 재사용된 자산들이 각 제품에서 일관되게 동작하는지 확인하고, 변동성 관리가 제대로 이루어졌는지 테스트합니다.

• 제품이 기능적 요구 사항을 충족하는지 확인.
• 비기능적 요구 사항(성능, 안정성, 보안성 등)을 테스트하여 품질 보장.
• 변동성 관리가 제품에서 올바르게 적용되었는지 확인.
• 핵심 자산 저장소에서 재사용된 자산이 예상대로 동작하는지 검증.
• 최종 제품이 릴리스될 준비가 되었는지 확인하고, 잠재적인 오류를 수정.

 

소프트웨어 제품 라인의 이점

1. 생산성 향상

• 대규모 생산성 향상: 재사용 가능한 자산을 통해 개발 시간을 단축하고 비용을 절감할 수 있다.
• 더 빠른 시장 출시 시간: 이미 검증된 자산을 사용하므로 개발 주기를 단축할 수 있다.

2. 품질 향상

• 높은 품질의 제품: 재사용 가능한 자산은 여러 제품에서 검증되었으므로 품질이 높다고 간주 할 수 있다.
• 결함 감소: 재사용을 통해 코드 결함이 줄어든다.

3. 비용 절감

• 개발 비용 절감: 공통 자산을 여러 제품에 재사용함으로써 개발 비용을 줄일 수 있다.
• 유지보수 비용 절감: 공통 자산을 사용하면 유지보수 비용도 절감된다.

4. 시장 대응력 증대

• 시장 민첩성: 새로운 요구 사항에 빠르게 대응할 수 있다.
• 대규모 맞춤화 가능: 고객의 요구에 맞게 제품을 맞춤화할 수 있다.

 

 

소프트웨어 제품 라인 수행 시 고려사항

소프트웨어 제품 라인 기술은 제품 라인을 성공적으로 구현하기 위한 모든 활동을 대상으로 한다. 이를 위해 고려할 수 있는 관점(Perspective)는 다음과 같다.

• 소프트웨어 공학
• 소프트웨어 제품 라인 기술 관리
• 소프트웨어 제품 라인 운영을 위한 조직 관리

1. 소프트웨어 공학 관점

(1) 요구 사항 엔지니어링(Requirements Engineering)

• 목표: 시스템의 기능, 행동, 성능, 품질 및 제약 사항을 명확하게 정의.
• 활동: 요구 사항 수집, 분석, 명세, 검증 및 관리.
• 특징: 제품 라인 요구 사항은 공통 요구 사항과 제품별 요구 사항으로 나뉨. 공통 요구 사항은 변동 포인트를 포함하며, 제품별 요구 사항은 공통 요구 사항에 대한 델타로 관리.

(2) 아키텍처 정의(Architecture Definition)

• 목표: 시스템의 구조를 정의하고, 품질 속성(성능, 보안 등)을 충족하는지 확인.
• 활동: 아키텍처 설계, 문서화, 평가, 변동 메커니즘 정의.
• 특징: 제품 라인 아키텍처는 모든 제품에 적용되고, 공통성과 변동성을 포함해야 함. 변동 메커니즘으로 구성 요소 교체, 매개변수화, 상속 등을 사용할 수 있음.

(3) 구성 요소 개발(Component Development)

• 목표: 아키텍처에서 정의된 구성 요소를 개발.
• 활동: 구성 요소 설계, 구현, 테스트, 문서화. 특징: 구성 요소는 공통 자산에 포함되거나 특정 제품에 맞춰 개발됨.
• 공통 구성 요소는 변동 포인트를 지원해야 함.

(4) 도메인 이해(Understanding Relevant Domains)

• 목표: 제품 라인이 속한 도메인의 지식을 체계적으로 이해.
• 활동: 도메인 분석, 문제 식별, 솔루션 정의.
• 특징: 도메인 지식은 제품 라인의 범위 정의, 공통성과 변동성 식별에 사용됨.

2. 소프트웨어 제품라인 기술 관리 관점

(1) 구성 관리(Configuration Management)

• 목표: 제품 및 구성 요소의 버전, 변경 사항을 관리.
• 활동: 버전 관리, 변경 관리, 빌드 관리.
• 특징: 여러 제품의 버전을 체계적으로 관리하여 일관성과 추적성을 보장.

(2) 측정 및 추적(Measurement and Tracking)

• 목표: 프로젝트 진행 상황을 추적하고 성과를 측정.
• 활동: 메트릭 정의, 데이터 수집, 분석 및 보고.
• 특징: 제품 라인 성과를 정량적으로 평가하고 개선점을 도출.

(3) 기술 계획(Technical Planning)

• 목표: 기술 전략 및 로드맵을 수립.
• 활동: 목표 설정, 자원 계획, 일정 관리.
• 특징: 장기적 기술 목표와 제품 라인 전략을 연계.

(4) 리스크 관리(Technical Risk Management)

• 목표: 기술적 리스크를 식별하고 관리.
• 활동: 리스크 평가, 완화 계획 수립, 모니터링.
• 특징: 제품 라인에서 발생할 수 있는 리스크를 사전에 예방하고 관리.

3. 소프트웨어 제품라인 운영을 위한 조직 관리 관점

(1) 사업 사례 구축(Building a Business Case)

• 목표: 제품 라인 접근 방식의 경제적 타당성을 입증.
• 활동: 비용-편익 분석, ROI 계산, 사업 사례 문서화.
• 특징: 제품 라인의 장기적 이점을 경제적으로 설명.

(2) 시장 분석(Market Analysis)

• 목표: 제품 라인의 목표 시장을 분석하고 기회를 식별.
• 활동: 시장 조사, 경쟁 분석, 고객 요구 사항 파악.
• 특징: 제품 라인의 전략적 방향을 시장 요구에 맞추어 설정.

(3) 조직 계획(Organizational Planning)

• 목표: 제품 라인 접근 방식을 지원하는 조직 구조와 프로세스를 설계.
• 활동: 조직 구조 설계, 역할 및 책임 정의, 자원 배분.
• 특징: 효과적인 조직 관리로 제품 라인 활동을 지원.

(4) 교육(Training)

• 목표: 직원들에게 제품 라인 접근 방식에 대한 교육 제공.
• 활동: 교육 프로그램 개발, 교육 자료 제공, 교육 세션 실행.
• 특징: 직원들이 제품 라인 개념과 실습을 이해하고 적용할 수 있도록 지원.

 

소프트웨어 제품 라인 적용 사례

1. CelsiusTech: Ship System 2000

• 개요: 55개의 선박 시스템 패밀리 개발
• 주요 성과:
  • 개발자 수가 210명에서 약 30명으로 감소
  • 필드 시간(제품 출시 시간)이 약 9년에서 3년으로 단축
  • 100만~150만 라인의 소스 코드를 통합 테스트하는 데 1-2명의 인력만 필요
  • 새로운 플랫폼/운영 체제로의 재배치가 3개월로 단축
  • 비용과 일정 목표를 예측 가능
  • 고객 만족도가 높습니다.

2. Cummins, Inc.: Diesel Engine Control Systems

• 개요: 20개 이상의 제품 그룹과 1,000개 이상의 엔진 애플리케이션을 보유
• 주요 성과:
  • 제품 개발 주기가 몇 개월로 단축
  • 빌드 및 통합 시간이 1년에서 1주일로 감소
  • 품질 목표 초과 달성
  • 고객 만족도가 높음
  • 제품 일정 준수
  • 제품 라인 접근 방식 덕분에 Cummins는 산업용 디젤 엔진 시장에 빠르게 진입하고 지배할 수 있었음 

3. National Reconnaissance Office/Raytheon: Control Channel Toolkit

• 개요: 이 프로젝트는 지상 기반 우주선 명령 및 제어 시스템을 개발.
• 주요 성과:
  • 첫 번째 시스템은 보통보다 결함이 10배 감소
  • 변경 부분에 대한 빌드 시간은 몇 달에서 몇 주로 단축
  • 시스템 개발 시간과 비용이 50% 감소
  • 제품 리스크가 감소했습니다.

4. Market Maker GMBH: Merger

• 개요: 인터넷 기반 주식 시장 소프트웨어를 개발
• 주요 성과:
  • 각 제품은 고유하게 구성
  • 맞춤형 시스템을 설정하는 데 단 3일 소요

5. Nokia Mobile Phones

• 개요: 노키아는 연간 25-30개의 신제품을 출시하며, 초기에는 연간 5개였음
• 주요 성과:
  • 각 제품마다 다양한 기능과 크기를 지원.
  • 58개 언어를 지원.
  • 130개 국가에서 서비스를 제공
  • 여러 프로토콜을 지원함
  • 제품 출시 후에도 기능을 구성할 수 있음
  • 제품 라인 접근 방식 덕분에 노키아는 다양한 요구를 충족시키고 빠르게 신제품을 출시할 수 있다.