내 머리속 지우개

도메인 요구공학의 주요 목표는 다음과 같습니다.공통성과 가변성을 체계적으로 식별/관리: 이를 통해 제품 라인에서 재사용 가능한 요구사항을 정의하고, 다양한 제품이 요구사항을 공유할 수 있도록 하는 것이 핵심입니다. 이를 통해 제품 라인에서 개발될 예측 가능한 제품의 요구사항을 사전에 정의할 수 있습니다. 그러나 모든 예측 가능 제품의 요구사항을 개발하는 것은 불가능하고, 떄로는 계획되지 않은 제품이 개발되기도 하는 것은 불가피합니다.재사용 가능성 극대화: 여러 제품에서 공통적으로 사용되는 요구사항을 식별하고, 이를 재사용할 수 있는 구조로 만듭니다.가변성 관리: 제품별로 달라지는 요구사항을 효율적으로 관리하여, 각 제품의 특성을 반영할 수 있도록 합니다.도메인 요구공학의 주요 활동으로는:도메인 분석: 특..

소프트웨어 제품 라인(SW Product Line)에서 PL Scoping은 소프트웨어 제품 라인의 전략적 성공을 위한 핵심 과정입니다. PL Scoping은 크게 포트폴리오 스코핑, 도메인 스코핑, 자산 스코핑으로 나뉘며, 각각의 단계는 제품 라인에서 개발할 제품, 기능, 자산 등을 명확하게 정의하고 관리하는 데 중점을 둡니다. 각 스코핑 단계는 상호 연관되며, 전체 소프트웨어 제품 라인의 구조와 계획을 체계적으로 설정하는 역할을 합니다. 범위 설정 (PL Scoping)의 주요 단계는 다음 그림과 같습니다. 전체적인 SPL 프로세스는 별도로 정리해 두었습니다. 참고 부탁해요.  소프트웨어 공학: Software Product Line (SPL)예전에 정리했던 SPL (소프트웨어 제품 라인)에 대해 업..

소프트웨어 개발에서 DRBFM(Design Review Based on Failure Mode)을 수행하기 위해서는 FMEA와 마찬가지로 사전에 철저한 준비가 필요합니다. DRBFM은 설계 변경 사항에 집중하여 해당 변경이 시스템 전체에 미치는 영향을 분석하는 방법론이기 때문에, 이를 효과적으로 수행하려면 다음과 같은 준비 사항과 산출물이 필요합니다. 참고로 SW FMEA 수행을 위한 사전 준비에 대한 내용은 별도로 정리해 두었습니다.  SW FMEA의 Ground RulesSW-FMEA를 시작하기 전에, 그라운드 룰이 무엇인지를 결정할 필요가 있다.어떤것이 맞는것인지 어떤것이 틀린것인지에 대한 원칙은 없지만, SW-FMEA를 수행함에 있어(1) 어떤 고장을 고려할 것인지,(habana4.tistory...

SW FMEA와 유사하지만, 변경에 보다 더 집중하는 DRBFM이란게 있습니다.이미 아시는 분들은 잘 아시겠지만, 방법이나 목적이 FMEA와 아주 유사합니다.이번 포스팅에서는 DRBFM과 FMEA를 비교해 보겠습니다.   DRBFM(Design Review Based on Failure Mode)과 FMEA(Failure Modes and Effects Analysis)는 둘 다 결함이나 잠재적 문제를 사전에 발견하고, 이를 통해 제품이나 시스템의 신뢰성을 높이는 데 목적이 있는 분석 기법입니다. 하지만 이 두 기법은 각각 다른 방식으로 접근하며, 적용 방식과 효과에도 차이가 있습니다. 이번 포스팅에서는 DRBFM과 FMEA의 기본 개념을 설명하고, 소프트웨어 개발에 어떻게 적용될 수 있는지, 그리고 각..

SW FMEA를 수행할 때는 반드시 그라운드 룰(Ground Rule)이 필요합니다.물론, 이에 대한 정확한 원칙과 정답은 없을거 같아요.하지만, 최소한의 기준 정도는 확보하고 있으면 많은 도움이 될거라고 생각합니다.   SW FMEA를 시작하기에 앞서, SW FMEA Ground Rule 정의는 꼭꼭 필요한 사항입니다.SW FMEA의 Ground Rule은 분석의 일관성, 효율성, 명확성을 보장하고, 팀 간 협력과 의사소통을 원활하게 하며, 신뢰성 있는 결과를 도출하는 데 필수적입니다. 또한 Ground Rule은 분석 범위와 평가 기준을 명확히 설정해 체계적인 분석을 가능하게 하고, 리소스를 효율적으로 사용할 수 있도록 돕습니다. 뿐만 아니라, 위험 평가의 일관성을 유지하고, 분석 결과를 문서화하여 ..

SW FMEA는 소프트웨어 품질에 영향을 줄 수 있는 아주 중요한 활동입니다.하지만, SW FMEA를 수행하는데에는 많은 시간과 노력이 필요합니다.이번 포스팅에서는 SW FMEA에서 위험(Risk)를 평가하기 위한 고장 유형을 알아보고, 각 고장 유형별로 위험도를 평가하기 위한 대략적인 가이드를 살펴보고자 합니다.   먼저 SW FMEA는 아래 정의된 고장 유형들에 의해 고장 모드(Failure Mode)가 대부분 결정된다고 볼 수 있지만, 가장 중요한 것은 도메인 특성에 기인하는 기능에 따라 달라 질 수 있다고 생각됩니다. 이는 아래 고장 유형에 따른 위험도 평가가 절대적일 수 없을 뿐만 아니라, 도메인 특성에 따른 기능의 기여도와 기능의 영향(Effect)에 따라 위험도 평가가 달라질 수 있다는 점을..

예전에 정리했던 SPL (소프트웨어 제품 라인)에 대해 업데이트를 해 보려고 합니다.어려운 개념은 아니지만, 적용하기는 쉽지 않은거 같아요.수년동안 노력을 했지만, 정말 어려운거 같은데요.이번 포스팅을 통해 다시 정리도 하고, 마음도 다잡는 기회가 되면 좋겠습니다.   제품 라인 (Product Line)과 소프트웨어 제품 라인(Software Product Line)의 정의"제품 라인(Product Line)"이란 특정 마켓 세그먼트 혹은 미션의 구체적인 니즈를 충족시키고, 특정한 방식에서 핵심 자산의 공통집합을 이용하여 개발된 공통의 피처(Feature) 집합을 공유하는 소프트웨어 집약적인 시스템들의 집합입니다."소프트웨어 제품 라인(Software Product Line)" 이란 플랫폼과 대량의 고..

어떤 제품을 생산할때 그 제품을 생산/조립하는 라인을 구성하고, 양산품을 만들어 냅니다.그리고 이를 기반으로 다른 유사한 제품들을 반복해서 생산하게 되는데요.이를 소프트웨어 Variation (변형, 파생) 이라고 합니다.이번 포스팅에서는 먼저 소프트웨어 Variation에 대해 살펴 보도록 할게요.    목차소프트웨어 Variation : 기존 소프트웨어 Variation 개발 방식소프트웨어 Variant는 기본 코드베이스에서 파생된 다양한 버전의 소프트웨어로, 각기 다른 사용자 요구, 환경 또는 기능에 맞춰 수정된 소프트웨어 변형을 의미합니다. 소프트웨어 개발에서는 고객의 요구나 시장의 특성에 따라 동일한 기능을 공유하면서도 특정한 차이점을 가진 여러 제품이나 버전이 필요할 때가 많습니다. 이때, 소..

소프트웨어를 개발할 때, 문서화는 참 어렵고 시기적으로 적절성을 갖추기가 만만치 않습니다.언제 작성해야 하고, 어떻게 작성해야 하는지... 고민이 참 많이 됩니다.이번 포스팅에서는 소프트웨어 문서화의 중요성과 적절한 작성 시점에 대해 알아 보겠습니다.   소프트웨어 문서화는 모든 소프트웨어 개발의 필수적인 과정입니다. 특히 자동차 제어 소프트웨어의 경우 차량의 안전, 성능, 효율성을 좌우하는 중요한 역할을 하기 때문에, 이를 위한 철저한 문서화는 필수적입니다. 또한, 최근 자동차 산업에서 요구되는 사이버보안, 기능안전, ASPICE(Automotive SPICE) 등과 같은 기준을 충족하기 위해서도 소프트웨어 문서화는 필수적인 요소로 작용합니다. 이번 포스팅에서는 자동차 제어 소프트웨어의 문서화가 소프트..

임베디드 소프트웨어에서 실시간성은 아주 중요한 속성입니다.그래서 이번 포스팅에서는 임베디드 소프트웨어에서의 타이밍 분석에 대해 알아보겠습니다.   임베디드 소프트웨어에서의 타이밍 분석 (Timing Analysis)임베디드 소프트웨어의 정확성은 출력의 정확성뿐만 아니라 출력이 생성된 시점에도 크게 영향을 받습니다. 이는 임베디드 실시간 소프트웨어 개발 과정에서 타이밍 분석이 중요한 활동임을 의미합니다. 타이밍 분석에서는 시스템의 각 프로세스가 얼마나 자주 실행되어야 모든 입력이 적시에 처리되고, 시스템 응답이 제때 생성되는지를 계산합니다. 타이밍 분석의 결과는 각 프로세스가 얼마나 자주 실행되어야 하는지, 그리고 실시간 운영체제에 의해 이러한 프로세스들이 어떻게 스케줄링되어야 하는지를 결정하는 데 사용됩..