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

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 개인적으로는 전략 (Strategy)이란 말을 많이 사용합니다. 같은 프로젝트라도 가용 가능한 자원 (시간 포함)과 상황에 따라서 다른 부분들을 고려해봐야 하고, 그럴 때마다 저는 '그래서 우리의 전략은 어떻게/얼만큼/언제.. 등을 고민해봅니다' ASPICE에서도 전략 (Strategy)는 프로젝트 목표 달성을 위해 수행가능한 부분들을 고려합니다. 이러한 전략들은 구체화 하고 어떻게 수행할지, 결국은 이해관계자들과 합의하여 계획 (Plan) 형태로 작성됩니다. 예를 들면, Carry over 되는 프로젝트라도 변경될 부분들, 이전 차종에서 발견된/확인된 부분들을 통해서 System Requirements를 어떻게 관..

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 평가한다 (Evaluate): 시스템 아키텍처 (SYS.3), 소프트웨어 아키텍처 (SWE.2)의 상세 설계의 여러 대안을 평가한다. 먼저 아키텍처에 대해서 간단하게 얘기해보면, 아키텍처는 구현을 위한, 문제 해결을 위한 접근이 필요합니다. 즉 What 보다는 How에서 논의가 필요합니다. 구성요소는 어떻게 이뤄지고, 구성 요소들간에 관계, 그리고 이 구성요소들의 외부로 보여지는 속성들은 어떤지를 고민해야 합니다. 아키텍처가 필요한 이유는 이해관계자와 의사소통할 산출물이며, 비 기능 요구사항의 실현 가능성을 분석할 수 있게 합니다. 또한 이전 개발로부터 재 사용할 수 있게끔 활용될 수 있습니다. 아키텍처를 평가한다 ..

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

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 위 그림에서 각 프로세스 간에 연결되어 있는 선(Line)이 많이 보입니다. 선의 색에 따라서 추적성 (Traceability), 일관성 (Consistency)를 나타냅니다. 선이 많다는 것은 그만큼 추적성과 일관성이 많이 필요하다고 생각하시면 됩니다. 여기서, 추적성과 일관성은 다음을 의미합니다. 추적성 (Traceability): 작업 산출물 내 관련 요소들 간에 연결되어 추적 가능한지를 의미 일관성 (Consistency): 작업 산출물 내 관련 요소들 간에 내용과 의미가 일관되게 반영되어 있는지를 의미 추적성부터 간략하게 살펴보면 아래 그림과 같이 Requirements가 구현 그리고 Test case까지 ..

해당 글은 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 (폭포수) 모델이라고..