10. 개념 설계 프로세스 (Section 5.2)

요구사항 캡처 프로세스의 다음은 개념 설계 프로세스(Conceptual Design Process)이다.

 

그림 12 개념 설계 프로세스

개념 설계 프로세스와 다음에 나오는 상세 설계 프로세스에 대한 이해를 위해서 우선 앞서 보았던 전형적인 ASIC/PLD 프로세스와 하드웨어 설계 프로세스내의 5가지 프로세스를 매핑한 테이블을 다시 한 번 살펴보자.

 

붉은 박스로 표시된 부분이 설계와 구현 과정이다. DO-254 가이드라인에서는 다소 애매할 수 있는 ‘Conceptual’, ‘Detailed’라는 단어만을 사용해서 설명하고 있지만 좌측의 ASIC/PLD 프로세스에 포함되어 있는 단어들을 통해서 좀 더 개념을 명확하게 할 수 있을 것이다. 기본적으로 이런 정도의 개념을 가지고 앞으로 나오는 설명을 살펴보자.

 

10.1 개념 설계 프로세스 목표(Objectives)

 

개념 설계 프로세스에서는 다음과 같은 목표(Objectives)를 준수해야 한다.

 

 

해석을 보자.

 

1. 하드웨어 아이템 개념 설계가 요구사항과 일치하게 개발된다. 2. 파생 요구사항이 요구사항 캡처 혹은 다른 적절한 프로세스로 피드백된다. 3. 요구사항 누락 및 에러가 해결을 위해서 적절한 프로세스로 제공된다.

 

아주 원론적인 내용이다. 그리고 요구사항 캡처 프로세스에서도 보았던 파생 요구사항이나 요구사항 누락, 에러에 대한 설명을 보면 설계에 대한 내용보다는 오히려 요구사항에 대한 부분을 더 강조하고 있는 듯한 느낌도 든다.

 

일단 활동(Activities)에 대한 부분도 확인해 보자.

 

10.2 개념 설계 프로세스 활동(Activities)

 

개념 설계 프로세스의 활동(Activities)에 대해서 DO-254 가이드라인에서는 5가지를 제시하고 있다.

 

① 하드웨어 아이템에 대한 상위레벨 설명을 생성
a. 안전성과 관련된 아키텍처 제약 사항
b. 소프트웨어 혹은 다른 시스템 컴포넌트에서의 구현 제약 식별

② 주요 컴포넌트 식별
하드웨어 안전 요구사항에 미치는 영향, 미사용 기능의 영향 포함

③ 파생 요구사항을 요구사항 캡처 프로세서로 피드백

④ 요구사항 누락 및 에러를 해결하기 위해 적절한 프로세스로 피드백

⑤ 신뢰성, 유지 그리고 시험 특성의 식별

 

참고로 DO-254 가이드라인에서는 관련된 당사자들 간에 개념 설계 프로세스 활동의 공감을 얻기 위해서 ‘Design Review’와 같은 활동을 추천하고 있다. 개발 단계에서 흔히 접하는 ‘PDR’, ‘CDR’과 같은 중간 점검 회의라고 보면 된다.

 

이상의 내용으로 보면 DO-254에서는 개념 설계 프로세스를 통해서는 주요 컴포넌트를 구분하는 정도의 수준을 요구하고 있으며 그 과정에서 필연적으로 나오게 되는 요구사항에 대한 확인과 완성도를 높이는 것 역시 중요하다는 점을 강조하고 있다는 것을 확인할 수 있다. 보다 구체적인 활동은 다음 단계인 상세 설계 프로세스에서 수행되기 때문일 것이다.

 

이제 다음 단계인 상세 설계 프로세스 로 넘어가 보자.