[현대오토에버 SW스쿨 2기] 자동차 SW개발 프로세스(2)

이번 글에서는 'A-SPICE에 대한 개요와 그것이 자동차 소프트웨어 개발 프로세스에 왜 중요한지, 그리고 A-SPICE를 구성하는 핵심 요소들' 에 대해 깊이(?) 있게 다뤄보려고 한다. 😁

A-SPICE 개발 배경

• OEM의 고민으로 인해 탄생 🧐 → ‘부품 업체들에 대한 프로세스 품질 평가 기준이 필요해!’
• Audi, BMW, VW 등 유럽 OEM 업체가 연합하여 HIS(Hersteller Initiative Software) 그룹을 구성
• A-SPICE는 비교적 늦게 만들어졌고, 이미 당시에 사용하고 있던 모델들이 있었음
  • 대표적으로 ISO/IEC 12207 과 ISO/IEC 330xx가 있었고, 얘네를 기반으로 자동차에 특화된 프로세스 모델을 만들었음!
• 현재는 VDA QMC Working Group13 과 Automotive SIG 에서 주관함

Automotive Software Process Improvement and Capability dEtermination

• “전장 SW 프로세스를 개선하고, 능력을 평가한다!”

A-SPICE 프로세스 모델 구조

우선 ‘무엇’을 평가할 건지 필요하고, 그것을 어떤 ‘지표’로 평가할지 필요. 그리고 ‘어떻게’ 평가할지 필요함

• ‘무엇 ⇒ 프로세스 참조 모델(Process Reference Model)
  • 프로세스 범위 혹은 프로세스 별 정의에 필요한 식별자, 이름, 목적, 성과 를 설명한 모델
  • 즉, 프로세스를 ‘이해’ 하기 위한 것들을 정의해 놓은 것.
  • 공식 문서에 ‘빨간색’으로 된 부분들이 보통 PRM(Process Reference Model) 임
• ‘지표’ ⇒ 프로세스 평가 모델(Process Assessment Model)
  • 평가 대상에 해당하는 ‘지표’ 를 설명한 것
  • 보통 ‘녹색’으로 된 부분이 PAM(Process Assessment Model)
• ‘어떻게’ ⇒ 측정 프레임 워크(Measurement Framework)
  • 이거는 A-SPICE에서 고유한게 아니라 ISO/IEC 33020을 ‘채택’ 해서 사용하고 있음
  • 그래서 표지에서도 Measurement Framework 는 안써있음

프로세스 카테고리 3개, 프로세스 그룹 8개, 개별 프로세스 32개로 구분

• 3.1과는 달리 4.0 버젼에 MLE(Machine Learning Engineering Process Group)이라는게 생김

• HWE(Hardware Engineering Process Group도 생김

• ACQ(Acquisition Process Group) ⇒ 협력업체로부터 제품을 ‘획득’ 할때 필요한 과정

• MAN(Management Process Group) ⇒ 개발 프로젝트 자체를, 내부적으로 PM(?) 혹은 리더들이 해야하는 과정

• REU(Reuse Process Group) ⇒ 자산들을 ‘재사용’할때 수행해야하는 과정

• PIM(Process Improvement Process Group) ⇒ 프로세스의 ‘개선’을 위한 프로세스

• SUP(Supporting Process Group) - 품질보증이나 형상관리 등 ‘지원’ 을 위한 프로세스

⇒ 이런 과정들을 통해서 최대한 효율적이고 품질 좋은 제품을 만들자!

근데 프로젝트마다 성격이 다르기 때문에, VDA scope만 적용하거나, VDA scope 이외 추가 프로세스를 적용하거나 혹은 VDA scope 중에서도 일부만 적용함.
Why? → 협력업체가 없을수도 있고, 여러가지 환경 변수가 있기 때문

프로세스 평가 모델(Process Assessment Model)

크게 2가지로 나눠짐

프로세스 수행 지표(Process Performance Indicators)

• 기본 프랙티스(Base Practices) - 활동 중심 평가 지표
• 작업 산출물(Work Products) - 결과 중심 평가 지표
  → 요 둘의 관계는 “Base Practices” 를 수행함으로써 “Work Products”이 나오는 것.
  

프로세스 능력 지표(Process Capability Indicators) Lv1

• 일반 프랙티스(Generic Practices) - 활동 중심 평가 지표
• 일반 자원(Generic Resources) - 인프라 중심 평가 지표

• Generic ← 이거 붙어있는 이유는, ‘모든’ 프로세스 공통이기 때문

6단계의 프로세스 능력 수준(CL: Capability Level)

• 안타깝게도 상당한 기업이 아직 0~1 단계라고 함… 하하 😅
• 보통 기업에서 요구 및 목표하는 수준은 level 2라고 함.
• level4 에서는 퀄리티를 예측할 수 있을정도에 이름.
  • 개발 초기에 정확한 예측을 할 수 있다면 정말 Best…
  • 자동차뿐만 아니라, 항공이라던지 국방 등 여러 분야에서.. ← 물론 이 분야(항공, 국방) 에서는 level 4를 요구함
    • Why -> 훠어얼씬 안전이 요구되는 분야기 때문에 🛫 🪖
• 근데 아무튼 중요한건 Level 2임!!!

아래 사진은 프로세스 별 프로젝트 속성(PA: Process Attributes)의 달성 정도에 따라 구분한 등급 체계

당연히 CL 0에는 아무것도 없고, 그 위에는 한두개씩 존재

• 2단계 “Managed” 라는게 어떤 의미냐면 ‘산출물에 대한 관리를 해라’ 임

  • Base Practice 와 Work product 연결

• 프로세스 능력 지표 PA 1.1(CL 1)에 Generic Practices 랑 Generic Resources 있는 이유는, 수행지표를 달성해라! 라는것과 동일함.

• 1단계는 ‘체계’적이지는 않더라도 Base Practices에 대응하는 활동을 일단 ‘수행’ 하고 작업 산출물을 만드는데에 초점을 맞춤

  • ‘DO’에 포커싱되어있음
  • 여기서 'DO' 란 저번 글에 정리했던 PDCA 사이클의 D 부분임.

• 2단계는 ‘수행관리(PA 2.1)’ 와 ‘작업 산출물 관리(PA 2.2)’ 가 충족되어야함

  • PA 2.2 는 쉽게 말하자면,, ‘문서’ 를 잘 만들고, 그 문서를 토대로 검사 및 보완을 해라.
    • 또는 형상관리까지 포함!
    • QA + 형상관리 ← 요 2개가 핵심!

A-SPICE 핵심 컨셉 (7가지)

1. “플러그인 컨셉” (The “Plug-in” Concept)

   • 프로젝트 성격에 따라 영역을 추가 삭제할 수 있음
     • 협력업체가 없으면 ACQ 영역 뺴버림
     • 혹은 VDA 영역만 실행

2. “V 모델 컨셉” (The Tip of the “V”)

3. 용어 “엘리먼트” ,”컴포넌트”, “유닛”, “아이템”(Terms “Element”, “Component”, “Unit” and “Item”)

   1. 엘리먼트: V 모델 왼쪽 아키텍쳐 및 설계 수준에 있는 모든 구조적인 개체
   2. 컴포넌트: 최하위 엘리먼트(최소 하나 이상의 유닛으로 구성)
   3. 유닛: 더 이상 쪼갤수 없는 최하위 수준의 컴포넌트
   4. 아이템: V모델 왼쪽 엘리먼트와 대응되는 오른쪽의 요소

4. “추적성” 과 “일관성” (”Traceability” and “Consistency”)

   1. “Why” 추적성이 필요할까? → 실제로 현업에서 물어보면 ‘추척’ 하려고 한다고 얘기한다고 함.
      • 커버리지 파악
      • 효율성
      • 처음에는 진짜 고생한다고 함… 하지만 한번 해놓으면 편함
   2. “Why” 일관성이 필요할까?
      • 추적표에서 잘 묶어놓는것..?
        • 나중에 잘 묶였는지에 대한 검증으로 ‘리뷰’ 를 해야됨.
      • 이걸 잘 해놔야 추적을 잘 할 수 있음

5. “합의한다” 와 “요약하고 의사소통 한다” (”Agree” and “Summarize and Communicate”)

   1. ‘공통된 이해’ 가 이루어져야됨.
   2. V 모델 왼쪽 → communicate agreed 로 명시
   3. V 모델 오른쪽 → summarize and communicate 로 명시

   → ‘합의 되었다’ 라는 건 V 모델에서 중시하는 ‘리뷰’가 끝났다 라는것.

   4. Tester)에서 ‘summarize’ 먼저 하는 이유는, 테스트 결과는 대부분 Low level이기 때문에, 원활한 communicate를 위해서 Test Report를 만들어서 넘겨줘야함.

6. “평가”, “검증 기준”, “준수 보장” (”Evaluate”, “Verification Criteria” and “Ensuring Compliance”)

   1. 여러 전문가로 여러 대안을 ‘평가’ → 편향되지 않도록
   2. 검증 기준: 요구사항 검증을 위해 기준 충족
   3. 준수 보장: V모델 왼쪽 프로세스의 산출물을 충족하도록 테스트 명세가 개발되어야 함을 의미

7. “전략”과 “계획”의 관계(The Relation Between “Strategy” and “Plan”)

   1. 프로젝트 목표를 달성하기 위해 프로세스를 수행하기 위한 방안 → 전략
   2. 능력 수준1은 프로세스 별 계획(BP) 이 필요하지만, 2 이상 부턴 각 수준에 맞는 Generic plan이 필요함.
   
   
   

본 포스트는 디지털선도기업인 현대오토에버&현대엔지비와 전문교육기관인 한국전파진흥협회가 주관하는 현대오토에버 모빌리티 임베디드 SW 스쿨 2기 교육을 통해 배운 내용입니다. 😀