ASPICE 기본 이론

변경요청관리 프로세스의 흔한 패턴 (feat 형상관리)

아즈마민초 2026. 5. 29. 17:24

 

형상관리와의 관계

실제로 SUP.8과 SUP.10은 거의 붙어 다닙니다.
왜냐하면:

Baseline
↓
변경 필요
↓
CR
↓
영향분석
↓
승인
↓
새 Baseline
 

이 흐름이기 때문.


그래서 실무에서는

SUP.8이 없으면
SUP.10도 의미가 약해짐

 

OEM이 진짜 중요하게 보는 시점

OEM 입장에서 중요한 건

승인된 산출물
 

입니다.

Customer Released Requirement
Approved Design
Released Software
 

등.


이 시점 이후 변경은
거의 반드시

CR
영향분석
승인
 

을 기대합니다.


현실적인 결론

실무적으로 자동차 프로젝트에서는:

Draft 상태의 산출물은 일반 수정 절차로 관리하고,
Baseline 또는 승인된 형상항목이 된 이후의 변경부터는 SUP.10 변경요청관리 프로세스를 적용하는 경우가 가장 일반적입니다.

다만,

고객 변경요청(OEM CR), 법규 변경, 안전 요구사항 변경 등은 Baseline 여부와 관계없이 Change Request로 관리하는 경우가 많습니다.

그래서 심사관이 "변경요청관리 프로세스는 언제부터 적용합니까?"라고 물으면,

승인 및 Baseline된 형상항목에 대한 변경부터 적용하며,
고객 변경요청은 Baseline 여부와 관계없이 관리합니다.
 

라고 답하면 가장 실무적이고 ASPICE적으로도 자연스러운 답변에 가깝습니다.