내 머리속 지우개

요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다. 국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “적절성(Appropriate)”은 소프트웨어 개발과 시스템 설계에서 요구사항이 적절한 수준에서 정의되어야 한다..

요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다. 국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “필수성(Necessary)”은 모든 요구사항이 시스템의 목표 달성에 반드시 필요한 요소만을 포함해야 한다는 원..

자율주행 기술의 발전은 교통사고 감소와 이동 편의성 향상과 같은 긍정적인 변화를 가져올 수 있지만, AI 기반 시스템의 안전성을 확보하기 위한 엄격한 기준이 필요합니다. 특히, 자율주행차(AV)에 적용되는 AI 기술이 예측할 수 없는 다양한 도로 환경에서도 안전하게 작동하도록 보장하는 것이 중요합니다. 이와 관련하여 SOTIF(Safety of the Intended Functionality)와 ISO/PAS 8800은 AI 기반 자동차 시스템의 안전성을 검증하고 신뢰할 수 있는 표준을 마련하는 중요한 규제 프레임워크입니다. 이번 포스팅에서는 이 두 가지 표준의 역할과 자율주행 시스템의 안전성을 평가하는 방법에 대해 알아보도록 하겠습니다. 1. SOTIF (ISO 21448)란 무엇인가?SOTIF는 기존..

상용차(트럭 & 버스)는 대형 화물과 다수의 승객을 운송하는 중요한 이동 수단으로, 안전성이 최우선으로 고려되어야 합니다. 특히, 자동차 기술이 기계적 제어에서 전자제어를 거쳐 소프트웨어 중심으로 발전함에 따라, 상용차에서도 안전 시스템이 크게 변화하고 있습니다. 이번 포스팅에서는 소프트웨어 정의 차량(SDV, Software Defined Vehicle) 발전 단계를 분석하고, 제어적 안전이 어떻게 향상되는지 살펴보겠습니다. 관련 글 더 보기SDV 시대에 피할 수 없는 기술적 부채와의 동행SDV를 위한 자동차 부품 공급망 변화가 필요하다.Ethernet 기반 차량 네트워크 설계에서 Functional Safety 고려사항 상용차(Commercial Vehicle) 중심의 SDV 전환 전략 수립 시 고려..

소프트웨어 개발에서 성공적인 시스템을 구축하기 위해서는 사용자의 기대(니즈, Needs)를 정확하게 이해하고, 이를 충족할 수 있도록 구체적인 조건(요구사항, Requirements)으로 변환하는 과정이 필수적입니다. 그러나 많은 프로젝트에서 이 과정이 제대로 수행되지 않으면, 최종적으로 사용자의 기대와 다르게 동작하는 소프트웨어가 개발되는 경우가 많습니다. 소프트웨어 니즈와 소프트웨어 요구사항은 밀접한 관계를 가지지만, 개념적으로 명확한 차이를 갖고 있습니다. 소프트웨어 니즈는 사용자가 원하는 바를 반영하는 상위 수준의 개념이며, 소프트웨어 요구사항은 이를 실현하기 위한 구체적이고 검증 가능한 조건을 정의하는 것입니다. 이번 포스팅에서에서는 소프트웨어 니즈와 소프트웨어 요구사항의 의미를 설명하고, 두 ..

소프트웨어 엔지니어로서 우리는 늘 높은 품질의 소프트웨어 개발과 정해진 일정 내에 제품을 출시해야 하는 두 가지 과제를 동시에 해결해야 하는 어려움에 직면합니다. 이상적으로는 충분한 시간을 확보하여 요구사항을 철저히 분석하고, 체계적인 설계를 거쳐 코드 리뷰와 검증을 통해 완성도 높은 소프트웨어를 개발하는 것이 바람직합니다. 그러나 현실에서는 비즈니스 요구 사항에 따라 일정이 단축되는 경우가 많으며, 변경사항도 빈번할 뿐만 아니라, 이에 따라 품질을 확보하는 과정이 축소되거나 간소화되는 경우가 빈번하게 발생합니다. 이러한 일정 압박 속에서 품질을 충분히 확보하지 못한 소프트웨어가 출시되면, 이후 현장에서 문제를 일으키고, 개발자는 긴급한 버그 수정과 패치 작업에 시달리게 됩니다. 이러한 과정이 반복되면서..

자동차 산업은 지금, 기계 중심에서 소프트웨어 중심(Software-Defined Vehicle, SDV) 으로의 대전환을 맞이하고 있습니다. 차량의 성능과 기능을 결정짓는 요소가 엔진과 변속기가 아니라 소프트웨어 업데이트(OTA), 인공지능(AI), 네트워크 연결성 등의 디지털 기술이 되는 시대가 도래한 것입니다.  그러나 새로운 기술과 혁신이 도입될 때마다 반드시 따라오는 그림자가 있습니다. 바로 기술적 부채(Technical Debt)입니다. SDV 전환 과정에서 빠른 시장 대응과 개발 속도를 유지하기 위해 단기적인 해결책이 선택되는 경우가 많고, 이는 필연적으로 기술적 부채를 발생시킵니다. 그러나 기술적 부채를 단순히 코드 품질 저하나 개발 속도의 문제로만 본다면, 그 위험성을 간과하는 것입니다...

"모든 기능을 문제없이 동작하게 해 주세요!!" 언뜻 보면 완벽한 요구사항입니다.모든 기능을 구현해야 하고, 구현하는 모든 기능에 문제가 없어야 합니다.이만큼 완벽한 요구사항이 있을까요? ㅎㅎ 안타깝지만, 이게 최근까지도 현실에서 심심찮게 볼 수 있는 농담같은 진담이었습니다.이번 포스팅에서는 요구사항 작성시 발생하는 일관성과 모호성을 예방하기 위한 방안으로Easy Approach to Requirements Syntax (EARS)에 대해 살펴 보고자 합니다. 관련글 보기ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)명확한 요구사항 작성 (모호성 제거) - 시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Req..

한가지 에피소드를 살펴 볼까요?"프로세스가 없어서 그래!"프로젝트를 진행하면서 필요한 업무가 정의되어 있지 않을 때, 흔히들 "프로세스가 없어서 그래!!" 라고들 합니다. 그래서 프로세스를 정의해야 한다고 하면서 절차와 담당자를 지정하고 산출물을 정의한 프로세스 문서들을 많이 만들어 냅니다. 그런 다음 열심히 설명회를 하거나 교육을 진행하며, 실무자에게 프로세스를 준수 할 것을 요청합니다. 그런데 실무에서는 너무 많은 종류의 산출물로 인해 그리고 짧은 개발일정으로 인해 프로세스가 외면 받기 시작합니다. 또한 그렇게 시간이 흘러 조직이 변경되어 프로세스에 지정된 담당자가 존재하지 않거나, 프로세스 개선이란 이름으로 중간중간 누락된 절차들을 만들어 프로세스가 변화됩니다.  이 에피소드에서는 프로세스를 단순히..

Software-Defined Vehicle(SDV)는 차량의 주요 기능을 소프트웨어로 정의하고 제어하는 자동차 개발 패러다임입니다. 또한 SDV를 설명함에 있어 소프트웨어로 정의된 여러 기능들을 하드웨어 개발과는 별개로 빠르게 개발하고 유지보수와 추가 기능 개발이 하드웨어에 종속되지 말아야 한다는 속성, 즉 하드웨어-소프트웨어 디커플링(HW-SW Decoupling)이 중요한 속성으로 강조됩니다.  이번 포스팅에서는 SDV의 핵심 속성 중 하나인 하드웨어-소프트웨어 디커플링에 대해 좀 더 자세히 알아 보겠습니다. 사실 많은 사람들이 디커플링을 소프트웨어와 하드웨어가 완전히 독립적이다 라고 오해하는 경우가 있는데, 이는 디커플링의 정확한 본질을 잘 알지 못하는데서 비롯된 문제라고 생각됩니다. 이렇게 상당..