Verification review와 Confirmation review

정말 한 100년만에 블로그에 글을 올리는 것 같다.

어느새 겨울이 되었고, 이제 한 달만 있으면 한 살을 더 먹는다. ㅠ

잡담은 여기까지

표제에 있는 것 처럼

자동차 기능안전(Functional safety)에서는 산출물(Work product)의 검증(또는 검토)을 2가지 방법으로 적용하고 있다.

1. Verification

2. Confirmation

ISO 26262 part1의 Vocabulary 을 참고하면 다음과 같이 정의 내릴 수 있다.

2.18 확인 검토 (Confirmation review)

요구되는 독립성 수준을 갖춘 검토자가 작업산출물에 대해 ISO 26262의 요구사항에 부합하는지 확인하는 것

비고1. 확인 검토에 대한 전체 목록은 ISO 26262-2에서 제공한다.

비고2. 확인 검토의 목표는 ISO 26262에 적합함을 보장하는 것이다.

2.138 검증 검토 (Verification)

개발 활동에 대한 결과가 프로젝트 요구사항이나 기술 요구사항 또는 두 가지 모두를 충족한다는 것을 보장하기 위한 검증 활동

비고1. 검증 검토의 개별 요구사항은 ISO 26262의 각 부의 별도 절에 나타나 있다.

비고2. 검증의 목표는 유즈 케이스와 고장형태와 관련하여 아이템이나 엘리먼트의 기술적 정확성과 완결성을 확인하는 것이다.

보기. 기술 검토, 워크스루, 인스펙션

위 정의에서 한글말 번역으로 인해 이해가 쉽지 않을 수도 있겠지만,

결국은 둘다 작업산출물이 요구사항에 맞게끔 작성되었는지 확인한다는 것이다.

그런데 왜 2가지로 분류하였으며, 해당 차이는 무엇일까?

첫 번째로. 검증(또는 검토)하는 작업 산출물에 차이가 있다.

ISO 26262 part2. 표 D.1을 통해 Verification review의 대상 산출물은 다음과 같다.

1. 위험원 분석 및 리스크 평가

2. 안전 목표

3. 기능안전개념

4. 기술안전 요구사항 명세

5. 시스템 설계

6. 하드웨어 안전 요구사항

7. 하드웨어 아키텍처 메트릭 평가와 관련하여 적용된 방법의 결과

8. 소프트웨어 안전 요구사항과 정제된 하드웨어-소프트웨어 인터페이스 요구사항

9. 소프트웨어 아키텍처 설계

10. 소프트웨어 단위 설계 및 구현

11. 소프트웨어 컴포넌트 인정 보고서

12. 하드웨어 컴포넌트 인정 보고서

13. 안전성 분석

휴우 많다. 그리고 참 한글로 해놓으니 더 헷갈린다;;

위 넘버링 처럼 13가지의 산출물만 보면 된다?

아니다. 13가지의 대상물이니 산출물은 그 이상이 될 것이다.

예를 들면 시스템 안정성 분석, 하드웨어 안전성 분석, 소프트웨어 안전성 분석으로 산출물이 나오면 벌써 3가지가 되듯이 말이다.

또한 위의 대상은 최소한이라고 기억하자.

해당 Verification review는 ASIL 레벨에 따라 권장사항 또는 필수사항이 될 수 있다.

이어서 ISO 26262 part2. 표1을 통해 Confirmation review의 대상 산출물은 다음과 같다.

1. 아이템의 위험원 분석 및 리스크 평가

2. 안전 계획

3. 아이템 통합 및 시험 계획

4. 타당성 확인 계획

5. 안전 분석

6. 소프트웨어 도구 기준 평가 보고서 및 소프트웨어 도구에 사용에 대한 인정보고서

7. 캔디데이트의 실증논거(분석, 데이터, 대체)

8. 안전 케이스의 완전성

Verification review의 대상과 겹치는 듯, 아닌 듯 해보이지 않는가?

Verification review에서는 안전 목표, Confirmation review에서는 안전 계획

Verification review에서는 안전성 분석, Confirmation review에서는 안전 분석

동일한 산출물이라면 함께 검증(또는 검토)할 수 있겠지만, 

Confirmation review는 ISO 26262 기능안전 관점에서 그리고 Item수준에서의 적합함을 보장한다고 이해하자.

참고로 여기서 말하는 모든 글은, 블로그 주인장이 이해한 수준에서 작성된 글이다.

반박하는 글은 환영하지만, 욕하지는 말아줬으면 한다.

두 번째로. 검증(또는 검토)하는 사람에 차이가 있다.

Verification review에서는 검증(또는 검토)하는 사람의 독립성을 딱히 말하고 있지 않다.

ISO 26262라는 내용을 제외하고 본다면, 설계자가 작성한 산출물에 대하여 직접 검토할수도 있을 것이다. 혹은 동료에게 검토를 맡길 수 있을 것이다.

Verification review에서는 사람에 대한 차이를 직접적으로 구분하고 있지 않다.

반면에 Confirmation review에서는 ASIL 수준에 따라서 I0 ~ I3로 구분하여야 한다고 말한다.

- : 이 확인 수단에 대한 요구사항과 권장사항 없음

I0 : 확인 수단을 실시하는 것이 좋다. 이때는 다른 사람이 실시해야 한다.

I1: 확인 수단을 다른 사람이 수행해야 한다.

I2: 확인 수단을 다른 팀의 사람, 즉 동일한 직속 상관에게 보고하지 않는 사람이 수행해야 한다.

I3: 확인 수단을 다른 부서나 조직의 사람, 즉 관리, 자원, 발행 권한에 관한 고려된 작업 산출물에 대한 책임을 가지는 부서로부터 독립성이 있는 사람이 수행해야 한다.

세 번째로. 적용하는 시점에 차이가 있다.

Verification review는 언제 하는 것이냐?

그야 작업 산출물이 완료되면 바로 수행한다.

Confirmation review는 언제 하는 것이냐?

그야 작업 산출물이 완료되면 바로 수행할 수도, 아닐 수도 있다.

Confirmation review의 Timing during the safety life cycle을 보면

After completion of the corresponding safety activity

Completion before the release for production

관련된 안전활동 완료 후

생산을 위한 배포 전 완료라고 되어 있다.

Safety activity의 완료 시점을 어떻게 나누냐에 따라

Confirmation review는 달라질 수 있다.

또한 어느 정도로 깊이있게 볼지는 정하기 나름이다.

그리고 ISO 26262에서는 Refine이란 동사를 참 좋아한다.

산출물이 Refine 되면 당연히 Review도 다시 해야 한다.

프로세스를 적용하는 조직에서는 각 회사에 맞게 Verification review와 Confirmation review를

적용하는 시점과 위 내용들을 고려하여 적절히 프로세스를 구축해야 할 것이다.

이상 오랜만에 끝.