미정

실무적으로 자동차 업계의 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 ..