ASPICE의 문제해결관리 프로세스 준수를 해야할 때 질문이 있는데, 동료검토에 의한 이슈 발견이나, 품질보증 담당자의 감사 활동에 의한 이슈 발견이나, 프로젝트 이슈가 발생해서 문제해결관리를 위해 등록하여 관리하는 업체가 있는데, 이 각 이슈가 발생할 때마다 CCB가 발생해야하는게 일반적이야 일반적이지 않아?
결론부터 말하면:
아닙니다.
문제해결관리(SUP.9)에 등록되는 모든 이슈마다 CCB를 여는 것은 일반적이지 않습니다.
오히려 그렇게 운영하면 프로젝트가 마비됩니다.
먼저 문제해결관리(SUP.9)와 변경요청관리(SUP.10)를 분리해야 함
예를 들어 QA가 감사 중 발견
SWE.3 상세설계서 Trace Link 누락이건 문제(PB, Issue)입니다.
하지만
설계 변경
코드 변경
릴리즈 변경은 아닙니다.
따라서:
Issue 등록
↓
담당자 지정
↓
수정
↓
확인
↓
종결로 끝날 수 있습니다.
CCB 안 열어도 됨.
어떤 경우 CCB가 필요하냐
CCB는 본질적으로:
변경을 승인하는 조직입니다.
즉:
문제
↓
변경 필요
↓
CCB관계입니다.
문제 자체 때문에 열리는 게 아닙니다.
실제 업체들은 보통 어떻게 운영하냐
보통 이슈를 등급으로 나눔.
Level 1
Minor
예:
- 오타
- 링크 누락
- 리뷰 코멘트
처리
담당자 수정
QA 확인
종결CCB 없음
Level 2
Major
예:
- Requirement 수정
- Design 수정
처리
영향분석
PL 승인필요시 CCB
Level 3
Critical
예:
- 고객 요구 변경
- Safety 영향
- 릴리즈 영향
처리
CR
CCB
승인거의 필수
'ASPICE 기본 이론' 카테고리의 다른 글
| 문제해결 프로세스에서 긴급해결 발생 조건 (0) | 2026.05.29 |
|---|---|
| 문제해결 관리의 긴급 해결 프로세스 생략 가능 프로세스, 불가 프로세스 (0) | 2026.05.29 |
| 변경요청관리 프로세스의 흔한 패턴 (feat 형상관리) (0) | 2026.05.29 |
| SYS.4와 SWE.6의 차이 (0) | 2026.05.29 |
| 고객 요구사양서, 승인도 파헤치기1 (0) | 2026.05.20 |