Verification 및 Validation관점에서 Safety에 대한 차이


이런 질문을 던지고 싶다.

  • Safety를 Verification 관점에서 본다면 어떻게 평가해야 할까?
  • Safety를 Validation관점에서 본다면 어떻게 평가해야 할까?

 

굳이 평가 행위를 Verification과 Validation으로 나누고 싶지는 않은데, 그냥 생각해보자는 거다.

Scope을 나누기는 하더라도 실제 평가 방법이나 평가 환경은 동일할 수도 있다. (물론 다를 수도 있다..)

Verification을 한다면 Safety function의 의도된 행위의 여부에 중점을 둬야 할 것이다. 즉 ‘의도한 대로의 행동’을 보였는가?

하지만 Validation을 한다면 Safety function의 의도적 동작이 아니라, Safety Attribute의 달성 여부에 중점을 둬야 할 것이다. 즉, ‘충분한 safety가 달성되었는가?’

시스템 개발을 할 때, 고장모드 분석을 해서 발생 가능한 failure mode를 식별해서 plan을 세웠을 것이다. 그것이 operation이 되었건, system의 logic이 되었건…

그때 verification관점에서는 failure mode의 발생으로 인한 의도된 safety function이 구현되었느냐를 확인해야 할 것이다. 예를 들어 Air bag의 경우 박치기 조건에서 펑 튀어 나오냐..

Validation관점에서는 그런 fault injection혹은 non-nominal조건으로 충분한지에 대한 검토가 필요할 것이다. 박치기의 다른 조건을 본다던지, 아니면 펑 튀어 나오는 것의 로직이 타당한지에 대한 것이나, 아니면 그 로직의 malfunction에 대한 고려를 한다던지… 뭐 그런식..

별결 다 따진다고 하는지 모르겠다. 하지만 이게 어디 scope인지를 계속 따져야 나중에 개발 및 검증 범위를 명확히 하는데 도움이 된다.

경험한 사례로 SW수준의 설계를 System 아키텍처라고 한 것이나, System 요구사항을 Sw요구사항이라고 기술된 것을 봤다. 그런 방식으로 했을 때 별일 없을 거라고 생각하면 오산이다.

개발이 안되고 검증이 안된다.

그런 개념이 장착되지 않으면 대충 개발하고 대충 검증하게 되며, 품질도 대충대충된다.

그러면서 어쩔 수 없다고 항변할 것이다.

scope의 모호함으로 생기는 문제이다.

scope을 명확하게 잡게 되면

달성해야 하는 것과 포기해야 하는 것을 명확하게 나눌 수 있다.

반드시 지켜야 하는 것과 지키지 않아도 되는 것을 나눌 수 있다.

 

 

 

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중