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

도성룡 강사님의 ASPICE 기본 교육 내용을 인용해서 글을 작성하는 것을 말씀 드립니다. 제 처음 전공은 "품질경영, 품질공학" 입니다. 신뢰성 공학과 관리도 설계를 세부 전공하였고 현장 품질을 알아야 한다는 혼자만의 생각을 가지고서 매몰차게 호되게 부딪힌 경험이 있습니다. 현재는 자동차 부품 연구소에서 일하면서 그 때의 호되게 경험했던 기억이 간혹 떠오를 때가 있는데요. 품질과 관련된 일이 생길 때라고 말씀 드릴 수 있겠네요. ISO 26262, ASPICE, CMMI 등을 하면서 현업 개발자분들 중에는 이런 말씀을 하시는 분들이 간혹 있습니다. "이거 해야돼?" "이게 뭐라고.. 바빠 죽겠는데.." "고객이 시켜서 하는 거잖아" "사람 붙여줘, 구해줘, 우린 바빠서 못해" 좋습니다. 아무리 설득해도..

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

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

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

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