소프트웨어 제품 라인(SW Product Line)에서 PL Scoping은 소프트웨어 제품 라인의 전략적 성공을 위한 핵심 과정입니다. PL Scoping은 크게 포트폴리오 스코핑, 도메인 스코핑, 자산 스코핑으로 나뉘며, 각각의 단계는 제품 라인에서 개발할 제품, 기능, 자산 등을 명확하게 정의하고 관리하는 데 중점을 둡니다. 각 스코핑 단계는 상호 연관되며, 전체 소프트웨어 제품 라인의 구조와 계획을 체계적으로 설정하는 역할을 합니다.
범위 설정 (PL Scoping)의 주요 단계는 다음 그림과 같습니다.
전체적인 SPL 프로세스는 별도로 정리해 두었습니다. 참고 부탁해요.
아래에서는 PL Scoping의 각 단계에 대해 상세히 설명하겠습니다.
1. 포트폴리오 스코핑 (Portfolio Scoping)
포트폴리오 스코핑은 소프트웨어 제품 라인에서 개발할 제품들을 정의하는 과정입니다. 제품군 내에서 어떤 제품이 포함될지 결정하고, 각 제품의 주요 특징과 변동성 요소를 분석합니다. 이 단계는 제품 라인의 초기 전략을 수립하고, 각 제품의 역할을 명확히 하는 매우 중요한 과정입니다.
다음은 포트폴리오 스코핑 단계의 최종 결과물이라 할 수 있는 제품 포트폴리오 범위 정의 결과에 대한 예입니다. 제품의 각 피처들이 있고, 제품군에 따라 피처를 할당하여 공통/변동부를 결정하기 위한 기반이 될 수 있습니다.
1.1 멤버 제품 정의(Defining Member Products)
멤버 제품이란 소프트웨어 제품 라인에 포함될 제품들을 의미합니다. 예를 들어 자동차를 개발하고자 할 때 OEM에서 개발하는 SUV, Sedan, Truck, Bus와 같은 차량 유형별로 제품 라인을 정의하고, 각 제품 라인에 속하는 상세 차종들이 멤버 제품에 해당합니다.
따라서 멤버 제품 정의 단계에서는 소프트웨어 제품 라인에 포함된 모든 제품들을 정의하는 것을 목표로, 제품 라인의 주요 제품을 식별하고, 각각의 제품이 어떤 시장이나 고객 그룹을 목표로 하는지 명확히 정의합니다. 또한 제품 간의 공통된 목표를 설정하고, 각 제품이 제공할 주요 기능을 파악합니다.
멤버 제품 정의 단계의 결과물은 멤버 제품 리스트, 제품 요구 사항 명세서가 있습니다.
1.2 주요 피처 정의(Defining Major Features)
이 단계에서는 각 제품의 주요 피처를 정의하고, 제품 간에 어떤 기능이 공통으로 사용되는지와 어떤 기능이 제품마다 달라지는지 파악합니다. 이를 위해 제품군에서 제공해야 할 필수 기능과 옵션 기능을 구분하고, 이를 통해 각 제품의 기능적 요구 사항을 명확하게 정의합니다.
주요 피처 정의는 공통적인 기능(공통성)과 변동적인 기능(변동성)을 도출하는 것이 핵심입니다. 자동차 산업에서 예를 들면, 각 차종에 공통적으로 사용되는 전자 제어기, 센서, 스위치류를 정의하고, 제품간 변동성을 식별합니다. 따라서 공통피처로는 전자 제어기, 기본센서(온도센서, 속도센서 등)이 있으며, 변동피처로는 특정 모델에만 들어가는 특정 시스템 등을 변동피처라 할 수 있습니다.
주요 피처 정의 단계의 결과물은 주요 피처 리스트, 공통성 및 변동성 분석 문서가 있습니다.
1.3 제품군 정의(Defining Product Families)
제품군 정의 단계에서는 여러 제품을 제품군(Product Families)으로 그룹화하여 관리할 수 있도록 설정합니다. 예를 들어, 중형 차량과 소형 차량이 포함된 세단 제품군을 만들고, 대형 차량이 포함된 SUV 제품군을 정의합니다.
따라서 제품 기능이나 시장 요구 사항에 따라 유사한 제품들을 그룹화하고, 각 제품군의 역할을 정의합니다. 제품군 내에서는 공통적인 요구 사항을 공유하고, 필요에 따라 변동성을 적용할 수 있도록 설계합니다.
주요 제품군 정의 단계의 결과물은 제품군 리스트, 제품군 정의 문서가 있습니다.
1.4 포트폴리오 범위 검증(Portfolio Scope Validation)
포트폴리오 범위 검증 단계에서는 정의된 제품군과 주요 피처의 범위를 검증하여, 제품 라인 전략에 맞게 구성되었는지 확인합니다.
이 단계에서는 제품 라인에 포함된 모든 제품과 제품군이 전략적으로 적합한지 검토하고, 각 제품의 범위가 명확하고 일관성 있게 설정되었는지 확인합니다. 이를 통해 제품군 간의 균형을 맞추고, 공통 자산의 최대 재사용을 보장합니다.
포트폴리오 범위 검증 단계의 결과물은 포트폴리오 검증 보고서, 피드백 문서가 있습니다.
2. 도메인 스코핑 (Domain Scoping)
도메인 스코핑은 소프트웨어 제품 라인에서 다룰 도메인과 서브 도메인을 정의하는 과정입니다. 도메인 스코핑은 각 제품군의 기능을 좀 더 구체적으로 그룹화하고, 이를 통해 공통성과 변동성을 체계적으로 관리할 수 있는 구조를 설계합니다. 이를 위해 제품 라인을 효과적으로 구축하고 제품 생산의 경제성을 확보하기에 충분한 재사용성을 제공할 수 있도록 주요 도메인/하위 도메인들을 식별하고 그들의 경계를 결정하는 것을 목표로 합니다.
다음 그림은 앞에서 정의한 포트폴리오 범위 결과를 기반으로 도메인 범위를 설정한 결과를 나타냅니다. 즉, 사용자 인터페이스와 도어락 제어와 같은 기능 영역을 설정한 후, 앞서 정의한 피처들을 그룹핑합니다.
2.1 도메인 및 서브 도메인 정의(Defining Domain and Sub-Domain)
도메인 및 서브 도메인 정의 단계에서는 소프트웨어 제품 라인에서 다루는 도메인을 정의하고, 이를 세부적으로 서브 도메인으로 분류합니다. 예를 들어 자동차 분야에서 전자 제어 시스템은 다양한 도메인으로 나누어질 수 있습니다. 엔진 관리 시스템, 브레이크 시스템 차체 제어 시스템 등의 도메인이 있을 수 있습니다. 따라서 각 도메인 내에서 사용되는 ECU, 센서, 스위치 등의 기능을 그룹핑하여 도메인별로 정의합니다.
이 단계에서는 제품 라인이 속한 산업 또는 시장 내에서 주요 도메인을 식별하고, 해당 도메인을 좀 더 세분화하여 서브 도메인으로 구분합니다. 이를 통해 도메인 내에서 공통성과 변동성을 보다 명확하게 관리할 수 있습니다.
도메인 및 서브 도메인 정의 단계의 결과물은 도메인 및 서브 도메인 리스트, 도메인 정의서 등이 있습니다.
2.2 피처 그룹핑 및 정제(Grouping and Refining Features)
앞서 식별한 주요 피처들을 도메인 내에서 그룹화하고, 기능적으로 연관된 피처들을 한 그룹으로 정제합니다. 예를 들어, 엔진 관리 도메인에서는 온도 센서, 압력 센서, 속도 제어 ECU 등의 그룹을 정리하고, 그 중에서 특정 차종에만 들어가는 기능을 구분합니다.
이 단계에서는 공통적인 기능과 변동성을 고려하여 피처를 그룹으로 묶고, 각 그룹이 어떻게 변동성을 관리할 수 있을지 정의합니다. 피처 그룹 간의 상호 연관성도 고려하여 설계합니다.
피처 그룹핑 및 정제 단계의 결과물은 피처 그룹 리스트, 피처 그룹 정의서 등이 있습니다.
2.3 도메인 범위 검증(Domain Scope Validation)
도메인 스코핑을 통해 정의된 도메인의 범위를 검증하고, 이를 통해 제품 라인 전략에 맞게 도메인이 구성되었는지 확인합니다.
이 단계에서는 도메인 및 서브 도메인이 공통성과 변동성을 적절히 반영하고 있는지 확인하며, 도메인 내 피처 그룹이 적절히 구성되었는지 검토합니다.
3. 자산 스코핑 (Asset Scoping)
자산 스코핑은 소프트웨어 제품 라인 내에서 재사용할 코어 자산과 변동성을 처리할 자산을 구분하고 정의하는 단계입니다. 자산 스코핑은 현재와 미래의 소프트웨어 제품 개발을 위한 비용을 예측하고, 자산의 재사용성과 변동성을 극대화할 수 있는 방법을 정의하는 데 초점을 둡니다.
자동차 시스템에서 기존에 사용 중인 ECU, 센서, 스위치 등의 자산을 평가하여 재사용 가능한지 판단하고, 새로운 자산이 필요한 경우 이를 추가로 개발해야 하는지 결정합니다. 예를 들어, 기존에 사용하던 브레이크 센서를 모든 차종에 재사용할 수 있지만, 자율 주행용 센서는 새로 개발해야 할 수 있습니다.
3.1 기존 자산과 신규 자산 분리(Separating Existing and New Assets)
소프트웨어 제품 라인 내에서 기존에 사용되고 있는 자산과 신규로 개발해야 할 자산을 구분합니다. 현재 사용 중인 자산을 평가하여 재사용 가능한 자산을 식별하고, 신규 자산을 정의합니다. 이를 통해 기존 자산의 재사용성을 높이고, 필요한 자산 개발을 계획할 수 있습니다.
예를 들어 현재 사용 중인 ECU, 센서, 스위치 등의 자산을 평가하고, 어떤 자산을 재사용할 수 있을지, 새로 개발해야 할 자산이 무엇인지 구분합니다.
결과물로는 자산 목록(기존 자산 및 신규 자산), 자산 분리 보고서 등이 있습니다.
3.2 자산 개발 비용 추산(Estimating Asset Development Costs)
현재 제품의 자산 개발 비용과 미래 제품을 위한 자산 개발 비용을 추산합니다. 기존 자산을 재사용함으로써 절감할 수 있는 비용과, 신규 자산을 개발하기 위한 예상 비용을 추정합니다. 이를 통해 제품 라인 전체의 자산 개발 효율성을 높이고, 장기적인 자산 관리 전략을 수립할 수 있습니다.
예를 들어 기존 자산을 재사용함으로써 절감할 수 있는 비용과, 신규 자산 개발을 위한 비용을 추정합니다. 이를 통해 제품 라인의 전체 자산 개발 비용을 관리하고 최적화합니다.
3.3 자산 범위 정의(Defining Asset Scope)
자산의 범위를 명확히 정의하여, 제품 라인 내에서 각 자산이 어디에서 재사용될 수 있을지, 그리고 각 자산의 변동성이 어떻게 관리될지를 결정합니다. 자산별로 재사용할 수 있는 범위를 정의하고, 각 자산이 어떤 제품에 적용될지, 또는 어떤 변동성을 처리할 수 있을지 명확히 결정합니다. 이를 통해 자산의 효율적인 재사용과 유지보수를 계획할 수 있습니다.
예를 들어 각 자산의 범위를 명확히 정의하고, 재사용할 수 있는 자산의 범위와 각 자산의 변동성을 설정합니다. 예를 들어, 엔진 제어 ECU는 모든 차종에서 재사용되지만, 자동 주차용 센서는 특정 고급 차량에서만 사용될 수 있습니다.
'Software Engineering > SPL (SW Product Line)' 카테고리의 다른 글
SPL: 도메인 설계 (Domain Design) - 유연성 설계 (Design for Flexibility) (0) | 2024.10.26 |
---|---|
SPL: 도메인 설계 (Domain Design) - 가변성 설계 (Design for Variability) (2) | 2024.10.25 |
SPL: 가변성 모델링 (Variability Modeling) - 재사용성과 유연성 극대화 (1) | 2024.10.24 |
SPL: 도메인 요구공학 (Domain Requirements Engineering) (0) | 2024.10.24 |
소프트웨어 공학: Software Product Line (SPL) (2) | 2024.10.06 |