12. DO-178 소프트웨어 리뷰(Software Review) – Job Aid (1)

DO-178 인증과 관련된 문서들은 무수히 많다. 너무 많다 보니 그 중에서 무엇을 봐야하는 지 판단하는 것조차 쉽지 않다. 물론 시간이 충분하다면 관련된 문서들을 일일이 확인하고 참고하면 좋겠지만 어떤 문서가 중요하고 어떤 도움이 되는지 판단하기가 어렵고 막상 중요하다고 하더라도 대부분 영문으로 되어 있는 데다가 대체로 분량이 많아서 한 번 읽는 것조차도 현실적으로 쉽지 않은 일이다. 어쩌면 필자가 이렇게 정리하고 있는 부분들이 바로 그런 고민의 결과를 공유하는 자리라고 할 수 있다.

 

그런 가운데서도 필자가 DO-178 가이드라인 문서만큼이나 중요하게 생각하는 문서가 있으니 바로 아래 그림의 Job Aid라는 문서이다.

 

 

필자는 이 문서를 단순한 학습 차원이 아니라 실제 컨설팅 업무의 도구(?)로 사용하고 있다. 어쩌면 DO-178 가이드라인 문서보다도 더 자주 사용하고 더 많이 보는 문서라고 할 수 있을 것 같다. 도대체 무슨 내용이길래 그 정도인가 싶을 듯한데 이제 그 이유를 하나하나 살펴보자.

 

(1)   Job Aid에 대한 소개

 

우선 표지의 가운데에 적혀 있는 부분을 보자.

 

‘Conducting Software Reviews Prior to Certification’

 

해석을 하면 ‘인증에 앞서 소프트웨어 리뷰를 수행하기’ 정도로 번역할 수 있을 듯하다. 그리고 문서 하단에는 ‘Job Aid’라는 용어가 보이고 있다. 실제로 이 문서는 소프트웨어 리뷰를 위한 용도로 사용되는 문서이다.

 

실제로 문서의 목적을 설명한 곳에는 다음과 같이 적혀 있다.

 

해석을 보자.

 

PART 1 – 소프트웨어 리뷰에 대한 개요   목적      이 Job Aid는 연방항공국(FAA) Order 8110.49, Software Approval Guidelines의 Chapter 2에 작성된 것처럼 인증당국, 피지명자, 그리고 지원자가 소프트웨어 리뷰를 수행하는 것을 지원한다.

 

참고자료가 또 다시 언급되고 있는데 일단 그 부분은 무시하고 내용만 보자면 결국 ‘인증당국, 피지명자, 그리고 지원자’의 ‘소프트웨어 리뷰’를 지원하기 위한 목적의 문서라는 점을 설명하고 있다.

 

사실 이 문서는 기본적으로 DO-178B 가이드라인을 기준으로 FAA에서 만든 문서이며 FAA 홈페이지를 통해서 공식적인 링크를 제공하던 문서였다. 그런데 어쩐 일인지 DO-178C가 나오면서는 이 문서의 링크가 사라져 버려서 원칙적으로는 DO-178C에 대해서는 공식적인 참고가 인정되지 않는 문서이다. 하지만 DO-178B와 DO-178C가 큰 차이점이 없다는 점에서 Job Aid를 DO-178C에 대한 참고자료로 사용하는 데에는 실무적으로는 전혀 문제가 되지 않는다. 무엇보다도 이 문서 자체가 다음과 같이 참고를 위한 목적으로 만든 문서이고 실제 적용에 대한 부분은 당사자가 책임을 지고 커스터마이징을 해야 하는 것이어서 더더욱 문제가 되지 않는다.

 

해석을 보자.

 

이 Job Aid는 소프트웨어 리뷰 프로세스 과정에서 하나의 참조툴로써 사용되어야만 한다. 그것은 체크리스트로써 사용될 의도를 가지고 있지 않으며 리뷰될 필요가 있는 모든 가능한 상황의 모든 것을 포함하는 것은 아니다. 혹은 Job Aid가 DO-178B를 대신하려는 의도를 가지고 있지 않다. 그것은 DO-178B와 함께 사용되어야 한다.

 

한마디로 이 문서를 전적으로 믿지 말고 알아서 잘 사용하라는 말이다. 다소 무책임(?)하게 들릴 수도 있는 내용이지만 실제로 그 이상의 역할을 하고 싶어도 그럴 수 없는 한계를 가지고 있는 것이 사실이다.

 

이제 소프트웨어 리뷰를 위해서 Job Aid를 어떻게 참고할 수 있는지 하나씩 확인해 보자.

 

(2)   Job Aid를 이해하기 위한 용어 및 개념

 

Job Aid를 이해하기 위해서는 몇 가지 용어와 개념을 먼저 이해해야 한다. DO-178 가이드라인에서 사용되는 용어와는 또 다른, 실제 현장에서 사용되는 용어들과 개념이 포함되어 설명되고 있기 때문이다. 그 중 대표적인 것들을 정리하면 다음과 같다.

 

①     소프트웨어 리뷰(Software Review)

 

앞서 Job Aid는 FAA에서 만든 Order 8110.49, Software Approval Guidelines에서 설명하고 있는 소프트웨어 리뷰(Software Review)를 지원한다고 한 바가 있다. 언뜻 소프트웨어 리뷰라고 하게 되면 문서 리뷰나 코드 리뷰와 같은 단편적인 활동을 말하는 것으로 받아들이기 쉬운데 실제 여기서 사용되는 의미는 소프트웨어의 전반적인 부분을 리뷰하는 것을 말한다.

 

여기서 ‘전반적인 부분’의 범위가 바로 Order 8110.49 문서로 규정된다고 할 수 있다. 실제로 Order 8110.49는 타이틀에서 볼 수 있듯이 소프트웨어 승인을 위한 가이드라인 문서이고 Chapter 2에는 다음과 같은 내용들이 설명되어 있다.

 

Job Aid에는 위에서 나오는 SOI#1, SOI#2, SOI#3, SOI#4를 중심으로 실제 수행 과정 및 방법에 대한 내용들이 상세하게 설명되어 있다. 따라서 인증당국뿐만 아니라 피지명자(DER을 말한다), 그리고 지원자 모두 소프트웨어 리뷰를 위해서 각자의 위치에서 참고할 수 있는, 실제로도 반드시 참고해야 하는 문서이다.

 

그런데 여기서 한 가지 짚고 넘어갈 부분이 있다. 바로 소프트웨어 리뷰를 수행하는 주체가 누구인가에 대한 부분이다. 정답부터 말하자면 바로 인증당국, 즉 FAA이다. 실제로도 Order 8110.49 문서는 인증당국(DER을 포함)이 소프트웨어를 어떻게 인증하는 지를 가이드하는 문서이고 Job Aid는 그러한 인증을 위해서 수행하는 소프트웨어 리뷰를 어떻게 해야 하는지를 상세하게 설명하고 있다. 따라서 Job Aid에 작성된 소프트웨어 리뷰를 수행하는 주체 역시 인증당국이 된다. 이러한 배경을 가지고 앞으로 나오는 설명을 이해하자.

 

②     주요 Key Player

 

DO-178 인증과 관련된 주요 관계자에 대해서 Job Aid에서는 ‘Key Player’라는 용어로 설명하고 있다. 한글로 번역해서 표현할 수도 있지만 뉘앙스를 그대로 전달하기 위해서 영어를 그대로 사용하기로 한다. 그런데 Key Player로 지정하고 있는 대상이 상당히 많다. 일단 순서대로 나열해 보자.

 

1)     Aviation Safety Engineer Software (ASE-SW)

2)     Aviation Safety Engineer (ASE)

3)     Aviation Safety Inspector (ASI)

4)     Flight Test Engineer/Pilot

5)     Chief Scientific & Technical Advisor (CSTA)

6)     Technical Specialist (TS)

7)    Project Manager

8)     Directorate Standards Staff

9)     Headquarter (HQ) Software Personnel

10)  Designated Engineering Representative (DER) With Software Authorization

11)  Manufacturing Designees

12)  Applicant

13)  Software Developer

 

각각에 대해서 1명씩만 치더라도 무려 13명(?)이나 제시되고 있다. 생각보다 많은 것 같지만 사실 FAA라는 조직이나 항공기라는 규모를 생각하면 절대 많은 숫자가 아니다.

 

그런데 DO-178 인증을 지원하는 입장인 우리가 과연 위의 Key Player를 모두 알아야 할까? 물론 다 알면 좋겠지만 필자는 그 중 소프트웨어 리뷰를 수행하는 것에 초점을 맞추어 반드시 알아야 할 Key Player를 정해서 위와 같이 붉은색으로 표시했다. 이들만 추려서 Job Aid에서 설명하는 주된 역할을 정리하면 다음과 같다.

 

Key Players	Primary Role in Software Review
Project Manager	• Responsible for coordination, schedule, and oversight of the overall certification project.
Designated Engineering Representative (DER) with Software Authorization	• Works on behalf of the FAA (Aircraft Certification Office) to review software compliance. • Assists as part of the review team. • Often performs review(s) prior to the FAA review to make preliminary compliance findings and to resolve any issues. May be responsible for conducting review and providing review results to ASE-SW. • May be responsible for recommending approval or approving the software aspects of the system or the system, if delegated.
Applicant	• Applies for Type Certificate, Supplemental Type Certificate, Amended Type Certificate, Amended Supplemental Type Certificate, or Technical Standard Order Authorization. • Responsible for the compliance with applicable regulations, policy, special conditions, issue papers, and system and software policy. May or may not be the system or software developer. • Responsible for oversight of system and/or software developer to ensure compliance, if applicable. • Attends on-site software reviews. If the applicant is not the software developer, the applicant’s oversight personnel, systems engineer, and/or other team members should be present at on-site reviews.
Software Developer	• May be the applicant or one of their system suppliers who is the developer of the system and/or the developer of the software under evaluation to be installed on an aircraft. • Members of software developer team may include: software program manager, software development manager/lead, software verification manager/lead, software engineers, programmers, software quality assurance (SQA) personnel, software configuration management (SCM) personnel, etc.

 

사실 Key Player에 대한 부분은 필자가 직접 만나보거나 경험하지 못한 부분이 많아서 필자의 지식만으로 구체적인 설명을 하는 것이 맞는 건가 싶은 생각이 드는 게 사실이다. 그래서 원문과 필자의 해석을 1:1로 정리했다. 혹시 의구심이 드는 분들이라면 원문을 직접 보시기를 추천 드린다.

 

Key Players	소프트웨어 리뷰에서의 주요 역할
Project Manager	• 조율, 스케쥴, 그리고 전체 인증 프로젝트의 감독에 대한 책임을 가진다.
Designated Engineering Representative (DER) with Software Authorization	• 소프트웨어 준수를 리뷰하기위해 FAA(Aircraft Certification Office)를 대신해서 작업한다. • 리뷰팀의 일부로써 지원한다. • 때때로 예비 준수 미달(Findings)을 만들고 어떠한 이슈를 해결하기 위해 FAA에 앞서서 리뷰를 수행한다. 리뷰를 수행하고 ASE-SW에게 리뷰 결과를 제공하는 책임을 가질 수 있다. • 시스템의 소프트웨어 특성 혹은 시스템에 대한 승인을 추천하거나 승인하는 책임을 가진다.
Applicant	• TC(Type Certificate), STC(Supplement Type Certificate), ATC(Amended Type Certificate), ASTC(Amended Supplemental Type Certificate), 혹은 TSOA(Technical Standard Order Authorization)에 대해 지원한다. • 적용가능한 규정, 정책, 특별한 조건, 이슈페이퍼, 그리고 시스템 및 소프트웨어 정책에 대한 준수의 책임이 있다. 시스템 혹은 소프트웨어 개발자이거나 아닐 수 있다. • 가능하다면 준수를 보장하기 위해 시스템 그리고/혹은 소프트웨어 개발자의 감독에 대한 책임을 가진다. • 현장 소프트웨어 리뷰에 참석한다. 만약 지원자가 소프트웨어 개발자가 아니라면, 인력, 시스템 엔지니어, 그리고/혹은 다른 팀멤버들에 대한 지원자의 감독이 현장 리뷰에 존재해야 한다.
Software Developer	• 항공기에 설치되기 위해 평가되는 소프트웨어에 대한 시스템의 개발자 그리고/혹은 소프트웨어의 개발자인 지원자이거나 혹은 그들의 시스템 공급자 중 하나일 수 있다. • 다음과 같은 소프트웨어 개발팀의 멤버들이 포함될 수 있다: 소프트웨어 프로그램 매니저, 소프트웨어 개발 매니저/리더, 소프트웨어 검증 매니저/리더, 소프트웨어 엔지니어, 프로그래머, 소프트웨어 품질보증 인력, 소프트웨어 형상관리 인력, 등

 

추려서 정리해도 여전히 많고 내용이 어렵다. 필자가 Job Aid 문서를 전체적으로 보고 난 결과를 기준으로 최대한 간략하게 정리를 해 보자면 다음과 같이 정리할 수 있을 것 같다.

 

-       Project Manager: 인증을 위한 소프트웨어 리뷰를 총괄하는 팀장

-       Designated Engineering Representative (DER) with Software Authorization: DER

-       Applicant: 인증 지원자

-       Software Developer: 소프트웨어 개발자

 

거듭 이야기하지만 위의 정리는 전적으로 필자의 개인적인 의견이다. 그리고 아무래도 국내에서의 소규모 프로젝트에 대한 경험만을 가지고 있다 보니 대규모 프로젝트의 관점이 제대로 반영되지 않은 부분도 있을 듯하다. 그럼에도 이렇게 Key Player에 대해서 정리하는 것은 소프트웨어 리뷰를 위해서는 최소한 이 정도의 Key Player를 갖추고 진행해야 한다는 점을 이야기하고자 하는 것이다.

 

③     소프트웨어 리뷰팀(Software Review Team)

 

앞서 소프트웨어 인증과 관련된 Key Player에 대해서 설명했다면 이제 실제로 소프트웨어 리뷰를 수행하는 팀에 대해서 이야기할 순서이다. 이는 인증당국인 FAA의 관점에서 보자면 인증을 담당하는 팀이 별도로 존재하는 상태에서 실제 소프트웨어 리뷰를 수행하는 팀이 조직되는 것이다. Job Aid에서는 리뷰팀에 대해서 다음과 같이 설명하고 있다.

 

여기서 잠시 DO-178 인증을 위한 소프트웨어 리뷰가 무엇을 하는 것인지 잠시 살펴보자. 다음 절에서 보다 상세하게 설명하겠지만 소프트웨어 리뷰팀의 구성을 이해하기 위한 차원에서 살펴보자면 크게는 다음과 같이 구분할 수 있다.

 

-       기술적인 리뷰: 주로 소프트웨어 개발자가 수행

-       프로세스적인 리뷰: 주로 QA가 수행

 

리뷰팀을 구성하는 것은 결국 이와 같이 구분되는 리뷰에 기반해서 이루어진다고 볼 수 있다. 위의 설명은 바로 그러한 배경을 가지고 리뷰팀을 어떻게 구성하는지에 대해서 설명하고 있다. 전체적인 해석은 생략하고 위에서 제시된 구성원의 구분을 정리하면 다음과 같다.

 

-       Engineering(ENG) Team Member 최소 1명

-       Quality Assurance/Configuration Management(QA/CM) Team Member 최소 1명

-       추가로 필요에 따라서 아래와 같은 인력이 포함될 수 있음

l  Software Engineers

l  Non-software Engineers

l  Chief Scientific and Technical Advisor

l  Technical Specialist

l  Directorate Personnel

l  Headquarters Personnel

l  International Certification Authorities

 

위에서 추가될 수 있는 인력이 나열되어 있는데 이는 결국 리뷰를 제대로 수행하기 위해서 해당 인력이 반드시 필요한 지가 관건이 될 것이다. 물론 프로젝트나 소프트웨어의 규모에 따라서도 달라질 수 있겠지만 해당 분야의 전문가가 필요한 상황이라면 그런 것과는 관계없이 리뷰팀에 포함되어야 한다.

 

④     리뷰 유형(Review Types)

 

DO-178 인증을 위한 소프트웨어 리뷰에는 다음과 같은 2가지 유형이 있다.

 

-       On-site Review

-       Desk Review

 

참고로 필자는 위의 구분을 ‘현장리뷰’와 ‘원격리뷰’로 해석한다. 아마 용어만으로도 쉽게 구분이 될 텐데 On-site Review는 주로 실제 개발이 진행되고 있는 현장, 즉 지원자가 근무하는 곳에서 이루어 지는 것을 말하며 Desk Review는 현장과는 떨어진, 주로 리뷰팀이 근무하는 곳에서 이루어 지는 것을 말한다. 물론 이것 외에도 지원자(Applicant)가 자체적으로 수행하는 리뷰(Self-assessment Review)가 있긴 한데 그것은 공식적인 부분은 아니므로 일단 여기서는 제외하기로 하자.

 

Job Aid에서는 두 가지에 대한 구분을 표로 정리해서 설명하고 있다. 원문의 내용이 많아서 따로 구분해서 해석된 내용으로 정리하면 다음과 같다.

 

리뷰 유형	방법
On-site Review	• 소프트웨어 개발 프로세스의 적절한 단계를 리뷰 • 소프트웨어 개발자의 시설에서 팀에 의해서 수행됨 (유의사항: 지원자가 지명한 DER과 SQA가 반드시 참석해야 함)
Desk Review	• 적절한 소프트웨어 라이프 사이클 데이터를 리뷰 • FAA 혹은 지원자의 시설에서 개인 혹은 팀에 의해서 수행됨 • 소프트웨어 개발자에 의한 관여는 아주 적거나 없음

표 1 리뷰 방법에 따른 구분

 

리뷰 유형	적절한 경우
On-site Review	• 고위험의 시스템 (레벨 A와 B 소프트웨어) • 개발되고 있는 새로운 시스템 • 여러 기능을 가진 통합된, 복합 항공 시스템 • DO-178B를 처음 지원하거나 처음 수행하는 사람 • 소프트웨어 개발 그리고/혹은 감독에 대한 경험이 미숙한 지원자 • 빈약한 개발 프로세스의 히스토리를 가진 지원자 • 새로운 혹은 독특한 기술, 소프트웨어, 방법, 시스템 혹은 소프트웨어 아키텍처, 안전성 제안, 파티셔닝 컨셉 등 • 시스템과 비행 시험동안에 여러가지 문제들을 보여주는 시스템인 경우 • 사용되는 기술 혹은 환경에 큰 변화가 있는 경우 (예를 들면, 인력, 툴, 방법) • DER이 요청 • DER에 대한 FAA의 감독이 필요함
Desk Review	• 이전에 승인된 소프트웨어의 중요한 변경 • 덜 위험한 시스템 (레벨 C와 D 소프트웨어) • 훌륭한 성과 히스토리를 가진 경험있는 항공 회사 • DER에 대한 신뢰가 좋음

표 2 리뷰 적합도에 따른 구분

 

리뷰 유형	방법
On-site Review	장점: • 개발 인력으로의 접근 • 더 심도있는 리뷰 • 안전성 특성에서의 더 높은 신뢰 • 데이터에 대한 완전한 접근 • DER 성과 평가를 수행하는 것을 도움   단점: • 예산과 시간에 대한 고려 • 출장이 필요할 수 있음 • 개발자의 일정에 영향을 줄 수 있음
Desk Review	장점: • 소프트웨어 개발자의 일정과 리소스에 방해를 주지 않음   단점: (만약 떨어진 곳에서 수행된다면) • 많은 회사들이 그들이 없는 상태에서 데이터가 리뷰되는 것을 허용하지 않음 • 소프트웨어 개발자에게 직접 질문을 할 수 없음 • 많은 양의 데이터를 전달해야 할 수 있음

표 3 장단점에 따른 구분

 

필자는 DER과 DO-178 인증(준용)을 진행하면서 위와 같은 유형의 리뷰를 모두 경험했다. 국내에서 진행되는 케이스의 특성상 지금까지 설명한 내용과 조금 다른 부분이 있긴 하지만 사실 그때 진행한 과정 전체가 실제로는 지금 설명하고 있는 소프트웨어 리뷰 과정이었다. DER이 리뷰팀의 역할과 함께 FAA라는 감독자의 역할까지 모두 수행한 것이다. 참고로 이는 국내에서 진행하는 DO-178 인증(Certification)이라는 것이 실제로는 DO-178 준용(Compliance)이기 때문에 가능한 부분이라는 점을 기억하자.

 

참고) Job Aid의 문서 곳곳에는 ‘Designee’라는 단어가 자주 나온다. 기본적으로 이것은 ‘DER’을 지칭하는 것으로 이해할 수 있다. 위의 표에서도 실제 사용된 용어는 ‘Designee’인데 ‘피지명자’라는 용어 대신 직관적인 이해를 위해서 ‘DER’로 표기를 했다. DER에 대해서는 별도의 절을 통해서 상세한 설명이 있을 예정이다.

 

⑤     SOI(Stages of Involvement)

 

SOI라는 용어 자체는 굳이 한글로 번역하자면 ‘관여 단계’ 정도로 번역할 수 있다. 그렇다면 누가 ‘관여’를 한다는 것일까? 이에 대한 설명을 다음 문장에서 확인할 수 있다.

 

해석을 보자.

 

소프트웨어 리뷰의 목적은 DO-178B 목표와 다른 적용가능한 소프트웨어 정책, 지침, 그리고 이슈페이퍼로의 준수를 보장하는 것이다. 준수여부를 평가하기 위해 일반적으로 프로젝트의 소프트웨어 라이프 사이클 동안에 FAA가 관여하는 네 개의 단계가 있다. 네 개의 SOI 리뷰가 아래에 리스트되어 있고 Table 4에서 확인된다.   (1)   계획 리뷰 (SOI#1) (2)   개발 리뷰 (SOI#2) (3)   검증 리뷰 (SOI#3) 그리고 (4)   최종 리뷰 (SOI#4)

 

위의 설명을 통해서 SOI는 FAA가 관여하는 단계라는 것을 알 수 있다. 그리고 그 관여는 DO-178 목표를 준수하는지를 평가하는 것이고 그것은 소프트웨어 리뷰를 통해서 확인된다. 이것을 SOI라고 하고 총 네 가지 단계로 구분하고 있다. (원문에는 없지만 각각을 구분하는 SOI 번호를 함께 표기했다.)

 

이어지는 절에서 각각의 단계를 구분해서 좀 더 자세히 알아보게 될 것이다. Job Aid에는 이러한 단계의 구분을 요약해서 정리한 테이블이 먼저 제시되고 있는데 여기서 그것을 바로 확인하는 것 보다는 전체를 살펴보고 마지막에 정리하는 차원에서 보는 것도 의미가 있을 것 같다.

 

참고로 위에서 제시한 네 개의 단계가 반드시 이대로만 진행되는 것은 아니다. 다음 설명에 그런 내용이 잘 언급되어 있다.

 

해석을 보자.

 

어떤 프로젝트에 대해서는 네 개의 리뷰보다 더 많은 것이 보장될 수 있다. 예를 들면, 많은 하위시스템(Sub-systems)을 가진 큰 프로젝트, IMA(Integrated Modular Avionics) 시스템, 혹은 여러 문제를 경험하고 있는 프로젝트를 들 수 있다.

 

경우에 따라서는 네 개의 리뷰가 아닌 다섯 개 혹은 그 이상의 리뷰도 가능하다. 물론 이는 DO-178 인증을 시작하기 전에 인증당국과 협의를 통해서 결정하게 된다. 또 하나 참고할 부분이 있다.

 

해석을 보자.

 

만약 리뷰가 SOI를 합친다면 의제의 내용이 합쳐질 수 있다. 예를 들면 만약 하나의 리뷰가 계획과 개발 리뷰를 합쳐서 수행되었다면 의제, 가능한 데이터 그리고 미팅의 길이는 Supplement 3, Section 1으로부터 SOI#1과 SOI#2에 대한 두 개의 샘플 의제를 합칠 필요가 있을 것이다.

 

앞서 본 것과는 반대로 네 개의 리뷰가 아닌 세 개 혹은 두 개의 리뷰도 가능하다는 것을 설명하는 부분이다. 역시나 이 부분도 인증당국과의 협의가 필요한 부분이며 네 개의 단계를 기준으로 작성된 Job Aid의 참고사항이 합쳐지는 것과 같은 커스터마이징이 필요하다는 점도 설명하고 있다.

 

참고로 Order 8110.49라는 문서에는 이에 대한 설명이 아래와 같이 직접적으로 나온다. 해석은 생략한다.

 

실제로 SOI의 단계는 기본적으로 네 개의 단계가 가장 무난하다. 많은 DO-178 인증이 그런 식으로 진행되어 왔다. 하지만 이것이 절대적인 것은 아니다. 특히 우리나라와 같이 DO-178 인증이 익숙하지 않은 상태에서는 무작정 그렇게 따라만 갈 수 없는 것이 현실이다. 필자의 경험에서 보자면 지금까지 SOI#4까지 모두 진행한 경우가 없으며 SOI#3까지만 진행한 경우가 많았다. 그리고 진행과정에서도 미진한 부분이 너무 많이 확인되는 경우에는 비록 공식적인 SOI 번호를 붙이지는 않았지만 추가적인 소프트웨어 리뷰를 수행한 경우가 대부분이었다.

 

앞으로 설명될 SOI에 대해서는 기본적인 개념을 이해하는 것으로 생각하고 실제 적용에서는 항상 변수가 있을 수 있다는 점을 기억하자.