내 머리속 지우개

시스템 아키텍처 설계는 도출된 요구 사항에 따라 시스템의 동작과 구조적 특성을 정의하는 활동을 의미합니다. 시스템 아키텍처는 시스템 요소들이 해당 운영 환경에서 함께 작동하여 이해관계자의 요구를 충족하도록 보장합니다. 전통적으로 시스템 엔지니어링은 직관적인 도메인별 [예: 항공우주, 방위, 자동차, 소비자 제품 등] 제품 관행을 적용하여 프로세스와 절차에 중점을 두어 왔습니다. 이러한 관행은 뛰어난 문서 작성 기술과 결합하여 설계 구성 정보를 여러 문서로 수동으로 정리합니다. 이 문서들은 시스템 아키텍처 설계를 고유한 조직적 표기법으로 텍스트 설명과 그래픽 도표로 묘사하지만, 형식적인 의미론은 없습니다. 이 문서들은 설계 구성 정보를 동기화하기 위해 수동으로 업데이트되어야 하며, 그 결과 일관성 문제와 ..

시스템 요구 사항 정의 프로세스는 이해관계자가 원하는 기능을 기술적이고 개발자 중심의 관점으로 변환하여 시스템이 이러한 기능을 어떻게 달성할 수 있는지 설명합니다. 시스템 요구 사항은 SoI(System of Interest, 개발 대상 시스템)이 이해관계자의 요구를 충족하기 위해 반드시 충족해야 할 사항을 설명하며, 잘 구성된 텍스트 진술과 지원 모델 또는 다이어그램의 적절한 조합으로 표현됩니다. 시스템 요구 사항은 시스템 엔지니어링에서 다음과 같은 중요한 역할을 합니다:시스템 아키텍처 및 설계 활동의 기초를 형성합니다.시스템 통합 및 검증 활동의 기초를 형성합니다.프로젝트 전반에서 상호작용하는 여러 프로젝트 팀 구성원 간의 의사소통 수단을 제공합니다.시스템 요구 사항 정의 프로세스의 출력물은 시스템 ..

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

내손 중고등학교가 2025년 3월에 개교하기로 했습니다. 그리고 드디어 신입생 모집 및 선발 계획 공고가 나왔네요.  국제 바칼로레아 교육 - 내손 중•고등학교 입학 설명회 (2025년 3월 개교)내년 3월이면 기다리고 기다리던 경기도 의왕시 내손동에 경기도 최초로 중고교 과정 통합 국제 바칼로레아(IB) 프로그램 기반의 "내손 중고등학교"가 개교한다고 합니다. 이에 학교 운영과 학생habana4.tistory.com 2024.10.10일자 업데이트: 내손 고등학교 입학 전형 요강도 나왔습니다. (바로가기)  군포의왕교육지원청 - 공지사항군포의왕교육지원청 - 공지사항 페이지 입니다.goegu.kr:443 내손중학교 지원자격내손중학교는 2025학년도에 신입생 총 88명을 선발한다고 하며, 지원 자격을 살펴..

McKinsey에서 보내오는 아티클 중 전기 트럭에 관한 내용이 있어 정리 해 봅니다.전기 트럭에 대한 가능성과 도전과제가 흥미로운 부분이라고 생각됩니다.(원문 바로가기)   전 세계적으로 전기차 시장이 빠르게 성장하고 있는 가운데, 트럭 산업도 예외는 아닙니다. 특히 배터리 전기 트럭(BEV)은 Zero-Emission 파워트레인으로의 전환을 이끄는 주요 기술로 자리 잡고 있습니다. BEV 트럭은 기존 내연기관 트럭의 탄소 배출 문제를 해결할 수 있는 가장 강력한 솔루션 중 하나로 평가받고 있으며, 그 중심에는 배터리 기술이 있습니다. 배터리는 BEV 트럭의 핵심 부품으로, OEM의 성공을 좌우하는 중요한 요소입니다. 배터리의 기술적 차별화와 빠른 혁신 속도는 OEM이 경쟁에서 앞서 나가는 데 필수적인..

이 포스팅은 "소프트웨어정책연구소"에서 발간하는 "소프트웨어 중심사회 10월호 (vol.124)"의 이슈 내용을 기반으로 작성되었습니다.  2024년 10월호 - SPRie-book 보기 이슈 ISSUE 유럽연합 인공지능법(EU AI Act)의 주요내용 및 시사점 책임 있는 AI를 위한 기업의 노력과 시사점 포토에세이 PHOTO ESSAY 중간-이호준 포커스 FOCUS 디지털 무역 현황 및 이슈 AI 거spri.kr 유럽연합(EU)의 인공지능법(EU AI Act)은 AI 기술의 급속한 발전과 이에 따른 윤리적, 법적, 사회적 문제를 해결하기 위해 만들어진 최초의 포괄적인 규제 법안입니다. 이 법안은 AI 시스템을 위험 수준에 따라 분류하고, 그에 맞는 규제 방식을 적용함으로써 AI 사용에 대한 신뢰성과 ..

소프트웨어 개발에서 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)에 따라 위험도 평가가 달라질 수 있다는 점을..