시스템 설계자

이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : "시스템 아키텍트"– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2006년 12월) (이 템플릿 메시지 삭제 방법 및 삭제 타이밍에 대해 알아보기)

시스템 아키텍트

시스템 설계자는 크고 복잡한 시스템을 개별 엔지니어가 처리할 수 있는 관리 가능한 서브시스템으로 나눕니다.
직종.
이름	시스템 아키텍트
직업 유형	직업
액티비티 섹터	시스템 엔지니어링 시스템들 설계. 공학 기술
묘사
능력	사용자 도메인 지식, 과학 지식, 엔지니어링, 계획 및 관리 기술
필요한 교육	「교육」을 참조

시스템 아키텍트는 정보통신 테크놀로지 프로페셔널입니다.시스템 설계자는 특정 요건을 충족하기 위해 컴퓨터화된 시스템(소프트웨어와 하드웨어로 구성된 시스템)의 아키텍처를 정의합니다.이러한 정의에는 시스템의 컴포넌트, 컴포넌트 상호작용 및 인터페이스(환경, 특히 사용자와의 관계 포함), 설계 및 구현에 사용되는 테크놀로지 및 리소스가 포함됩니다.

시스템 설계자의 작업은 구현 문제를 방지하고 미래 단계에서 예상치 못한 확장/변경을 쉽게 허용하는 것을 추구해야 합니다.여기에는 폭넓은 경험이 필요하기 때문에 일반적으로 시스템 설계자는 하드웨어, 소프트웨어 및 유사한(사용자) 시스템에 대한 실질적이지만 일반적인 지식을 가진 매우 선임 기술자입니다.무엇보다도 시스템 설계자는 사용자의 경험 영역에 대해 상당히 잘 알고 있어야 합니다.예를 들어, 항공 교통 시스템의 설계자는 모든 수준의 사용자를 포함한 항공 교통 시스템의 모든 작업을 표면적으로 잘 알고 있어야 한다.

시스템 아키텍트의 직함에는 소프트웨어 엔지니어나 프로그래머보다 높은 수준의 설계 책임이 내포되어 있습니다.단, 일상 업무는 중복될 수 있습니다.

개요

시스템 설계자는 조직의 여러 이해관계자와 접촉하여 다양한 수준의 요구사항, 도메인, 실행 가능한 기술 및 예상되는 개발 프로세스를 파악합니다.이들의 작업에는 복수의 설계 및 구현 대안 결정, 식별된 모든 제약조건(비용, 일정, 공간, 전력, 안전성, 가용성, 신뢰성, 유지보수성, 가용성 및 기타 '장애' 등)에 기초하여 그러한 대안을 평가하고 추가 설계에 가장 적합한 옵션을 선택하는 것이 포함된다.이러한 작업의 출력은 시스템의 핵심 특성 및 나중에 변경하기 어려운 특성을 설정합니다.

소규모 시스템에서는 일반적으로 아키텍처가 개발자에 의해 직접 정의됩니다.단, 대규모 시스템에서는 시스템 전체의 개요를 설명하고 사용자, 스폰서 및 기타 이해관계자와 다른 한쪽의 엔지니어 간에 상호 작용할 수 있도록 시스템 설계자를 임명해야 합니다.매우 크고 매우 복잡한 시스템에는 여러 명의 설계자가 포함될 수 있습니다.이 경우 설계자는 공동으로 서브시스템 또는 측면을 통합하고 시스템 전체를 담당하는 최고 설계자에게 응답합니다.일반적으로 설계자의 역할은 사용자와 엔지니어 사이의 중개자로서 사용자의 요구와 요건을 엔지니어가 주어진 (엔지니어링) 제약조건 내에서 실행할 수 있다고 결정한 것과 조정하는 것입니다.

시스템 설계에서 설계자(및 엔지니어)는 다음을 담당합니다.

• 사용자 및 스폰서 및 기타 모든 이해관계자와 접촉하여 (진화하는) 요구를 판단합니다.
• 사용자의 요구 및 기타 제약사항에 따라 최고 수준의 시스템 요구사항을 생성합니다.
• 이 일련의 높은 수준의 요건이 일관되고 완전하며 정확하며 운용적으로 정의되어 있는지 확인합니다.
• 요구사항이 수동, 소프트웨어 또는 하드웨어 기능에 의해 가장 적합한지 여부를 판단하기 위해 비용 편익 분석을 수행하고 상용 또는 이미 개발된 구성요소를 최대한 활용합니다.
• 파티션 알고리즘(및 기타 프로세스)을 개발하여 파티션 간에, 그리고 사용자와 시스템 간에 최소한의 통신이 필요하도록 현재 및 예측 가능한 모든 요건을 개별 파티션에 할당합니다.
• 대규모 시스템을 서브시스템과 컴포넌트로 분할(연속 레이어)합니다.각 서브시스템과 컴포넌트는 단일 엔지니어 또는 엔지니어 팀 또는 부하 설계자가 처리할 수 있습니다.
• 설계 및 구현 엔지니어 및 설계자와 접촉하여 설계 또는 구현 중에 발생하는 모든 문제를 기본적인 설계 개념, 사용자의 요구 및 제약사항에 따라 해결할 수 있도록 합니다.
• 최대한 견고하고 확장 가능한 설계가 개발되도록 보장합니다.
• 설계자, 테스트 엔지니어 및 사용자와 함께 특히 컴퓨터 휴먼 인터페이스에 대한 모든 높은 수준의 요건이 충족되었음을 판단하는 일련의 승인 테스트 요건 생성.
• 스케치, 모델, 초기 사용자 가이드, 프로토타입 등의 제품을 생성하여 사용자와 엔지니어가 지속적으로 최신 상태로 유지하고 진화하는 시스템에 대해 합의할 수 있도록 합니다.
• 모든 아키텍처 제품 및 아키텍처 입력이 포함된 제품이 최신 상태로 유지되고 심각한 지연이나 구식이 되지 않도록 합니다.

시스템 설계자: 토픽

대규모 시스템 아키텍처는 설계는커녕 한 사람이 상상하기엔 너무 큰 시스템을 처리하기 위한 방법으로 개발되었습니다.이러한 규모의 시스템은 급속히 표준이 되고 있기 때문에, 대규모에서 매우 큰 시스템의 문제를 해결하기 위해서, 아키텍처의 어프로치와 아키텍트가 점점 더 필요하게 됩니다.일반적으로 점점 더 큰 시스템은 계층화 접근법에 의해 '사람'의 비율로 감소됩니다. 계층화 접근법에서는 각 계층이 개별적으로 이해할 수 있는 여러 하위 계층으로 구성됩니다. 각 계층에는 자체 수석 엔지니어 및/또는 설계자가 있습니다.한 레벨의 완전한 레이어는 상위 레이어의 기능적인 '컴포넌트'로 표시됩니다(최고 레이어에서는 모두 사라질 수 있습니다).

사용자 및 스폰서

건축가는 인간의 요구를 이해하고 인간의 기능적이고 미적으로 만족할 수 있는 제품을 개발해야 합니다.훌륭한 설계자는 최종 제품에 대한 사용자의 비전과 그 비전에서 요구사항을 도출하고 구현하는 프로세스의 주요 관리자이기도 합니다.

건축가는 정확한 절차를 따르지 않는다.이들은 매우 인터랙티브하고 비교적 비공식적인 방법으로 사용자/스폰서들과 소통하며, 함께 설계된 (엔드) 시스템에 필요한 진정한 요건을 추출합니다.설계자는 최종 사용자 및 (주요) 시스템 엔지니어와의 지속적인 커뮤니케이션을 유지해야 합니다.따라서 설계자는 사용자의 환경과 문제, 그리고 솔루션 공간의 엔지니어링 환경을 잘 알고 있어야 합니다.

높은 수준의 요건

사용자 요건 사양은 사용자와 설계자의 공동 제품이어야 합니다.사용자는 각자의 요구와 위시리스트를 가져오고 설계자는 비용, 시간 및 기타 제약 조건 내에서 실행 가능한 것을 알 수 있습니다.사용자의 요구가 일련의 높은 수준의 요건으로 변환되는 경우, 수용 테스트의 첫 번째 버전을 작성할 수 있는 최적의 시기이기도 합니다.이 버전은 그 요건을 엄격하게 최신 상태로 유지해야 합니다.이렇게 하면 사용자는 자신이 무엇을 얻고 있는지 확실히 알 수 있습니다.또한 테스트 불가능한 요구사항, 오해 및 요구사항 증가로부터 보호합니다.

엔지니어링 요건의 첫 번째 레벨의 개발은 순수하게 분석적인 작업이 아니며 설계자와 엔지니어가 모두 참여해야 합니다.제약조건을 충족하기 위해 타협이 필요한 경우 설계자는 최종 제품과 전체적인 외관과 느낌이 사용자의 의도를 크게 벗어나지 않도록 해야 합니다.엔지니어는 제약조건을 최적화하면서도 실행 가능하고 신뢰성 있으며 확장 가능하며 견고한 제품을 보장하는 설계 개발에 집중해야 합니다.사용자에게 필요한 서비스를 제공하는 것이 엔지니어링된 시스템의 진정한 기능입니다.그러나 시스템이 점점 더 커지고 복잡해짐에 따라 시스템, 하드웨어 및 소프트웨어 아키텍처의 보다 일반적인 원칙을 설계에 적용하는 것, 즉 기존 시스템 개발 원칙의 좁은 적용은 불충분하다는 것을 알게 되었습니다.(하위) 시스템이 필요할 것 같습니다.아키텍처는 최종 완제품의 단순화된 모델로 볼 수도 있습니다.아키텍처의 주된 기능은 부품과 부품 간의 관계를 정의함으로써 특히 컴퓨터 휴먼 인터페이스의 경우 사용자가 생각하고 있는 것을 일관되고 완전하며 정확하게 표현하는 것입니다.또한 부품이 서로 잘 맞고 원하는 방식으로 관련되도록 하기 위해 사용됩니다.

사용자 세계의 아키텍처와 엔지니어링된 시스템 아키텍처를 구별할 필요가 있습니다.전자는 사용자 세계의 문제와 해결책을 나타내고 해결합니다.주로 엔지니어링된 시스템의 컴퓨터 휴먼 인터페이스(CHI)에서 캡처됩니다.엔지니어링된 시스템은 엔지니어링 솔루션을 나타냅니다. 즉, 엔지니어가 CHI를 지원하기 위해 기술 인프라의 구성요소를 개발 및/또는 선택 및 결합하는 방법을 제안합니다.숙련된 건축가가 없으면 두 건축물을 혼동하는 불행한 경향이 있습니다.단, 엔지니어는 하드웨어와 소프트웨어, 기술 솔루션 공간의 관점에서 생각하는 반면 사용자는 적절한 시간 내에 A지점에서 B지점으로 사람을 이동시키고 적절한 에너지 소비를 통해 문제를 해결하거나 고객과 직원에게 필요한 정보를 제공하는 등의 관점에서 생각할 수 있습니다.시스템 설계자는 사용자 환경의 아키텍처와 엔지니어링 시스템 아키텍처(모두 잠재적으로 유용한)에 대한 지식을 결합해야 합니다.전자는 사용자와의 공동 활동이고 후자는 엔지니어와의 공동 활동입니다.이 제품은 사용자의 요건을 반영한 고도의 요건 세트이며 엔지니어가 시스템 설계 요건을 개발하는 데 사용할 수 있습니다.

요구사항은 프로젝트 과정, 특히 장기간에 걸쳐 진화하기 때문에 사용자가 시스템을 받아들일 때까지 설계자가 필요합니다.설계자는 개발 과정에서 이루어진 모든 변경과 해석이 사용자의 관점을 훼손하지 않도록 보장합니다.

비용/편익 분석

건축가는 제너럴리스트입니다.이들은 하나의 기술에 대한 전문가가 아니라 많은 기술에 대한 지식을 갖추고 특정 상황에 대한 적용 가능성을 판단할 수 있어야 합니다.또한 지식을 실제 상황에도 적용하지만 하드웨어와 소프트웨어, 수동 등 다양한 기술을 사용하여 다양한 솔루션의 비용 및 이점을 평가하고 시스템 전체가 사용자의 기대에 따라 작동하도록 보장합니다.

많은 상용 또는 이미 개발된 하드웨어 및 소프트웨어 컴포넌트는 비용, 응답, 처리량 등의 제약조건에 따라 독립적으로 선택될 수 있습니다.경우에 따라 설계자는 이미 (거의) 도움 없이 엔드 시스템을 조립할 수 있습니다.또는 컴포넌트를 선택하고 특수 목적 기능을 설계 및 구축하기 위해 하드웨어 또는 소프트웨어 엔지니어의 도움이 필요할 수 있습니다.설계자(또는 엔지니어)는 안전, 보안, 통신, 특수 목적 하드웨어, 그래픽, 인적 요인, 테스트 및 평가, 품질 관리, 신뢰성, 유지보수성, 가용성, 인터페이스 관리 등 다른 전문가의 도움을 받을 수도 있습니다.효과적인 시스템 아키텍처 팀은 필요에 따라 중요한 전문 분야의 전문가와 접촉할 수 있어야 합니다.

파티셔닝 및 계층화

건물을 계획하는 건축가는 주민들에게 즐겁고 유용할 수 있도록 전체적인 디자인을 작업합니다.단독주택을 짓기 위해서는 건축가 한 명만으로도 충분할 수 있지만, 새로운 고층건물을 설계할 때 발생하는 세부적인 문제를 해결하기 위해서는 많은 엔지니어가 필요할 수 있다.작업이 충분히 크고 복잡한 경우에는 아키텍처의 일부를 독립된 컴포넌트로 설계할 수 있습니다.즉, 주택단지를 건설하는 경우 건축팀의 일원으로 단지에 한 명의 건축가와 각 건물 유형에 한 명의 건축가가 있을 수 있습니다.

대규모 자동화 시스템에는 설계자와 엔지니어링 인재도 필요합니다.엔지니어링된 시스템이 충분히 크고 복잡한 경우, 시스템 설계자는 하드웨어 설계자 또는 소프트웨어 설계자의 작업 일부를 따를 수 있습니다.다만, 이들 모두가 공동 아키텍처 팀의 멤버일 수도 있습니다.

설계자는 시스템 요건을 단일 하드웨어 또는 소프트웨어 엔지니어 또는 엔지니어링 매니저와 팀의 범위 내에 있는 주요 컴포넌트 또는 서브시스템에 할당해야 합니다.그러나 설계자를 엔지니어링 슈퍼바이저로 간주해서는 안 됩니다(항목의 크기가 충분히 크거나 복잡하면 수석 설계자는 보다 전문화된 설계자에게 부분을 배분합니다).이러한 각 구성요소/하위 시스템은 충분히 독립된 객체이며 시뮬레이션된 입력을 공급하고 출력을 기록하기 위한 단순한 테스트베드만을 사용하여 전체와 분리된 완전한 구성요소로 테스트할 수 있다.즉, 항공 교통 관제 시스템이 데이터 관리 서브시스템을 설계 및 구축하기 위해 어떻게 작동하는지 알 필요는 없습니다.서브시스템이 동작할 것으로 예상되는 제약조건만 알면 됩니다.

훌륭한 설계자는 시스템이 아무리 복잡하더라도 각 (하위) 시스템 또는 계층에 대해 비교적 단순하고 "깨끗한" 개념으로 구축되어 특별한 훈련 없이 모든 사람, 특히 사용자가 쉽게 이해할 수 있도록 합니다.설계자는 최소한의 휴리스틱을 사용하여 각 파티션이 올바르게 정의되고 클러지, 회피책, 숏컷 또는 혼란스러운 세부사항과 예외가 없는지 확인합니다.사용자가 진화함에 따라 (일단 시스템이 현장에서 사용되고 나면) 예외, 특수한 경우 및 훨씬 더 많은 "미세 인쇄"를 포함하는 개념보다 나중에 단순한 개념을 발전시키는 것이 훨씬 더 쉽습니다.

아키텍처를 계층화하는 것은 한 사람이 이해할 수 있도록 각 계층에서 아키텍처를 충분히 단순하게 유지하는 데 중요합니다.계층이 올라가면 하위 계층의 전체 시스템이 상위 계층의 단순한 구성요소가 되고 상위 계층에서 모두 사라질 수 있습니다.

인수 테스트

인수 테스트는 시스템 설계자의 주요 책임입니다.이는 프로그램 리드가 사용자에게 시스템이 원래 계획대로 진행되었으며 관련된 모든 설계자와 엔지니어가 목표를 달성했음을 증명하는 주요 수단입니다.

사용자 및 엔지니어와의 커뮤니케이션

건축 건축가는 스케치, 모형, 그리고 그림을 사용합니다.자동화 시스템(또는 소프트웨어 또는 하드웨어) 설계자는 스케치, 모델 및 프로토타입을 사용하여 사용자, 엔지니어 및 기타 설계자와 다양한 솔루션 및 결과를 논의해야 합니다.사용 설명서의 초기 초안 버전은 특히 프로토타입과 함께 매우 중요합니다.단, 고객이 합리적으로 이해할 수 있는 실용적이고 잘 작성된 요건 또는 사양을 작성하는 것이 중요합니다(고객이 적절히 승인할 수 있도록 하지만 주요 사용자의 요건은 이해를 위한 예비 사용자 매뉴얼에 기재해야 합니다).그러나 설계자와 다른 구현자가 의미나 의도에 대해 의심의 여지가 없도록 정확하고 명확한 언어를 사용해야 합니다.특히, 모든 요건은 테스트 가능해야 하며, 테스트 계획의 초기 초안은 요건과 동시에 개발되어야 한다.모든 이해관계자는 프로그램 시작 시 요건 충족의 유일한 결정요인으로 승인 테스트 설명 또는 이에 상당하는 사항을 승인해야 한다.

건축가의 비유

미국의 많은 주에서 "건축가"라는 단어의 어떤 형태든 사용은 "제목법"에 의해 규제되고 있으며,^[1] 이를 사용하려면 건축 설계사 자격증이 있어야 합니다.

영국의 아키텍트 등록 위원회는 제한된 사용에서 아키텍트의 사용(소프트웨어와 IT 환경에서 사용되는 경우)을 제외합니다.^[2]

「 」를 참조해 주세요.

• 엔터프라이즈 아키텍처
• 엔터프라이즈 아키텍트
• 하드웨어 아키텍처
• 요건 분석
• 소프트웨어 아키텍처
• 소프트웨어 엔지니어링
• 시스템 아키텍처
• 시스템 모델링
• 시스템 엔지니어링
• 시스템 설계
• 비즈니스 분석가
• 서비스 지향 모델링 프레임워크(SOMF)

레퍼런스

추가 정보

• Donald Firesmith 외:엔지니어링 시스템 아키텍처의 방법 프레임워크, (2008)
• Mark W. Maier and Rechtin, Everhardt, The Art of Systems Architecting, 제3판(2009년)
• Gerrit Muller, "시스템 아키텍처: 비즈니스 관점", CRC Press, (2012).
• Eberhardt Rechtin, Systems Architecting: Creating & Building Complex Systems, 1991년
• J. H. Saltzer, M. F. Kaashoek, 컴퓨터 시스템 설계 원리: 소개, Morgan Kaufmann, 2009.
• Rob Williams, 컴퓨터 시스템 아키텍처: 네트워킹 접근법, 제2판 (2006년 12월)

외부 링크

• 컴퓨터 시스템 설계의 원리: 개요 – MIT Open Course Ware
• 시스템 아키텍처: Canaxia가 설계자를 참여시킵니다, 기사