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

A-SPICE 개발 배경 및 소개

• Automotive SPICE 개발 배경
  ISO/IEC 12207과 ISO/IEC 330xx를 기반으로 자동차 소프트웨어 시스템 개발에 특화된 프로세스 모델을 만듬.
  얘네는 국제표준, A-SPICE도 국제 표준일까? -> 노노 독일 표준.
  근데 사실상 세계에서 다써서 Defecto standard라고 한다.

• Automotive SPICE 소개
  Process Reference Model, Process Assessment Model 이렇게 두가지로 구성되어있다.
  2017년에 만들어졌는데 여전히 쓰임. 23년 말에 4.0이 나왔지만 여전이 3.1이 대세. 현대 뿐만 아니라 해외 OEM들도 그렇다.
  업체들의 우수 사례들이 정리되어있기 때문에 이걸 기반으로 평가할 수 있다.
  A-SPICE => "자동차 부품 업체들의 소프트웨어 프로세스를 개선하고 능력을 평가하기 위한 기준을 제시한 프로세스 모델"
  ISO/IEC 15504가 원래 SPICE.

---

A-SPICE 프로세스 모델 구조

• Automotive SPICE 프로세스 모델의 구성
  • 측정 프레임워크(Measurement Framework)
    -> 평가 방법(기준, 등급 등)
    이 부분은 ISO/IEC 33020꺼 그대로 갖다 썼다. 오른쪽 두 가지는 A-SPICE 고유한 것. 그래서 표지에 두가지만 써있는 것.
  • 프로세스 평가 모델(Process Assessment Model, prm)
    -> 평가 지표, practice들의 지표가 된다, 32개가 있다.
    프로세스 성과(Outcomes)와 프로세스 속성 성과(Process Attribute Outcomes)가 심사 대상 조직의 프로젝트에 존재하는지 식별하고 만족하는지를 평가하기 위한 지표를 정의한 모델
  • 프로세스 참조 모델(Process Reference Model, prm)
    -> 평가 대상
    평가 대상 프로세스의 범위와 프로세스 별 정의에 필요한 프로세스 식별자(ID), 이름(Name), 목적(Purpose), 성과(Outcomes)를 설명한 모델

• Automotive SPICE 프로세스 참조 모델의 프로세스 카테고리
  

  • 프로세스 범위를 표현하며 다음과 같이 구성
    3개 프로세스 카테고리
    -> primary, organizational, supporting
    8개 프로세스 그룹
    32개 개별 프로세스
    OEM 입장에서 Supplier에게 적용하는 것 -> A-SPICE
    A-SPICE에서는 엔지니어링 뿐만 아니라 전체 개발에 필요한 것들을 모두 정해두었다.

• 조금 더 중요한 필수 프로세스를 VDA scope로 지정
  32개 중에 16개가 VDA scope
  가장 일반적인 경우에는 VDA scope만 적용.
  플러스 알파를 요구하는 경우도 존재한다.
  당연히 더 적게 적용하는 경우도 있다.

• Automotive SPICE 프로세스 평가 모델 개요
  프로세스 성과
  => 프로세스 수행 지표(LV1 이하 평가)

  프로세스 속성 성과
  => 프로세스 능력 지표(LV1 이상 평가)

• Automotive SPICE 프로세스 평가 모델의 지표 유형

  • 프로세스 수행 지표
    Base Practices, Work Products
  • 프로세스 능력 지표
    Generic Practices, Generic Resources
    지표는 이렇게 두가지로 나눠진다.
    프로세스 능력 지표는 모든 32개 process에 공통적으로 적용된다. 3, 4 ... 각 레벨에 대한 GP, GR이 존재한다.

• Automotive SPICE 프로세스 평가 모델의 <프로세스 수행 지표> 구성 요소
  평가는 프랙티스(과정), 작업 산출물(결과)을 기반으로 프로세스 성과가 얼마나 달성되었는지 체크하는 방식으로 진행되고 그를 통해서 프로세스 별로 레벨이 나온다.

• Automotive SPICE 프로세스 평가 모델의 <프로세스 능력 지표> 구성 요소
  LV 1 이상에서 쓰이는 지표. LV 2부터 그 이상까지 프로세스 속성(Goal)이 2개씩 존재한다. LV 1에는 Goal이 하나 존재한다.

---

A-SPICE의 프로세스 능력 수준

• 6단계의 프로세스 능력 수준(CL: Capability Level)으로 구분
  • 능력 수준 0: 불완전한 프로세스(Incomplete)
    -> 프로세스가 없거나 거의 지켜지지 않는 프로세스 존재. 수행한 결과물이 거의 없음. 대다수의 프로세스.
  • 능력 수준 1: 수행된 프로세스(Performed)
    -> 'do'는 잘한 것. 수행했으니까 산출물이 있음. 능력 수준 0과는 확연한 차이 존재.
  • 능력 수준 2: 관리된 프로세스(Managed)
    -> 표준과 상관없이 각 프로젝트에서 정한 길로 가면 됨. 이 정도만 돼도 잘한 것. 여기부터는 plan이 기본적으로 존재. LV. 2가 현실적인 OEM의 목표.
  • 능력 수준 3: 정립된 프로세스(Established)
    -> 조직의 표준 프로세스가 정립되었다.
  • 능력 수준 4: 예측 가능한 프로세스(Predictable)
  • 능력 수준 5: 혁신 프로세스(Innovating)
    -> 이상적인 레벨들이다.

• 프로세스 속성(Process Attribute)의 정의
  프로세스 능력 수준의 달성 정도를 평가하기 위한 프로세스의 특성 -> 예를 들어, 소프트웨어 요구사항 분석 프로세스가 능력 수준 2를 달성하려면 Managed Process 특성을 만족해야 함!! 즉, 능력 수준 별 Goal을 만족해야 함!!

• Automotive SPICE 능력 수준 1의 특징
  프로세스가 체계적이지 않더라도 수행되고, 프로세스 성과가 산출물로 존재함.

• Automotive SPICE 능력 수준 2의 특징
  프로세스가 관리하에 체계적으로 수행되고 프로세스 성과가 산출물로 존재함.

• Automotive SPICE 능력 수준 3의 특징
  표준 프로세스를 테일러링 하여 프랙티스가 수행되고 프로세스 성과가 산출물로 존재함.

---

A-SPICE의 핵심 컨셉

1. 플러그인 컨셉(The "Plug-in" Concept)
2. "V 모델" 컨셉(The Tip of the "V")
3. 용어 "엘리먼트", "컴포넌트", "유닛", "아이템" (Terms "Element", "Component", "Unit", and "Item")
4. "추적성"과 "일관성" ("Traceability" and "Consistency")
5. "합의한다"와 "요약하고 의사소통 한다" ("Agree" and "Summarize and Communicate")
6. "평가한다", "검증 기준", "준수 보장" ("Evaluate",
   Verification Criteria" and "Ensuring Compliance")
7. "전략"과 "계획"의 관계 (The Relation Between "Strategy" and "Plan")

• 플러그인 컨셉
  프로세스들이 각각 컴포넌트화 되어있어서 필요에 따라 추가하거나 제외한다.

• V 모델 컨셉
  verification: Are you building the product right?
  -> 스펙을 가지고 test
  validation: Are you building the right product?
  -> 유저 관점에서 test, 유저가 의도한대로 동작하느냐?
  그래서 A-SPICE 4.0에서는 사용자 요구 분석에 대응되는 V 모델의 test 부분이 validation으로 표현되어있다.

• 용어 엘리먼트, 컴포넌트, 유닛, 아이템
  엘리먼트: V 모델 왼쪽의 아키텍처 및 설계 수준에 있는 모든 구조적인 개체
  컴포넌트: 소프트웨어 아키텍처(SWE.2)의 최하위 엘리먼트로 소프트웨어 상세 설계(SWE.3)의 정의를 위해 사용
  유닛: 더 이상 분해할 수 없는 최하위 수준의 컴포넌트, 컴포넌트는 하나 이상의 유닛으로 구성됨
  아이템: V 모델 왼쪽의 엘리먼트에 대응되는 오른쪽의 요소
  흠.. 그니까 전체 자동차 아키텍처에서 제동장치 부분을 담당하는 부분이 해당 아키텍처의 컴포넌트라고 하면 그 컴포넌트를 구성하고 있는 소프트웨어의 코드 속에서 함수가 유닛 즉 최하위 수준의 컴포넌트가 된다.

• 추적성과 일관성
  추적성: 작업 산출물 내 관련 요소들 간에 연결되어 추적 가능한지를 의미
  일관성: 작업 산출물 내 관련 요소들 간에 내용과 의미가 일관되게 반영되어 있는지를 의미
  추적성과 일관성은 상호 보완적 관계
  모두 선행 후행 관계 즉 chain으로 연결되어 있다.

  • 추적성이 필요한 이유
    커버리지 분석 및 파악, 변경에 대한 영향도 분석, 요구사항의 구현상태 관리

• 합의한다와 요약하고 의사소통 한다.
  V 모델의 왼쪽은 "합의된 프로세스 별 작업 산출물을 의사소통한다." 이고 오른쪽은 "테스트 케이스 별 수행 결과를 의사소통하기 보다는 요약한 결과를 공유한다." 이다.

• 평가한다, 검증 기준, 준수 보장
  평가한다: 시스템과 소프트웨어 아키텍처, 소프트웨어 상세 설계의 여러 대안을 평가함을 의미
  검증 기준: 요구사항 검증을 위한 정성적/정량적 충족 기준을 의미
  준수 보장: 테스트 명세는 V 모델 왼쪽 개발 프로세스의 산출물을 충족하도록 개발되어야 함을 의미

• 전략과 계획의 관계
  전략은 결국 계획이다. strategy = plan
  전략은 프로젝트 목표를 달성하기 위해 프로세스를 수행하기 위한 방안으로 이는 구체화하고 이해 관계자들과 합의하여 계획 형태로 작성됨