미정

실무적으로 자동차 업계의 ASPICE 기반 문제해결관리 절차(PRM/SUP.9)에서 "긴급 해결(Emergency Resolution)" 조건은 보통 다음 수준으로 정의합니다.중요한 것은: "급하다"가 아니라"정상적인 문제해결 절차를 수행하면 사업적/기술적 손실이 발생하는 경우" 를 긴급 해결로 정의하는 것입니다.1. 가장 일반적인 긴급 해결 조건① 고객(OEM) 양산 일정 영향예)고객 릴리즈 D-3SOP 직전PPAP 제출 직전고객 마일스톤 직전문제가 발생예: 고객 제출 바이너리 오류 ..

ASPICE의 문제해결관리 프로세스 준수를 해야할 때 질문이 있는데, 동료검토에 의한 이슈 발견이나, 품질보증 담당자의 감사 활동에 의한 이슈 발견이나, 프로젝트 이슈가 발생해서 문제해결관리를 위해 등록하여 관리하는 업체가 있는데, 이 각 이슈가 발생할 때마다 CCB가 발생해야하는게 일반적이야 일반적이지 않아? 결론부터 말하면: 아닙니다. 문제해결관리(SUP.9)에 등록되는 모든 이슈마다 CCB를 여는 것은 일반적이지 않습니다.오히려 그렇게 운영하면 프로젝트가 마비됩니다. 먼저 문제해결관리(SUP.9)와 변경요청관리(SUP.10)를 분리해야 함예를 들어 QA가 감사 중 발견 ..

ASPICE의 문제해결관리 프로세스에서 긴급 해결 절차를 탈 때, 당장에 생략할 수 있는 프로세스와 생략할 수 없는 프로세스 같은게 있어? ASPICE에서 흔히 오해하는 것이: "긴급 변경(Emergency Change)이면 절차를 생략해도 된다" 가 아닙니다. ASPICE SUP.9(Problem Resolution Management)와 SUP.10(Change Request Management) 관점에서 보면, 긴급 해결 절차는 "순서를 바꿀 수는 있어도, 핵심 통제 활동은 생략할 수 없다" 에 가깝습니다..

형상관리와의 관계실제로 SUP.8과 SUP.10은 거의 붙어 다닙니다.왜냐하면: Baseline↓변경 필요↓CR↓영향분석↓승인↓새 Baseline 이 흐름이기 때문.그래서 실무에서는 SUP.8이 없으면SUP.10도 의미가 약해짐 ..

SWE.6보는 것 Software+MCU 수준SYS.4보는 것 Sensor↓ECU↓Actuator ..

지금 Supplier의 시스템 요구사항 명세서에서 System External interface 부분을 보고 있는데 여기서 커넥터 PIN을 작성했어여기서 커넥터 PIN이 뭐야Supplier의 시스템 요구사항 명세서(SRS) 중 System External Interface(시스템 외부 인터페이스) 섹션에 커넥터 PIN을 작성한 것은 매우 자연스럽고 올바른 접근입니다. 이 부분은 우리 제어기(ECU)가 차량 내부의 다른 제어기, 센서, 전원(배터리)과 물리적·전기적으로 어떻게 연결되는지 명확히 정의하는 곳이기 때문입니다.명세서의 해당 항목을 검토하시거나 작성하실 때, 반드시 확인해야 할 핵심 체크리스트를 정리해 드립니다.📋 External Interface의 PIN 작성 필수 항목핀 맵 (Pinout L..

좋아 이제는 각 산출물의 시기에 대해서 궁금한데, 내가 알기로 승인도는 협력사에서 작성하지만 그 승인도는 고객이 준 요구사항으로부터 나온 것을 반영하는 거잖아? 그러면 내가 보기엔 OEM은 인터페이스 구현까지 반영된 승인도 형태의 고객 요구사양서를 협력사한테 줬을 일을 없을 테고, OEM중에 HKMC같은 경우는 고객 요구사양서 문서로 '고객 SR', '시스템 사양서', '진단 사양서', '사양운영안' 등을 주는 거로 알고 있거든? 이 때 협력사는 승인도를 작성할 떄 고객이 준 요구사양서 문서 중에 어떤 산출물의 어떤 내용을 반영하는 거야? (물론 여기까지 내가 한 내용이 추측으로 말한 거기 때문에 내 가정 자체가 틀렸다면 그것까지 너가 고려해서 고쳐서 말해줘도 돼) 네, 지금 말씀하신 이해 방향이 전체..

혹시 자동차 프로세스에서 승인도가 뭔지 설명해줄 수 있어? OEM과 서플라이어간에 교류하는 고객의 요구사항 문서 중 하나 같긴한데.. 네, 자동차 개발 프로세스에서 말하는 **“승인도”**는 일반적으로 OEM과 협력사(Supplier) 사이에서 주고받는 “고객 승인용 도면(Approval Drawing)” 또는 “승인용 사양서”를 의미합니다.실무에서는 꽤 중요한 문서이고, 단순 참고용 도면이 아니라 **“고객이 이 사양으로 개발/제작해도 된다고 공식 승인하는 기준 문서”**의 성격을 가집니다.자동차 업계에서는 회사마다 조금씩 다르게 부르지만 보통 아래와 같은 표현들이 혼용됩니다.승인도고객 승인도Approval DrawingCustomer Approved Drawing승인 사양서Release Drawing..

ASPICE를 준수하는 프로세스에서 문제해결관리와 변경요청관리 프로세스 간에 연계가 있자나, 즉 내부 문제 식별에서 변경이 필요할 경우 변경요청을 통해 변경요청관리 프로세스를 태우는 것과, 처음부터 고객이 변경 건을 요청해서 바로 변경요청과리 프로세스를 태우는 것이 있자나, 여기서 나는 전자의 경우에 대해서 실무적으로 정말 어떤 산출물을 가지고 어떤 활동들이 이어지는 건지 알고 싶어 맞습니다. ASPICE에서 실무적으로 중요한 포인트가 바로 그 부분입니다.즉:문제해결관리(Problem Resolution Management, SUP.9) 에서 식별된 문제 중제품/산출물/요구사항/설계/테스트 등에 “변경”이 필요하면변경요청관리(Change Request Management, SUP.10 또는 조직 Cha..

형상감사 관련 질문을 할건데, 만약에 시스템 요구사항 명세서 1.2버전에 대해서 특정 베이스라인 긋는 시점일 때, 베이스라인을 그었어. 그 이후에 시스템 요구사항 명세서가 1.3 버전이 되었어 그러면 이 바뀌기 전에 반드시 형상 변경 요청이 되었어야하고, CCB회의도 이루어졌어야 해? ASPICE 프로세스를 만족하기 위해서 말이야 네, ASPICE 관점에서는 일반적으로 베이스라인 이후에 산출물이 변경되었다면, 그 변경은 반드시 형상변경관리(Change Control) 절차를 거쳐야 합니다.즉 질문하신 상황이라면:시스템 요구사항 명세서(SyRS) v1.2를 기준으로 Baseline 설정 완료이후 문서가 v1.3으로 변경됨→ 이 경우에는 원칙적으로:변경 요청(CR/ECR 등) 등록영향도 분석(Impact A..