허접.강기사의 재미없는 놀이

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 개발하면서 다양한 리스크가 존재합니다. 여러 프로젝트에서 공통적으로 나타나는 리스크에서 없어지지 않는 하나가 의사소통, 공유인 것 같습니다. 만들어진 작업 산출물에 대한 REVIEW가 완료되면 관련 이해관계자가 해당 내용을 인지하고 있어야 합니다. 이 부분을 위에서 말씀 드린 의사소통, 공유라고 말씀 드리는 것입니다. ASPICE에서도 이러한 부분이 현실적으로 나타나는 공통의 리스크인 점을 알고서 핵심 컨셉 5번째로 활동을 요구하고 있습니다. V 모델 왼쪽 편 (Left side)에서는 "Communicate agreed", "합의한다"라고 말하고, V 모델 오른쪽 편 (Right side)에서는 "Summarize..

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 용어는 기본적으로 매우 중요하게 / 잘 알맞게 사용되어야 합니다. 자동차 산업에서는 많은 약어 (Abbreviation)을 사용합니다. 같거나 유사한 기능도 OEM/지역 별로 다르게 부르기도 하고요. 예를들면 AEB: Autonomous Emergency Braking, FCA: Forward Collision-Avoidance Assistance 등과 같이요. 핵심 컨셉 3번째는 이러한 용어에 대해서 정의를 합니다. 엘리먼트 (Element): V model에서왼쪽 편 (Left side)의 설계 들을 말합니다. (ISO 26262에서도 광범위하게 사용되는 용어입니다) 컴포넌트 (Component): 소프트웨어 아..

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 아래 그림과 같이 Requirements 가 왼쪽에 있다면, Qualification Test가 오른쪽에 있습니다. 아키텍처가 왼쪽에 있는 경우 통합 테스트가 오른쪽에 있듯이요. 이러한 V자는 시스템에서 도메인 Software level로 이어지더라도 동일하게 적용됩니다. 구현(코딩) 시 Unit Verification 이 맵핑되듯이요. 그럼 왜 V model을 기반으로 프로세스를 구성하였을까요? / 고려해서 생각해야 할까요? 일반적으로 소프트웨어 프로세스는 아래와 같은 단계를 거치게 됩니다. 이러한 단계를 한번 씩 수행하면서 요구사항 부터, 테스트 단계까지 쭈욱 이어가는 것을 Waterfall (폭포수) 모델이라고..

1. 다양한 기술 특성 기계, 전기, 전자, 화학, 생명공학, 소프트웨어 등의 다양한 기술들이 통합되어 완성되는 시스템이기 때문에 요구사항이 중요함 자동차 분야는 비즈니스적인 이해와 더불어서 협력해야 하는 기술 도메인이 다양함 2. 시스템의 규모 자동차가 지능화 되어 가면서 시스템의 복잡도는 기하 급수적으로 증가 1억만 라인, 1억 5천만 라인.. 점점 늘어나는 규모와 복잡도 3. 협업 관계 업무의 세분화 및 분업화로 OEM과 Tier 간의 협업 관계 증가 자동차 메이커 (OEM)에서 시스템 레벨에서의 Tier1 그리고 Sub 시스템 (또는 컴포넌트, 엘리먼트)의 Tier 2 .. 등 다양한 이해관계로 구성되어 있음 4. 법, 규제 강화 자동차 시스템은 인간의 생명, 안전보장 그리고 환경 보호에 민감한 ..