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

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

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 시스템이란 의미부터 생각해 봅니다. 시스템은 하나의/또는 작은 소프트웨어만으로도 구성될 수 있으며, 또는 간단한 하드웨어 또는 IC를 포함하는 복잡해진 PCB로 구성되어 센서, 제어, 액추에이션을 수행할 수도 있습니다. 그리고 외부 환경의 영향으로부터 안전성, 힘, 역학 등을 고려한 메카닉까지 포함할 수도 있죠. (아래 그림에서는 SWE를 포함해서 이러한 영역을 Domain level로 표현하고 있습니다.) ASPICE PAM (Process Assessment Model), PRM (Process Reference Model) 에서는 기본적으로 SYS (System Engineering), SWE (Software..

항행안전시설 강의 중에 재미난 영상 소스가 있어서 공유 드립니다. 유투브 링크 참고하시기 바랍니다. https://www.youtube.com/watch?v=gsquRfr5MWA

법은.. 너무 재미가 없다. 정확히는 머리 속에 잘 안들어온다. 또 의욕에 가득차서 수강을 하였으나, 역시나 중간고사가 다가오니.. 후회가 든다. 그래도 시작은 했으니까.. 공부해보자. 머리속에 잘 들어오기 위해서 좋아하는(?) 그림으로 요약하면서 해보기로 한다. 대강 1강을 요약해보면 이런 그림으로 정리할 수 있었다. 항공법이 있는데, 시간이 지나서 세분화된 3개의 법으로 구분되어 이용되고 있었고, 최근에는 보안이나 드론과 같은 무인기가 추가되면서 법도 추가되었다. 각 법이 포함되는 범위에서 기억하기로 하고, (몇 장, 몇 개.. 이런건 포기하고) 법은 '국가 법령 정보 센터' 란 곳에서 검색해볼 수 있다. https://www.law.go.kr/LSW/main.html 국가법령정보센터 ! @ # $ ..

문제1. 소프트웨어 품질에 대한 설명으로 가장 적절한 것은? 정답 및 해설 : 요구사항을 충족하는 정도를 의미 (소프트웨어 품질의 정의는 요구사항을 얼마나 만족하는지를 나타내는 것으로, 바람직한 명시된 요구사항과 묵시적 요구사항을 모두 달성해야 한다.) 내 오답: 소프트웨어가 지닌 바람직한 비기능 속성의 정도 추가 정리1. 묵시적 요구사항은, 내재된 요구사항은 명시되지 않은 요구사항 외 당연히 포함되어야 할, 기본적인, 그럴거라고 여겨지는 모든 요구사항을 말합니다. 해당 부분에 따라 품질 수준이 달라질 수 있습니다. 명시된 부분 외 추가적인 부분들도 다뤄져야 합니다. 추가 정리2. 품질은 크게 (1) 제품 품질, (2) 프로세스품질로 구분됩니다. 제품품질은 소프트웨어가 운용될 환경에 올려져 최종 시스템이..

공학 Engineering은 많은 공과대학에서 배우는 여러 학문들의 범위에서 비용과 현실적인 문제들을 ... (생략) 뭐 이런 얘기를 하고자 하는 건 아닙니다만, 우리가 흔히 오해하는 부분들을 다루는 내용이 나와서 몇 자 적어봅니다. 동일한 입력이 들어가고, 동일한 출력이 나온다. 동일한 입력이 들어갔는데, 동일한 출력이 나오지 않으면 그것이 공학인가? 현실적으로 네!, Yes! 그럴 수 있습니다. 공학은 현실적인 문제를 다루기 때문입니다. 현실적(Real, Fact 등)이지 않은 부분까지 집중해서 다룬다고 하면 학문, 자연과학의 범위에서 더 중점적으로 논의가 되어야 한다고 생각합니다. (이런 생각은 어디까지나 개인의 지식과 의견, 가치관, 경험 등에 따라 달라질 수 있습니다. 제 생각이 그렇다는 겁니다..

Q1. 소프트웨어 프로세스는 소프트웨어를 만들기 위해 무엇을 어떻게 해야 하는지에 대한 가이드이다. 정답: 소프트웨어 프로세스는 소프트웨어를 만들기 위해 무엇을 해야 하는지에 대한 가이드이다. 어떻게에 대한 내용은 포함하지 않는다. 내 생각: 소프트웨어 + 프로세스, 프로세스를 What으로만 봐야하는 것일까? 프로세스는 가이드라인, 노하우를 포함할 수 있을텐데 너무 일반화된 접근에서 생각한 것은 아닌지 생각된다. 개인적으로는 무엇을 (what), 어떻게 (How) 그리고 When, Who, Why, (Where)를 충분히 포함할 수 있다고 생각한다. Q2. 비정상적인 상태나 환경에서 시스템이 제 기능을 수행할 수 있는 정도를 의미하는 품질 속성은? 정답: Robustness 비고: 난 Availabili..

AIAG-VDA 가이드북을 읽다보니, RPN (Risk Priority Number) 외 AP (Action Priority) 를 통한 정의가 보이네요. 왜 포함된거지? 목적이 뭐지? 어떤 배경으로 생겨난 거지? 궁금해서 찾아보니 아래 그림으로 확실하게 이해가 되네요. 그림을 보시면 Scenario A와 Scenario B 모두 RPN 80으로 동일합니다. 우선순위와 중요도에 따라 업무(Task)를 배정하는데, 위 2 개의 Scenario는 동일하게 보아야 할까요? RPN으로만 구분한다면 그럴 수 있겠지만, 설명되어 있듯이 RPN만으로는 이러한 충분하지 못한 부분이 있음을 말하고 있습니다. Severity가 높은 시나리오부터 접근하여 분석하는 것이 필요할 것입니다. 이러한 부분을 위해서 Action Pr..

FMEA 가이드 북을 읽다가 재미난 부분을 알게 되어서 짧게 글을 써봅니다. 몇 년전에 발표된 AIAG-VDA FMEA 가이드북에서도 글 제목과 같이 FHTI가 언급되어 있더라고요. 아래 그림을 보시면 Fault Handling Time Interval, FHTI의 정의가, Fault로부터 Failure가 발생되고, Hazardous event가 발현되는 시점까지로 정의되어 있습니다. 반면에 ISO 26262 part 1에서는 Safe state로 천이하는 시간까지를 의미합니다. ISO 26262 part 1에서, Hazardous event까지는 아래 그림과 같이 FTTI, Fault Tolerance Time Interval 로 정의되어 있습니다. 좀더 AIAG-VDA 가이드북을 읽다보니 아래와 같이..