GSN(Goal Structuring Notation) for Safety Case

Safety case를 작성하는 방법은 많다? 아니다 .정확히 말하면 자유롭다. 정해진 것은 없다.

여러 방법 중에 위와 같은 방법도 있다. 이것을 간단하게 공유하고자 한다.

GSN은 그래픽한 표현 방법이다. 아래의 기호들을 사용해서 Safety case를 작성할 수 있다.

출처: Fig. 5.2 Principal elements of the Goal Structuring Notation in The Agile Safety Case published by Springer

일단 위 기호들을 보면 이해할 수 있다시피 Goal은 Safety case에서 "우리의 제품은 안전하다" 라는 최상위 목표로 표현할 수 있다. Safety case에서는 이를 Claim으로 간주할 수 있다.

잠깐 다른 걸 얘기해보자. Safety case는 다음과 같은 구조를 가진다. 

출처: Kelly, T. P., Arguing Safety – A Systematic Approach to Safety Case Management, DPhil Thesis,

Department of Computer Science, University of York, UK, 1998

위 그림에서 Claim을 다음과 같이 정의해 보자.

"the highly automated vehicle is acceptably safe for use on public road."

(결국 안전하다는 Goal이다.)

Argument를 얘기하기 전에 Evidence로 아래와 같이 정의해본다.

"Test result showing 3,000,000 miles of incident-free autonomous driving successful audit against the requirements of standard X state of the art hardware and software employed"

(이해 되시죠? 300마일 동안 사고 없었고, 표준/기준 X에 기반하여 만족한 결과를 보여줬다. 하드웨어, 소프트웨어서 최신의 기술을 고려하였다)

자 그러면 위 그림에서 Argument는 무엇일까? 왜 Evidence로 제시한 결과가 우리의 Claim 즉 제품/서비스(기술)이 안전하다고 할 수 있는지 보여줘야 한다.

즉 Argument가 없이는 불완전한 설명일 수 밖에 없다. 즉 Safety case는 위 3가지의 요소가 잘 어울어져야 한다.

다시 본론으로 돌아가서,

이러한 목표와 관련된 Context를 위해서 식별된 모든 시스템이 필요하고, 우리의 시스템 정의가 필요하다. 이를 Context 기호를 사용할 수 있다.

최상위 Safety case의 목적인 Goal은 여러 하위 Goal들로 나누어질 수 있다. 상세화 된다고 이해하면 된다. 상세화 할 경우에는 우리의 Strategy, Solution에 따라 달라질 수 있다.

즉 상위의 Argument는 하위의 입장에서 Claim 또는 Strategy로 이해할 수 있다.

만약에 현재의 State of the Art로 적용되지 않는 부분이 고려된다면 "Undeveloped Goal"를 사용하면 된다.

예시로 아래와 같이 살펴볼 수 있다. (The agile safety case 참고)

Safety case는 short, simple, familiar words의 룰을 지켜야 한다.

왜냐하면 복잡하게 회원 가입할 때 보이는 법적인 책임을 물지 않으려고 쓰는 글과 같이 적혀서는 우리의 시스템이, 제품, 서비스(기술)이 안전하다는 것을 이해할 수 없기 때문이다.

위 GSN을 통해서 Safety case를 작성하는 것은 이러한 점을 만족시킬 수 있을 것이다.

(그러나 이를 작성하는 이는 매우 어려운 작업일 것이다.)

휴가를 앞두고서 신이나서 여러 글들을 올리고 있다.

육아로부터 조금 자유롭게 되면 더 많은 글들을 올리고, 이 글을 읽는 사람들과 논의하고 싶다.

이상 읽어주셔서 감사합니다.