인터페이스 설계방법 인터페이스 설계 실무에서 주요 요소는 대부분 적용에 적합한 다음과 같은 다섯 가지 단계로 요약할 수 있다. · 단계 1 : SOI - 운용환경관계 식별 · 단계 2 : 시스템 또는 품목 아키텍처 개발 · 단계 3 : 아키텍처 논리적 개체관계 제시 · 단계 4 : 운용 인터페이스 유스 케이스 제시 · 단계 5 : 물리적 인터페이스 특성 제시 이제 인터페이스 설계방법의 각 단계를 살펴보도록 하자. 1. SOI - 운용환경관계 식별 방법론의 첫 번째 단계는 대상시스템(SOI)에 상응하는 인터페이스를 나타내는 사용자 운용 환경 내에서 연관 개체를 식별하는 방법이다. 2. 시스템 또는 품목 아키텍처 개발 외부 시스템과의 논리적 또는 물리적 관계를 나타내기 위한 시스템 또는 개체 아키텍처를 개발하는 단계이다. 3. 아키텍처 논리적 개체관계 제시 시스템이나 개체 아키텍처 또는 확인된 사용자 요구분석에 기초하여 인공시스템과 운용환경과 같은 내부 및 외부 개체 사이에 논리적 개체관계를 제시하는 단계이다. 일반적으로 이 단계는 공식화된 인터페이스를 기술하는 단계이다. 4. 운용 인터페이스 유스
[시스템 인터페이스 분석, 설계 및 통제(3)] 인터페이스 설계방법 [시스템 인터페이스 분석, 설계 및 통제(4)] 인터페이스를 적용한 시스템 능력 구성 인터페이스 표준화 어떤 형태의 시스템 설계와 마찬가지로 인터페이스 설계 또한 비용, 일정, 기술을 최소화하는 한편 특정 요구사항을 충족시키며 리스크를 지원해야 한다. 당신이 신규 인터페이스 솔루션을 설계할 때 발생하는 모든 시기에 당신은 입증되지 못한 인터페이스에 대한 위험을 완화하도록 준비해야 한다. 이러한 리스크에 따른 영향을 감소하는 방법은 이미 입증된 설계 솔루션을 사용하는 길이다. 부가적으로 당신이 선택한 어느 기술 솔루션도 아주 짧은 기간 내에 진부화 되고 있다는 사실을 생각해야 한다. 예리하게 비교해 보면 특히 컴퓨터와 같은 시장에 나와 있는 상용 제품은 완전히 새로운 시스템을 요구하지 않는 한 시스템 능력과 성능을 유지하기 위하여 기술적 업그레이드를 수용할 수 있도록 설계가 요구되고 있다. 산업시장 요구를 충족시키는 하나의 방법은 라인교체품목(LRU)을 모듈화, 상호교환, 융통성 및 유지보수 가능성을 달성하는 표준 인터페이스를 설정하는 길이다. 이것은 무엇을 의미하는가? 컴퓨터는 마더보드(LR
상호작용 구체화 1. 업무 설계와 분석 일단 시스템 기능이 특정 시스템 구성품에 대해 지정되고 나면, 기능은 일반적으로 보다 상세하게 정의될 수 있다. 인간에게 할당된 기능은 일반적으로 업무로 불린다. 시스템 요구사항과 기능 구조의 제약사항이 주어진다면 인간공학 엔지니어는 인간이 시스템 내에서 어떻게 그들에게 할당된 업무를 수행할 것인지 명확하게 정의할 필요가 있다. (1) 업무 목록 개발 인간이 수행하는 업무를 검토하기 전에, 고려되고 있는 업무의 완전한 목록을 종합할 필요가 있다. 그와 같은 분해가 유용하다면, 이 프로세스 또한 업무의 분해 과정이 포함된다. 거의 모든 인간공학 엔지니어에게 업무목록(task list)의 작성에 대한 책임이 주어지지만, 업무를 보다 잘 이해하기 위하여 시스템 엔지니어나 다른 설계자와 함께 일하기 원한다. 인간공학 엔지니어는 시스템 엔지니어와 다른 설계엔지니어로부터 얻은 정보를 평가하고 인적업무의 완전한 목록을 고안해 내게 될 것이다. 업무 목록 개발에 대한 부가적인 입력사항은 승인된 기능 할당과 인터페이스-특정 업무를 포함한다. 인터페이스-특정업무는 선택된 인터페이스의 기능들로 작성된다. 인터페이스-특정 업무는 통상적으로
이 장에서는 시스템 개발 기간 동안 인간 요소 엔지니어와 시스템 엔지니어 사이에 발생되는 중요한 상호작용을 기술한다. 이러한 상호작용은 공유되어야 하는 정보, 결정해야만 하는 사항, 그리고 승인이 요구되는 활동이나 전반적인 의사결정 활동을 포함한다. 이러한 정보는 인간공학이나 인간 시스템 엔지니어링(HSE : Human Systems Engineering)에 관한 전반적인 내용 또는 인간공학 업무를 수행하는 ‘방법(how-to)’에 대한 지침으로서의 역할을 하고자 함에 있다. 따라서 인간공학 노력의 통합과 이해를 통해 시스템 엔지니어에 대한 지침을 제공하는 데 그 목적이 있다. 이 장에 포함된 모든 정보는 시스템 엔지니어링과 인간공학 양 분야에 대한 업무분석으로부터 시작된다. 이 업무분석은 인력 충원 가용성(MAF : Manning Affordability Initiative)에 대한 인간중심 설계환경(HCDE : Human Centered Design Environment)을 지원하기 위하여 수행된다. 특정한 시스템 엔지니어링이나 인간공학 프로세스에 대해 잘 알지 못하는 상호작용을 독자적인 방법으로 알아보려고 하는 노력이 계속되어 왔다
시스템 설계 및 개발 품목과 CI에 대한 소유권 부여 개발규격이 진화함에 따라 CI 개발책임은 통합제품팀(IPT)이나 개발팀과 같은 소유자에게 그 책임을 부여해야 한다. 그림 1은 이러한 사례를 보여주고 있다. 여기서 어떻게 시스템 아키텍처가 제품 구조라인을 따라 분할되는지를 유의하라. 그림 1. CI 소유권과 책임 부여 이는 특별히 운용 단어로서의 ‘제품’에 대한 주요 포인트이다. 통합제품팀을 설정한 프로그램에 대하여 각 IPT는 ‘제품’ 개발에 초점을 두어 자기가 담당하고 있는 제품에 인터페이스가 되어있는 품목을 개발하고 있는 IPT와 상호 인터페이스를 협력하도록 한다. 예를 들면, IPT 1은 상호 인터페이스 설계 쟁점사항을 IPT 2와 협조한다. 한 제품을 개발하는 책임은 오로지 하나의 IPT에 국한된다. 다중 레벨 품목의 사이즈, 복잡도 및 위험 정도에 따라 그림 1에서와 같은 하나 또는 그 이상의 제품에 대한 책임을 부여해도 좋다. 중간 정도의 복잡도와 위험을 지닌 제품 A와 B를 개발하는 책임은 IPT 1에 부여된다. 반대로 제품 C에 대한 책임은 그 자체의 복잡도와 위험에 따라 IPT 2에 부여된다.