[Automotive Electronics] 자동차에 적용되는 A-SPICE의 효과적인 준수 계획 봅시다

이 5월 311입니다 베디도우소류ー션의 전문 큰 기업 MDS테크놀로지가 개최한 '자동차 SW개발자 콘퍼런스 2017'에는 ISO/IEC 15504(SPICE)독 1의장인 베옹토우힝델(Bernd Hindel)박사가 기조 강연자로 초청되었습니다. 힌델 박사는 자동차 소프트웨어 개발 프로세스의 국제 그냥 Automotive SPICE(이하 A-SPICE) 인증기관인 iNTACS의 설립자로 SPICE의 국제 그냥 수립을 주도한 인물이었다.베옹토우힝델(Bernd Hindel)박사는 "자동차 SW개발자 1,000여명이 참가한 이번 콘퍼런스가 매우 인상적이었고, 한정 자동차 산업에서 A-SPICE엔지니어링 프로세스에 대한 관심을 느낄 수 있었다","MDS테크놀로지의 기술력을 기반으로 좋은 파트 당싱시프을 기대합니다."과 예기했다.차량 내 전자 제어 장치(ECU)에 탑재되는 소프트웨어의 품질 향상을 목적으로 유럽의 주요 완성 차 업체가 공동 개발한 A-SPICE의 초판이 발행되고 10년이 지난 2015년에 최신 버전 v3.0(A-SPICE 3.0)이 출시되었습니다. A-SPICE 3.0은 "대상 제품 개발 프로젝트의 품질 개선"에 주안점을 두고 있어 최근에는 자동차의 기능 안전성의 국제 무료(ISO 26262)이 요구하는 프로세스 인프라 구축을 목적으로 완성 차 업체들이 협력 업체에 A-SPICE준수를 요구하고 있다.힌 델 박사는 자동차 SW의 복잡성이 증가하고 안전과 보안 문제가 강조되면서 SW및 시스템 엔지니어링이 점점 중요할 것이라고 ISO 26262, A-SPICE등 개발 프로세스의 유기적 통합을 통해서 개발·생산성을 높이고 계셔야 한다고 강조했다. 그는 "자율 주행 혁명으로 향후 5년 이내에 자동차 산업의 기존 사업 체계가 무너지고 제조 업체보다 SW개발 업체들이 더 높은 이윤을 창출하는 시대가 올것"이라며"SW의 오류로 인한 의문의 발생, 해킹 등 안전과 보안 관련 이슈를 해결하는 것이 향후 과제"라고 지적했다. 향후 힌델 박사의 강연 이야기(주제: How to become Automotive SPICE compliant)를 정리해 소개합니다.CMMI에서 SPICE, 그리고 A-SPICE로 성숙도 모델(Maturity Models)의 목표는 제품의 품질을 향상시키는 것이었다.제품의 품질은 결국 개발 프로세스의 품질과 동등하다는 가설이 있습니다만, 이것은 개발 프로세스가 좋으면 좋은 품질의 제품을 만들 수 있다는 것을 의미할 것입니다. 고런 성숙도 모델은 능력 수준(Capability Level)에 의해서 정의되며 프로세스의 능력 수준은 수준 0에서 레벨 5까지 6단계로 구분된다. 자동차 산업으로는 그냥 레벨 3(Managed)만큼 적합 판정을 받는다.성숙도 모델은 관련 모델(Best Practice)과 각 레벨에 맞게 측정할 수 있는 측정 프레임입니다.워크(Measurement Framework)로 구성된다.초기 성숙도 모델로는 CMM(Capability Maturity Model)을 들 수 있다. CMM은 카네기멜론대 부설 조사개발센터인 소프트웨어공학조사소(Software Engineering Institute, SEI)가 미 국방부의 후원 아래 만든 그대로였다. 미국의 대기업뿐 아니라 독자적인 기업에서도 소프트웨어의 성숙도 모델이 필요했지만 라이선스 비용을 미 국방부에 지불하는 것을 원치 않았다. 결국 1980년대에 소프트웨어가 많이 필요했던 영국군 측에서 CMM이 아닌 새로운 모델을 찾아 나선다, 유럽 내에서 독자적인 프로젝트가 개시되었습니다. 당시 이 프로젝트를 부트스트랩(Bootstrap)이라고 불렀습니다.러시아 보쉬 알카텔 등이 이 프로젝트에 참여했다.부트스트랩은 조직의 소프트웨어 개발 및 관리 프로세스의 품질을 평가·향상시키는 방법으로, CMM의 방식과 매우 비슷하다. 영국군은 단지 부트스트랩 작업이 거의 끝나갈 무렵, 이 프로젝트에 근거한 ISO '다만'을 재정정하게 되었습니다. 즉 부트 스트랩이 ISO 15504 TR(기술 보고서)가 된 것이었다 SPICE로도 불리는 이 단지에서는 1995년도에 공식 발표됐지만 다음 시장에서는 CMMI와 SPICE가 대표적인 성숙도 모델로서 사용되었습니다.2000년도에 들어 자동차 업계에서는 소프트웨어의 중요성을 인식하게 되었습니다. OEM들은 대부분의 소프트웨어가 티아(Tier)1과 티아 2회사에서 사용되는 것을 인지하고 소프트웨어를 조립 라인에 제공할 때 검토하는 것만으로는 충분치 않다.협력업체의 전반적인 개발 프로세스를 검토하고 그 개발 프로세스가 좋으면 제품도 좋다고 판단하게 된 것이다.때문에 OEM들은 개발 프로세스 평가 수단으로서 CMMI과 ISO 15504중 어느 성숙도 모델을 사용해야 할지 결정해야 했다.그러나 CMMI는 지불해야 할 비용이 만만치 않았다. 라이선스 비용을 SEI 측에 지불해야만 했기 때문이었다. 결국 비용 우이뭉로 독 1의 주요 자동차 회사 가진 전부입니다. 러시아와 BMW, 포르셰, 돈 샌디, 폴크스바겐 등은 SPICE을 평가 모델로 도입키로 했다.더욱이 CMMI는 미 국방부가 주도했기 때문에 모델에서 어느 하나를 바꾸려면 승인을 받아야 했다. CMMI 기반으로는 업계에 특화된 프로세스 모델로서 개발할 수 없었던 것이다. 자동차 산업은 업계에서 쓰이기를 원했고 그 용어가 모델에 반영되기를 바랐다. CMMI는 이를 허용하지 않는 반면, ISO에서는 그렇게 할 수 있을 가능성이 있었다. 예를 들어 ISO 15504의 경우 관심 분야별로 과정 평가 모델을 독자적 용어로 구성할 수 있었다. SPICE에 여러 버전이 있는 것은 이런 이유에서다. 현재 우주공학, 금융, 의료 분야 등의 SPICE가 있는데, 각 분야별로 해당 SPICE 버전을 작성할 수 있음을 보여주고 있다.동산지, BMW, 다입니다.러시아, 포르셰, 폴크스바겐이 참여하고 있는 HIS그룹은 2003년도에 SPICE을 사용하기로 결정했다. A-SPICE 1.0버전은 2005년에 발표됐지만 이것이 바로 ISO 15504였다 ISO그대로의 경우 5년마다 새로 갱신되지만 ISO15504의 새 버전의 ISO 33000이 2015년에 발표되었습니다. A-SPICE도 여기에 맞춰야 했기에 새로운 A-SPICE 3.0을 제정했다.A-SPICE 3.0은 ISO 33000에 기반했으며 독 1자동차 협회(Verband Der Automobilindustrie, VDA)에 의해서 제정되었습니다. 배포는 워킹 그룹 13(AK 13)에서 맡고 있다.'학습'이 중요한 A-asics & Abstractions A-SPICE 자체 SPICE는 확실히 사용해야 하는 규제가 아니라 프로세스 성숙도 평가 모델임을 기억할 필요가 있다. 성숙도 모델은 "개선"을 중시하며, SPICE(Software process Improvement and Capability Evaluation)에서의 "I" 또는 "Improvement"의 약어이다. A-SPICE는 구입해 사용할 수 있는 프로세스가 아니다. 다양한모델케이스와이를어떻게배워야하는지에대한아이디어였다,즉에이스피이스는과정개선을위한학습이주된이야기이며관련된모델케이스를정리할때학습하는이야기가어떤것인지를정의해야합니다. 한마디로 학습을 소프트웨어 엔지니어링 분야에 적용한 것이다. A-SPICE에는 Basics와 Abstractions이 들어 있지만 이를 이해하면 A-SPICE을 준 한 과정을 마련할 수 있다.A-SPICE의 최대 장점 1개는 요구 사항의 이행을 증명하기 위한 트레이서 빌리티(Traceability)인 A-SPICE는 추적성 면에서 CMMI보다 명확한 요구 사항을 제시합니다. 각 고객의 요구사항에 대한 추적성을 유지하기 위해서는 필요한 정보를 수집하고 문서화해야 하는데, 여기에 테스트를 위한 요구사항이 포함되는 것은 아니다. 추적성이 제대로 확보될 경우 시간을 절약할 수 있다. 물론, 엔지니어링 툴로 추적성을 확보하기란 쉽지 않지만, 1단 확보하면 평균 개발 공학의 속도가 빨라지고 전체 프로젝트에서 뭐 1이 1어가 나왔는지도 쉽게 알 수 있게 된다. 여기서 '안다'는 것은 결국 학습을 통해 배운다는 것을 의미하겠죠.엔지니어링에는 다양한 기술을 사용할 수 있으므로 가이드라인(Guidelines)이 필요하다. 어떤 기술이 자신의 방법, 도구를 사용할지 1정의 수준 이상의 품질이 도우이보도에룰 수 있다.또한 프로젝트에서 의사결정을 내려야 하는 시점에서 결정을 돕는 전략(Strategies)이 필요하다. 어떻게 보면 이게 엔지니어링 A-SPICE가 요구사항에 대한 추적성만을 요구하는 것은 아니다. IBM Rational DOORS자신 PTC Integrity 같은 도구가 이력 추적를 확보할 수 있도록 돕고 있지만 이들은 실질적으로 전체 요구 사항 50카피.센트 정도 밖에 커버할 수 없을 겁니다. A-SPICE에서는 워크패키지(Work Packages)에 대한 추적성을 요구하고 있다. 한마디로 프로젝트 계획을 수립하고 모니터링까지도 포함돼야 한다는 것이었다.우선 요구사항의 추적을 살펴보자. 요구사항에 대한 추적성이 있어야 한다는 것은 요구사항의 전반적인 생활 패턴을 모두 추적해야 한다는 것을 의미합니다. 요구사항을 이미 캡쳐하고 분석하고, 디자인을 추출하고, 그것을 구현한 후에 테스트해야 하는 요구사항을 분석하는 것은 A-SPICE에 있어서 매우 중요한 사안이지만, 분석해야 하는 속성까지도 정의하고 있다. 요구사항의 타당성(feasibility), 테스트 가능성(testability), 요구사항이 미치는 영향(impact), 중요도(criticality), 요구사항을 이행하는데 걸리는 비용 추정(estimation)이 포함된다.워크패키지에대한트레이스성도있어야합니다. 이것은 워크패키지 생활패턴을 봐야 한다는 것인데 그러기 위해서는 프로젝트 초반에 워크패키지가 마련되어야 할 것입니다. 그 향후 비용에 대한 예측이 필요하고, 달력에 쓰기 위한 스케줄링이 필요할 것입니다. 다음의 실행과 검토가 이루어져야 합니다. 워크패키지에 대한 비용 측정과 스케줄링을 다시 해야 하는 경우도 있다. 이러한워크패키지가프로젝트매니저(PM)측에서이루어지고있는데워크패키지에대한추적성이필요할것입니다.이 분야의 추적을 하면 많은 것을 배울 수 있다. 엔지니어가 워크패키지로 비용을 추정하고 워크패키지를 이행하면 처음 예산보다 어느 정도 자신감이 빠져나갔는지 알 수 있다. 또 자신이 얼마나 달성하는지 스스로 알 수 있지만, 여기서 다시 한번 '학습'의 중요성을 알 수 있다.기술한 가이드라인에 대해 상정해 두고자 한다. 가이드 라인은 방법(methods)이 쟈싱 툴(tools)때문에 필요한데 이것이 A-SPICE의 요구 사항이었던 ISO 26262또, 준수를 위한 가이드 라인이 필요하지만 안전과 관련된 문화(Safety culture)는 어떻게 되는가, 달성 가능한지에 대한 이에키이 포함되지 않으면 안 됩니다.향후 전략(Strategies)에 기초한 의사결정이 이루어지지만 사실 추정(estimation) 면에서도 전략적 의사결정이 이루어져야 합니다. 비용뿐만 아니라 다양한 엔지니어링에 관한 추정을 하는데도 다양한 기술이 있는데 그 기술을 어떻게 선택하고 자기온추정치를 어떻게 활용할 것인가 하는 전략도 필요할 것입니다.검토(Review) 전략도 필요할 것입니다. 검토할 수 있는 방법에도 여러 가지가 있을 뿐만 아니라, 각 산출물에 대해 어떤 검토를 실시할 것인가라는 전략이 필요했기 때문이었다.아시다 시피 100카피.세인트 확실히 테스트 할 수 있는 방법은 없어. 그렇다면 테스트에 관한 전략, 화이트박스로 할지, 블랙박스로 할지, 아니면 더 상세한 테스트를 할지에 대한 전략이 필요하다. SPICE에서는 "100카피.세인트 정확하지 않다면 그에 대비한 전략이 있어야 합니다.라고 언급하고 있다. A-SPICE에서 모든 엔지니어링 프로세스에 대한 전략이 필요한 것은 이러한 이유에서였다.PDCA(Plan-Do-Ch)eck-Act)는 개선을 위한 것이었다 개발자는 먼저 스스로 목표를 설정해야 합니다. 내가 프로젝트를 통해 향상되고 있는지, 어떻게 알 수 있는지? 그래서 프로젝트 매니저가 앞으로의 프로젝트에서는 더 잘 하는지 어떻게 알 수 있을까? 이를 알아야 개발팀의 전반적인 개선을 이끌어낼 수 있다.또 소프트웨어 구조가 스스로 개선되었는지, 자신의 구조가 어떻게 개선될 수 있는지 알 수 있는가? A-SPICE에서는 이러한 목표와 전략, 그리고 목표를 달성하기 위한 결심, 이를 실행할 수 있는 실행방안, 목표를 모니터링하고 후속조치할 수 있는 또 다른 에스컬레이션 할 수 있는 부분이 있어야 한다고 요구하고 있다. 이것도 결국 학습과 관련된 것이었던 A-SPICE의 모든 과정마다 이것이 다 들어있다. A-SPICE 제정 당시, 그러한 점이 기본이 되어야 한다고 생각해서 A-SPICE를 제정한 것이었다.

>

후진이 없이 지속적인 발전 때문에 ISO/IEC 330xx=A-SPICE 3.0A-SPICE의 프로세스 능력 수준은 수준 0에서 5까지 6단계로 구성된다(그림 1). 이곳에서 지역을 넘어 가야 할 단계가 레벨 2였다 수준 2는 정의(define) 하고 점검(review) 하는 단계였다 이는 프로세스에 의해서 발발한 작업 산출물이 적절하게 관리되는 정도를 측정함으로써 1반 적으로 작업 산출물에 대한 요구 사항과 문서화 및 컨트롤을 위한 요구 사항을 정의하고 이를 만족시키기 위해서 작업 산출물을 점검하고 조정합니다.

>

레벨 3에서는 그대로 프로세스가 존재하거나 해당 프로세스가 맞춤화와 피드백을 통해서 개선되는지 확인한다.A-SPICE는 자신의 단지화된 프로세스를 좋아하지 않는다. 사내에 있는 단지화된 프로세스가 있어 변경이 불가능하다면, 이것은 A-SPICE의 원칙에 반한다. A-SPICE는 프로세스에 대해 끊임없이 의문을 갖기를 바라며, 프로세스를 프로젝트에 맞게 맞춤화하고 사후에는 해당 프로세스가 프로젝트에 적합했는지 피드백해야 한다. 프로세스의 어느 부분이 개선될 수 있는지에 대해서도 알려야 한다.레벨 4는 추정(estimation)로 측정(measurement)단계이지만, 현재 자동차 OEM들은 레벨 4를 요구하지 않는다. 대부분의 작은 기업들은 안전을 위한 프로세스, 자신의 보안을 위한 프로세스는 레벨 3을 요구한다. 그러나 앞으로는 레벨 4까지 적용될 것으로 예상된다.

>

A-SPICE프로세스 영역 ISO/IEC 330xx시리즈는 거의 60개의 프로세스 영역(process areas)으로 구성된다. A-SPICE는 3개의 프로세스 영역이 있다. 이전 버전이 소프트웨어 계열만 실험합니다.면 20하나 5년 7월 하나 5일 발표된 A-SPICE 3.0에서는 시스템을 구성하는 기계적·하드웨어, 소프트웨어에 대한 상위 개념으로 시스템 엔지니어링 그룹을 배치했습니다. 앞으로는 A-SPICE의 평가를 하드웨어 개발과 메카니컬 개발 쪽에서도 할 수 있게 될 것이다. 그림 2에 빨간 테두리로 표시된 부분이 HIS그룹에서 권장하고 있는 셈이다.요구 사항에 대 칠로 평가를 실시하려면 프로세스마다 2~3시간의 인터뷰가 필요하다. A-SPICE의 경우 3개 영역에 대해서 전부 인터뷰를 하기 때문에 많은 비용이 걸릴 것이다. 이에 대해서 HIS그룹은 하나 5개 영역을 선정하고 HIS의 범위(scope)에 근거하여 하나 5개의 프로세스 영역을 평가(assessment) 하는데 일주일 만에 충분히 됬 슴니다.

>

수위 일이 쌍방향 추적성(bidirectional traceability)과 일관성(consistency)가 중요하다(그림 3). SPICE가 90년대에 만들어졌기 때문에 A-SPICE의 근간은 V-cycle였다 V-cycle는 소프트웨어 엔지니어링 프로세스(SWE)와 시스템 엔지니어링 프로세스(SYS)으로 구성되어 있다. 이 트레이서빌리티는 V-cycle에 근거해 정의되지만, 스텝마다 트레이서빌리티가 있어야 한다. 추적성은 프로젝트를 보다 잘 이해하기 위한 기초이며 효율적인 엔지니어링이 필요했기 때문이다.만약 프로젝트에 변경 요청을 하려면 추적성이 확보돼야 제대로 디자인을 바꾸고 요구사항을 변경할 수 있다.레벨 일은 트레이서빌리티가 없으면 불가능하다. 수준 일 50%정도가 결국은 추적 성과 일관성에 관련된 것이기 때문이다, 그래서 추적성이 없으면 수준의 평가는 의견 없다.

>

수준 2에서는 개선을 위한 목표를 설정합니다. 프로젝트 관리자로서 개선하기 위해 어떤 일을 해야 하고, 개발자로서 스스로 어떻게 개선할 수 있는지 목표를 설정하는 것이었다. Part 2.1에서는 워크 패키지를 예정 및 모니토링하의 봉 인 성과 관리 역할 분담, 인력 배치 때도 목표 설정하는 것을 다룬다. Part 2.2는 템플릿과 형상(Configuration)관리 점검과 관련된 것이었다.레벨 3의 경우에는 프로세스를 정의하고 이를 적합화된 방식으로 사용하는 것이었다. 요기에는 추정과 모니터링, 형상관리와 점검이 들어간다. 또한 보통 프로세스와 피드백, 프로세스 맞춤화, 팀원의 스킬 관리 등도 포함된다.다시 한번 정리하면, 수준 1은 어느 소프트웨어 엔지니어링에서 장인 정신(Craftsmanship)이다. 추가적으로 배울 것은 없고 대학에서 배우는 정도면 충분하다. 수준 2는 프로젝트를 개선하기 위한 자세이다. 형상 관리 후에 점검하고, 템플릿을 준수해, 이미 있는 것을 재이용하려고 하는 자세를 가져야 합니다"라는 것이었다.레벨 3은 좋은 점을 기억하고 이를 다시 활용하자 세있다. 때문에 레벨 3에서는 경험을 문서화하고 이를 프로세스로서 정착시키는 것이었다. 간단해 보이지만 이런 성숙도 단계까지 나아가 적용하기는 쉽지 않다. 담당자가 기술적인 부분에 대해서 이해하고 개선을 위한 자세를 갖추고 좋은 프로세스가 어떠한가를 파악하고 이를 재이용하는 데는 시간이 드는 것이 아니기 때문이었다.A-SPICE의 도입이 6단계로 구성된 A-SPICE을 단계적으로 어떻게 도입하는가? 먼저 전반적인 비즈니스 목표와 목적을 파악해야 합니다. 고객이 레벨 3의 준수를 요구할 때에는 이미 늦었다. 그 전에 먼저 시작해야 하고 향상 목표도 있어야 합니다. 현재의엔지니어링을개선하고시간을절감하며현장에서오류수를줄인다는목표가필요합니다. 이러한 목표가 있어야 프로세스 모델 도입 시 도움이 되는 것이었다.경영진과 개발자가 참여하는 워크숍을 통해 어떤 목표를 세워야 하는지, 개발자 입장에서 어떻게 개선해야 하는지 파악해야 합니다. 워크숍 등을 통해 목표를 정의한 후 갭 분석(Gapanalyses)을 해야 합니다. 그러기 위해서는 현재 사용하고 있는 프로세스를 가장 먼저 분석해야 하는데, 엑셀이든 PPT든 보유하고 있는 독자적인 프로세스를 A-SPICE를 통해 평가하면 된다. 즉 기존의 것과 비교하라는 것인데, 어떤 차이가 있는지 파악하고 우선순위를 정해서 전에 정한 목표를 달성할 수 있는지 확인해야 합니다.그 다음은 프로세스 구조(Architecture)를 정의해야 합니다. 회사마다 필요한 구조가 다르겠지만 구조에는 인트라 프로세스(Intraprocess)구조와 인터 프로세스(Interprocess)구조 2가지가 있다. 건물에 비유하면 인트라 프로세스 구조는 건설되고 있는 하본인의 건물이며, 인터프로세스 구조는 많은 건물이 있는 도시로 생각하면 된다. 인트라 프로세스 구조에는 역할정의(Role descriptions), 템플릿(Templates), 툴(Tools), 라이프사이클(Lifecycles), 워크인스트럭션(Work instructions), 체크리스트(Checklists) 등이 있다. 이러한 용어는 프로세스를 스토리할 때에 보통 사용되며, 이것을 메타모델(Meta Model)이라고도 부른다.대기업마다 사용하는 용어가 다르기 때문에 프로세스를 정의하기 위해서는 최초로 개발자가 어떤 용어를 사용하는지를 파악하는 것이 중요하다.이제 추상화(abstraction)해야 합니다. 프로세스 자산(Process assets)의 유형은 프로세스 엘리먼트의 유형을 추상화해야 하는데, 이러한 프로세스 요소 유형이 본인 중에 프로세스에 사용되는 것이었다.메타 모델은 그림 4의 같은 형태로 될 수 있다. 엔지니어링 툴이 있고 역할 정의가 있으며 국면과 마일스톤이 있다. 또한 프로세스와 활동 그룹(Activity Group)이 있으며 의사자결(Decision)과 활동(Activity)이 있다. 이런 구조는 대기업마다 있으며 모든 사람들이 이를 다 이해해야 프로세스를 만들 수 있다.다음은 인터프로세스 구조이다. 이 구조에는 프로세스가 여러 개 들어가 웃돌지만 영역별로 구분되어 있다. 매니지먼트 프로세스(전략관리, 비즈니스 플랜, 대기업 지배구조), 밸류 프로세스(연구, 제품개발, 제조, 영업 및 마케팅, 서비스 및 지원), 지원 프로세스(금융, 인적자원, 정보기술, 구매, 법률)가 있었다. 가치 프로세스는 큰 기업마다 다르지만, 이러한 프로세스는 보통 계층(hierarchy)이 있다. 제품 개발은 시스템 엔지니어링, 하드웨어 엔지니어링, 소프트웨어 엔지니어링, 품질관리(QM)로 세분화될 것이다. 이것이 인터프로세스 구조로서 사전에 정의했어야 했다.이 구조를 전체 정의한 후에 조직을 정의할 필요가 있습니다. 누가 프로세스를 바꿀 수 있는지, 프로세스 오덱, 프로세스 작성자, 프로세스 아키텍트, 프로세스 디자이너 덱스가 누구인지를 정의해야 합니다. 일반적인 소프트웨어 프로젝트와 유사하다고 할 수 있다. 팀이 구성되어 프로세스를 정의하고 변천을 관리할 수 있도록 해야 합니다. 이렇게처음으로조직이만들어지고본인서작업을시작해야합니다.그다음에 코치들이 있어야 돼요. 코치들은 정립된 프로세스를 이해하고 프로젝트 팀원들이 프로세스를 준수하면서 작업을 할 수 있도록 해야 합니다. 프로젝트 팀마다 한명의 코치를 두는 것을 추천합니다.다음으로 프로세스에 대한 모델링 작업을 할 수 있다. 가장 최근까지는 용어를 정의하고 메타모델을 만든 후 프로세스 영역과 프로세스 구조를 정의했다. 그 다음 조직을 만들고 역할(role)과 메서드 설명(Method Descriptions)을 했다. 그 후에는 프로세스 영역별로 정의하는데 프로세스 개요(Process Overview)를 마련하여 필요한 프로세스 영역별로필요한 활동(Activities), 산출물과 역할을 정의한 후 점검(Review)해야 합니다. 그 다음에는 템플릿, 체크리스트, 문서의 라이프사이클이 정의되고 리뷰되고 있는지 파악해야 합니다.다음으로 컴플리언스를 확인해야 합니다. 그 다음 갭 분석을 하게 된다. 그 후 테일러링 가이드라인(Tailoring Guidelines)도 정의해야 합니다. 레벨 3에서는 테일러링 가이드 라인이 있어 향후의 프로세스를 개선할 수 있기 때문이었다. 그 방법이 즉석 메서드와 툴이 된다. 요기에는 즉석 메소드 설명과 도구 설명을 마련하여 프로세스에 포함시키고 트레이닝(Trainings) 절차가 마련되며 팀이 new 프로세스에 대해 교육을 받고 코치가 결정되어 무엇을 해야 할지 자결해야 합니다.마지막에는 측정(Measurement)이 포함되어야 합니다. 측정은 프로세스 자체에 들어가 그 목표를 달성했는지 여부를 파악할 수 있도록 하는 것이었다. 기존 프로젝트보다 개선됐는지를 파악하기 위해 프로젝트 매니저가 사용하는 기준 중 하본이나 측정치를 맞췄는지를 본다는 것이었다.이 과정을 거치면 향후 프로세스를 전사적으로 전개할 때 하본인의 프로젝트를 파일럿 프로젝트로 진행하고, 성공하면 다른 프로젝트에 적용하며, 코치와 모두 전체적으로 적용할 수 있게 된다. 측정치에 대한 평가는 이후에 이루어지며 워크숍에서 정해진 목표가 달성되었는지 여부를 볼 수 있다. 이렇게 함으로써 A-SPICE의 궁극적인 목적인 학습조직이 만들어지게 되었다.정리하자면 가장 먼저 A-SPICE와 ISO 26262를 이해해야 합니다. 그 때문에, AUTOSAR나 모델 베이스의 설계 툴이라고 하는 메서드가 필요하다. 또, DOORS 본인 Integrity와 같은 툴도 필요하다. 무엇보다사람이이런부분에대해서충분히이해하고효율적으로일할수있어야합니다. 모든 과정에는 시행착오가 있었다. A-SPICE는 후퇴가 아니라 지속적인 발전을 위한 것이었다. 이야기 요약-A-SPICE는 세계 자동차 엔지니어링 분야에서 가장 많이 사용되는 개발 프로세스 평가 모델이 될 것이다.-2015년에 발표된 최신 버전'A-SPICE 3.0'이 올해 의무화될 계획이었다. 대부분의 OEM은 A-SPICE을 사용하고 그들의 부품 협력 업체(Tier 1)을 평가하는 것이었다.-대부분의 Tier 1은 A-SPICE을 사용하고 엔지니어링 프로세스를 개선할 수 있다.베옹토우힝델(Bernd Hindel)CEO, Method Park-독일 에르랑겐 대학 컴퓨터 공학 박사와 독일의 에를랑겐 대학 교수(소프트웨어 엔지니어링 프로젝트 관리)-폭스바겐 자동차 대학, 아우크스부르크 대학교, 뷔르츠부르크 대학 초청 강사-iNTACS설립자-ISO/IEC 15504(SPICE), 독일 의장

출처:Automotive Electronics 7/8월호