내 머리속 지우개

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

임베디드 소프트웨어 아키텍처에도 패턴이 적용될 수 있습니다.이번 포스팅에서는 임베디드 소프트웨어 아키텍처에적용될 수 있는 기본적인 패턴에 대해 알아 보겠습니다.   임베디드 소프트웨어 아키텍처 패턴 개요아키텍처 패턴은 좋은 설계 관행에 대한 추상적이고 스타일화된 설명으로, 시스템 아키텍처의 구조와 적용 시점, 장점 및 단점을 이해하는 데 중요한 정보를 제공합니다. 이러한 패턴은 단순히 일반적인 디자인을 인스턴스화하는 것이 아니라, 특정 아키텍처를 이해하고 이를 기반으로 자신만의 구체적인 설계를 만들기 위한 출발점으로 사용되어야 합니다. 임베디드 소프트웨어와 인터랙티브 소프트웨어의 차이로 인해, 임베디드 시스템에서는 프로세스 중심의 아키텍처 패턴이 사용됩니다. 여기서는 세 가지 일반적으로 사용되는 실시간 ..

소프트웨어 공학 관점에서는 임베디드 소프트웨어를 어떻게 볼 수 있을까요?임베디드 소프트웨어에는 몇가지 특징이 있기 때문에,이를 소프트웨어 공학점 관점에서는 고려해야 할 중요한 요소라 할 수 있습니다.이번 포스팅에서는 소프트웨어 공학 관점에서 임베디드 소프트웨어 모델링에 대해 알아 보겠습니다.      임베디드 소프트웨어 개요오늘날 컴퓨터는 단순한 가정용 기기부터 게임 컨트롤러, 자동차, 비행기, 그리고 대규모 제조 공장까지 다양한 시스템을 제어하는 데 활용됩니다. 이때 컴퓨터는 하드웨어와 직접 상호작용하며, 소프트웨어는 하드웨어에서 발생하는 이벤트에 반응해 적절한 제어 신호를 보내게 됩니다. 이러한 시스템에서 사용하는 소프트웨어를 임베디드 소프트웨어라고 하며, 주로 하드웨어에 내장된 형태로, 읽기 전용 ..

차량 충돌 시 가해지는 충격량에 따라 인명 피해가 매우 커질 수 있어요.이는 차량 안전 메커니즘을 결정하기 위해 중요한 수치인데요.이번 포스팅에서는 차량 충격량을 계산하는 방법과 충격량에 따른 인명 피해 정도를 살펴 보겠습니다.  차량이 가속할 때 발생하는 충격량(impulse)은 인명 피해를 초래할 수 있습니다. 이를 계산하려면 충격량, 충격력, 그리고 충격이 걸리는 시간을 고려해야 합니다. 충격량은 차량의 속도 변화와 질량을 바탕으로 하며, 특히 충돌 시 속도가 급격히 변할 때 인명 피해가 발생할 가능성이 높습니다. 1. 충격량(Impulse)의 정의충격량은 다음과 같이 정의됩니다:여기서,•  I: 충격량 (N·s, 뉴턴 초)•  F: 충격력 (N, 뉴턴)•  t: 충격이 발생하는 시간 (초)•  D..