전체 글(392)
-
복잡한 아키텍처를 단계적으로 설명하는 방법: C4 Model
소프트웨어 아키텍처를 설명하기 위해서는 주로 비지오나 파워포인트를 이용하여 다이어그램을 그린 적이 있습니다. 처음에는 나름 잘 정리했다고 생각했고, 시스템을 구성하는 주요 소프트웨어를 박스로 나누고, 서로 주고받는 인터페이스를 선으로 연결했습니다. 중요한 데이터의 흐름도 표시했고, 필요한 곳에는 어떤 기술을 사용하는지도 적었습니다. 그런데 다양한 보고 라인을 거치면서 누군가는 전체적인 구조가 안 보인다고 이야기 하기도 하고, 어떤 사람은 그림을 보면서 어디까지가 우리가 개발하는 영역이고 어디부터가 외부 시스템인지 잘 모르겠다고 하는 한편, 또 어떤 사람은 특정 기능이 어떤 컴포넌트로 구성되는지를 물었고, 또 다른 사람은 실제로 어떤 ECU에서 실행되는지를 궁금해했습니다. 되돌아 보니, 모든 사람들이 같은..
09:08:57 -
SDV 시대, 차량 진단 - ODX와 OTX에서 SOVD까지, 무엇이 달라지고 무엇을 준비해야 하는가?
차량 진단을 처음 접했을 때 가장 처음 접했던 단어가 UDS였습니다. 진단기로 특정 ECU에 접속하고, Diagnostic Session을 변경하고, DID를 읽거나 DTC를 확인하고, Routine을 실행하는 식입니다. 그리고 조금 더 살펴보다 보면 Security Access와 ECU Programming까지도 접하게 됩니다. 그래서 "차량 진단 = UDS"와 같이 둘을 같은 개념으로 생각하기도 했습니다. 하지만 실제 차량의 진단 환경을 조금 더 넓게 들여다보면 UDS만으로는 설명되지 않는 부분이 많습니다. 예를 들어 진단기는 ECU가 어떤 DID를 제공하는지 알아야 합니다. 해당 DID의 데이터가 2 Byte인지 4 Byte인지, 물리값으로 변환하기 위해 어떤 Scaling을 적용해야 하는지도 알..
2026.09.06 -
시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #3
이전 포스팅에서 이어집니다. [관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Analy..
2026.09.05 -
시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #2
이전 포스팅에서 이어집니다...[관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Anal..
2026.09.01 -
문서상 추적성은 완벽한데, 왜 변경 영향 분석은 안될까?
최근 프로젝트에서 요구사항을 변경을 추적하고 관리하는 업무를 수행하고 있는데요. 거기에선 수시로 많은 요구사항 변경들이 공유됩니다. 그런데 어떤 변경은 처음에는 큰 변경이라 생각지 않았지만, 요구사항 관리 시스템에서 해당 항목을 찾아보니 관련 시스템 요구사항과 소프트웨어 요구사항이 연결되어 있었고, 설계와 시험 항목까지 연결되어 있었습니다.그리고 문서상으로는 별다른 문제도 없어 보였습니다.그런데 변경 영향을 확인하기 위해 관련 담당자들이 모이면 상황이 달라집니다. 이 요구사항이 바뀌면 어느 소프트웨어까지 수정해야 하는지, 연결된 인터페이스에도 영향이 있는지, 기존 시험을 다시 수행해야 하는지 하나씩 확인하기 시작했는데 누구도 전체 범위를 명확하게 설명하지 못했습니다. 결국 각 담당자가 자신의 영역으로 돌..
2026.09.01 -
시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1
[관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 (현재글) 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Analysis- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #2 5. 시스템의 경계를 정한다 - Context Diagram + Initial BDD (Block Definition Diagram) 6. 시스템이 해야 할 일을 찾는다 - Use Case Analysis 7. 같은 기능을 서..
2026.08.29