문제해결 관리의 긴급 해결 프로세스 생략 가능 프로세스, 불가 프로세스

 

ASPICE의 문제해결관리 프로세스에서 긴급 해결 절차를 탈 때, 당장에 생략할 수 있는 프로세스와 생략할 수 없는 프로세스 같은게 있어?

 

ASPICE에서 흔히 오해하는 것이:

"긴급 변경(Emergency Change)이면 절차를 생략해도 된다"

가 아닙니다.

ASPICE SUP.9(Problem Resolution Management)와 SUP.10(Change Request Management) 관점에서 보면,

긴급 해결 절차는 "순서를 바꿀 수는 있어도, 핵심 통제 활동은 생략할 수 없다"

에 가깝습니다.

---

먼저 ASPICE가 진짜 싫어하는 것

예를 들어 양산 차량에서:

고객 차량 운행 중 ECU Reset 발생

 

문제가 발생했다고 가정해보겠습니다.

긴급 대응이라며:

코드 수정
↓
바이너리 배포
↓
끝

 

하면 ASPICE는 매우 싫어합니다.

왜냐하면:

• 왜 수정했는지 모름
• 누가 승인했는지 모름
• 영향 분석 안 함
• 추적 안 됨

상태가 되기 때문입니다.

---

긴급 해결 시 일반적으로 생략 가능한 것

실무적으로는 아래와 같은 것들은 일시적으로 후행 처리하는 경우가 많습니다.

---

1. 상세 원인 분석(Root Cause Analysis)

정상 프로세스

문제 발견
↓
원인 분석
↓
수정

 

긴급 프로세스

문제 발견
↓
임시 수정
↓
고객 대응
↓
사후 Root Cause Analysis

 

가능

---

예)

Reset 발생
↓
Watchdog 관련 임시 보호코드 삽입
↓
차량 배포
↓
사후 Root Cause 분석

 

---

2. 완전한 영향 분석

정상 프로세스

Req
Design
Code
Test
Safety
형상

 

전부 분석

---

긴급 상황

우선 영향 최소 범위만 확인

 

후

사후 정식 영향 분석 수행

 

가능

---

3. 정식 리뷰

정상

Peer Review
Leader Review
Approval

 

---

긴급

구두 승인
메일 승인

 

후

사후 정식 Review

 

가능

---

긴급 상황에서도 생략하면 안 되는 것

이건 중요합니다.

---

1. 문제 등록

생략 불가

예)

Problem Report
Issue Ticket
Redmine
JIRA

 

등록

---

왜?

나중에:

왜 수정했는가?

 

추적해야 함.

---

2. 변경 이력

생략 불가

예)

Emergency Fix
CR-123

 

기록

---

왜?

Source-Binary 추적 필요.

---

3. 최소 승인

생략 불가

ASPICE 입장

누군가는 승인해야 함

 

---

긴급이라도:

PM
품질책임자
기술책임자

 

중 누군가 승인.

---

4. 형상관리

절대 생략 불가

예)

Emergency Release V1.2.1

 

형상 등록

---

이걸 안 하면:

어떤 코드가 고객에게 나갔는지 모름

 

상태.

---

5. 검증

절대 생략 불가

범위는 줄일 수 있음.

예)

정상

Full Regression

 

---

긴급

Impact Area Test
Smoke Test

 

---

하지만

무검증 배포

 

는 ASPICE에서 매우 위험.

자동차 업계에서 흔한 Emergency Process

실제로는:

문제 발견
↓
긴급 문제 등록
↓
긴급 영향 분석(최소)
↓
긴급 승인
↓
수정
↓
필수 검증
↓
고객 배포
↓
사후 Root Cause Analysis
↓
사후 정식 영향 분석
↓
사후 문서 보완

 

형태가 많습니다.