회사 업무 중 검증 계획서 이슈

회의 벌써 두 차례나 진행되었는데 기능안전 검증 계획서를
누가 어떻게 작성할 지에 대해서 해결이 되지 않고 또 
다음 회의로 넘어가게 되었다.

나는 이렇게 도돌이가 되는 이유를 사람들이 생각하는 안 건에
대해 명확하게 파악하지 않고 뜬구름 잡는 개념으로 생각하고
주구장창 토론만 했기 때문이라 파악했다 

고로 나는
이를 해결하기 위해 나는 검증 계획서가 26262 표준에서 어떻게 
나와 있는지 분석부터 했다.

먼저 해외 고객 DIA문서를 살펴 보았다 고객이 검증 계획서에
들어가야 할 산출물이 무엇인지 파악하기 위해서였다. 

system architectural design
hardware-software interface specification
the specification of requirements for POSD
TSC
hardware safety requirements 
hardware design
SPFM,LPFM(FMEDA)
PMHF(FMEDA)
Hardware integration and verification report
software verification report
software verification specification
verificaiton specification, verification report
verification plan
Dependent Failures Analysis Verificationi report
safety analyses verification report(system, hw, sw)
등의 문서들 이었다. 

결국
요구사항명세서, 아키텍처, 안전분석, 시험에 대한 
검증 계획서가 있어야 함을 알았다. (Part 8에 언급된 내용과 일치함)

이 검증 계획서 안에 들어가야 하는 내용을 정리했다.

a) 검증될 작업 산출물의 내용

b) 검증 목표

c) 검증을 위해 사용된 방법

d) 검증을 위한 합격 및 불합격 기준

e) 해당되는 경우, 검증 환경

f) 해당되는 경우, 검증에 사용된 장비

g) 해당되는 경우, 검증을 위해 필요한 자원

h) 이상점이 감지된 경우, 취해져야 될 조치

i) 회귀 전략


표준에서 검증에 대한 요구사항이 Part 4,5,6에 나와있음
→ 이것들은 report 형태로 된 산출물을 고객이 요구할 거임

그런데
Part 8에는 위의 4,5,6을 포함한 모든 검증 요구사항에 대한 
계획을 요구하는 검증 계획서를 작성해야 한다고 언급함

서술된 내용에 의하면 마스터 검증 계획서를 작성하란 언급은 없지만, (Part8_9.5.1)
Part8에서 하나의 요구사항처럼 보이므로 고객입장에선 하나의 
마스터 검증 플랜을 원할 수 있음

그리고 절차서 및 지침서에 서술하는 것으로는
검증 계획서를 대체할 수 없음 왜냐하면 위의 Part 8에서 요구하는
검증 계획서에 들어갈 내용 중에
검증될 작업 산출물의 내용, 검증 목표, 검증을 위해 사용된 방법,
검증을 위한 합격 및 불합격 기준은 절차서 및 지침서에 
들어갈만한 내용은 아닌 것처럼 보임(억지로 넣는다면 넣겠지만..)
또한 저 필수 항목 중 각 프로젝트에 따라 변화될 수 있는 것도 있음
(절차서 및 지침서에 넣으면 모든 프로젝트에 대해서 고정이므로
변화가 필요할 시에 대처가 안됨)

결국 마스터 검증 플랜을 작성하는 것이 좋아 보이는데 이에 대한
책임을 누가 가지냐에 대한 문제가 생길 수 있음 하지만 
각 검증 내용에 들어갈 내용은 각 도메인에서만 전문적으로 파악
및 정의할 수 있으므로 결국 각 도메인에서 자신의 파트에 대해서
작성해야 함
→결론 검증 계획서 템플릿 만들어서 각 도메인에게 뿌려지면
각자 알아서 템플릿 채워야 함