위키원
시스템공학
시스템공학(systems engineering)은 복잡한 시스템을 합리적으로 설계하거나 개발하기 위해 고안된 공학분야이다.
시스템이란 둘 이상의 객체나 요소들이 정의된 목적달성을 위해 서로 유기적으로 상호작용하여 시너지 효과를 발휘하는 결합체를 말한다. 다만 여기에 하드웨어만 들어가는 것이 아니다. 예를 들어 항공기 시스템이라 하면, 항공기, 조종사, 정비사, 교육훈련 시스템과 격납고, 활주로, 관제시설 등을 포함한다. 이러한 시스템은 각 자원들이 얼마나 균형과 조화를 이루냐에 따라 시스템 전체의 가치와 효율성이 결정된다. 시스템공학이란 복잡한 시스템을 개발함에 있어 경제학, 공학 등의 학문 지식을 통합시켜놓은 분야이다.
시스템공학을 체계공학 · 조직공학 · 계통공학이라고 하며, 간단히 SE로 나타낸다. 각종 구성요소가 하나의 유기적 질서 아래 결합되어 일정한 투입을 하면 그에 따른 산출이 생기는 처리과정의 체계를 시스템이라고 한다. SE는 시스템의 구조를 해명하는 시스템분석(system analysis), 필요한 시스템을 설계하는 시스템디자인(시스템 설계), 시스템을 실제로 형성하는 시스템 구성(system configuration)으로 이루어진다. 그러나 시스템에는 천체의 운동과 같은 자연적 시스템과 전화망같은 인공적 시스템이 있는데, SE의 대상은 후자에 국한된다. 더구나 인공적 시스템에서 기계 자체와 같이 순전한 물적인 시스템의 분석 ·설계 ·구성에 있어서는 특히 SE란 말을 사용해오지 않았다.
SE를 강조하게 된 것은 조직이나 사회의 현상과 같이 인간 ·물건 ·정보 ·기술 ·시간과 같은 여러 요소가 복잡하게 조립되어 움직이는 시스템(man machine system)을 과학적으로 해명하고 그것을 유효하게 구성 ·조작하고자 하는 데에 출발점이 있다. 1950년대 후반 미국에서 국방이나 우주관계의 규모가 큰 시스템을 개발한 경험을 바탕으로 그 탄생을 보게 되었다. 따라서 SE는 조직이나 관리와 밀접한 관계가 있다. SE는 당초, 재고관리 시스템과 같은 비교적 작은 시스템에 적용되었으나 차차 그것을 서브 시스템으로 하는 큰 시스템에도 적용되고 있으며, 기술이 발달됨에 따라 환경오염문제 ·교통문제 ·도시문제 ·해양개발문제 등에도 크게 이바지하게 될 것이다.
개요[편집]
시스템공학은 사회기술적 시스템 (Socio-technical systems) 을 명세(specifying)하고, 설계(designing)하고, 구현(implementing)하고, validating하고, deploying하고, 유지(maintaining)하는 것을 말한다. 시스템이 제공하는 서비스들, 서비스들을 구축하고 작동시키는 것에 대한 제한(constraint), 그리고 그것들이 사용되는 방법들과 관련된다.
시스템공학은 성공적인 시스템 개발을 실현하기 위한 포괄적(holistic) 접근방법으로, 일반시스템이론(General System Theory)의 핵심 개념인 구성요소들간 상호작용과 창발성(Emergent Property)을 제품시스템 또는 사회기술적인 시스템 개발에 응용하여 문제해결의 공정, 방법 및 도구들을 공부하는 분야이다. 하부분야로 시스템 공학 관리, 요건 공학, 시스템 아키텍팅(시스템의 구조를 만드는 일을 하는 것), 시스템 모델링·모사·해석, 시스템 설계, 시스템 통합시험, 시스템 검증 등의 분야가 있다. 시스템의 정의에 개념적, 물리적, 사람들의 조직 등을 포함하면 구성요소들의 상호작용을 통한 창발성의 추구는 모든 인위적 활동과 그 결과물 들이 모두 포함된다. 따라서 시스템 기술 프로세스의 응용범위는 모든 대상 시스템들로 넓어진다. 시스템 아키텍팅 분야가 엔터프라이즈 아키텍팅에 응용되는 것이 좋은 예가 된다.
포괄적 접근방법이란 시스템 수명 주기, 전문 분야, 이해 관계자, 임무·목표, 자연 환경, 외부 시스템, 불확실성 요소 등 상호작용을 하는 모든 것들을 고려하여 개발의 문제와 해결책을 정의하고 찾는 방법이다. 복잡한 시스템일수록 반복적·점진적으로 상세히 정의하며 개념 설계, 예비 설계, 상세 설계 공정을 기획·조정 및 관리하며 성공적 개발사업의 수행을 위해 부분 최적화가 아닌 전체 최적화를 위해 모든 기술적 분야를 총괄하는 시스템 기술프로세스를 주도하며 수행한다. 시스템 공학은 필요한 모든 전문분야와 이해관계자들의 요구사항과 제약사항을 절충하여 시스템 요구사항을 정하고 이를 만족하는 시스템 설계 해결책을 찾기 위해 개발 프로세스, 방법 및 도구를 공부한다. 시스템 공학자는 사용자를 포함한 모든 이해관계자의 요구를 충족하는 시스템 해결책을 얻기 위해서 사업적인 면과 기술적인 면을 모두 고려해야 한다.
시스템공핚에 종사하는 사람은 시스템 엔지니어라고 한다.
주요 방법론[편집]
아래는 표준적으로 쓰이는 시스템 엔지니어링 방법론. 모두 영문판이며 인터넷에서 표준 자료를 무료로 다운로드할 수 있다.
- MIL-STD-810: 미 국방부에서 만든 체계공학 방법론이다. 이 중 MIL-STD-810G는 밀스펙이라 해서 군용품 신뢰성의 기준이 되었다.
- EIA-632:
- ISO / IEC 15288
- IEEE 1233
- CMMI-DEV
- CMMI-SVC
형상관리[편집]
- CSCI
- HWCI
회의체[편집]
- 체계요구사항 검토회의(SRR, System Requirement Review)
- 체계기능 검토회의(SFR, System Function Review)
- 체계설계 검토회의(SDR, System Design Review)
- 기본설계 검토회의(PDR, Preliminary Design Review)
- 상세설계 검토회의(CDR, Critical Design Review)
- 최종설계 검토회의(FDR, Final Design Review)
- 사업관리 검토회의(PMR, Project Management Review)
- 시험준비 검토회의(TRR, Test Readiness Review)
시스템공학 프로세스[편집]
1) 시스템의 서로 다른 부분들을 병렬적으로 개발하려는 필요 때문에, 일반적으로 Waterfall 모델을 따른다.
- 하드웨어를 수정하는 것은 매우 비용이 많이 들기 때문에, 단계들(phases) 사이에 작은 범위로 반복한다.
- 소프트웨어는 하드웨어 문제를 보상해야 할 것이다.
2) 서로 다른 지식체계를 가지고 함께 일해야 하는, 엔지니어들을 포함하는 것은 피할 수 없다.
- 엔지니어들은 서로 다른 지식 체계를 가지고 있기 때문에, 사용하는 어휘가 다를 것이다. 그러므로 많은 협상이 필요하다. 엔지니어들은 각자 충족시켜야하는 개인적인 안건들을 가지고 있을 것이다.
1단계: 요구사항 정의 (Requirements definition)[편집]
Requirements definition에서 정의되는 요구사항은 3가지 종류가 있다. (1) Abstract functional requirements ... 시스템 기능들은 추상화된 방법으로 정의된다.
(2) System properties ... 시스템의 일반적인 Non-functional requirements은 정의된다.
(3) Undesirable characteristics ... 수용될 수 없는 시스템의 행동들이 명시된다.
- -시스템을 사용하는 조직 전체의 목표들도 정의되어야 한다.
※시스템 목표 (System objectives)
- - 특정한 환경에서 시스템이 필요한 이유, 시스템이 만들어지는 이유를 정의해야 한다.
1) 기능적인 목표 (Functional objectives)
- - 도난 화재 경보 시스템을 예로 들면, 이 시스템은 도난과 화재에 대해 내부 그리고 외부 경고를 제공해야 할 것이다.
2) 조직의 목표 (Organisational objectives)
- - 도난 화재 경보 시스템을 예로 들면, 그 시스템을 사용하는 빌딩의 원래 기능이 도난 또는 화재에 의해 심각하게 파손되지 않음을 보장해야 할 것이다.
※시스템 요구사항 문제(System requirements problems)
- - 복잡한 시스템은 보통 나쁜 문제들을 해결할 수 있도록 개발된다.
- => 충분히 이해되지 않는 문제들을 해결할 수 있어야 한다.
- => 시스템이 점점 명시됨에 따라(being specified) 변한다.
- - 시스템의 lifetime 동안 하드웨어 개발과 커뮤니케이션 개발은 예상되어져야 한다.
- - 시스템의 컴포넌트 구조를 알지 않는 상태에서, 비기능적 요구사항들을 정의하는 것은 특히 더 어렵다.
2단계: 시스템 설계 (System design)[편집]
1) Partition requirements
- - 요구사항들을 관련된 그룹으로 조직한다.
2) Identify sub-systems
- - 시스템 요구사항을 집합적으로 충족시키는 sub-systems의 집합을 식별한다.
3) Assign requirements to sub-systems
- - 요구사항들을 서브시스템들에 할당한다.
- - COTS(Commercial, Off-The-Shelf)가 통합되는 경우, 특정한 문제들을 야기한다.
4) Specify sub-system functionality.
5) Define sub-system interfaces
- - 서브시스템을 병렬적으로 개발하기 위한, 중요한 활동이다.
※시스템 설계 문제 (System design problems)
- - 하드웨어, 소프트웨어, 사람 컴포넌트로 요구사항을 파티셔닝하는 것은 많은 협상을 포함할 것이다.
- - 어려운 설계 문제들은 소프트웨어를 사용하여 쉽게 해결된 것이라고 종종 추정된다.
- - 하드웨어 플랫폼들은 소프트웨어 요구사항에 부적절할 것이다. 그러므로 소프트웨어가 이를 보상해야 한다.
※요구사항과 설계
- - 요구 공학 (Requirements engineering)과 시스템 설계는 서로 연결되어 있는 불가분의 관계다.
- - 시스템의 환경과 다른 시스템들에 의해 제기되는 제한들(Constraints)은, 실제 사용될 디자인을 선택할 때 영향을 미친다.
- - 초기 설계는 요구사항을 구조화하는 데 필요할 것이다.
- - 설계를 하면 할수록, 요구사항에 대해 더 잘 알게 될 것이다.
- - Spiral model
※시스템 모델링 (System Modeling)
- - 구조적인 모델은 시스템을 구성하는 서브시스템들의 추상화된 관점을 표현한다.
- - 서브시스템들 사이의 주요한 정보 흐름들을 포함할 수 있다.
- - 일반적으로 블록 다이어그램으로 표현된다.
- - 모델에서, 기능적인 컴포넌트들의 서로 다른 종류를 식별할 수 있다.
- - 예를 들어, 강도 알람 시스템은 다음처럼 architectural model로 표현할 수 있다.
다음처럼 각각의 서브시스템에 설명(description)을 달 수도 있다.
- 움직임 센서 : 시스템에 의해 감시되는 방에서 움직임을 감지한다.
- 문 센서 : 빌딩 외부 문이 열리는 것을 감지한다.
- 알람 컨트롤러 : 시스템의 동작을 통제한다.
- 사이렌 : 침입이 의심될 때 들을 수 있는 경고를 발생시킨다.
- Voice Synthesiser : 의심되는 침입의 위치를 알려주는 음성 메시지를 합성한다.
- Telephone Caller : 보안, 경찰로의 외부 연락을 취한다.
3단계: 서브시스템 개발 (Sub-system development)[편집]
- - 하드웨어, 소프트웨어, 그리고 커뮤니케이션을 개발하는 병렬 프로젝트이다.
- - COTS 시스템 입수를 포함할 수도 있다.
- - 시스템의 변화 알리는 메커니즘이 관료적이고 느리다면, 개발 일정이 늦어질 것이다.
- => 재작업의 필요성이 커진다.
4단계: 시스템 통합 (System integration)[편집]
- - 시스템을 만들기 위해, 하드웨어와 소프트웨어와 사람을 함께 배치하는 프로세스이다.
- - 서브시스템들이 한 번에 하나씩 통합될 수 있도록, 점진적으로 작업되어야 한다.
- - 서브시스템들 간의 인터페이스 문제들은 보통 System integration 단계에서 발견된다.
- - 시스템 컴포넌트들의 조직적이지 않은 전달(delivery)은 문제가 된다.
5단계: 시스템 설치 (System installation)[편집]
- - 시스템이 완성된 후, 시스템은 사용자,고객의 환경에 설치되어야 한다.
- - 환경적인 전제들이 틀릴 수 있다.
- - 새로운 시스템이 도입되는 것에 대해 사람을의 저항이 있을 수 있다.
- - 어떤 경우에, 시스템은 다른 대안 시스템들과 공존해야 할 것이다.
- - 케이블 문제와 같이, 물리적인 설치 문제가 있을 수 있다.
- - Operator 훈련이 식별되어야 한다.
6단계: 시스템 진화 (System evolution)[편집]
1) 큰 시스템들은 긴 lifetime을 갖는다. 큰 시스템들은 변화하는 요구사항을 충족시키도록 진화되어야 한다.
2) 진화는 본래 매우 비용이 큰 활동이다.
- - 변화들은 기술적이고, 사업적인 관점에서 분석되어야 한다.
- - 서브시스템들의 상호작용으로 인해, 예기치 못한 문제들이 발생할 수 있다.
- - 원래의 설계 결정을 고수해야할 근거는 거의 없다.
- - 시스템 구조(System structure)는 변화가 생김에 따라 점점 더 더러워진다.
3) 유지보수 되어야만 하는 현존하는 시스템을 레거시 시스템 (Legacy systems) 이라고 부른다.
7단계: 시스템 해체 (Decommissioning)[편집]
- - 시스템의 유용한 lifetime이 끝난 후, 시스템의 서비스를 종료하는 단계이다.
- - 위험한 화학물질 등 환경을 오염시킬 수 있는 물질을 제거할 필요가 있다.
- - 캡슐화를 통해, 시스템 설계에 포함되어 계획되어야 한다.
- - 데이터를 재구조화하거나, 다른 시스템에서 사용될 수 있도록 전환할 필요가 있을 수 있다.
※조직과 사람 그리고 시스템
- - 사회기술적 시스템 (Socio-technical systems) 은 컴퓨터 하드웨어, 소프트웨어, 사람을 포함하며, 어떤 사업적인 목표를 달성하기 위해 설계된다.
- - 사회기술적 시스템 (Socio-technical systems) 은 조직의 목표 또는 사업의 목표를 달성하는 것을 돕도록 의도된 조직의 시스템이다.
- - 시스템이 사용되는 조직의 환경을 이해하지 않는다면, 시스템은 사업과 시스템의 사용자의 실제 필요를 충족시키기 어려울 것이다.
※사람과 조직의 요소 (Human and Organisational factors)
1) Process changes
- - 시스템이 환경에서 사용되는 work processes에 변화를 요구하는가?
2) Job changes
- - 시스템이 환경에서의 사용자들을 단순화하는가? 또는 사용자들로 하여금 그들이 일하는 방식을 바꾸게 하는가?
3) Organisational changes
- - 시스템이 조직에서의 정치적인 권력 구조를 바꾸는가?
※조직의 프로세스
- - 시스템 공학의 프로세스들은 조직의 procurement processes와 겹치고, 서로 상호작용한다.
- - Operational processes은 이도된 목적을 위한 시스템을 사용하는 것에 포함되어 있는 프로세스들이다. 새로운 시스템에서, Operational processes는 시스템 설계의 부분으로서 정의되어야만 한다.
- - Operational processes는 유동적일 수 있게 설계되어야하며, operations이 특정한 방향으로 행해지도록 강제해서는 안된다. 문제가 발생했을 때, human operators가 그들의 계획을 사용할 수 있다는 사실은 중요하다.
- Procurement/development processes
※시스템 조달 (System procurement)
1) 한 조직이 어떤 필요를 만족시킬 수 있도록 시스템을 획득하는 것을 말한다.
2) 일반적으로, Procurement를 하기 전에 System specification과 architecural design이 필요하다.
- - 시스템 개발 계약을 하기 위한 specification이 필요할 것이다.
- - specification을 하면 필요에 따라 COTS system을 구매할 수도 있을 것이다. 보통 이렇게 하는 것이 아무 준비도 없는 상태에서 개발을 하는 것보다 더 비용이 저렴하다.
3) 일반적으로 크고 복잡한 시스템은 COTS와 특별하게 설계된 컴포넌트의 조합으로 구성된다. 이렇게 다양한 종류의 컴포넌트를 위한 Procurement processes은 다양하다.
.png)
※Procurement issue
- - 요구사항들은 COTS 컴포넌트의 역량에 맞도록 수정되어야만 할 것이다.
- - 요구사항 명세(requirements specification)는 시스템 개발 계약의 한 부분이다.
- - 시스템을 빌드할 도급업자가 선택된 후에, 일반적으로 변화를 서로 조율할 수 있는 계약 협상 기간이 있다.
※Contractors 와 Sub-contractors
- - 큰 하드웨어/소픝웨어 시스템들을 Procurement하는 것은 몇몇의 주요 도급업자(Contractor) 중심으로 이루어진다.
- - 시스템의 일부를 지원하기 위해, 또 다른 도급업자에게 Sub-contracts가 이슈된다.
- - 고객(Customer)는 주요 도급업자와 계약하며, Sub-contractors와 직접적으로 거래하지는 않는다.
※레거시 시스템 (Legacy systems)
1) 오래 되거나 한물 간 기술을 사용하여 개발된 Socio-technical systems를 말한다.
2) 사업을 하는데 중요하여 이러한 시스템을 버리기는 너무 위험한 경우가 많다.
- - 은행 고객 회계 시스템
- - 비행기 유지보수 시스템
3) Legacy systems은 새로운 사업 프로세스를 제한하고, 회사 예산의 높은 비중을 소비하게 한다.
※레거시 시스템 (Legacy system) 컴포넌트
_%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8.png)
1) Hardware
- - 구식의 메인프레임 하드웨어일 것이다.
2) Support Software
- - 더 이상 사업에 관련이 없는 공급업자가 포함되어 있을 것이다.
3) Application Software
- - 구식의 프로그래밍 언어로 쓰여져있을 것이다.
4) Application data
- - incomplete하거나 inconsistent한 경우가 많을 것이다.
5) Business processes
- - 소프트웨어의 구조나 기능에 의해 제한될 것이다.
6) Business Policies and Rules
- - 시스템 소프트웨어에 내재되어 있거나 삽입되어 있을 것이다.
참고자료[편집]
- 〈시스템 공학〉, 《위키백과》
- 〈[url 제목]〉, 《사이트명》
- 〈체계공학〉, 《나무위키》
- 〈시스템공학〉, 《두산백과》
- bycho211, 〈시스템 공학 (System Engineering)〉, 《네이버 블로그》, 2020-01-21
같이 보기[편집]
