실무적으로 변경요청은 어떻게 이루어지는가?

ASPICE를 준수하는 프로세스에서 문제해결관리와 변경요청관리 프로세스 간에 연계가 있자나, 즉 내부 문제 식별에서 변경이 필요할 경우 변경요청을 통해 변경요청관리 프로세스를 태우는 것과, 처음부터 고객이 변경 건을 요청해서 바로 변경요청과리 프로세스를 태우는 것이 있자나, 여기서 나는 전자의 경우에 대해서 실무적으로 정말 어떤 산출물을 가지고 어떤 활동들이 이어지는 건지 알고 싶어

 

 

맞습니다. ASPICE에서 실무적으로 중요한 포인트가 바로 그 부분입니다.
즉:

• 문제해결관리(Problem Resolution Management, SUP.9) 에서 식별된 문제 중
• 제품/산출물/요구사항/설계/테스트 등에 “변경”이 필요하면
• 변경요청관리(Change Request Management, SUP.10 또는 조직 Change Mgmt 프로세스) 로 연계되어
• 공식 변경통제 절차를 타게 됩니다.

그런데 실무에서는 이 흐름이 단순히 “이슈 하나 만들고 끝”이 아니라, 꽤 많은 산출물과 승인 흐름으로 이어집니다.

아래를 “현업에서 실제 굴러가는 수준”으로 설명해볼게요.

---

1. 상황 예시

예를 들어:

• 차량 시동 후 특정 조건에서
• CAN Timeout 발생 시
• Fail-safe 진입이 늦게 발생함

이라는 문제가 테스트 중 발견되었다고 가정해봅시다.

---

2. 문제해결관리 프로세스 시작 (SUP.9)

여기서는 핵심이:

“문제를 식별하고 원인 분석하고 추적 관리하는 것”

입니다.

보통 최초 산출물은:

---

(1) Problem Report / Defect / Issue 등록

도구 예:

• Jira
• Redmine
• Codebeamer Issue Tracker
• Polarion Defect
• ALM 등

생성되는 정보:

 

이게 문제관리의 시작점입니다.

---

3. 초기 분석 활동

여기서 실무적으로 많이 하는 활동:

---

(2) Triage / Screening

보통 CCB 또는 리더급이 판단:

• 진짜 문제 맞는가?
• 중복인가?
• 우선순위는?
• 안전 영향 있는가?
• 즉시 수정 필요한가?

산출물:

• Issue 상태 변경
• Priority 결정
• 담당자 지정

예:

• Assigned to SW Architect
• Severity = Critical

---

4. 원인 분석 (Root Cause Analysis)

이 단계가 SUP.9의 핵심입니다.

실무적으로:

 

 

사용되는 기법:

• 5 Why
• Fishbone
• Fault Tree
• Debug Log
• Trace 분석

산출물:

• RCA 보고 내용
• 영향 분석 초안

---

5. 여기서 “변경 필요” 판단 발생

중요한 포인트입니다.

문제 해결 방법이:

• 단순 운영 조치가 아니라
• 산출물 수정이 필요하면

여기서 변경관리 프로세스로 넘어갑니다.

즉:

6. 변경요청(Change Request) 생성

여기서 별도의 CR(Change Request)가 생성됩니다.

실무적으로는:

• Problem Report와
• Change Request를
• 링크로 연결합니다.

예:

관계

Problem PRB-1023 → CR-204 연결

---

7. 변경요청 산출물 내용

여기서부터는 “변경 통제” 영역입니다.

보통 CR에는:

---

(3) Change Request 문서/티켓

포함 내용:

8. 영향 분석 (Impact Analysis)

이게 ASPICE에서 굉장히 중요합니다.

실무적으로 가장 핵심 문서 중 하나입니다.

---

(4) 영향 분석서

분석 대상:

실무에서 여기서 보는 핵심

① 무엇을 수정해야 하는가?

• 요구사항?
• 설계?
• 코드?
• 테스트?

---

② 무엇을 다시 검증해야 하는가?

• Regression 범위
• Retest 범위
• Safety Re-validation

---

③ 베이스라인 영향 있는가?

이미 Release된 베이스라인이면:

• 형상통제 필요
• 재승인 필요

---

9. CCB(Change Control Board) 승인

영향 분석 후 승인 단계.

여기서 판단:

산출물

• CCB 회의록
• 승인 기록
• 전자결재
• Tool Status 변경

예:

• CR Status = Approved

---

10. 실제 개발 변경 수행

여기서부터 엔지니어링 활동 시작.

실제 수정:

 

11. 검증 및 Regression

변경 후 반드시:

• 영향 범위 검증
• Regression 수행

실무적으로:

12. Closure

마지막으로:

---

(5) Problem Report 종료 조건 확인

문제가:

• 재현 안 됨
• 수정 검증 완료
• 회귀시험 완료

되면:

실제 실무 흐름을 한 줄로 정리하면

SUP.9(문제관리)

문제 발견
→ 문제 등록
→ 원인 분석
→ 수정 필요 판단

↓

SUP.10(변경관리)

변경요청 생성
→ 영향 분석
→ 승인(CCB)
→ 변경 수행
→ 검증/회귀시험
→ 베이스라인 업데이트

입니다.

---

실무에서 중요한 “연계 포인트”

ASPICE 관점에서 진짜 중요하게 보는 건:

---

① 문제 ↔ 변경요청 Traceability

즉:

• “왜 이 변경을 했는가?”
• “어떤 문제 때문에 변경되었는가?”

가 연결되어 있어야 함.

예:

• PRB-1023 ↔ CR-204

---

② 영향 분석 Evidence

ASPICE assessor들이 매우 중요하게 보는 것:

“변경 영향 분석을 정말 했는가?”

입니다.

특히:

• 테스트 영향
• 안전 영향
• 타 기능 영향
• Regression 범위

---

③ 승인 없이 변경 금지

ASPICE/ISO26262 둘 다 중요.

즉:

• 그냥 코드 수정 X
• 공식 승인된 변경이어야 함

---

실무에서 흔한 Tool 흐름

예시:

Problem Report 등록
    ↓
Root Cause Analysis
    ↓
Change Request 생성
    ↓
Impact Analysis 첨부
    ↓
CCB 승인
    ↓
Code Commit
    ↓
Test Result 연결
    ↓
Baseline Update
    ↓
Closure

 

---

마지막으로 아주 중요한 실무 포인트

실무에서는 사실:

• Problem Report와
• Change Request를

완전히 따로 운영하지 않는 회사도 많습니다.

예:

예를 들면 Jira/Redmine에서는:

• Bug Issue 하나 안에
• RCA
• Impact Analysis
• Approval
• Test Result

다 넣어서 운영하기도 합니다.

다만 ASPICE 관점에서는 중요한 게:

• 프로세스 활동이 수행되었는가
• Evidence가 남았는가

이지,
반드시 티켓이 두 개여야 하는 건 아닙니다.