Category Archives: misc

Pilot Robot의 현실화 — ASK MAGL


곧 지구의 평화는 지켜질 것 같다..

한국 어느 기업에서 세계 최초로 파일럿 로봇을 만들고 있나 보다. 외국에서는 이 영상을 보고 엄청나게 흥분하는 모습들도 보인다. 정말 현실화된다면, 군사용으로 재해구조용으로 엄청난 진보를 가져올 듯 하다. Watch Korea’s mech take its first steps with a pilot on board That real, life-sized mech Korean company Hankook Mirae debuted recently isn’t just for show. Its designer, […]

방법: Pilot Robot의 현실화 — ASK MAGL

Advertisements

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을 명확하게 잡게 되면

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

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

 

 

 

 

측정할 수 없어 보이는 것을 측정하라..


최근에 CNS/ATM분야에서 System에 대한 Validation방법론을 보고 신세계로구나! 하고 감탄을 했다. Verification에서 수행하고자 하는 접근법과는 상이하게 차이가 있는 Validation의 세계에 입문한 느낌이었다.

확연히 Validation관점에서 점검해야 하는 항목들과 점검 기준은 Verification과는 많은 부분 차이가 있었다. 우연히 그런 정보를 획득하게 된 것에 대해서 my precious(그래봤자 유효기간 6개월이나 갈까 모르겠다만)를 외쳤다.

 

본론으로 들어가서, 어디 책에서 본 얘긴데, 관리분야의 한 흐름 중에 모든 것을 측정할 수 있다고 생각하고, 관리되지 않는 이유는 측정하기 않기 때문이라는 신조로 모든 것을 계측하려는 부류가 있다.

첨엔 그러려니…했는데,,,,,,

 

AHP기법으로 의사결정을 할 때, Top objective에 대한 결정을 하기 위해 최종단에서의 unit은 indicator로 되어 있고, 결국 그 indicator라고 하는것이 측량학파(뭔가 적절한 이름이 있을 거 같긴한데, 일단 이상해보여도 대충 적는다)에서 나온 그 컨셉이라는 점이었다.

(AHP와 Validation이 연결되어 있는 것도 신선했는데…)

 

생각보다 indicator에 대한 적용이 광범위하게 이루어져 있다는 사실에 좀 놀랐고, 호기심이 생겼다.. 그저 이론적으로만 들이대는 그런 내용은 아닌거같다.

 

회사에서도 그런 framework을 적용해서 KPI를 아주 우스꽝스럽게 만들기도 한다. 그것도 어쨌거나 적용사례이다.

 

관련 키워드: GQM, Process indicator, ISO 15939

관련 링크:

Practical Software and Systems Measurement

GQM Sample

GQM Paradigm

AHP