25. PSAC(Plan for Software Aspects of Certification)

 

PSAC을 다시 살펴보자. 왜냐하면 그 만큼 중요한 문서이기 때문이다. 그것이 여전히 계획으로 존재하는 동안 PSAC은 실제로 당신의 인증 전략과 프로세스가 구체화되는 것이다. 당신은 주요 인증 주제로부터 주의를 분산시킬 수 있는 너무 많은 세부사항을 포함하기를 원하지는 않는다. PSAC은 유일하고 가장 중요한 소프트웨어 인증 문서이고 DER과 FAA에 의해서 확실하게 리뷰될 것이다.

역주) 앞서 PSAC에 대해서 설명한 적이 있는데 다시 한번 여기서 정리하자면 PSAC은 일종의 계약서와 같다. 당사자는 인증을 신청한 회사와 FAA 혹은 DER이 된다. 물론 실제 계약서 형식을 띄는 것은 아니지만 상호간에 함께 진행하고자 하는 부분이 무엇인지 충분히 납득할 만한 수준으로 PSAC을 작성하게 된다. 실제로도 PSAC이 가장 먼저 작성되고 DER이 가장 중점적으로 확인하게 된다. 다만 저자의 설명처럼 계약서에 모든 내용을 하나하나 상세하게 적는 것은 계약서의 성격에 맞지 않는 것처럼 PSAC도 그런 식으로 작성하지 않도록 유의해야 한다.

 

PSAC에 대한 중요한 변경이 있을 경우 승인을 위해서 다시 제출되지만 변경이 사소한 경우에는 그럴 필요까지는 없다. 그것이 Software Accomplishment Summary를 가지는 이유이며 거기에는 그런 종류의 차이점이 문서화된다. 핵심은 사소한 변경이라도 DER과 FAA에게 계속 통보가 되고 어떤 제안을 할 수 있도록 하는 것이다. 예를 들면 “그 변경은 괜찮습니다. 당신은 그것을 Software Accomplishment Summary에 작성할 수 있습니다.”와 같은 식이다. 하지만 만약 예를 들어 소프트웨어 툴인증, 중복성, 위험레벨 등과 같은 중요한 이슈에 대한 당신의 접근을 변경한다면 비록 사소한 차이점이 중요하지 않더라도 PSAC의 재발행이 필요할 수 있다. 중요한 점에 대해서는 당신은 분명히 PSAC을 개정하기를 원할 것이다. 만약 당신이 레벨 C라고 생각했는데 FAA 혹은 안전성 분석이 레벨 B라고 말한다면 당신은 그것을 반영하기 위해 PSAC을 개정할 필요가 있고 부가적인 변경들이 계속해서 일어날 것이다.

역주) 앞서 PSAC이 계약서라고 했는데 계약서가 변경되면 당사자간에 다시 도장을 찍어야 한다. DO-178에서도 그와 유사하게 DER이 변경된 부분을 확인해서 승인 여부를 알려주게 된다. 그런데 오타 수정하는 것처럼 사소한 것 하나하나도 모두 그렇게 해야 할까? 그런 정도는 아니라는 것이다. 그 정도는 알아서 수정해서 내부적으로 히스토리만 잘 관리하면 되며 나중에 DER에게 그 히스토리를 보여주는 것으로 충분하다. 그 정도 융통성은 있다.   또 하나 중요한 문서가 Software Accomplishment Summary(SAS)이다. 앞서 설명한 적이 있지만 PSAC과 1:1로 매칭되는 문서라고 보면 된다. 계약서가 PSAC이라면 최종 보고서가 SAS이다. PSAC에 작성한 계약서대로 진행했는지, 다른 부분이 있다면 무엇인지, 왜 그런 것인지를 적는 것이 SAS이다.

 

PSAC의 목표   감항당국에 제출되어야만 하는 최소한의 소프트웨어 라이프사이클 데이터:   Plan for Software Aspects of Certification(PSAC, 핵심 문서) Software Configuration Index(SCI) Software Accomplishment Summary(SAS)   PSAC은 제안된 소프트웨어 라이프사이클이 개발되는 소프트웨어 레벨에서 요구하는 엄격함에 부합하는지를 결정하는 주된 방법이다.   PSAC은 인증 기준을 만족하는 것에 동의하는 준수 방법으로 완전성과 일관성을 전달한다.

 

Aircraft Certification Office에 제출해야만 하는 최소한의 라이프사이클 데이터는 위에 언급된 세 개의 문서들이다. PSAC은 일반적으로 FAA에 의해서 승인된다. 또한 일부 FAA 사무소는 DER들에게 위임하지만 최소한 세 개의 문서는 보기를 원한다. 그것이 그들이 그 외의 다른 것은 요청할 수 없다거나 당신의 시설에 와서 모든 산출물을 감사할 권리가 없다는 것을 의미하지는 않는다. 그리고 그들은 시스템의 위험성, 프로젝트의 새로움, 당신이 적용하는 특별히 새로운 툴과 프로세스 그리고 네 번째이자 가장 중요한, DO-178B 프로세스에서의 당신의 전문성에 대한 레벨에 따라서 실제로 그렇게 한다. 당신은 지원자로써 얼마나 많은 시스템을 인증받아 왔는가? 당신이 이 프로세스에 처음이고 위험레벨이 높다면 그들은 당신에게 조금 더 주의를 기울인다.

역주) 이미 설명한 대로 DER은 FAA의 위임을 받은 사람이다. 결국 FAA가 해야 할 일을 그대로 하는 것이다. 하지만 현실에서는 아무래도 FAA가 직접 관여하는 것보다는 조금 더 융통성이 있는 것도 사실이다. 다만 기억할 점은 저자의 말처럼 당신이 DO-178이 처음이고 경험이 없다면 DER이 좀 더 당신에게 주의를 기울일 것이라는 점이다. 쉽게 말해서 좀 더 엄격하고 꼼꼼하게 살펴보게 된다. 대신 그 만큼 부족한 부분에 대해서 상세한 컨설팅을 받을 수 있다는 장점이 있는 것 또한 사실이다.

 

PSAC의 목표     소통하고 동의를 얻는다

 

따라서 PSAC은 당신이 제안하는 레벨에 대해서 라이프사이클 데이터와 프로세스가 DO-178B를 준수하는지를 알아보는 주된 방법이다. 그것은 당신과 FAA 혹은 DER간의 계약상의 동의이며 작업 베이스라인을 세운다. 소통하는 라인을 열기 위해 가능한 일찍 이것을 수행하기위해 노력하라. 당신은 일반적으로, 예를 들면 STC 프로그램(Supplemental Type Certificate, 부가형식증명)을 제안하면서 시작하며 FAA가 프로젝트 번호를 생성하도록 하기 위해 지원한다.

 

다음으로, 당신은 프로그램 혹은 프로젝트에 특정한 인증 계획을 생성한다. 이것은 소프트웨어 혹은 하드웨어가 아니라 전체 어플리케이션에 관련된 것이다. 그것은 당신의 전체적인 인증 접근방법을 정의한다. 당신이 필요한 것은 TSO이고 적용하는 것은 FAR(Federal Aviation Regulations)이다. 그것은 또한 당신에게 PSAC을, 필요하다면 PHAC(Plan for Hardware Aspects of Certification)을 가리킨다. 그런 다음 당신은 소프트웨어에 대해서 PSAC을 생성하고 소프트웨어 준수에 관해서 최소한의 작업 연결을 갖게 된다. PSAC은 인증 기준을 만족하기 위한 협의된 준수 방법으로 완전성과 일관성을 커뮤니케이션한다. 이것은 소프트웨어에 대해서 DO-178B를 준수하기 위한 계약이자 당신이 취하고자 하는 접근법이다.

PSAC 내용 Section 11.1 DO-178B; PSAC은 반드시 다음을 포함해야 한다:   시스템 개요 – 시스템 기능을 기술, HW/SW로 할당, 아키텍처, 프로세서, HW/SW 인터페이스 & 안전성 특성   소프트웨어 개요 – 소프트웨어 기능 설명, 파티션, 중복성, 리소스 공유, MVDS, 고장 허용범위, 타이밍 & 스케쥴링   인증 고려사항 – 인증 기준, 준용 방법, 보증 레벨, 레벨에 대한 정당화(SSA), 실패에 대한 SW 영향정도   소프트웨어 라이프사이클 – 각각의 라이프사이클 요약(요구사항, 설계, 코드, 검증, 품질보증, 형상관리), 각각의 소프트웨어 라이프사이클의 objective가 어떻게 만족하는가, 조직 구조, 시스템 역할, 인증 교섭 책임

 

한 가지 질문이 항상 생겨난다. FAA는 PSAC의 내용에 대한 추천하는 포맷이나 테이블을 가지고 있는가? 그에 대한 답은 그들은 그것을 추천할 수 없다는 것이고 모든 사람들은 자신들만의 것을 가진다는 것인데, 하지만 그것은 FAA가 보기를 원하는 것이 무엇인가에 대해서 거의 표준이 된다. DO-178B의 Section 11.1은 최소한의 셋을 구체적으로 기술한다. 이것은 반드시 만족해야 하며 다른 것들도 포함될 수 있다. 모든 것은 FAA 및 DER과 협상가능하다는 것을 항상 기억하자. 하지만 당신이 계속해서 소통할 수 있고 지금까지 통용되어온 방식이란 점에서 당신은 게임에서 앞서 나갈 수 있는데 왜 뒤쳐져서 게임을 시작하려 하는가?

역주) 지속적으로 이야기하는 것이지만 DER은 심사위원이자 당신의 컨설턴트이다. 따라서 내가 잘 모르는 부분은 언제든 DER을 통해서 조언을 들을 수 있다. 친절한(?) DER을 만난다면 괜찮은 자료도 바로 받을 수 있을 지 모른다. 저자의 설명은 바로 그런 것을 이야기하는 것이다.

 

일단 형상 인덱스가 결정되고 당신이 프로그램을 완료했다면 Software Accomplishment Summary에 모두 정리하라. 이것은 소프트웨어 라이프사이클에서 다음 X주, X달, 그리고 X년 동안에 무엇이 수행되었는지를 말한다. Software Accomplishment Summary는 실제로 무엇이 수행되었는지 그리고 그것이 PSAC에 의해서 요청된 템플릿 양식을 따르는지를 이야기한다.

 

어떤 회사들은 자신들의 PSAC을 가지고는 SAS라 부르고 “will do”를 “have done”으로 바꾸기도 한다. 그것이 꼭 맞는 것은 아니다. 왜냐하면 그들은 모든 것을 한 것은 아니며 아마도 최소한 작은 차이점은 만들었을 것이기 때문이다. 하지만 Software Accomplishment Summary는 당신이 인증하는 시점에서 프로젝트에 대한 Open된 문제점 리포트에 대해서 특별한 추가 데이터를 가져야만 한다. 당신은 그것에 대해서 형상인덱스를 가리키도록 할지 모르지만 어딘가에 그것을 포함해야 한다. 예를 들면, 당신은 개발과정에서 무엇을 수정했는가와 같은 것이다. 너무 상세하게 언급하지는 말아라. Software Accomplishment Summary는 그것들을 담고 있을 것이다.

역주) 역자는 아직 SAS를 작성해 보지는 않았지만 DER을 통해서 대략적으로 어떻게 작성되어야 하는지에 대해서는 설명을 들은 바가 있다. SAS에 대한 저자의 설명이 다소 모호한 부분이 있지만 결론적으로 앞에서 말한 부분을 기억하면 된다. PSAC과 1:1로 대응되는 기준으로 실제 진행된 내용을 전체적으로 정리하는 것이다. 계획(PSAC)과 다른 부분이 있다면 결과(SAS)에서 그 부분이 표현이 되어야 한다.

 

DO-178B의 Section 11.1은 당신이 개발하는 시스템 기능, 아키텍처, 프로세서, 하드웨어와 소프트웨어간의 인터페이스 그리고 안전성 특성에 대한 개요를 최소한의 수준으로 작성할 필요가 있다고 말한다. 소프트웨어 개요 또한 포함되어야 한다. 만약 고장 허용범위, 파티션 설계 혹은 중복성이 있다면 당신은 유사하지 않은 아키텍처를 구현해야 할 수도 있다. “유사하지 않은(dissimilar)”이 무엇인가? 1990년대에 비행 컨트롤 시스템을 위한 프로그램에 대해서 작업한 적이 있었다. FAA는 중요한 레벨 1 소프트웨어(그때는 DO-178A가 기준이었다)라고 말했는데 그때는 레벨 1, 2 그리고 3의 세 가지 레벨이 있었다. 우리는 협상을 했고 시스템의 중요성을 유지하기 위한 접근의 토론을 통해서 그 소프트웨어를 레벨 2 혹은 그 보다 낮은 위험성으로 결론을 내렸다.

 

우리는 어떤 협상과정을 거쳐서 그것을 했을까? 먼저 그것은 비행 컨트롤 시스템이었기 때문에 우리는 항공기에 동일한 동작을 수행하는 세 개의 중복된, 동일한 LRU를 넣는 것으로 결정했다. FAA는 말했다. “글쎄요, 그것은 충분하지 않습니다. 비록 당신이 세 개의 박스를 가지고 있지만 그것들은 모두 동일한 소프트웨어를 가지고 있습니다. 그것들은 동일한 방식으로 모두 실패할 수 있습니다. 다른 방법이 있습니까?”

 

우리는 대답했다. “각각의 박스는 명령을 내리는 컨트롤이 있고 박스와 컨트롤 기능의 활동을 감시하는 모니터가 있습니다. 그래서 컨트롤 사이드에서 나오는 데이터를 확인해서 모든 하드웨어와 기능을 체크합니다.”

 

“충분하지 않습니다.” FAA가 대답했다. “역시나, 세 개의 박스 모두에서 동일한 실패가 발생할 수 있습니다.”

 

우리는 말했다. “이건 어떤가요? 우리는 컨트롤은 Ada 언어로 개발했고 모니터는 C언어로 개발했습니다. 그들은 동일한 기능을 수행하며 다른 박스와 비교하기 전에 내부적으로 비교됩니다.” FAA는 말했다. “안됩니다. 비록 당신이 하나는 이 언어로, 다른 것은 또 다른 언어로 작성한다고 하지만 우리는 여전히 실패 가능성에 대해서 마음을 놓을 수 없습니다.” 그리고는 그들은 말했다. “비록 그 시스템이 중요하지만 당신에게 레벨 2 혹은 더 낮은 위험성에 대해서 승인을 주기 위해 한 가지가 더 필요합니다.”

 

그들의 요구를 어떻게 생각하는가? 다시 한번 말하지만 거기에는 동일한 박스들이 있었다. 이미 서로 다른 CPU가 있고 서로 다른 컴파일러가 있다. 그것들은 협상의 일부였다. 그것은 유사함이다. 그런 다음 그들은 우리에게 리버스 로직으로 작성된 동일한 기능을 수행할 것을 요구했다. 그래서 우리는 듀얼 채널 – 삼중의 여분을 가진 시스템상에서 리버스 로직을 적용함으로써 위험 레벨을 감소시키는 방법에 대한 중복뿐만 아니라 모니터 채널상에 유사하지 않은 아키텍처와 리버스 로직을 정의해야 했다. 그것은 너무 심한 것이었고 아주 많은 문제들을 일으켰기 때문에 그들은 다시는 리버스 로직에 대해서 요구하지 않았다. (그리고 이 비행기는 오늘날 아주 성공적으로 운항하고 있다. 하지만 항공장비 제작자는 개발과정에서 많은 돈을 허비해야 했다.)

Section 11.1 DO-178B PSAC은 또한 다음을 포함해야 한다:   소프트웨어 라이프사이클 데이터 – 생산되고 컨트롤되는 데이터, 데이터의 관계, 제출될 데이터의 구분, 데이터 형식과 제출방법 일정 – 계획을 따르기 위해 인증당국에 제공되는 가시성에 대한 방법   추가적인 고려사항 – 인증 프로세스에 영향을 줄 수 있는 특성들   준용 대체 방법 툴인증 이전에 개발된 소프트웨어 옵션 선택 가능한 소프트웨어(Option-selectable Software) 사용자 수정가능 소프트웨어(User Modifiable Software) 상용 소프트웨어(COTS Software) 현장 로딩 가능 소프트웨어(Field-loadable Software) MVDS(Multiple Version Dissimilar Software) 제품 서비스 히스토리

 

역주) MVDS(Multiple Version Dissimilar Software)를 구글링으로 찾아보면 영문위키에 아래와 같은 내용이 나온다. 참고하자. N-version programming (NVP), also known as multiversion programming or multiple-version dissimilar software, is a method or process in software engineering where multiple functionally equivalent programs are independently generated from the same initial specifications.

 

 

위험 레벨 혹은 설계 보증 레벨을 정당화하기 위해 시스템 안전성 분석에 대한 인증레벨과 정당성을 고려하라. 라이프사이클 활동에 대한 라이프사이클 데이터의 요약에는 인증 교섭 작업을 수행할 것이라는 점을 포함해야 한다. 최상위 레벨의 일정 또한 필요하다. 어떤 데이터를 생성하고 이들 데이터간의 관계는 무엇인가? 당신은 이전에 개발된 소프트웨어를 가지고 있지 않을 수도 있겠지만 그것을 PSAC의 추가 고려사항 섹션의 하위 문단으로 추가하고 이전에 개발된 소프트웨어가 사용되지 않을 것이라고 말해야 한다. 그런 식으로 함으로써 당신은 그것을 고려했고 그 질문은 사라진다. 비록 당신이 위의 항목 중 어떤 것도 사용하지 않는다고 하더라도 각각의 특성에 대한 문단을 포함하고 당신이 그것을 사용하지 않을 것이라는 것을 간단하게 언급해라. 당신은 그것을 읽는 사람에게 당신이 핵심 이슈들을 알고 있고 무언가를 그저 숨기려고 하지 않는다는 것을 알려줌으로써 좀 더 안심할 수 있게 만든다.

역주) 여기서 저자가 말하고자 하는 핵심은 DO-178 인증 관련 문서를 작성하면서 자신과 관계없는 부분이라도 빼먹지 말고 최소한 타이틀이라도 달아서 ‘해당사항 없음’이라는 말이라도 적어 놓으라는 것이다. 그렇게 해 놓음으로써 DER이 봤을 때 이 부분을 고려했구나 라는 것을 알 수 있다. 그런데 만약 그런 언급조차 없이 작성 자체를 안 하게 되면 DER은 따로 물어보는 수 밖에 없다. “당신은 이걸 사용하느냐? 어떻게 할 것이냐?”와 같은 식이다. 사소한 부분이지만 DER은 이렇게 관계없는 부분도 하나하나 확인한다는 것이고 그렇다면 관계 있는 부분은 얼마나 자세히, 제대로 볼 것인지 예상할 수 있는 부분이다.

 

다른 계획들, 구조적 특성들, 상세한 일정, 툴과 컴포넌트에 대한 상세한 설명에 대해서는 어떤가? 당신은 이들 각각을 모두 고려했고 유효하게 만들어서 알렸으며 보수적인 결정도 내렸다. 따라서 당신은 그런 세부 내용들을 PSAC에 포함하기를 원한다. 이게 맞을까? 절대 그렇지 않다. PSAC은 당신의 프로젝트에 대한 모든 상세한 내용을 위한 쓰레기통이 아니다. 그것은 그러한 다른 세부사항들을 각각의 계획과 산출물내에서 참조하는 인증 특화된 문서이다. 당신의 PSAC을 얇고 깔끔하게 유지해라. 얼마나 얇게? 거의 항상 25 ~ 40페이지면 충분하다. 15페이지보다 적으면 긴 질문을 계속해서 받게 될 것이다.

역주) 인증이라고 하면 다들 겁부터 난다. 특히 방대한 문서를 작성하는 부분은 가장 골치아프고 힘든 부분이다. 현실적으로 이 부분을 부정할 수는 없지만 한편으로는 DO-178에서는 불필요한 문서작업을 요구하지 않는다는 점을 이해할 필요가 있다. 무턱대고 많은 내용을 채우고 페이지수를 늘리는 무식한(?) 작업을 할 필요가 없다는 뜻이다. 그런 점에서는 상대적으로 문서 작업량이 적다고 할 수 있지만 그럼에도 실제 작성할 부분이 많은 것은 사실이다. 다시 한번 말하지만 DO-178에서는 무작정 많이 적는다고 DER이 좋아하는 게 아니라는 점을 반드시 명심하자.

 

PSAC의 함정: 그것을 피하는 방법   PSAC에 대한 동의없이 개발을 진행(매우 많은 비용이 들 수 있는) 일찍 만들고 제출, 문서 계약을 얻기, FAA/DER의 이른 관여   모든 내용을 작성하지 못함 체크리스트를 사용, 완전하고 분명하게 되도록, FAA/DER의 이른 관여   불완전 혹은 모호함 체크리스트를 사용, 정확하도록, FAA/DER의 이른 관여   업데이트/통지없이 계획을 수정 PSAC은 컨트롤되고 제출됨, 살아있는 문서   PSAC이 SAS와 일치하지 않음 PSAC은 살아있는 문서, 수정이 유지되고 제출됨, FAA/DER의 관여   PSAC에서 설계 레벨 보증이 정당화되지 않음(너무 높거나, 너무 낮은 것은 당신에게 비용을 요구한다) FHA, SSA, PSSA와 시스템 안전성 프로세스는 PSAC의 합의에 앞서서 완료된다.   마지막이 아니라 시작시점에 PSAC을 완료하고 제출하라 일찍 그리고 자주 커뮤니케이션함으로써 함정을 피하라

 

설계 레벨 보증은 PSAC에서 정당화되지는 않는다. 당신의 FHA 시스템 안전성 분석과 모든 문서들을 PSAC에 넣으려고 하지 마라. 이들은 이전에 시스템 개발 프로세스와 시스템 안전성 평가에서 수행되었다. 그것이 당신이 아키텍처를 제안했던 방법이다.

 

PSAC은 위험레벨, 시스템 안전성 분석 그리고 우리가 소프트웨어 레벨 2가 되는 방법에 대한 동의가 있을 때 까지는 제출되어서는 안된다. 그런 다음에야 PSAC이 제출된다. 가능한 일찍 그것이 수행되고 그 레벨에 도달하도록 노력하라. PSAC이 모든 산출물과 상세 내용을 포함해서는 안되지만 시스템 아키텍처, 소프트웨어 레벨, 형상관리, 품질보증, 개발 및 검증을 다루는 한 세트의 데이터 항목들과 계획들을 참조해야 한다. 시작하면서 당신의 PSAC을 완성하고 제출하라. 업데이트 혹은 통지를 하지 않는 함정을 피해라. 동의된 PSAC으로 개발을 진행하지만 이후에 변경이 되는  회사들은 스스로를 위험에 빠뜨릴 수 있다. PSAC은 모든 세부사항이 SAS와 일치해야 하는 것은 아니다. 프로젝트 개발 과정에서 여러가지 사소한 차이가 만들어질 것이라는 것을 예상할 수 있다. PSAC은 살아있는 문서이지만 SAS는 왜 PSAC을 따르지 않았는지에 대한 정당성이 필요할 수 있는 영역이 있다. 인증 시점에서 오픈된 문제점 리포트는 무엇인가? 그것들은 Software Accomplishment Summary에서 참조된다. 다시 한 번 말하지만, 이들 항목들을 이해하기 위해 당신의 FAA와 DER이 가능한 일찍 관여하게 해라.

 

PSAC에 대한 함정과 그것을 어떻게 피할 수 있는지에 대해서 이야기해보자. 일단 당신이 FAA에 PSAC을 제출하게 되면 그것은 당신이 얼마나 이 프로세스에 잘 숙달되어 있는지에 대한 첫 번째 인상이 된다. 만약 그 상태로 FAA에게 의견을 구한다면 글쎄, 그것이 당신이 매우 잘 숙달되도록 만들지는 않는다. 그것은 그저 하단에 서명을 하고 당신이 가진 영수증 전부를 박스에 넣고는 “국세청(IRS Internal Revenue Service), 당신들이 내가 얼마나 납부해야 하는지 계산하세요.”라고 말하면서 소득신고서를 보내는 것과 비슷하다. 그것은 제대로 진행되지 않을 것이며 혹은 적어도 당신이 원하는 바가 아니다.

 

당신은 그것을 모두 수행하고, 당신의 완전성을 보여주며 아무런 실수가 없었고 가능한 일찍 동의를 얻기를 원한다. 어떤 것들을 뒤에 남겨두지 말아라. 항목들에 대한 체크리스트가 PSAC에 포함되도록 하고 최소한 그런 항목들을 모두 포함하게 만들어라. FAA와 DER이 관여하게 만들어라. 왜냐하면 그들은 이전에 이런 것들을 수 백 건 보아왔고 무엇을 살펴봐야 하는지를 안다.

 

어떤 가정도 피해라. PSAC을 완성해서 당신이 무엇을 하려고 하는지를 정확히 보여라. 여기에 설명된 것처럼 여러 활동들을 분명하게 설명하라. 만약 툴인증을 수행하려는 계획을 가지고 있다면 툴의 이름과 사용 목적을 작성해라. PSAC의 툴인증 섹션에 그저 “우리는 몇 가지 툴들을 사용할 것이며 나중에 인증을 제공할 것입니다.”라고 작성하지 마라. 그 툴들이 무엇이고 날짜는 언제인가? “우리는 검증툴만을 사용할 계획입니다. 개발툴은 사용하지 않을 예정입니다. 검증툴은 구조적 커버리지 분석을 위한 Vector Software사의 VectorCAST입니다.”라고 작성하라. 툴의 이름을 명시하되 버전 번호를 넣지는 말아라. “툴인증에 대한 우리의 접근은 다음과 같을 것이다.”라고 적은 후에 단지 세 개 내지 네 개의 점을 추가한 후에 인증받게 될 툴을 언급한다. (많이 적을 필요는 없다) 나머지는 나중에 다른 문서에서 상세화될 것이다. 당신이 확실한 접근법을 가지고 있고 간단명료하게 설명할 수 있는 한 그것은 받아들여질 수 있다. PSAC의 다른 섹션에 대해서도 같은 방식으로 진행되며 주요 관심사가 위에 언급되었다.

역주) PSAC을 어떻게 작성하면 되는지 요령(?)을 설명하고 있다. 사실 이런 부분은 직접 자신이 진행해 봐야 느낌을 받을 수 있는 부분이다. 일단 이런 내용이 있다는 것을 기억하고 추후에 실제로 PSAC을 작성하게 될 경우 이 부분을 다시 한 번 찬찬히 읽어보자. 그제야 깨닫게 되는 부분이 있을 것이다. .