자동차 업계의 SW직군을 목표로 취업을 준비하시는 분들이라면
Aspice라는 용어를 많이 들어봤을 것이라 생각됩니다.
인터넷에 Aspice의 정보를 찾으면 내용이 꽤 어렵게 나옵니다.
그래서 예비 취준생분들과 신입 자동차 SW 직군의 분들을 위해서 이 글을 작성합니다.
이 글을 쓰는 저도 신입의 기준이며,
별도로 수익을 창출하지 않으며, 포트폴리오가 주목적이라는 점을 밝힙니다.
Aspice의 한글 번역본은 감사하게도
씨엔비스라는 곳에서 무료?로 공유해주시고 계십니다.
그러나 내부 내용을 재가공하는 것은 안된다고 명시되어 있습니다.
CNBIS
CNBIS
고객지원 Convenient & Beneficial Intelligent Systems
www.cnbis.co.kr
이 글에서는 정말 대략적인 개요를 설명할 생각이며,
더 깊은 내용은 씨앤비즈와 같은 회사들을 통해서 컨설팅을 받는게 좋다고 생각합니다.
구글에 Aspice를 검색하면, 나오는 정의는 다음과 같습니다.
"전자 및 소프트웨어 기반 시스템의 개발 프로세스의 성숙도를 평가합니다."
"Aspice는 Automotive SPICE(Sofware Process Improvement Capability dEtermination)의 약어로 유럽 주요 OEM이 자동차용 S/W를 개발하는 부품 업체의 개발 프로세스의 역량을 평가하기 위한 목적으로 만든 산업계 통용 표준입니다."
ASPICE 개요 (tistory.com)
위의 블로그를 보면 알겠지만, 내용이 쉽지 않습니다.
결론적으로 말하자면, Aspice는
자동차 업계에서 부품을 개발하는 협력사들이 부품을 개발할때, S/W 개발 프로세스를 잘 준수하였는지를
평가하는 기준이라고 보시면됩니다.
중요한점은 차량에 들어가는 S/W는 보통 임베디드 시스템이라고 해서
하드웨어(PCB)가 존재하고 그 내부에 S/W가 들어가게됩니다
그러나 Aspice의 현재 버전 (3.1)에서 볼 때,
Aspice의 약어가 무엇인가를 다시 한 번 확인해봅시다.
Automotive SPICE(Sofware Process Improvement Capability dEtermination)
S/W 프로세스를 개선하는 평가지표이며, H/W에 대한 평가는 Aspice의 영역에 포함되지 않습니다.
그래서 Aspice 4.0 부터는 H/W에 대한 평가를 포함하려 하고 있다.
이거 하나만 기초 지식으로 기억하고 가시면 됩니다.
Automotive SPICE(Sofware Process Improvement Capability dEtermination)
S/W의 프로세스를 평가한다.
여기서 이해가 안된다면, S/W 프로세스를 모르기 때문이라고 생각됩니다.
Aspice는 그래서 S/W 개발의 프로세스를 하나의 그림으로 표현을 해주었는데
그림을 보는 것도 쉽지 않죠.
왜 이런 프로세스를 적용하려고 하는걸까?
이를 설명하기 위해서는 자동차의 부품이 어떻게 개발되는가?
이를 먼저 이해해야 합니다.
OEM (현대자동차)에서 부품을 개발하는 일을 직접 하지 않고
협력사를 통해서 부품을 생산합니다.
그러면 어떻게 일이 진행되어야 하냐면
먼저 OEM에서 부품사에게 자신들의 요구사항을 전달하게 됩니다.
그러면 부품사에서는 OEM에서 원하는 요구사항을 충족하는 부품을 만들어 OEM에게 납품을 하게됩니다.
정말 간단하게 보면 이런 구조가 만들어지게 됩니다.
근데, OEM 입장에서 생각해볼때 부품사가 정말로 내 요구사항에 맞는 제품을 생산하였는가?
이를 확인해야하는데
부품사에 쳐들어가서 너네가 지금만든 제품의 코드부터 설계자료를 우리한테 줘!
라고 할 수는 없습니다. 부품사의 보안자료이자 자산이기 때문이죠
즉 OEM에서는 부품사에서 어떻게 제품을 개발하고 있는지 까봐야할 필요가 있는거죠.
그래서 OEM에서 어떤걸 요구하게 되냐면
우리 요구사항
1. A는 B다
이걸 어떻게 개발을 했어?
그러면 부품사에서는
1. A는 B다
라는 내용이 어떻게 자신들의 제품에 녹아들어가 있는지를 OEM측에 설명 해주어야 합니다.
다시 아까 봤던 그림으로 돌아와서 보면
정말 단순하게 S/W 부품의 개발은 어떤식으로 진행이 되냐면
1. 시스템 개발 -> 2. 소프트웨어 개발 -> 3. 검증 -> 4. 출시
위의 Aspice의 그림에서 보이는 순서를 타고 갑니다.
하나 더 붙여 볼까요?
0. OEM 요구사항 -> 1. 시스템 개발 -> 2. 소프트웨어 개발 -> 3. 검증 -> 4. 출시
이러한 단계를 탈건데, OEM의 요구사항이 S/W 개발단계 동안 반영이 되는가?
즉 자신(OEM)들이 제시한 요구사항을 제품에 완벽하게 녹여내었는가?
결국 이를 평가하려하는 것이
Apsice의 첫번째 목적입니다.
여기까지 이해를 했다면
자동차 SW 산업이 대충 어떻게 굴러가는지 이해를 하게 되었다고 생각합니다.
다시 그림을 들고와서 봅시다.
이제 SW 개발자라면 어떤 항목들을 고려해야하는지 확인을 해보도록 하죠
아래 그림에서 보이는 것처럼
빨간색 표시된 부분을 주로 고려하게 됩니다.
각 단계별 프로세스를 타게된다면 제품을 개발하는데 문제가 없다고 생각하면 됩니다.
이제 하나 하나씩 보도록 합시다.
일단 자동차 업계로 취업을 희망하는 취준생이라면
이 이후로 설명드리는 내용을 세부적으로 알 필요가 없습니다.
위의 설명드린 Aspice를 왜 적용하는지까지만 이해해도 됩니다.
그리고 신입의 기준이라면
이미 회사 자체에서 각 단계에 맞는 템플릿이나 프로그램으로 Aspice를 준수할 수 있게 구축되어 있을 것이고
그렇지 않은 회사라면, 위에서 언급한 씨엔비스와 같은 회사에서 컨설팅을 받는 것이 좋습니다.
OEM (고객)이 부품사로 와서 어떤 부품을 만들어 달라고 할겁니다.
어떤 부품의 예시를 하나 들어보도록 합시다.
자동차로 하면 조금 그러니까
예시를 다른거로 들어서
사칙연산이 가능한 계산기를 만들어주세요.
그리고 부품사에서는 이 계산기를 수주했다고 생각합시다.
우선적으로 OEM에서는 계산기에 대한 요구사항을 주게 됩니다.
우선 수주가 진행되고, 가장 첫 번째 단계는
Management Process입니다.
첫번째 MAN.3는 Project Management 입니다.
정말 말 그대로 Project Management에 대한 내용을 정리하는 부분입니다.
구글에 Aspice MAN.3 로 검색하면 나오는 내용을 참고하도록 합시다.
4.5.1 MAN.3 Project management (flecsim.de)
4.5.1 MAN.3 Project management
www.flecsim.de
위의 사이트에서 나오는 내용을 잠시 인용하자면 (번역기 사용)
이를 성공적으로 구현한 결과 프로세스:
1. 프로젝트의 작업 범위(Project Scope)가 정의됩니다.
2. 목표 달성 가능성 사용 가능한 리소스와 제약 조건(constraints)이 있는 프로젝트가 평가됩니다.
3. 완료하는 데 필요한 작업 및 리소스 작업의 규모와 추정치가 결정됩니다.
4. 프로젝트의 요소 간의 인터페이스 및 다른 프로젝트 및 조직 단위가 식별되고 모니터링;
5. 프로젝트 실행 계획은 다음과 같습니다. 개발, 구현 및 유지 관리;
6. 프로젝트 진행 상황을 모니터링하고 보고합니다. 그리고
7. 계획에서 벗어난 부분을 수정하고 다음을 수행하기 위한 조치 프로젝트에서 식별된 문제의 재발 방지 프로젝트 목표가 달성되지 않은 경우.
참고 1: 필요한 자원에는 다음이 포함됩니다. 개발 도구, ECU에 있는 하드웨어(CPU, RAM, 플래시 RAM, 등), 테스트 장비, 방법론.
참고 2: 사람과 기술의 기술 프로젝트를 개발하는 데 사용되는 것을 평가해야 하며 필요한 경우 교육 과정, 도구 업그레이드, 신기술 도입 등 계획을 세워야 합니다.
참고 3: 프로젝트 실행 계획은 다른 요소 중에서, 작업 분할 구조를 포함하고, 책임, 일정 등1. 프로젝트의 작업 범위 (목적)
2. 사용 가능한 리소스와 제약조건
3. 완료하는데 필요한 리소스 작업의 규모 및 추정치 (공수)
4. 프로젝트 요소간의 인터페이스 (연락망)
5. 프로젝트의 실행 계획 (일정)
6. 프로젝트의 진행 상황 모니터링 (회의)
7. 문제의 재발방지 프로세스
그그리고 참조에서 보는 것처럼
장비, 툴 등에 대한 내용, 구성원의 평가, 일정 등등이 들어갑니다.
뭐 이런 내용을 들어갑니다. 그래서 위의 사이트에서 보자면
위와 같은 결과물이 나와야한다고 제시를 하고 있습니다.
(Work Product라고 하는 이유는 결국 이러한 행위의 결과가 문서로 남기 때문입니다)
세부 내용은 사이트를 들어가서 내용을 확인해보면 될 것 같습니다.
대충 정리를 하면
프로젝트를 시작하기 위해서 일정에 맞춰 계획도 짜고, 어떤 장비를 쓸건지 회의도 하고
매주 모니터링도 하고, 문제가 발생하지 않게 조치를 취하는 내용이 정리되어 있다고 보면됩니다.
그 다음에는
MAN.5 Risk Managements
간단해요.. Risk Managements에 대한 내용이 나오게 됩니다.
그냥 Risk를 어떻게 관리할 것인가에 대한 내용으로 대충 넘어갑니다.
4.6.2. MAN.5 Risk Management (flecsim.de)
4.6.2. MAN.5 Risk Management
MAN.5.BP3: Identify risks. Identify risks to the project both initially within the project strategy and as they develop during the conduct of the project, continuously looking for risk factors at any occurrence of technical or managerial decisions. [Outcom
www.flecsim.de
그리고 MAN.6 의 경우에는 S/W 개발과는 거리가 멀어요
4.6.3 MAN.6 측정 (flecsim.de)
4.6.3 MAN.6 Measurement
MAN.6.BP6: Retrieve measurement data. Collect and store data of both base and derived measures, including any context information necessary to verify, understand, or evaluate the data. [Outcome 5] MAN.6.BP11: Communicate potential improvements. Communicate
www.flecsim.de
자 대충 Managements Process가 마무리 되면
다음으로는 Support Process를 살펴봅시다.
보통 S/W 개발에서는 SUP.1, SUP8. SUP.9, SUP.10 만 생각하면됩니다.
나머지는 관심이 있다면 찾아보시면됩니다.
4.4.1 SUP.1 품질 보증 (flecsim.de)
4.4.1 SUP.1 Quality assurance
problems and/or non-conformance with agreement requirements are identified, recorded, communicated to the relevant parties, tracked and resolved; and
www.flecsim.de
먼저 SUP.1 Quality Assurance는
정말 간단합니다.
우리가 하고 있는 Aspice가 잘 지켜지고 있는가를 평가합니다.
이 부분은 Aspice 상에서는 S/W 개발팀과는 다른 별도의 사내 품질팀에서 진행을 해야합니다.
그래서 품질보증 활동을 진행하고 부적합 사항이 발생하면, 이를 보고하여 시정할 수 있게 합니다.
SUP.8 Configuration Management는
형상관리에 대한 내용으로
Aspice 활동간 발생하게 되는 Work Product를 어떻게 관리할 것인지에 대한 support 프로세스입니다.
뭐.. 깃헙이 있을 수 있고 그러죠 그래서 아래의 내용을 보면,
부품사에서 개발을 진행하면서 나오는 Work Product를 살펴볼 수 있습니다.
4.4.5 SUP.8 구성 관리 (flecsim.de)
SUP.9 Problem Resolution Management는
개발을 진행하면서 발견된 문제점을 잘 관리하고 있는가?
문제점은 이슈, 부적합 등등이 있을 수 있겠죠.
이러한 문제점이 발생하고 어떻게 모니터링하고 어떻게 해결하였는지가 해당 프로세스의 주요한 목적입니다.
4.5.6. SUP.9 Problem Resolution Management (flecsim.de)
SUP.10 Change Management 는
변경 요청 관리로,
계산기 시제품이 OEM으로 나간 이후에 변경되는 경우 변경 관리를 할 수도 있고
OEM에서 사양을 변경하는 경우가 있을 수도 있고
대충 뭔가 변경이 필요한 상황이 발생할 때, 진행하는 프로세스 입니다.
Support Process까지 계획과 전략을 세우면
본격적으로 프로젝트 개발을 진행합니다.
'ㅇ공부#자동차 > Aspice' 카테고리의 다른 글
| Automotive spice SYS.1 SYS.2 (System Engineering Process) (0) | 2024.09.12 |
|---|---|
| Automotive SPICE MAN.3 (Project Management) (2) | 2024.09.09 |