잡談/DO-178 번역
-
20. DO-254(하드웨어)잡談/DO-178 번역 2019. 3. 18. 15:41
역주) DO-254에 들어가기 전에 먼저 언급할 부분이 있다. 솔직히 역자가 DO-254와 관련된 하드웨어 분야에 대해서는 잘 알지 못한다. 그럼에도 이렇게 번역을 하는 것은 DO-254가 DO-178과 유사한 부분이 많기 때문이다. 실제로 DO-254 가이드라인은 DO-178을 기반으로 만들어졌다. 또한 DO-254에서 말하는 하드웨어라는 것은 사실 소프트웨어의 성격을 많이 가지고 있는 FPGA와 같은 것을 말한다.(일반적으로 생각하는 딱딱한 부품, 장비와 같은 그런 하드웨어가 아니다.) 무엇보다도 현재 저자가 설명하고 있는 부분은 하드웨어의 기술적인 부분보다는 인증을 받기 위한 프로세스를 중심으로 설명하는 수준이어서 비록 일부 부족한 부분이 있겠지만 DO-254에 대한 이해를 하는 데에는 도움을 드릴..
-
19. 시험 그리고 툴잡談/DO-178 번역 2019. 3. 18. 15:32
만약 우리가 예를 들어서, Motorola 68332 혹은 power PC에 대해서 크로스 컴파일한다면 PC상에서 모든 것을 시험할 수 있을까? 아니, 그럴 수 없다. 사실 당신은 심지어 레벨 D에 대해서조차도 모든 것을 실제 타겟 바이너리로 시험해야 한다. 하지만 PC 혹은 시뮬레이터상에서 바이너리를 시험하는 것은 만약 프로세싱이나 출력이 하드웨어와 관련된다면 유효하지 않다. 그래서 만약 그것이 타이밍 관련, 비트 관련, 스택 관련, BSP 혹은 운영체제 관련된 출력 혹은 독립적인 IO라면 우리는 실제 하드웨어상에서 시험해야 한다. 하지만 우리에겐 하나의 작은 경품이 주어진다. 알고리즘, 로직 결정 그리고 예외 처리에 대해서는 타겟 플랫폼의 결과와 시험 플랫폼이 동등하다는 것을 보여주는 한 하드웨어상에..
-
18. 구조적 커버리지 분석잡談/DO-178 번역 2019. 3. 18. 15:28
구조적 커버리지 분석은 광범위한 요구사항 시험을 포함해서 검증이 모든 objective를 만족하는 정도를 다룬다. 그것은 또한 코드, 코딩 작성자 그리고 시험자에 관한 어떤 특성을 구분한다. 코딩 과정에서의 Dead Code와 같은 것을 발견하는 특성도 있다. Dead Code는 어떤 것이 시험되든 코드의 어떤 부분도 얻을 수 없기 때문에 명확하다. 그것이 작성되었기 때문에 아마도 한번은 사용되었겠지만 그것에 관한 수정이 발생하면 더 이상 필요없게 되고 사용되지도 않는다는 것을 당신은 깨닫게 된다. 더 많은 기능들이 소프트웨어 일부로 불필요하게 추가되었고 따라서 그것은 이런 방식으로 구분된다. 구조적 커버리지 시험 – 1 소프트웨어 에러에 대한 최종 방어 지금껏 나온 것들 중에 가장 지루하고 비싼 보호 ..
-
17. 소프트웨어 시험잡談/DO-178 번역 2019. 3. 18. 15:18
DO-178B 이전에는 품질이 시험을 통해서 개선될 수 있다는 암묵적인 철학을 가지고 있었다. 그것은 실제로 감탄할 만한 철학이다. 하지만 약간의 흰머리가 있는 경험많은 항공전자 엔지니어에게 물어보면 “시험은 평가할 수 있고 간접적으로 품질을 개선할 수는 있지만 품질 자체를 개선하지는 않는다.”라는 말을 듣게 될 것이다. 그리고 그것은 DO-178B의 핵심이다. 시험(또한 “검증”으로 불리는)은 각 시스템의 “정확성”을 평가하는 정확성 프로세스의 일부이고 그 평가는 요구사항, 설계 그리고 구현을 개선할 수 있다. 역주) 역자에게는 시험이 품질을 높일 수 없다는 말이 처음에는 잘 이해가 되지 않았다. 시험을 해서 버그를 잡게 되면 그 만큼 품질이 좋아지는 게 아닌가? 하지만 이제는 그 의미를 좀 구분할 수..
-
16. 단위시험잡談/DO-178 번역 2019. 3. 18. 15:05
DO-178B는 당신에게 단위시험을 말하지 않으며 혹은 그것에 관해서 상세한 논의도 없다. 그러나 모든 항공전자 프로젝트에 대해서 우리는 여전히 그것을 하기를 원한다. 얼마나 많은 에러들이 단위시험에서 발견되어 왔는가? 많다. 당신 회사에 대해서 생각해보라. 당신은 많은 수동단계들을 거쳐왔고 많은 시험들을 설계해 왔다. 그것들은 소프트웨어에 기반했을 것이며 받드시 그 소프트웨어를 이끌어 낸 요구사항인 것은 아니다. 일반적으로 우리는 단위시험을 통해서 수많은 작은 에러들을 발견한다. 당신이 단위시험을 해야 한다는 것을 알기 때문에 개발자가 미리부터 이를 대비해야 하는지는 논쟁이 될 수 있다. 개발자는 단위시험을 통과할 것이라는 것을 확신하고 있다. 당신은 각각의 단위에 대해서 시험 데이터와 케이스를 개발하..
-
15. 소프트웨어 설계잡談/DO-178 번역 2019. 3. 18. 14:42
DO-178B에 있어서 소프트웨어 설계는 매우 융통성이 있다. 라이프사이클이 어떻게 수행되어야 하는지, 어떤 문서들이 합쳐져야 하는지 혹은 따라야할 방법론이 무엇인지를 요구하지 않는다. 그런 융통성은 당신이 자신의 방식을 정의하도록 만들어 준다. 당신은 유스케이스(Use Case)를 사용할 것인가? UML을 사용할 것인가? 다이어그램으로 구조 차트와 데이터를 사용할 것인가? 구조화된 문법을 사용할 것인가? DO-178B는(아래 그림에서 보이는 것처럼) 설계에 대해서 네 가지 핵심 특성을 기술하라고 말한다. 소프트웨어 설계 개요 DO-178B는 설계/문서에 융통성을 제공한다 네 가지 핵심 특성들: 하위레벨 요구사항 인터페이스 정의 데이터 플로우 컨트롤 플로우 왜 DO-178B는 이런 융통성을 제공할까? D..
-
14. 시스템 요구사항잡談/DO-178 번역 2019. 3. 18. 14:31
시스템 요구사항은 일반적으로 고객과 당신 회사의 마케팅 부서에 의해서 제공되지만 그 개발은 상당히 복잡하다. 요구사항은 Preliminary TAC analysis, Human factors, Operator tasks, Operational hazard analysis, System hazard analysis, Safety verification 그리고 Operational analysis와 같은 여러 소스로부터 올 수 있다. 그것은 시스템 요구사항과 시스템 컨셉의 한 세트를 만들어 낸다. 역주) 여기서 영어로 된 부분은 시스템 안전성 분석과 관련된 복잡한 용어들이어서 억지로 한글 번역을 하지 않고 영문 그대로 적었다. DO-178을 진행하기 위해서 시스템 안전성 분석에 대해서 잘 알고 있다면 좋기는..
-
13. 소프트웨어 개발 & 검증 계획잡談/DO-178 번역 2019. 3. 18. 14:22
계획문서의 좋은 점은 일단 당신이 문서를 만들고 나서 새로운 엔지니어를 고용할 경우 그가 개발과정에서 자신이 어떤 역할을 해야 하는 지를 알 것이라는 점이다. 단 몇 시간 동안 전체 계획문서를 읽어본 후에 그는 프로세스와 엔지니어링 단계내의 활동을 어떻게 수행하는지 그리고 그 운영 절차에 익숙해질 것이다. 개발 계획문서에서 우리는 프로그램의 각 단계 사이의 관계뿐만 아니라 환경, 툴, 프로세스 그리고 전략 사이의 관계를 정의한다. DO-178B는 두 가지 종류의 소프트웨어 엔지니어링 계획을 요구한다. 소프트웨어 개발 계획(SDP)과 소프트웨어 검증 계획(SVP)이다. SVP가 리뷰와 시험을 커버하는 반면에 SDP는 통합(설계와 코딩을 포함해서)을 통해서 요구사항을 커버한다. 소프트웨어 개발 계획 개요 소..