22. 갭분석

 

이제 당신은 DO-178B와 DO-254의 기본적인 특성을 이해하므로 이제는 당신의 조직 내에서 그것들을 어떻게 제대로 구현할지를 고려할 시간이다. 갭분석은 당신의 현재 개발 프로세스를 DO-178/DO-254 요구사항과 비교하고 차이점, 즉 “갭”을 확인하는 활동이다. 갭분석을 이해하기 위해 DO-178B와 당신 조직의 프로세스 사이에 있는 갭에 관해서 이야기를 시작해보자. 적용에 따라서 조직은 여러 가지 갭을 가질 것이다. 당신이 만약 미국의 군에 있다면 아마도 당신은 MIL-STD-498 혹은 MIL-STD-2167A 파생형의 표준을 사용하고 있을 것이다. MIL-STD-498에서 수립되는 대부분의 개발 프로세스들은 DO-178B에 적용되겠지만 당신은 무엇이 적용되지 않고 무엇이 빠지는지를 알고 싶어한다. 갭이 어디에 있는지를 찾고 그것을 채워라. 하지만 우리가 보는 것은 많은 회사들이 갭분석을 어떻게 하는지를 알지 못하는 것은 말할 것도 없고 갭이 어디에 있는지를 알지 못한다는 것이다.

역주) 갭분석은 결국 DO-178과의 갭이 어느 정도인지를 분석해 보는 것이다. 우리 회사가 DO-178 인증을 받으려고 하는데 과연 현재 수준이 어느 정도인가를 체크해 보는 것이라고 할 수 있다. 직접 할 수도 있지만 현실적으로는 전문가인 DER이 수행하는 것이 가장 적절하다고 할 수 있다. 물론 그 만큼의 비용이 드는 부분은 감수해야한다. 역자의 의견으로는 비록 돈과 시간이 좀 들더라도 사전교육 차원에서 갭분석을 먼저 받고나서 DO-178 인증을 본격적으로 진행할 것을 추천한다.

 

 

MIL-STD-498에 대한 갭분석에서 공통 항목은 VDD, 즉 당신의 개선된 Version Description Document이다. 그 용어는 원래 MIL-STD-2167A와 그 전신으로부터 왔다. DO-178B는 Software Configuration Index(SCI)라는 용어를 제공했다. 만약 당신이 Version Description Document를 Software Configuration Index에 비교한다면 완전히 동일하지는 않다. 갭이 있다. VDD는 특별히 소프트웨어 형상과 그것을 어떻게 재빌드하는지에 대해서 말한다. SCI는 그 이상이다. 그것은 당신이 관리하는 베이스라인, 그 베이스라인에 포함되는 문제점 리포트, 무엇이 재빌드되고 시험되었는지와 함께 베이스라인의 일부가 되는 소프트웨어와 문서에 관해서 말한다. 만약 당신이 VDD가 SCI와 완전히 동일하다고 믿는다면 당신은 틀렸다. 하지만 MIL-STD-498에서 소프트웨어 개발 계획의 결과와 결합된 VDD가 그런 질문들에 대해서 답하게 된다.

역주) 갭분석을 하면 당연히 여러 곳에서 차이점을 발견하게 된다. 위의 VDD는 그 중 하나의 예시이다. 그런데 실제 진행해 보면 이렇게 차이점만 있는 것이 아니다. 때로는 기존에 사용하던 문서나 프로세스를 그대로 사용할 수도 있다. 이론적으로는 그 부분의 갭은 ‘0’이 되는 것이다. 갭분석은 결국 이런 식으로 갭이 어느 정도인지를 하나하나 찾아내는 과정이라고 할 수 있다.

 

DO-178B는 모든 데이터가 거기에 있는 한 당신이 그것을 어떻게 묶는지는 신경 쓰지 않는다. 만약 MIL-STD-498 프로세스가 있다면 SCI가 무엇이고 데이터가 어디에 표시되는지에 대한 상호 참조 테이블을 생성하라. 그것은 조금 더 어렵지만 SCI를 작성할 필요는 없다. VDD를 계속 사용해라. 하지만 갭은 무엇인가? 갭분석은 당신을 위해서 그것을 확정하려고 노력한다. 현재의 회사 프로세스에서 DO-178B 혹은 DO-254는 항상 중복을 가진다.

갭분석   당신의 현재 프로세스/활동들과 DO-178B에 대해서 필요한 것들 간의 “갭”을 평가   이전에 DO-178B 히스토리가 없는 경우의 전형적인 갭은? SEI CMM Level 1: 70 ~ 90% SEI CMM Level 2: 50 ~ 75% SEI CMM Level 3: 35 ~ 60% SEI CMM Level 4: 25 ~ 40% SEI CMM Level 5: 20 ~ 35%

 

전형적인 갭에는 DO-178B에 대한 이전 히스토리가 없다. 경험에 의하면 그것이 정확히 100%는 아니라는 것을 알게 되었다. 만약 당신이 레벨 1이라면 아마도 70 ~ 90%의 갭을 가지고 있을 것이다. 생각해보면 100%라고도 할 수 있는 레벨 1인 경우에서 조차도 30%의 중복 – 아마도 코딩 부분인 – 을 가진다는 것이 놀랍다. SEI 레벨 2에서는 50 ~ 70% 갭이다. SEI 레벨 3에서는 좀 내려가서 35 ~ 60% 갭이다. 이러한 조직들에서 원하는 것과 비교할 때 레벨 5에 도달했을 때 조차도 25 ~ 35% 갭을 가질 것이다. DO-178B는 다른 프로세스들이 요구하지 않는 독특한 것들을 원한다.

 

갭분석에서는 DO-178B가 말하는 어떤 사소한 부분도 세밀하게 보아야 한다. 안전성 평가 프로세스를 조사하라. 회사는 그것을 수행하는 것에 대해서 어떻게 처리하고 있는가? 만약 당신이 MIL-STD-498 프로세스에 있다면 일반적으로 항공기의 생존 가능성으로부터가 아닌 임무 안전성 혹은 위험도의 기준으로 수행된 적당한 안전성 분석이 있다. 비록 거기에는 안전성 분석 프로세스가 있지만 수정되고 변경되어야 할 미묘한 차이 – 갭이 있다. 그들은 그것을 명확하게 레벨 A, B, C, D 혹은 E로 평가하는 것 보다는 1, 2 혹은 3의 미션 위험 특성으로 평가한다. 그리고 기억하자. DO-178B와 DO-254는 위험레벨을 정의하는 것을 지원하는 것과 함께 당신의 프로세스가 그것을 달성하는 것을 보장하기 위한 시스템 아키텍처를 반복적으로 개선하기 위해 안전성 평가 프로세스를 사용한다.

 

DO-178B 프로세스의 개요   안전성 평가 프로세스 세 가지 시스템 안전성 평가 프로세스가 있다. Functional Hazard Assessment(FHA), Preliminary System Safety Assessment(PSSA) 그리고 SSA   계획 프로세스 계획 프로세스의 목적은 각 아이템이 의도된 기능을 안전하게 수행할 것을 보장하는 증거를 충분한 양만큼 가진 상태로 기능 및 감항 요구사항들이 하드웨어 아이템으로 변경되는 방법을 정의하는 것이다.   아키텍처 계획 & 개발 안전성이 주어지면, 기능과 성능 요구사항이 시스템 프로세스에 의해서 소프트웨어/하드웨어로 할당된다. 소프트웨어/하드웨어 안전성 평가는 각각의 기능에 대해서 소프트웨어/하드웨어 설계 보증 레벨을 결정하며 사용될 적절한 설계 보증 전략을 결정하는데 기여한다.

 

계획 프로세스를 보자. 다섯 가지 기본 프로세스에 대해서 다섯 개의 기본 계획을 모두 달성하는가? 당신은 아마도 네 가지를 달성하고 다섯 번째인 PSAC은 하지 않을 것이다. 당신은 세 개의 기본 표준을 만드는가? 대부분의 회사들은 요구사항, 설계 그리고 코딩에 대한 어떤 종류의 표준을 가지고 있어서 당신은 이들 표준에 약간의 개선을 하기만 하면 된다. 만약 MIL-STD-498 혹은 영국식의 DEF 표준을 따른다면 PSAC에서 기대되는 대부분의 데이터는 소프트웨어 개발 계획으로 마무리된다.

 

갭분석   요구사항 프로세스 소프트웨어/하드웨어 아이템 요구사항을 구분하고 기록   개념 설계 프로세스 요구사항을 만족하기 위한 설계를 구현하는 경우 발생할 수 있는 잠재적인 요소들을 결정하는데 평가될 수 있는 상위레벨 설계 컨셉을 생산   상세 설계 프로세스 상세 설계에 대한 기초로써 하드웨어 아이템 요구사항과 개념 설계 데이터를 사용

 

요구사항 프로세스를 살펴보고 당신의 체크리스트가 필요한 기준을 만족하는지를 확인하기 위한 평가를 수행하라. 흥미로운 활동은 요구사항이 실제로 모호한지를 결정하는 것이다. 모든 요구사항 문서들, 안전성 평가 요구사항, 설계 코드, 기능 구조 시험, 형상관리 그리고 품질보증을 살펴보라. 우리의 관점에서 갭분석은 무엇이라고 생각하는가? 갭분석을 할 때 DER은 정보를 조사하고 당신이 준수하는지 하지 않는지를 결정한다. 그것은 효과적인 갭분석이고 그 갭을 채우는 것은 아마 당신이 기준을 준수하도록 만들게 될 것이다. “아마”를 쓴 것은 다른 DER은 당신이 준수하지 않고 있다고 말할 수도 있기 때문이다. 물론, ‘모든’ DER은 옳다! 사실, 당신이 만약 당신의 DER로부터 받아들이기 어려운 의견을 받게 되면 유사한 상황을 가졌던 다른 회사의 사례를 요청하는 것을 주저하지 말아라. 그리고 당신은 언제든 다른 DER의 의견을 받을 수 있다.

역주) 무심코 지나칠 수 있는 부분에서 아주 중요한 내용이 나왔다. DER은 항상 옳을까? DER도 사람인데 틀릴 수 있는 게 아닐까? 여기에서는 맞다 혹은 틀리다의 관점보다는 의견이 다를 수 있다는 관점으로 보기 바란다. 당연히 DER도 사람이므로 실수도 할 수 있고 잘못 알고 있을 수도 있다. 다른 회사의 사례나 다른 DER의 의견을 묻는 것도 결국은 판단의 근거를 확인하는 과정으로 볼 수 있다. 혹시 DER과 함께 하게 된다면 무엇이든 물어보기 바란다. 특히 초기에는 귀찮다고 느낄 정도로 많이 물어보기 바란다. 비싼 비용을 들여서 어렵게 시간을 들이는 마당에 그렇게라도 본전(?)을 뽑아야 하지 않겠는가? 다시 한 번 말하지만 DER은 당신의 ‘컨설턴트’로서 온 것이다.

 

일반적으로 당신이 MIL-STD-2167, MIL-STD-498, DEF Stan 55 혹은 56 유형의 회사라면 당신은 거의 SEI 레벨 2와 3 사이일 것이다. 왜냐하면 정부는 당신이 정부와 사업을 하려고 하면 레벨 3이 되어야 할 것이라고 말하기 때문이다. 그럼에도 불구하고 대부분의 레벨 3과 4의 회사들은 그런 정도의 레벨을 준수하는 프로세스를 가지고 있다는 점에 유의하자. 하지만 그들의 실제 구현은 일반적으로 하나 그리고 때로는 두 레벨 아래이다. 다른 말로 하면, 그들은 멋진 프로세스를 가지고 있지만 따르지를 않거나 만약 따른다고 하더라도 그것을 증명할 수 없다. PSAC은 일반적으로 80% 정도의 큰 갭을 가지는데 대부분의 회사들은 PSAC에서 요구하는 정보를 가지고 있지 않기 때문이다. PSAC은 DO-178B를 위해 필요한 독특한 문서이다. 대부분의 다른 표준들 역시 PSAC과 같은 어떤 것도 가지고 있지 않다. 품질보증 계획은 작은 갭을 가지고 있다. 형상관리 계획은 있다고 하더라도 매우 작은 갭이다. 개발 계획은 일반적으로 작은 범위부터 중간 정도까지의 갭이 있다.

 

대부분의 회사들은 DO-178B가 원하는 모든 질문에 답하지 못할 수도 있는 개발 계획을 가지고 있다. 소프트웨어 검증 계획은 당신이 이야기하는 어떤 소프트웨어 검증 계획도 구조적 커버리지 분석 프로세스와 그것을 어떻게 구현하는지를 포함하고 있지 않기 때문에 더 높은, 더 오래된 유형의 갭을 가진다. 일반적으로 대부분의 다른 조직에서는 구조적 커버리지 분석이 DO-178B의 독특한 특성이다. 당신은 거기에서 큰 갭을 발견하게 된다.

인증 갭분석은 무엇을 조사해야 하나?   계획 문서들(PSAC, SCMP, SQAP, SDP, SVP) 다음을 포함하는 개발 및 정확성 프로세스: 안전성 평가 요구사항, 설계, 코드 기능 및 구조 시험 형상관리 및 품질보증 툴인증 체크리스트, 리뷰, 감사 DER 활동들

 

대부분의 회사들은 항공기 기능의 관점에서 안전성 평가를 수행하지 않는다. 구조적 커버리지는 DO-178B에 독특한 것인데 대부분의 상업회사들은 비용에 비해서 이득이 매우 적다고 보기 때문에 수행하지 않는다. DO-178B는 아마도 개발과 검증 프로세스의 일부로써 인증을 요구하는 유일한 표준일 것이다.

 

대부분의 회사들은 체크리스트를 가지고 있지만 DO-178B 관점에서 요구되는 것들은 아니어서 갭이 크다. 또 다른 큰 갭은 DER 교섭인데 그것은 FAA에 대한 독특한 단계이다. 그곳의 누군가가 당신이 준수한다는 것을 말해주지 않으면 당신은 인증받을 수 없다.

 

DO-178B의 지식을 가진 사람은 TBD가 없이 완전한 활동을 수행해야 한다고 분명하게 말한다. 정확성은 TBD가 없다는 의미이다. 우리는 리뷰를 위한 요구사항 문서를 받고 많은 수의 TBD를 발견한 적이 있다. 그것은 받아들일 수 없는 것이다. TBD를 피하기 위해 하는 것들을 보면 그것을 모두 ***로 바꾸거나 괄호를 한 공백을 사용하고 있다. 그것은 먹히지 않는다. 당신은 모든 답을 채워야 하고 그렇지 않으면 리뷰는 끝나지 않는다. 그리고 리뷰가 끝날 때까지 당신은 DO-178B의 전이 기준을 만족할 수 없고 다음 단계로 이동할 수 없다.

역주) 이 글을 보시는 분 중에 TBD를 사용한 적이 있을지 모르겠다. 역자는 DO-178을 접한 이후로 TBD 마니아(?)가 되었다. 여차하면 TBD를 쓰는 것이다. TBD의 효용은 여기서 저자가 이야기하는 설명 이상의 무엇이 있다. 일단 기억할 점은 저자가 이야기한 “***로 바꾸거나 괄호를 한 공백을 사용하는 곳에는 반드시 TBD를 사용하라는 것이다. 무조건 그렇게 사용하시기 바란다. 그렇게 함으로써 적어도 그 부분을 임시방편으로 처리하고 넘어갔다가 잊어버리는 문제는 피할 수 있다. (참고로 이는 역자의 개발스타일(?)이라고 할 수 있다. 다른 더 좋은 방법이 있다면 당연히 그것을 사용하시기 바란다.)

 

어떤 경우에 좋은 답은 당신이 요구사항이 무엇인지, 즉 그것이 10밀리세컨드인지 혹은 100밀리세컨드인지 알지 못한다고 말하는 것이다. 요구사항에 어떤 것을 넣고 이렇게 언급하는 것이다. 예를 들면 50밀리세컨드 요구사항이 임시라고 하는 식이다. 빈칸으로 남겨두지 말아라. 왜냐하면 소프트웨어 엔지니어는 내일까지 그 소프트웨어를 마무리해야 할 지 모르기 때문에 그것을 채울 것이기 때문이다. 그는 무엇이 될 지를 결정하고 그 숫자를 넣는다. 3개월 후 아무도 체크하지 않기 때문에 그 숫자는 여전히 거기에 있다. 이제 그 숫자는 지연시간으로 문제를 일으키고 있지만 아무도 그 부분을 분석하지 않는다. 그 소프트웨어는 잘 날아다니고 있고 관리자는 말한다. “Bobby, 우리는 세 버전만큼 낮은 상태입니다. 괜찮아요.” 엔진 관리 그룹이 “10밀리세컨드가 그 때 당시의 요구사항이었기 때문에 우리는 모든 것을 다시 시험해야 합니다. 그것은 100밀리세컨드였어야 했어요.”라고 말할 때 무슨 일이 생길 지 추측해보자.

 

따라서 TBD는 To 구문만큼 아주 드문 케이스를 제외하고는 거기에 있어서는 안 된다. 따라서 실제 요구사항을 정의하고 나중에 설계 프로세스에서 다시 체크하기 위해 되돌아가는 것을 확인하라. 그것은 당신이 모든 TBD를 해결했는지를 묻는 것이다. 당신이 그것을 한다는 것을 보장하는 좋은 방법은 소프트웨어 변경 요청을 생성하고 그 이슈가 해결될 때까지 그것을 오픈 처리해 두는 것이다. 그것은 당신이 나중에 그것을 잊어버리지 않도록 보장한다.

 

용어가 일관성을 유지하도록 확실히하라. 당신이 하나의 문서에서 “High-level requirement”라는 용어를 사용한다면 다른 곳에서 “conceptual”이라고 말하지 말라. DO-178B와 DO-254는 당신의 프로세스에서 일관성에 관한 것이고 따라서 당신은 문서 용어에 일관성을 가져야 한다. 만약 어떤 것이 하나의 문서에서 “green”이라면 다른 곳에서도 green인 것이 더 낫다. 만약 달러 표시가 특정 변수에 대한 입력이라면 시스템 전체에 결쳐서 모두 그것을 사용하라.

역주) 용어의 일관성은 사소하지만 반드시 명심해야 할 부분이다. 특히 우리말로 대충 비슷하다고 해서 영어로 그렇게 적게 되는 경우가 많은데 DO-178을 수행하는 경우에는 “비슷한 것”은 절대 “같은 것”이 아니다. 명백하게 “다른 것”이라는 점을 명심하자. 습관의 문제이기도 하다. 그렇다면 그런 습관은 DO-178을 시작하면서부터는 완전히 버린다고 생각하기 바란다.

 

추적성은 시스템 레벨 요구사항을 아래쪽의 상위레벨 요구사항으로, 그런 후 하위레벨 하드웨어/소프트웨어 요구사항으로 분명하게 추적하며 코드 및 시험으로부터 위쪽으로 역방향으로 추적한다. 만약 시스템이 시스템 레벨 요구사항을 가지고 있지 않으면 어떻게 될까? 실제 어떤 케이스에서는 한 그룹의 똑똑한 엔지니어들이 그들의 머리에만 존재하는 요구사항을 사용해서 상용 제품(나중에 엄청난 성공을 거둔)을 개발했다. 하지만 DO-178B의 요구 때문에 그 제품은 시스템 요구사항을 얻기 위해서 리버스엔지니어링을 해야 했다. 그것은 설계에 부정적인 영향을 미쳤고 상당한 비용을 들여서 업데이트되어야 했고 시장 출시도 지연되었다.

 

현실은 당신이 이들 요구사항을 실제 상황에서 발견할 것이라는 점이다. 그것들은 당신의 시스템 요구사항에 존재한다. 그럼 그것은 당신이 시스템 통합자 및 시스템 개발자로써 그것을 해야한다는 것을 의미하는 걸까? 당신은 어떤 식으로든 시스템 요구사항을 작성하므로 그것들은 좀 더 개량화할 수 있다. 당신은 가로로 ±12피트, 세로로 ±10피트로 정확도를 정의할 수 있다. 그것이 더 계량화된 것이고 더 정확한 요구사항이다. 시스템이 안전필수의 조종사 동작에 40밀리세컨드 이내에, 비안전필수의 조종사 동작에 100밀리세컨드 이내에 반응할 수 있다. 우리는 이것을 두 개의 요구사항으로 분해한다. 만약 내가 시스템 스펙을 재작성하고 있다면 내가 분해하고 있는 것인가? 누군가 작성이 부족했거나 분명하지 않은 요구사항을 작성했기 때문에 내가 시스템 스펙을 재작성하는 것일 뿐이다.

 

현실에서 자주 일어나는 것은 고객이 기본적인 기능들을 정의하고 당신의 영업팀이 그것들을 더 설명하는 것이다. 당신은 구동 컨셉 문서 혹은 구매 스펙을 얻은 후에야 시스템 스펙을 얻게 되거나 혹은 당신이 직접 그것을 작성해야 할 것이다. 운영체제에 대한 시스템 스펙을 작성하는 것은 굉장히 난해한 일이지만 당신은 제대로 된 시스템 스펙이 될 때까지 반복에 반복을 거듭한다.

역주) 현실적으로 고객으로부터 요구사항을 제대로 받는 것은 상당히 어렵다. 특히 DO-178이 요구하는 수준과 내용으로는 거의 불가능에 가깝다. 애초에 인증을 목표로 같이 참여해서 처음부터 진행해도 가능할 지 모르겠다. 그럼 결국 현실에서는 개발자가 고객 요구사항 즉, 시스템 요구사항을 추가해서 혹은 변경해서 작성하게 된다. 위의 내용은 그에 대한 설명이다.

 

시험을 할 수 없는 요구사항을 고려하자. DO-178B는 강건성을 가진 소프트웨어를 요구하는데 예를 들면, 스트레스 상황을 서서히 감소시키는 것이다. 이것은 10초를 기다리고 당신이 종료하기 전에 경고를 제공한 후 재시작하고 백업 시스템이 인수받을 수 있도록 하는 것을 의미할 수 있다. 그것이 적절한 하나의 정의이다.

 

DO-178은 소프트웨어가 현대적인 프로그래밍 기법에 따라서 개발되기를 요구한다. ‘현대적인’이라는 것이 무엇일까?

 

“소프트웨어는 모든 동작 모드하에서 필요한 프로세싱을 제공한다.”라는 요구사항을 보자. ‘모드’가 무엇인가? 내가 그런 ’모드’를 구성하는가? ‘필요한 프로세싱’이란 무엇인가? 디스플레이 시스템에서 우리는 VMC 모드, IFR 모드, 결합모드, 네비게이션 모드 그리고 조이스틱 모드를 가지고 있다. 이것들은 요구사항과 구현에 의해서 어느 정도 커버되는 것일까?

 

컴퓨터 메모리 사용은 향후에 늘어날 것에 대비해서 최소화될 것이다. 이것은 또한 “소프트웨어는 사용하기 쉬울 것이다.”라고 정의될 수 있다. 당신은 모든 요구사항 문서에서 혹은 지금까지 받은 고객의 스펙에서 이것을 보아왔다. 고객은 대부분의 시간을 소프트웨어가 아닌 시스템만 다룬다.

 

문제는 충분한(sufficient), 모듈식의(modular), 성취(achievement), 적절한(adequate), 능숙한(proficient), 달성된(accomplished), 가능한(possible), 더 나은(better), 더 높은(higher) 혹은 더 느린(slower)와 같은 계량화할 수 없는 단어에 있다. 그것들은 수많은 사람들에게 수많은 의미를 가진다. 그것은 엔지니어링이 아니다. 우리는 일관성, 정확성 그리고 정밀함을 원한다.

 

어디에서 당황하게 될까? 만약 그것이 요구사항이라면 왜 그것이 목표가 되는걸까? 그것은 일관성의 문제이다. 요구사항은 당신이 이것을 할 것이라는, 반드시 수행되어야 한다는 것을 의미한다. 그것은 목표가 아니다. 목표는 당신이 그것을 달성하기를 ‘원한다’는 의미이다. 그것은 요구사항이 되어서는 안되며 “충분히(sufficiently)”가 정확하게 무엇인지 모른다는 점에서 당황하게 된다. 당신은 “충분히(sufficiently)”를 계량화할 수 없다. 만약 요구사항과 시스템 스펙이 있다면 요구사항을 이런 식으로 작성하라. 불분명한 요구사항을 제거하고 제대로 된 것들을 상세화하라.

역주) 개발자들에게는 코딩보다 문서화가 더 어렵다. DO-178은 특히 더 그렇다. 더구나 영어로 적어야 된다. 여기에서의 저자의 설명을 한글로 번역해 두긴 했지만 단어의 뉘앙스라는 것을 함께 이해하면서 파악해야 할 부분이어서 번역으로 커버하기 힘든 부분이 있다. 역자의 경험으로 이 부분에 대해서 결론적으로 이야기하자면 결국 많이 작성해 보면서 연습하는 방법밖에 없다는 생각이다. 머리로 아무리 잘 알고 있더라도 실제 작성을 해 봐야 어려운 부분이 어디인지, 내가 무엇을 모르는지 파악할 수 있다.

 

만약 당신이 하위레벨 지식을 가지고 있다면 설계 상세가 조금씩 나타나고 당신은 그것들을 요구사항이라고 부른다. 다음으로 당신은 상세 요구사항을 요청받을 것이다. 만약 모든 설계 상세가 준비된다면 누군가 당신에게 상세 요구사항을 생성할 것을 요청할 것이다. 그러면 당신은 다음으로 무엇을 하는가? 상세 요구사항에 대해서 코드를 작성하고, 특별히 그것이 당신의 요구사항이 되기 때문에 코드의 모든 라인에 대한 시험을 작성한다. 그것은 굉장히 난해한 일이 된다.

 

만약 당신이 시스템 스펙 혹은 상위레벨 요구사항에 대한 모든 상세사항을 가지고 있다면 거기에서 멈추어라. 누군가 “당신의 상세 요구사항은 어디에 있나요?”라고 물으면 “이것들이 제 상세 요구사항입니다.”라고 말하라. 그것은 정당화된다. 당신은 그것으로부터 코딩을 할 수 있다.

 

데이터 플로우(Data flow) 불일치. 소프트웨어 개발 데이터 플로우 다이어그램은 소프트웨어 요구사항 스펙을 작성하는 방법이었던 때가 있었다. 데이터 플로우 다이어그램을 중심으로 작성하고 무엇이 발생하는지를 기술할 수 있다. 그런 다음 어떤 사람들은 데이터 플로우상의 이름을 변경하거나 특정 데이터 플로우가 다른 곳으로 갔다는 것을 말하기 위한 다른 지시자를 사용기도 한다. 항상 특정해서 사용함으로써 이러한 불일치를 피하라.

 

주어진 입력으로부터 파생되지 않은 출력을 가지려고 함. 만약 당신이 나쁜 요구사항을 작성한다면 당신은 그에 따른 결과를 얻게 되거나 혹은 더 나빠질 것이다. 모든 시나리오가 구분되고 그려지는 것이 아니다. 우리는 당신이 시나리오를 생각해 내도록 강요한다는 점에서 UML 유스케이스(Use Case)를 좋아한다. 그것은 요구사항을 이끌어 내는 좋은 방법이다. 사람들은 유스케이스를 요구사항의 작성으로 사용하기를 원하지만 그것은 답변을 유도하는 방법이라는 점에서 문제가 있다. 당신은 유스케이스로부터 추출해야 하며 그것들을 요구사항으로써 설계해야 한다. 엔지니어들은 그들이 잘 알고 있는 에러는 구체화하지 않는다. 당신은 시스템을 완벽하게 잘 이해하는 엔지니어가 요구사항을 작성하도록 해서는 안된다. 만약 그가 시스템을 완전하게 이해한다면 그는 자신이 많은 것을 알고 있다고 가정하면서 명세화를 통한 기록을 하지 않기 때문에 요구사항을 작성하거나 상세화하는 작업을 제대로 하지 못할 것이다. 그것은 당신이 생각했던 것과는 반대되는 것이다. 그들은 다른 사람들 역시 그것을 잘 알 것이라고 가정하고 다른 사람들의 마음속에서 가정을 없애기 위해 필요한 약간의 세부사항을 작성하지 않고 아무렇지 않게 넘겨버린다.

 

엔지니어들은 일반적으로 자신들이 알고 이해하는 영역만 구체화한다. 미팅에서 물어보라. “이것을 아시나요?” 그럼 모든 사람이 대답한다. “그럼요.” 하지만 질문을 시작하게 되면 때로는 그 반대가 진실이다. 우리는 이런 상황에서의 요구사항 명세를 보아왔다. 요구사항을 작성하는 사람은 그런 것에 관해서 많이 알지 못하고 따라서 그는 어떤 일반적인 명세를 작성한다.(그리고는 자신의 일을 계속한다) 따라서 이런 상황을 조심해라. 당신은 모든 요구사항이 일관성을 가지고 완벽하게 작성되는 것을 보장할 철저한 요구사항 작성의 표준, 프로세스 그리고 체크리스트가 정말로 필요하다.

역주) DO-178에서 요구사항 작성은 상당히 어렵다. 더구나 영어로 작성해야 한다. 개발자들이 개발 과정에서 만들어 내는 문서들과는 비교할 수 없이 어려운 게 사실이다. 하지만 인증을 받으려면 그 어려운 과정을 거칠 수 밖에 없다. 그런데 다른 곳에서 하던 식으로는 곤란하다. DO-178의 기준에 맞는 완전히 새로운 방법으로 작성해야 한다. 위에서 저자가 설명하는 것은 결국 그 부분을 말하는 것이다. 개발자들이 관성대로 작성하는 방식은 DO-178에서는 통하지 않는다는 말이다. 그리고 당연히 그 부분에서 DER과 같은 전문가의 도움이 필요하다.

 

요구사항은 개발에 대한 기반이다. 만약 자신이 하고 있는 것을 제대로 아는 요구사항 작성자나 시스템 엔지니어를 발견한다면 그들에게 돈을 더 많이 주어라. 시스템 요구사항을 작성하는 사람의 숫자를 줄여라. 소프트웨어 라이프사이클로 내려가는 모호성과 다른 에러들을 저지르는 많은 수의 사람보다는 더 적지만 제대로 하는 사람을 가지는 것이 낫다. 실제로 요구사항은 당신의 기반이며 당신의 성공은 그 위에서 달성된다.

 

주기적으로 당신의 요구사항을 다듬어라. 요구사항 명세를 잡고서 몇 분만에 문서를 리뷰하고는 “품질보증 담당자와 제가 그 문서를 리뷰했고 모든 요구사항은 유효합니다.”라고 말하는 것은 DO-178B의 관점에서는 만족스러운 것이 아니다. 그것은 사실상 항공기에 탑재될 수 없다.

 

요구사항이 리뷰될 필요가 있다. 스펙이 아니다. 스펙의 리뷰가 아닌 리뷰의 증거가 있어야 한다. 거기에는 차이가 있다. 요구사항을 자주 다듬어라. 당신이 그런 개선을 할 수 있고 요구사항에 대한 리뷰를 추적할 수 있기 때문에 툴을 사용하는 것이 낫다.

 

만약 당신이 SRS 문서의 프로세스를 사용하면서 매우 자주 손을 대게 되면 그 문서는 아마도 영원히 업데이트되고 또 업데이트될 것이다. 그것은 너무 많은 노력을 낭비하는 서류작업일 뿐이다.

 

대부분의 소프트웨어 결함은 부족한 요구사항 때문이다. 우리는 15년동안 그것을 보아왔다. 교육 분야에서 소프트웨어의 최고 전문가들이 써온 모든 책에서 그것을 말한다. 지금 이 시점까지도 모든 연구는 그 문제가 해결되지 않았다고 말한다. DO-178B는 당신이 그것을 해결하기를 원한다.

 

소프트웨어 개발 매니저로서 우리가 즐겨하는 질문은 갓 졸업한 지원자에게 “소프트웨어 설계가 무엇인가?”라고 묻는 것이다. 그들이 이야기하는 첫 번째가 코드 – C++, 프로그래밍 – 에 관한 것이라면 그 사람은 채용하지 말아라. 그것은 소프트웨어 설계가 아니다. 그것은 프로그래밍이고 소프트웨어 엔지니어들은 그 두 개를 혼돈한다. 프로그래밍은 해머를 어떻게 사용하는지를 배우는 것이고 반면 설계는 어떤 해머가 사용되는지를 아는 것이다. 소프트웨어 설계는 그것이 실제로 어떻게 상호동작 하는지를 표현한다.

 

요구사항은 추적하기 쉽다. 요구사항 vs 설계는 무엇(what) vs 어떻게(how)와 같다. 그것이 우리가 가르치는 것이다. 코드를 작성하는 사람에 따라서, 당신이 사용하는 소프트웨어 언어에 따라서 자신만의 요구사항을 가지게 되기 때문에 요구사항은 모호해지게 된다. 따라서 폭포수 모델에서 당신이 단계를 넘어가다 보면 “요구사항”이라는 단어는 모호하게 되지만 일반적으로 우리는 하나의 요구사항을 “어떻게”에 대응하는 “무엇을”이라고 부른다.

역주) 특별히 이 부분은 저자를 통해서 직접 확인한 내용이 있다. 위의 번역은 그것을 기준으로 나름대로 의역한 부분인데 뭔가 저자의 의도가 확실하게 드러나지는 못하는 것 같다. 참고를 위해서 저자가 답변한 내용을 그대로 소개한다.   Yes, we say the requirement is “blurred out” because as we evolve toward external I/O, then internal I/O then control flow, we get further away from the requirement. So we need to always keep traceability to ensure we don’t get blurred.   -       August 8, 2018 from Vance Hilderman

 

개발 프로세스가 폭포수로 내려가면서 당신은 DO-178B가 찾고 있는 부분들을 정의한다. 당신은 마침내 코딩과 통합을 하면서 소스코드 레벨에 도달하게 된다. FAA는 어떤 언어가 사용되든 신경쓰지 않는다. (하지만 Ada, C 그리고 C++을 추천한다) 만약 당신이 C++로 작업한다면 FAA는 C++과 Ada가 동적이기 때문에 엄청난 양의 지침을 제공한다. Ada에서 런타임커널은 동적인 특성을 가지고 있고 DO-178B는 당신이 결정론적이 되기를 요구한다는 점을 상기하자. 당신은 둘 다를 가지고 갈 수는 없다.

 

결정론은 동적 할당, 동적 스택 그리고 동적 힙의 반대되는 개념이다. 그것은 하나의 프린터가 어딘가에서 대기하고 있기 때문에 코드와 런타임커널이 결정을 내리거나 인터럽트를 발생하거나 혹은 프로세스를 지연시키도록 만드는 것이다. 당신은 이것을 매우 조심스럽게 다룬다. 어떤 언어로도 코딩하는 것이 허용되더라도 이것은 알고 가자. 당신이 잘못된 길로 갈 수 없기 때문에 우리는 여전히 어셈블리 언어를 좋아한다. 그 코드는 하위레벨 요구사항을 따라야 한다.

 

이 프로세스를 벗어나면 당신은 소스코드와 실행 오브젝트코드를 얻는다. 소스코드가 설계 혹은 상위레벨 혹은 하위레벨 요구사항에 기술된 대로 따른다고 말할 수 있는 리뷰가 있어야만 한다.

 

표준을 준수한다는 것은 코드가 당신의 설계와 코딩 표준을 준수한다는 것을 확인하는 리뷰를 의미한다. 당신이 실제로 리뷰를 했다는 것에 대한 체크리스트상의 증거 – 뒤에 남은 빵조각 – 가 있어야 한다.

역주) 저자가 하고 싶은 이야기들이 두서없이 기술되어 있는 느낌이다. 결국 저자가 하고 싶은 이야기는 아래와 같이 정리할 수 있을 듯하다.   1.     요구사항은 계속해서 개선해 나가면서 작성해야 한다. 2.     요구사항의 구현인 소스코드 작성은 어떤 언어를 사용하든 관계없지만 중요한 것은 요구사항과의 추적성을 가지고 있어야 한다. 3.     요구사항부터 설계, 소스코드에 이르기까지 각 단계에서의 리뷰가 반드시 진행되어야 하며 증빙을 남겨야 한다. 4.     소스코드에 동적(Dynamic)인 부분이 있을 경우 주의해야 한다. 기본적으로 요구사항은 모호함이 있어서는 안되는데 동적인 것은 그와는 반대되는 개념이므로 이에 대한 정의와 구현에 유의해야 한다.   4번의 동적인 부분은 가급적 사용하지 않는 것이 좋다. 대신 사용해야 한다면 모호함을 제거할 수 있는 완벽한 증빙이 필요하다. 그 부분이 어렵기 때문에 DO-178에서는 가능하면 동적인 요소는 배제하는 경향이 있다.

 

하위레벨 요구사항으로의 추적성: 코드가 생성되기 전에 당신은 무엇을 추적하는가? 요구되는 모든 것은 당신이 적합성 리뷰(Conformity Review)를 할 때 프로젝트의 마지막 단계에서 추적성이 존재하는 것이다. 하지만 추적성 매트릭스는 사실 당신이 추적을 할 수 있다는 것을 측정하는 것을 보증하는 하나의 툴이다. 훌륭한 개발 관행을 보여주는 소프트웨어 엔지니어는 프로젝트의 착수에서부터 각각의 단계를 거치면서 완전한 추적성을 만들어 낸다. 그러한 추적성은 하나의 관리툴이기 때문에 항상 추적성을 유지하게 된다. 그것은 커버리지 보장과 측정 관리에 좋을 뿐만 아니라 DO-178B가 요구하는 하나의 단계로부터 다음으로 넘어가는 데 있어서 적절한 라이프사이클 전이에도 도움을 준다.

 

하나의 전이 포인트는 설계로부터 코드로 넘어가는 것이다. 이 단계에서 당신은 표준, 리뷰 그리고 추적성 리뷰를 가져야 한다. 이것들이 DO-178B 가이드라인의 Appendix A에서 발견되는 코딩단계의 objective이다. 당신은 정확성과 일관성을 어떻게 결정하는지를 어딘가에 명시한다. 그리고 절대적으로 당신은 코드에 대한 동료검토 동안에 추적성을 가져야만 한다. 왜냐하면 리뷰어는 코드가 추적성을 가진 그 요구사항을 구현했고, 한편으로는 오로지 그러한 요구사항만 구현했다는 것을 보장하기 위해 추적성을 사용해야 하기 때문이다.

 

그것이 표준 개발 라이프사이클이다. 한 회사가 전체 라이프사이클을 나선형 모델을 통해서 표현하는데 그 표현은 제대로 될 때까지 반복을 계속하는 기본적인 폭포수 모델이다. 계획은 이미 수행되었기 때문에 제외되지만 요구사항, 설계 그리고 코딩을 수행한다. DO-178B는 본래 그런 소프트웨어 방법론을 배제하지 않는다. 수행하는 사람들에게는 그들이 유의하는 한 불충분한 부분도 거의 허용한다. 하지만 다시 말하지만 적합성 리뷰에서는 산출물이 있어야 한다.

 

베이스라인을 생성할 때마다 DER은 정의된 프로세스를 따랐는지에 대한 증거를 찾는다. 만약 당신이 코드를 변경하게 되면 그는 코드, 요구사항 그리고 시험 케이스에 대한 리뷰를 매번 변경할 때마다 다시 보기를 원한다. DO-178B 프로세스는 그런 방식을 원하고 그렇게 작성되어 있기 때문에 당신은 그 끝에서 단 한 번 증거를 보여주어야 한다. 하지만 그것은 QA 그리고 적극적인 DER이 그것을 확인하기 위해 감사를 할 것이기 때문에 모든 과정에서 존재해야 한다.

역주) DO-178 인증을 어떤 정해진 방법론의 하나로 인식하는 경향이 있는 것 같다. 물론 그렇게 볼 여지가 많은 게 사실이지만 제대로 이해하고 나면 오히려 일반론을 이야기 한다는 것을 알게 된다. 오히려 중요한 것은 어떤 방법론을 사용하든 그것을 수행한 후 증빙을 남기는 것이다. 쉽게 말해서 말로만 했다고 하면 안된다는 것이다. 한국에서는 내가 했다면 한 것이고 내가 안다고 하면 아는 것이 되는 경우가 많다. DO-178에서는 그런 게 통하지 않는다. 내가 아무리 완벽하게 진행하고 알고 있더라도 그것을 증명할 증빙이 없다면 그것은 안 했거나 전혀 모르는 것으로 판정하게 된다.

 

아래의 테이블은 기본적인 소프트웨어 라이프사이클 활동에 대해서 “훌륭한” 항공전자 개발 조직(SEI CMMI Level 3을 수행하는)과 DO-178B에 의해서 요구되는 것들 사이의 전형적인 갭을 보여준다. 품질보증, 형상관리 그리고 소프트웨어 개발은 전형적으로 더 작은 갭을 가지는 반면에 DO-178B에 특화된 활동들은 상대적으로 더 큰 갭을 가지고 있다는 점에 유의하자.

 

인증 활동	갭 %
PSAC	80%
품질보증 계획	20 ~ 30%
형상관리 계획	10 ~ 20%
개발 계획	40 ~ 50%
소프트웨어 검증 계획	60 ~ 70%
안전성 평가	80 ~ 90%
요구사항 정의	20 ~ 30%
설계	10 ~ 15%
코딩	5 ~ 10%
기능 시험	5 ~ 10%
구조적 커버리지 시험	90 ~ 100%
형상관리	10 ~ 30%
품질보증	50%
툴인증	100%
체크리스트	30 ~ 50%
리뷰	30 ~ 50%
감사	30 ~ 50%
DER 교섭	100%

 

역주) 위의 표에서 DO-178에 특화된 활동으로는 PSAC, 구조적 커버리지 시험, 툴인증, DER 교섭을 들 수 있다. 지금까지 개발하면서 못 보던 것들이라고 생각하면 된다. DO-178 인증을 위해서는 필요하지만 다른 인증에서는 전혀 사용하지 않는 개념일 수도 있다. 하지만 적어도 우리나라에서는 군용 항공전자 소프트웨어 개발에 대해서 방사청에서 DO-178 인증을 상당부분 준용하고 있기 때문에 그 활용성이 높아지고 있는 것이 사실이다.