I. 배경
자동차 제어시스템의 소프트웨어를 개발할 때 개발 프로젝트 조직 내부에서 제어기능 전체를 자체 개발하는 경우도 있으나, 소프트웨어의 기능이 점점 커지고 복잡해짐에 따라 프로젝트 조직 내부에서 전체를 신규 개발하는 것 보다 외부에서 개발된 소프트웨어와 프로젝트 내부 조직에서 개발한 소프트웨어와 통합을 통해 고객에게 전달하는 경우도 점점 많아지고 있습니다.
소프트웨어 아키텍처를 설계할 때 특정 기능을 담당하는 SW아키텍처 컴포넌트에 대해서 외주 개발을 하거나, 자체 개발한 소프트웨어 재사용 등을 고려할 수 있습니다. (이는 프로젝트를 착수할 때, 혹은 소프트웨어 요구사항을 분석할 때 결정될 수 있습니다.)
본 기술 레터에서는 프로젝트 조직 외부에서 개발되는 몇 가지 경우에 대해 살펴보고 이러한 경우에 대해서 Automotive SPICE® 모델을 사용하는 경우, 어떻게 다뤄야 할지에 대해서 간단히 다뤄보고자 합니다.
여기서 외부란, 프로젝트 조직의 외부를 의미합니다. 따라서 같은 회사라 할지라도 프로젝트 조직 외부에 존재하고, 그 외부 조직의 기존 레거시 소프트웨어를 재사용의 경우도 외부 개발 소프트웨어로 가정하고 살펴보도록 하겠습니다.
2. 외부 개발 소프트웨어의 사례
외부에서 개발된 소프트웨어의 경우를 다음과 같이 생각해볼 수 있습니다.
프로젝트 조직 외부에서 이미 개발된 소프트웨어
이는 이전(혹은 타) 프로젝트에서 개발된 소프트웨어를 수정 없이 재사용하는 경우에 해당됩니다. 만일 이전 프로젝트에서 개발된 소프트웨어를 이번 프로젝트를 위해 수정이 가해지면 외부에서 개발된 소프트웨어로 간주하지 않고 내부 개발 소프트웨어로 간주해야 합니다.
계약에 의해 외부에서 개발한 소프트웨어
프로젝트 일부 소프트웨어를 계약을 통해 프로젝트 외부의 업체가 개발 및 검증을 하여 프로젝트 조직에 전달하는 소프트웨어의 경우에 해당됩니다.
COTS (Commercial Off-The-Shelf) 소프트웨어
COTS는 본 프로젝트를 위해서 개발된 소프트웨어가 아니며, 사전에 여러 프로젝트/업체를 위해 개발한 소프트웨어를 구매하여 사용하는 소프트웨어에 해당됩니다.
오픈 소스 소프트웨어
공개 소프트웨어라고도 하며 오픈소스 라이선스를 만족하는 소프트웨어를 말하며 공개된 소프트웨어를 특별한 제한 없이 사용할 수 있는 소프트웨어를 말합니다. 오픈 소스 소프트웨어는 보통 소스 코드만 제공되며 제공처로부터 지원을 받을 수 없는 경우가 대부분입니다. 또한 오픈 소스 라이선스는 고객에게 양도되어야 하므로 고객으로부터 오픈 소스 소프트웨어 사용에 대해 승인을 얻어야 합니다.
고객으로부터 받은 소프트웨어
자동차 OEM이 제공하는 소프트웨어로 프로젝트에 통합되어 고객에 최종 전달해야 하는 소프트웨어이며, 프로젝트 제약사항으로 식별됩니다.
3. 각 사례별 고려사항
위에 언급된 사례에 대해 공통적으로는 프로젝트 조직 내부에서 해당 소프트웨어 엘리먼트에 대해 상세 설계 프로세스(SWE.3)와 그에 대한 검증 활동 프로세스(SWE.4)는 수행하지 않을 수 있습니다.
프로젝트 조직은 외부에서 개발한 소프트웨어의 기능을 포함한 프로젝트 소프트웨어 요구사항을 개발(SWE.1)하여야 하며, 프로젝트 소프트웨어 아키텍처(SWE.2)에서 외부에서 개발한 소프트웨어에 대한 엘리먼트의 식별 및 엘리먼트에 대한 인터페이스를 식별하여야 합니다.
외부에서 개발한 소프트웨어에 대해서 통합 테스트를 통해 인터페이스가 소프트웨어 아키텍처를 준수하는지 검증(SWE.5)하여야 하고, 해당 외부 소프트웨어 기능을 포함한 통합된 소프트웨어가 프로젝트 소프트웨어 요구사항을 만족하는지 테스트(SWE.6)를 통해 확인해야 합니다.
외부에서 개발한 소프트웨어의 각 사례별 고려사항은 다음과 같습니다.
프로젝트 조직 외부에서 이미 개발된 소프트웨어
프로젝트 조직 외부에서 이미 개발된 소프트웨어를 수정없이 재사용하는 경우, 해당 소프트웨어를 프로젝트 요구사항의 일부(기능 및 비 기능 요구사항)로 정의되고, 전체 소프트웨어의 아키텍처 설계에 일관되게 반영되어야 합니다. 해당 소프트웨어에 대한 하위 설계 및 검증은 재사용하는 경우이므로 본 프로젝트에서 수행하지 않을 수 있습니다. 다만 재사용이기에 해당 소프트웨어에 대한 상세 설계 및 검증 결과는 확보해야 하며, 검증 결과에 대한 신뢰성은 확보되어야 합니다. 추가로, 프로젝트에서 개발하는 소프트웨어 변경이 발생하는 경우 재사용하는 소프트웨어 대한 변경 영향을 분석하여 적절한 조치를 취해야 합니다. 안전 관련 엘리먼트(컴포넌트)인 경우, 기능안전에서는 이러한 절차를 Software Component Qualification이라는 방법으로 검증을 요구합니다. (ISO26262-8:2018, 12절 참조)
계약에 의해 외부에서 개발한 소프트웨어
계약을 통해 프로젝트 외부 조직에게 일부 소프트웨어 기능에 대한 소프트웨어 개발을 의뢰한 경우이므로, ACQ.4 (Supplier Monitoring) 프로세스를 수행해야 합니다. 따라서 해당 소프트웨어에 대한 소프트웨어 요구사항을 식별하고 프로젝트에 개발하는 소프트웨어 아키텍처 설계에 외부 개발 소프트웨어를 식별하여야 한다.
ACQ.4 (Supplier monitoring)에서 프로세스 결과물은, 해당 소프트웨어 엘리먼트의 공급 업체와 개발 활동에 대해서 합의하고 합의된 정보가 서로 전달되며 공급 업체가 합의한대로 수행하는지 모니터링을 수행하는 것으로 되어 있습니다.
COTS 소프트웨어
COTS 소프트웨어를 위해 프로젝트에서는 요구사항을 식별하여야 하며, 식별된 소프트웨어 요구사항을 기반으로 COTS 소프트웨어를 선정해야 합니다. 선정할 때, 다음의 사항을 고려해볼 필요가 있습니다.
- COTS 소프트웨어의 운영 환경이 본 프로젝트에 적합 여부
- COST 소프트웨어에 대한 신뢰할 만한 기관으로부터의 검증 결과
- COST 소프트웨어에 대한 오류에 대한 처리
- 이는 프로젝트 조직에서 발견한 COTS 소프트웨어의 오류를 COTS 소프트웨어 공급사로의 전달하는 것뿐만 아니라, COTS 소프트웨어 공급사에서 확보한 오류에 대해서 프로젝트 조직에서는 어떻게 파악할 수 있는지에 대한 방안도 검토해야 합니다.
오픈소스 소프트웨어
오픈소스 소프트웨어를 사용하고자 할 때는 오픈 소스 소프트웨어 라이선스 및 저작권을 고려해야 합니다. 사용하고자 하는 오픈 소스에 대해 오픈소스 라이선스에 대해 검토하여 수용할 지 여부를 검토하여야 합니다. 예를 들어 오픈소스 라이선스 중 제일 많은 부분을 차지하는 GPL (GNU Public License)의 경우에는 오픈 소스에 대해 수정 및 추가한 부분은 공개하여야 합니다. 만일 공개하지 않은 경우에는 라이선스 위반으로 해당 저작권을 침해한 것으로 간주될 수 있습니다. 자동차 부품사에서 오픈소스를 이용하여 제어 소프트웨어를 개발 시, 이러한 라이선스에 해당 여부를 신중히 검토하여야 합니다.
고객으로부터 받은 소프트웨어
고객으로부터 받은 소프트웨어는 본 프로젝트의 제약사항으로 관리되어야 합니다. 상황에 따라서는 고객으로부터 받은 소프트웨어가 프로젝트 조직에서 구현하고자 하는 기능의 일부일 수 있고 별개의 기능일 수 있습니다. 별개의 기능일 경우에는 프로젝트 범위의 밖으로 다루지만, 해당 소프트웨어가 필요로 하는 자원은(CPU Resource, ROM, RAM 등) 프로젝트 리소스 제약사항으로 관리해야 합니다.
프로젝트의 일부의 기능을 담당하는 소프트웨어의 경우에는 사양을 분석하여 프로젝트의 사양의 요구사항 및 설계의 제약사항으로 관리하여야 합니다.
4. 맺는 말
현재 자동차 산업에서 소프트웨어의 비중이 점점 커짐에 따라 차량 제어 프로젝트에서 소프트웨어를 프로젝트 조직에서 온전히 수행하지 않고 외부 개발(기존 레거시 및 COTS, 오픈소스 등) 소프트웨어를 도입하는 경우가 점점 많아지고 있습니다. 이에 따라 프로젝트 조직 외부에서 개발하는 소프트웨어에 대해 사례별로 분석하여 조직에 필요한 적절한 경우를 선정하고, 그에 맞는 활동을 수행을 통해 자체 개발되는 소프트웨어와 일관된 품질 수준을 유지하고, 더 나은 품질의 소프트웨어를 배포하는 것이 필요합니다.
고객에게 좋은 품질의 소프트웨어를 배포하면 좋겠습니다.