A SPICE (심화)

 

 

 

 

 

이번 A-SPICE소개에서는 저번 시선과는 다르게 접근해보도록 하겠습니다.

 

 

 

A-SPICE 소개

 

 

 

ASPICE의 배경을 이해하기에 앞서서 지금은 사라진 HIS그룹에 대해 이야기 해보려고 합니다.

HIS는 지금 보시는 것처럼 독일어의 약어입니다, 독일 자동차 OEM의 모임 정도라고 생각하시면 됩니다.

HIS에는 아우디, BMW, 다임러 크라이슬러, 포르쉐, 폭스바겐같이 쟁쟁한 OEM들이 참여하고 있었습니다.

HIS그룹은 전반적인 자동차의 품질을 높이기 위한 고민으로 표준 소프트웨어 모듈, 프로세스의 성숙도 레벨, 소프트웨어 테스트, 소프트웨어 도구 등에 대해서 OEM의 활동 방향을 맞추고 통합하기 위해 만들어진 모임입니다.

 

현재, HIS라는 이름은 공식적으로 사라졌지만, 이러한 활동이 사라진 것이 아니라, 더 큰 협의체로 이관이 된 것입니다.

 

 

 

 

 

 

 

 

 

 

HIS의 고민

 

 

 

 

HIS 멤버들의 고민은, 자동차의 개발, 생산성을 어떻게 향상시킬 것인가, 이것에 대한 답으로, 차량을 구성하는 수많은 서브시스템들을 아웃소싱 하자, 그리고 한 사업장이 아닌 여러 사업장, 여러 국가에서 분산 개발을 하는 방법이나, 일부 모듈이나 라이브러리들은 COTS로 구매하는 방식같은 솔루션들을 찾았습니다.

 

여기서 COTS란 완성품으로 일반 대중에게 판매, 대여 또는 권한을 부여할 수 있는 컴퓨터 소프트웨어나 하드웨어, 기술 또는 컴퓨터 제품 등을 의미합니다.

 

자동차를 개발할 때 OEM만 잘 한다고 해서 되는 것은 아니라는 이야기입니다.

즉 여러 사이트, 여러 회사에서 만든 제품들이 통합되어야 하기 때문에 어떤 기준에 따라 적합하다는 것. 즉 컴플라이언스 하다는 것을 확인할 필요가 생긴 것입니다.

 

그래야만 서브 시스템을 통합할 수 있고, 플랫폼 레거시도 활용할 수 있고 프로덕트 라인으로 접근해서 생산성도 올릴 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

그래서 논의가 되고 정의가 되고 적용을 시도해본 것들이 A-SPICE, CMMI, ISO 26262, AUTOSAR와 같은 것들입니다.

 

쉽게 생각하면 “자동차라는 건물 안에, 문제가 있는, 또는 문제를 일으킬 소지가 있어 보이는 불량 세입자를 들이고 싶지 않아서 정의가 된 것이다” 라고 보시면 될 것 같습니다.

 

앞서 설명드렸듯이, HIS그룹 이라는 명칭은 2015년에 공식적으로 없어졌습니다. 그 이유는, 이제는 자동차 품질에 대한 고민을 몇 OEM들이 모여서 이야기 할 것이 아니라 좀 더 큰 테이블, 즉 더 많은 조직이 모여서 논의를 해야겠다는 취지인 것으로 이해할 수 있습니다.

 

현재는 VDA주관으로 이관이 되어서 Working Group이 만들어졌습니다.

 

 

 

 

 

 

 

 

 

Document history

 

 

A-SPICE 의 개정 이력을 보면 2005년에 최초 드래프트 버전이 나왔고 같은 해에 공식적인 배포도 되었습니다. 그 이후 2010년까지는 AutoSIG, SIG 라고 하면 스페셜 인터레스트 그룹의 약자 이구요. 이게 HIS라고 보시면 됩니다.

 

2010년까지는 HIS 그룹 주관으로 해서 A-SPICE가 관리 되었고,

2015년부터는 VDA QMC 주관의 Working Group 13이 A-SPICE를 관리하고 있습니다.

그리고 2015년부터는 A-SPICE의 버전도 2.5버전에서 3.0버전으로 바뀐 것을 보실 수 있습니다.

 

그동안의 과정을 보면 2005년에는 OEM이 협력업체에게 “A-SPICE의 적용을 고려하라” 라는 요청을 시작했고,

2007년부터는 일부 OEM이 실제로 일부 협력업체를 대상으로 A-SPICE 심사를 시작했습니다.

2015년부터는 국내협력업체에게도 A-SPICE를 요구하는 빈도가 확연히 증가한것으로 보여집니다.

 

그리고 현재는 3.1버전이 널리 활용되고있습니다.

 

 

 

 

 

 

 

 

Automotive Software Process Improvement Capability dEtermination

 

 

그렇다면 A-SPICE는 국제 표준일까요?

A-SPICE라는 이름에서도 알 수 있듯이 ISO 라는이름이 붙어있지 않습니다. 즉 국제 표준은 아닙니다.

 

그러나 자동차 업계의 대표주자들, 큰 형님 이라고도 부를 수 있는 쟁쟁한 OEM들이 ISO를 기반으로 A-SPICE를 정의했고, 이에 대해서 합의하고, 꾸준히 활용하고 있기 때문에 산업계에 널리 통용되는 표준이라고 봐야합니다.

 

A-SPICE의 풀네임은 Automotive Software Process Improvement Capability dEtermination, 즉 자동차의 소프트웨어 프로세스 개선을 하기 위한 역량을 결정하고 평가하기 위한 모델입니다.

그런데 자동차의 품질을 이야기할 때 소프트웨어만 놓고 이야기할 순 없기 때문에 소프트웨어에 기반한 시스템 영역까지 포함하고 있습니다.

그래서 소프트웨어 대신에 시스템이라고 바뀌어서 불리는 경우도 있기는 하지만 공식적인 풀네임은 소프트웨어라고 기억하시면 됩니다.

 

 

정리하면 A-SPICE는 유럽의 주요 OEM, HIS 멤버들이 ECU 개발 부품 업체의 프로세스 역량을 평가하기 위한 목적으로 2005년에 최초 정의되었고 2015년에는 VDA로 이관이 되면서 ISO 330 시리즈를 기반으로 3.0이 배포되었습니다.

또한 유럽 OEM중심으로 활용되는 산업계의 통용 표준이고, 요 근래에는 비 유럽권의 OEM들도 A-SPICE를 많이 요구하고 있습니다. 3.0이 배포된 이후에 과거 오랜 시간동안 유지되었던 버전 2에서 3으로 넘어가기 위한 시간이 필요했고 이렇게 이관 기준이 정의되어 있었습니다.

 

현재는 Period3 시기이기 때문에 지금 시점에서는 공식적인 2버전때의 심사는 유효기간이 끝났고 3버전대의 심사만 가능합니다. 하지만 OEM이 2.5의 버전을 요구하는 경우도 가끔 있다고 합니다.

 

 

 

 

 

Process Assessment Model

 

 

 

 

A-SPICE문서를 보면 지금 보시는 이러한 그림을 볼 수 있는데요 이 그림은 A-SPICE가 의도한 바를 표현한 그림입니다.

 

제일 위에 있는 프로세스 평가 모델을 통해서 “무엇을 해야 할지를 정의하고, 그 다음에는 기법 도구 템플릿 등을 통해서 어떻게 수행할지 정의하고, 프로젝트에 맞춰서 조정하고 실제 수행을 해라” 라고 이야기하고 있습니다.

 

이중에서 A-SPICE가 정의하고 있는 것은 제일 위에 있는 PAM, Process Assessment Model 입니다.

즉 어떤 프로세스를 왜 수행해야 하는지 그리고 무슨 활동을 해야 하고 그들 간의 관계는 어떠한 지를 정의하고 있는 것이고, 이를 기반으로 해서 각 회사, 팀, 프로젝트는 이것을 어떻게 달성할 것인지를 기법, 도구, 템플릿, 지표, 업무 흐름과 권한 및 역량 등을 토대로해서 어떻게 할 것 인지를 정의하고, 실제 프로젝트에 맞춰서 조정하고 구축하고 수행해라 라는 의도입니다.

 

그리고 “실제 수행을 하면서 필요한 활동들은 계속해서 보완을 해 나가라” 라고 기대하고 있습니다.

 

 

 

 

 

 

 

 

A-SPICE의 프로세스 영역

 

 

 

 

 

프로세스 카테고리

 

 

 

 

 

A-SPICE내의 프로세스는 3개의 범주 카테고리로 구분되어 있습니다.

 

첫번째는 Primary Life Cycle Process이고, 두번째는 Organizational Life Cycle Process, 세번째는 Supporting Life Cycle Process입니다. 그리고 각 프로세스의 범주는 하나 이상의 프로세스 그룹으로 구성이 됩니다.

 

 

첫번째 범주부터 설명을 드리겠습니다.

Primary Life Cycle Process 그룹은 시스템 개발에 필수적인 프로세스 그룹입니다.

우리 팀이 제품을 개발하기 위해서 필요한 시스템 소프트웨어 개발 프로세스도 포함됩니다.

모든 전체 시스템 중 일부는 협력업체를 통해서 개발하거나 구매할 수도 있습니다.

이러한 경우 외부 협력업체와 협업을 하고 조달 및 공급하기위한 프로세스들이 포함이 됩니다.

비유하자면 사람이 살아가는데 필요한 기초적인 의식주에 해당이 된다고 이야기할 수 있을 것 같습니다.

 

 

두번째 범주인 Organizational Life Cycle입니다.

Primary그룹이 수행되기 위해서는 한 명, 한 팀이 할 수 있는 것이 아니라 여러 팀 그룹 조직 회사들이 협업을 하게 될 것입니다.

이러한 다수의 조직을 관통해서 수행해야하는 프로세스 묶음이 해당됩니다.

그래서 목표에 대해서 전략을 세우고 관리하기위한 프로세스, 그리고 그러한 프로세스들을 적용하고 개선하기위한 프로세스, 그리고 회사에 표준 부품을 자산으로 구성을 하고 이것을 재사용하기위한 프로세스들이 포함이 됩니다.

비유하자면 의식주가 충족된 뒤에 더 만족스럽고 안정적인 생활을 유지하고 누리기 위해서 자신의 Life Cycle을 찾아가고 주변 환경에 투자를 한다거나, 항상 이용할 수 있는 단골가게를 찾아놓는 등의 활동들에 비유할 수 있을 것 같습니다.

 

 

마지막 범주는 Supporting Life Cycle입니다.

위의 두 그룹이 원활하게 수행될 수 있도록 도와주는 프로세스 그룹입니다.

제품개발을 하기위해서 지켜야 할 약속, 법칙등을 관리하는 지원적인 프로세스가 포함됩니다.

이것도 비유를 해보자면, 만족스럽고 안정적인 의식주 체계가 갖추어진 환경에서 살아가면서 마주할 수 있는 다양한 변수들이 있을텐데 그러한 것들을 대처할 수 있도록 자신만의 전략과 방법을 찾아가는 것들에 해당된다고 볼 수 있습니다.

예를 들어서 단골가게 사장이 바뀐다거나, 주변사람이 이사를 간다거나, 내가 이사를 가야한다거나, 이러한 변수들이 생겼을 때 어떻게 대응할것인지 미리 대비하고 그것에 따라 활동하는 것들이 해당된다고 볼 수 있습니다.

A-SPICE의 각 프로세스 영역은 이러한 프로세스 그룹 내의 어딘가에 속합니다.

 

 

 

 

 

 

 

Automotive SPICE PAM and VDA Scope (based on PAM 3.1)

 

 

 

전체 프로세스를 나열하면 이러한 그림으로 표현할 수 있습니다.

큰 박스들이 프로세스 범주 안에 속하는 프로세스 그룹이고, 안에있는 작은 회색박스가 각각의 프로세스들입니다.

총 32개의 프로세스 영역인데, 하지만 이렇게 많은것들을 다 해야하는 것은 아닙니다.

A-SPICE는 OEM이 협력업체의 프로세스 역량을 판단하기 위해서 만들어졌다고 말씀을 드렸었는데, 그렇다면 OEM입장에서는 협역업체가 이 프로세스를 잘 따르고 있는지 봐야할 것입니다.

즉 이 많은것들을 요구한다고 하더라도 확인을 다 하는 것은 굉장히 비효율적일 수 있다는 것입니다.

그래서 중요한 것 중에 더 중요한 것을 골라야한다고 생각을 했고, 필수적으로 준수해야하는 것들이 무엇일까 그리고 어떤것들을 봐야 그 회사 또는 그 프로젝트의 특성과 특징을 적절하게 판단할 수 있을까 라는 고민으로 정의된 것이 바로 VDA SCOPE입니다.

 

VDA SCOPE에 포함되는 프로세스는 위 사진에서 붉은색 테투리가 쳐져있는 16개의 항목들입니다.

 

 

 

 

 

 

VDA Scope

 

 

이러한 것들만 발췌를 하면 이렇게 비교적 간단한 그림으로 표현할 수 있습니다.

 

위에있는 영역은 시스템 레벨이고, ->아래있는 영역은 소프트웨어 레벨이고, 이 중간을 관통하고있는 6개는 관리지원 영역들입니다.

 

그러면 지금부터 VDA-SCOPE에 포함된 16개 프로세스들이 어떠한 것들인지 설명해드리도록 하겠습니다.

 

 

 

 

 

 

첫번째 시스템 2번, 시스템 요구사항 분석입니다.

고객요구사항을 기반으로 시스템요구사항을 분석하고 명세하는 프로세스입니다.

 

시스템3번은 시스템 아키텍처 설계입니다.

시스템 요구사항을 구현하기 위해서 시스템에 엘리먼트를 정의하고 아키텍처를 구성하는 프로세스 요건을 담고 있습니다.

 

그 다음, 소프트웨어 레벨로 내려와서, 소프트웨어 1번은, 소프트웨어 요구사항 분석입니다.

시스템 분석설계 과정중에 “소프트웨어가 구현해야한다” 라고 할당된 항목들이 있습니다.

그러한 항목들을 실제로 소프트웨어로 구현하기 위해서 소프트웨어 입장에서 어떠한 동작을 수행해야 하는지 정의하기 위한 프로세스를 담고 있습니다.

 

그 다음 소프트웨어 2번은, 소프트웨어 아키텍처 설계입니다. 요구사항을 구현하기 위해서 소프트웨어 엘리먼트들을 정의하고, 이들 간의 인터페이스와 동적설계를 정의하는 요건을 담고 있습니다.

 

그 다음 소프트웨어 3번은, 소프트웨어 상세 설계 및 UNIT 구현입니다. 소프트웨어 아키텍처에 정의된 가장 작은 단위가 컴포넌트입니다. 즉 엘리먼트들의 작은 단위가 컴포넌트라고 A-SPICE는 정의하고 있습니다. 소프트웨어 3번에서는 각 컴포넌트에 대한 상세 설계를 수행하면서 유닛들을 정의하고, 그 유닛을 실제 소스코드로 구현하기 위한 프로세스를 정의하고 있습니다. 오른쪽 영역에 있는 것들을 모두 검증과 관련된 프로세스들이고, 기본적으로 좌측에 있는 분석설계 프로세스 대비 각각 검증하는 프로세스라고 생각하시면 됩니다.

 

첫번째, 소프트웨어 4번은 유닛 검증이고, 소프트웨어 유닛이 상세 설계 및 비기능 요구사항을 충족하는지 검증하기 위한 프로세스를 정의하고 있습니다.

 

소프트웨어 5번은 소프트웨어 통합 및 통합시험입니다. 소프트웨어 유닛이 최종적으로 통합된 소프트웨어가 될 때까지 단계별로 전략에 따라 통합을 해가면서 소프트웨어 아키텍처 및 유닛 간의 인터페이스를 충족하는지 검증하기위한 프로세스입니다.

 

소프트웨어 6번은 Qualification test입니다. 완전히 통합된 소프트웨어가 반대측면에 있는 소프트웨어 요구사항을 충족하는지 검증하기위한 프로세스입니다.

 

다시 시스템레벨로 올라가서 시스템 4번은 시스템 통합 및 통합시험입니다. 시스템 엘리먼트들을 통합해가면서 시스템 아키텍처 및 엘리먼트 간의 인터페이스를 충족하는지 검증하기위한 프로세스이구요. 우리가 하드웨어, 소프트웨어 인터페이스 테스트라고 부르는 것이 시스템 통합시험에 포함됩니다.

 

마지막으로 시스템 5번은 시스템 Qualification test입니다. 완전히 통합된 시스템이 반대측면에 있는 시스템 요구사항을 충족하는지 검증하기위한 프로세스입니다. 지금까지 말씀드린 10개의 프로세스는 개발관련 프로세스이고, 지금부터는 나머지 6가지인 관리지원 프로세스에 대해 설명드리겠습니다.

 

MAN 3번은 프로젝트 관리입니다. 프로젝트 요구사항 및 제약사항의 범주 내에서 실제 프로젝트를 개발할 때 필요한 활동, 리소스 등을 식별하고 관리하기 위한 프로세스입니다. 그리고 모든 영역을 다 내부적으로 개발하지 못할 수도 있기 때문에 정의된 것이 Acquisition, 4번인 협력업체 관리입니다.

 

협력업체와 합의된 요구사항 대비 협력업체가 실제로 수행하는게 적절하고 적합한지를 추적관리하고 평가하기 위한 프로세스를 포함하고 있습니다.

 

Supporting 1번은 품질보증입니다. 개발 산출물 및 수행된 프로세스가 실제 정의된 기준과 계획 대비 적합한지 독립적이고 객관적인 보증을 하기위한 프로세스를 정의하고 있습니다.

 

Supporting 8번은 Configuration management, 즉 형상관리 입니다. 프로젝트의 모든 개발 산출물이 무결하게 관리될 수 있도록 하고, 프로젝트의 이해관계자들이 시의 적절하게 필요한 산출물들을 이용할 수 있도록 하기위한 프로세스를 정의하고 있습니다.

 

Supporting 9번은 Problem resolution management, 즉 문제해결 관리입니다. 문제를 식별하고 분석하며 해결이 될 때까지 관리하고 통제하기위한 프로세스를 포함하고 있습니다.

 

Supporting 10번은 Change request management, 즉 변경요청 관리입니다. 변경요청사항을 식별하고 분석하고 해결이 될 때까지 관리하고 통제하기 위한 프로세스를 담고 있습니다.

 

 

 

 

 

 

 

 

지금까지 설명드린 VDA SCOPE에 해당하는 16개의 프로세스들은 기본적이고 필수적인 영역입니다.

 

즉 “A-SPICE를 준수해야 한다” 라고 할 때 기본적으로 포함되는 영역입니다.

 

그런데 만약 어떤 프로젝트가 소프트웨어 개발만 포함한다면, 협력업체가 없다면, 또는 일부 테스트 영역은 OEM이 수행을 한다면, 그렇다고 하더라도 우리는 VDA SCOPE를 모두 적용해야 하는 것일까요?

 

 

정답은 그렇지는 않습니다.

 

OEM과 합의해서 실제 그 프로젝트의 개발 범위에 맞게, 적용할 프로세스의 범위를 조정할 수 있습니다.

따라서 가장 중요한 것은 “ A-SPICE의 프로세스 구조와 그 중 VDA SCOPE에 해당하는 각 프로세스에 대해 이해하고 고객과 프로젝트에 실제 적용할 프로세스 영역을 올바르게 협의하고 합의하는게 무엇보다 중요하다” 라고 말씀드릴 수 있습니다.