3.9 시스템 엔지니어링

개요와 동기

시스템 엔지니어링은 복잡한 시스템 전체를 처음부터 끝까지 엔지니어링하여 모든 부분이 함께 작동해 실제 필요를 충족하도록 하는 규율입니다. 그 부분에는 소프트웨어보다 훨씬 많은 것이 포함됩니다. 현대적 시스템은 대개 소프트웨어, 하드웨어, 사람, 데이터, 프로세스를 결합하며 지저분한 현실 세계에서 동작해야 합니다. 시스템 엔지니어링은 시스템의 전 수명에 걸쳐 이 모든 것을 정렬된 상태로 유지합니다.

이것은 소프트웨어 아키텍처와 다릅니다. 소프트웨어 아키텍처(3.1장)는 소프트웨어 구성 요소가 어떻게 구조화되고 서로 어떻게 대화하는지 결정합니다. 시스템 엔지니어링은 한 단계 위에 있습니다. 시스템 전체가 무엇을 해야 하는지, 소프트웨어와 하드웨어와 인간 운영자가 일을 어떻게 나누는지, 완성된 것이 동작함을 어떻게 증명할지 묻습니다. 전문 단체는 국제 시스템 엔지니어링 협의회인 INCOSE이고, 핵심 표준은 시스템 수명 주기 프로세스를 정의하는 ISO/IEC/IEEE 15288입니다.

이것이 대규모 기업과 정부 프로그램에 중요한 이유는 그 시스템이 크고, 오래 살며, 안전이 핵심이거나 임무가 핵심이기 때문입니다. 국방 플랫폼, 항공 교통 시스템, 위성군은 맞춤 하드웨어, 제3자 부품, 임베디드 및 클라우드 소프트웨어, 인간 운영자를 섞으며, 어떤 단일 팀도 전체를 머릿속에 담을 수 없습니다. 또한 흔히 시스템의 시스템을 만듭니다. 각각 단독으로 유용하지만 더 큰 능력을 제공하려면 협력해야 하는 많은 독립 시스템입니다.

이 장은 소프트웨어 요구 사항(2.8장), 아키텍처의 기본(3.1장), 소프트웨어 모델과 방법(2.12장), 상호운용성과 개방형 표준(3.8장), 프로젝트 관리(10.6장)와 연결됩니다.

핵심 원칙

부분이 아니라 전체를 엔지니어링하십시오. 시스템은 전체로서 성공하거나 실패하므로, 한 서브시스템을 따로 최적화하면 전체가 나빠질 수 있습니다.
수명 주기를 따르십시오. 시스템에는 최초의 개념에서 최종 퇴역까지 삶이 있습니다. 구축만이 아니라 그 모두를 계획하십시오.
모든 요구 사항을 추적하십시오. 모든 필요는 요구 사항, 설계 요소, 테스트로 대응되어야 합니다. 추적할 수 없다면 증명할 수 없습니다.
인터페이스를 의도적으로 관리하십시오. 대부분의 실패는 부분들 사이의 경계에서 일어나므로, 인터페이스는 명시적 소유권과 통제를 받을 가치가 있습니다.
검증과 확인을 따로 하십시오. 제대로 만들기(검증)와 올바른 것을 만들기(확인)는 다른 질문이며, 두 답이 모두 필요합니다.
창발적 동작을 예상하십시오. 부분을 결합하면 어떤 단일 부분도 보이지 않는 동작이 생깁니다. 일부는 요점이고 일부는 불쾌한 놀람입니다.
하드웨어와 소프트웨어를 함께 엔지니어링하십시오. 둘 다 맞춤일 때 한쪽의 결정이 다른 쪽을 제약하므로 함께 계획하십시오.

권장 사항

전체 시스템 수명 주기를 관리한다

시스템이 온전한 삶을 가진 것으로 다루고 각 단계를 계획하십시오. 흔한 수명 주기는 이렇게 흐릅니다. 개념(필요를 이해하고 선택지를 탐색), 요구 사항(시스템이 해야 할 일을 정확히 진술), 설계(아키텍처와 부분을 결정), 통합(부분을 한데 모음), 검증과 확인(동작하며 올바른 시스템임을 증명), 운영(운영하고 유지보수), 퇴역(데이터와 폐기를 포함해 안전하게 해체). ISO/IEC/IEEE 15288이 이를 위한 프로세스 프레임워크를 줍니다. 단계가 경직된 폭포수일 필요는 없습니다. 반복하고, 프로토타입을 만들고, 증분을 전달할 수 있습니다. 요점은 초기 계획이 흔히 무시하는 비싼 뒤쪽 단계를 포함해 모든 단계를 의식적으로 다룬다는 것입니다.

이해관계자 필요를 포착하고 추적성과 함께 요구 사항을 할당한다

시스템에 관심을 가진 사람들에서 시작하십시오. 사용자, 운영자, 소유자, 규제 기관, 대중입니다. 그들의 필요를 평이한 말로 모은 뒤, 구체적이고 테스트 가능한 엔지니어링된 요구 사항으로 바꾸십시오(2.8장 참조). 다음은 요구 사항 할당입니다. 각 시스템 수준 요구 사항을 특정 서브시스템에 배정하여, 어느 부분이 그것을 충족할 책임이 있는지 알게 합니다. 각 필요를 그 요구 사항, 그것을 충족하는 설계 요소, 그것을 검증하는 테스트에 연결하는 살아 있는 기록인 추적성 매트릭스를 유지하십시오. 이는 모든 필요가 덮여 있고 모든 부분이 이유가 있어 존재함을 언제든 증명하게 해 줍니다.

인터페이스를 명시적으로 관리한다

인터페이스는 부분들이 만나는 곳이자 시스템이 가장 자주 깨지는 곳입니다. 인터페이스는 물리적 커넥터, 네트워크 프로토콜, 데이터 형식, 사람의 절차일 수 있습니다. 각각에 대해 인터페이스 통제 문서(ICD), 곧 두 부분이 어떻게 연결되고 정보를 교환하는지에 대한 합의된 명세를 쓰십시오. 모든 인터페이스에 양쪽의 분명한 소유자를 두십시오. 일회성 커넥터가 아니라 공유되고 공개된 명세에 의지하면 통합이 훨씬 쉬워지며, 이것이 3.8장의 상호운용성 논거입니다. 가능한 곳에서는 인터페이스를 일찍 동결하십시오. 늦은 변경은 그것을 건드리는 모든 부분으로 파급되기 때문입니다.

통합한 뒤 검증하고 확인한다

시스템 통합은 서브시스템을 동작하는 전체로 결합하며, 문제가 아직 작을 때 찾도록 보통 한꺼번에가 아니라 단계적으로 합니다. 통합 뒤에는 두 가지 구별되는 검사인 검증과 확인(V&V)이 옵니다. 검증은 묻습니다. 시스템을 제대로 만들었는가, 곧 명시된 요구 사항을 충족하는가? 검사, 분석, 시연, 테스트로 검증합니다. 확인은 묻습니다. 올바른 시스템을 만들었는가, 곧 실제 사용에서 이해관계자의 진짜 필요를 충족하는가? 시스템은 검증은 통과(명세를 충족)하고도 확인에 실패(명세가 틀렸음)할 수 있습니다. 둘을 일찍 계획하고, 애초에 검증할 수 있도록 요구 사항과 인터페이스를 쓰십시오.

모델 기반 시스템 엔지니어링을 채택한다

전통적 시스템 엔지니어링은 서로 어긋나는 산더미 같은 문서를 만들었습니다. 모델 기반 시스템 엔지니어링(MBSE)은 그 더미를 시스템의 단일하고, 공유되고, 형식적인 모델로 대체하고, 거기서 뷰와 보고서를 생성합니다. 흔한 모델링 언어는 시스템의 요구 사항, 구조, 동작, 제약을 기술하는 그래픽 언어인 SysML(Systems Modelling Language)입니다. 모든 것이 하나의 연결된 모델에 있으므로 변경이 어디서나 갱신되고 추적성은 수동 추적이 아니라 질의가 됩니다. MBSE는 2.12장의 모델링 개념과 연결됩니다. 점진적으로 채택하되, 공유 모델이 가장 빨리 값을 하는 위험이 가장 높은 부분에서 시작하십시오.

창발적 동작에 시스템 사고를 적용한다

시스템 사고를 실천하십시오. 부분을 하나씩이 아니라 전체와 부분들 사이의 관계에 대해 추론합니다. 이것이 창발적 동작, 곧 부분이 결합할 때만 나타나고 어떤 단일 부분도 보이지 않는 속성을 예상하는 방법입니다. 좋은 창발은 흔히 시스템의 목적입니다(드론 떼가 어떤 단일 드론도 덮을 수 없는 영역을 덮음). 나쁜 창발은 놀라운 실패입니다(안전한 두 서브시스템이 상호작용해 위험한 상태를 만듦). 모델링한 적 없는 시스템에서 창발을 테스트로 없앨 수는 없으므로, 시뮬레이션과 구조화된 위해 분석으로 운영 전에 찾으십시오.

하드웨어와 소프트웨어를 함께 엔지니어링한다

시스템에 맞춤 하드웨어가 있을 때는 하드웨어/소프트웨어 공동 설계라는 실천으로 하드웨어와 소프트웨어를 함께 엔지니어링하십시오. 결정이 서로를 묶습니다. 하드웨어는 소프트웨어가 그 안에서 살아야 하는 타이밍, 메모리, 전력 한도를 정하고, 소프트웨어의 필요는 하드웨어가 제공해야 하는 것을 형성합니다. 긴 하드웨어 리드 타임도 일정을 이끕니다. 어떤 기능이 하드웨어에 살고 어떤 것이 소프트웨어에 살지 일찍 결정하고, 제약이 드러남에 따라 그 분할을 재검토하십시오.

장단점

접근 방식	장점	단점 / 비용
완전한 시스템 엔지니어링 엄밀함	늦은 놀람이 적음. 강한 추적성. 더 안전하고 감사 가능	높은 선행 비용. 느린 시작. 무거운 프로세스
가벼운 / 소프트웨어 전용 접근	작은 범위에 빠르고 싸고 유연	크고 다학제적인 시스템에서 무너짐. 인터페이스와 창발을 놓침
모델 기반 (MBSE)	단일한 진실 원천. 쉬운 추적성. 일관된 뷰	도구와 교육 비용. 문화 변화. 학습 곡선
문서 기반 시스템 엔지니어링	익숙함. 낮은 도구 비용. 공유하기 쉬움	문서가 서로 어긋남. 추적성이 수동이며 오류가 생기기 쉬움

핵심 트레이드오프는 엄밀함 대 속도입니다. 완전한 시스템 엔지니어링은 개념, 요구 사항, 인터페이스 작업에 노력을 앞에 몰아넣습니다. 그 노력은 크고, 오래 살고, 안전이 핵심인 시스템에서 몇 배로 본전을 뽑습니다. 운영 중 발견된 결함은 요구 사항 단계에서 발견된 같은 결함보다 수천 배 비쌀 수 있기 때문입니다. 작고 수명이 짧은 소프트웨어 전용 제품에서는 그 엄밀함이 과합니다. 프로세스의 무게를 시스템의 크기, 수명, 위험에 맞추십시오. 실패 방식은 30년 동안 돌고 실제 위험을 지닐 시스템에 버릴 프로젝트의 습관을 적용하는 것입니다.

팀과 논의할 질문

명세가 요구한 바로 그것을 만들고도 잘못된 시스템을 출시한 적은 어디이며, 무엇이 그것을 잡았겠습니까? 검증(제대로 만들었는가)과 확인(올바른 것을 만들었는가)은 다른 질문에 답하며, 명세 자체가 틀렸다면 시스템은 모든 검증 테스트를 통과하고도 확인에 실패할 수 있습니다. 큰 프로그램에서는 둘이 “테스트”로 뭉뚱그려져, 수정이 요구 사항 변경보다 수천 배 비쌀 때인 늦게야 누구도 실제 운영자의 필요에 대해 확인하지 않습니다. 인도된 시스템이 요구 사항을 충족하고도 실제 필요를 놓친 과거 예를 가져와, 어떤 확인 활동(실제 운영자와의 시뮬레이션, 현장의 초기 프로토타입)이 그것을 더 일찍 드러냈을지 물으십시오. 두 검사를 처음부터 계획하고, 애초에 검증할 수 있도록 요구 사항과 인터페이스를 쓰십시오. 이 구분이 희소한 리뷰 노력을 쓸 곳을 결정합니다.
시스템이 운영되기 전에, 후가 아니라, 나쁜 창발적 동작을 어떻게 찾아 나섭니까? 안전한 서브시스템을 결합하면 어떤 단일 부분도 보이지 않는 위험한 상태가 생길 수 있고, 모델링한 적 없는 시스템에서 창발을 테스트로 없앨 수는 없습니다. 안전이 핵심이거나 임무가 핵심인 프로그램에서 놀라운 상호작용은 누군가를 다치게 하거나 임무를 실패시키는 것이므로 실제 운영 전에 찾아야 합니다. 전체를 모델링하는 접근(시뮬레이션, 구조화된 위해 분석, 상호작용을 포착하는 SysML 모델)을 가져와, 서브시스템 간 동작 중 어느 것을 실제로 탐색했고 어느 것을 가정으로 치웠는지 물으십시오. 좋은 창발은 흔히 시스템의 목적이며 그것을 향해 설계할 가치가 있고, 나쁜 창발은 맞서 엔지니어링해야 하는 실패입니다. 유일한 통합 전략이 부분들을 엮어 놓고 어떻게 되는지 보는 것이라면, 프로덕션에서 창발을 발견하겠다고 계획하는 것입니다.
리드 타임이 긴 하드웨어 결정은 언제 동결되어야 하며, 그 마감이 소프트웨어 일정을 어떻게 이끕니까? 시스템에 맞춤 하드웨어가 있으면 둘을 함께 엔지니어링해야 합니다. 칩은 소프트웨어가 그 안에서 사는 타이밍, 메모리, 전력 한도를 정하고, 하드웨어 리드 타임이 흔히 전체 일정을 지배합니다. 소프트웨어를 분리 가능한 것으로 다루는 팀은 지역적으로 최적화하다가 통합에서 하드웨어 제약과 충돌해 몇 달을 잃습니다. 하드웨어 리드 타임과 하드웨어/소프트웨어 기능 분할을 결정해야 하는 날짜를 가져오고, 그 분할을 눈을 가린 채 동결하는 대신 제약이 드러남에 따라 재검토하십시오. 어떤 기능이 실리콘에 살고 어떤 것이 소프트웨어에 살지 일찍 결정할수록 비싼 번복이 줄어듭니다. 둘 사이의 인터페이스에는 인터페이스 통제 문서와 양쪽의 소유자가 필요합니다. 거기서의 늦은 변경이 그것을 건드리는 모든 것으로 파급되기 때문입니다.
단일 이해관계자 필요를 요구 사항, 설계 요소, 그것을 입증하는 테스트까지 추적할 수 있으며, 그 연결을 살려 두는 사람은 누구입니까? 추적성은 모든 필요가 덮여 있고 모든 부분이 이유가 있어 존재함을 언제든 보일 수 있게 해 주지만, 큰 프로그램에서 매트릭스는 아무도 소유하지 않는 순간 썩습니다. 상충하는 끌림은 실제입니다. 엔지니어는 추적성을 관료적 오버헤드로 경험하고, 손으로 유지하는 매트릭스는 설계가 바뀌는 것보다 빠르게 낡습니다. 현재 프로그램에서 진짜 가닥 하나를 가져와 방에서 처음부터 끝까지 따라가 보십시오. 지명된 이해관계자 필요에서, 할당된 요구 사항, 그것을 충족하는 서브시스템과 설계 요소, 검증 테스트까지, 그리고 사슬이 어디서 끊기는지 기록하십시오. 누가 매트릭스를 소유하는지, 추적성이 수동 추적이 아니라 질의가 되는 모델 안에 두어야 할지 결정하십시오. 기업과 정부 프로그램에서 매트릭스는 규제 기관과 획득 당국이 요구하는 감사 산출물이기도 하므로, 끊긴 사슬은 엔지니어링을 늦추는 것 이상으로 인증이나 지불을 멈출 수 있습니다.
모델 기반 접근이 도구와 문화 비용을 감수할 가치가 있습니까, 아니면 비싼 선반 속 소프트웨어가 되겠습니까? 문서 기반 시스템 엔지니어링은 익숙하고 도구가 싸지만 문서가 서로 어긋나고 추적성이 수동적이며 오류가 생기기 쉽습니다. MBSE는 그 더미를 하나의 연결된 모델로 대체하지만, 도구, 교육, 진짜 문화 변화의 대가를 치릅니다. 어느 극단이든 비쌉니다. 크고 다학제적인 프로그램에서 MBSE를 건너뛰면 통합의 놀람으로 값을 치르고, 모델을 최신으로 유지할 규율 없이 채택하면 모델이 없는 것보다 나쁜 선반 속 소프트웨어로 썩습니다. 도구 성숙도에 대한 정직한 판단, 팀에서 실제로 SysML 모델을 작성하고 유지할 수 있는 사람이 누구인지, 공유 모델이 가장 빨리 값을 하는 위험이 높은 한 서브시스템 중 어느 것이 접근을 시범할 수 있는지를 가져오십시오. 조직 전체에 한꺼번에 의무화하지 말고 점진적으로 결정하십시오. 공급자가 많은 대규모 기업이나 정부 프로그램에서는, 그렇지 않으면 낡은 문서를 주고받을 계약자들 사이에서 요구 사항, 인터페이스, 테스트를 일관되게 유지하는 현실적인 유일한 방법이 공유 모델인지 따져 보십시오.
수명 주기 계획이 운영과 퇴역에 진지하게 재원을 댑니까, 아니면 조용히 출시에서 멈춥니까? 오래 사는 시스템의 총비용을 지배하는 단계, 곧 수십 년간 운영하고 안전하게 해체하는 것은 초기 계획이 일상적으로 무시하는 단계입니다. 출시하라는 압박이 늘 있기 때문입니다. 상충하는 고려는 돈과 주의가 이런 뒤쪽 단계가 가장 멀게 느껴질 바로 그때 가장 희소하다는 점이며, 그래서 운영, 유지보수, 데이터 이전, 폐기가 비싸고 위험한 혼란이 될 때까지 미뤄집니다. 현재 수명 주기 계획을 가져와 운영과 퇴역에 소유자, 예산, 종료 기준이 명시되어 있는지, 출시를 결승선으로 다루는지 확인하십시오. 수명 종료 때 데이터와 하드웨어는 어떻게 되며, 그 사이 몇 년의 유지보수는 누가 지불하는지 물으십시오. 20~30년 운영되다가 공적 정밀 조사 아래 퇴역해야 하는 기업과 정부 시스템에서 계획되지 않은 해체는 규제, 환경, 기록 보존 의무를 위반할 수 있으므로, 퇴역은 첫 개념 검토부터 계획과 예산에 속합니다.

분야별 관점

스타트업. 아주 작은 팀은 공식 시스템 엔지니어링 프로그램을 운영할 수 없고 시도해서도 안 되지만, 펌웨어, 앱, 클라우드를 세 개의 별개 프로젝트가 아니라 하나의 시스템으로 다룰 수는 있습니다. 부분들이 어떻게 대화하는지 못 박는 짧은 인터페이스 문서를 하나 쓰고, 각 고객 필요를 그것을 충족하는 부분에 연결하는 단순한 표를 유지하고, 무거운 프로세스는 건너뛰십시오. 가장 희소한 자원은 엔지니어링 주의이므로, 경계에서의 잘못된 가정이 현장에서 제품을 조용히 깨뜨릴 곳에만 추적성 노력을 쓰십시오.

소기업. 전담 시스템 엔지니어도 빠듯한 예산도 없으니, 직접 설계하고 검증해야 하는 맞춤 통합보다 공개된 표준과 구매한 서브시스템에 기대십시오. 영원히 소유해야 하는 맞춤 커넥터 없이 부분이 맞도록 분명한 인터페이스 명세를 노출하는 벤더를 선호하십시오. 만들기 대 사기 선택을 제품 수명 동안 현실적으로 통제하고 검증할 수 있는 인터페이스가 무엇인지로 구성하고, 나머지는 사십시오.

대기업. 규모에서 문제는 많은 팀과 공급자에 걸친 일관성입니다. ISO/IEC/IEEE 15288에 맞춘 공유 수명 주기 프로세스, 모든 공급자 경계의 인터페이스 통제 문서와 지명된 소유자, 하나의 구성 요소 변경이 프로그램 전체의 소동을 촉발하지 않도록 하는 종단 간 추적성입니다. 공유 모델이 계약자 전반에서 요구 사항, 인터페이스, 테스트를 정렬해 유지하는 곳에 MBSE에 투자하십시오. 검증과 확인이 구별되게 유지되고 모든 요구 사항이 책임 있는 부분에 할당되도록 프로세스를 다스리십시오.

정부. 조달, 투명성, 공적 책임성이 모든 선택을 형성합니다. 계약에 시스템 엔지니어링 프로세스, 추적성, V&V 증거를 명시하고, 공급자에게 감사할 수 있는 인터페이스 통제 문서와 수명 주기 산출물을 인도하도록 요구하고, 어떤 실제 전환 전에도 안전과 임무 확인을 실제 운영자와 함께하는 독립 검토에 남겨 두십시오. 공공 프로그램은 안전한 해체와 기록 보존을 포함한 전 수명 주기에 답할 책임이 있으므로 운영과 퇴역을 명시적으로 계획하고 재원을 대십시오.

사례

스타트업. 연결된 센서를 만드는 네 명 규모의 하드웨어 스타트업은 공식 시스템 엔지니어링 프로그램을 감당할 수 없지만, 제품을 펌웨어, 모바일 앱, 클라우드 백엔드라는 세 별개 프로젝트가 아니라 하나의 시스템으로 다룹니다. 장치, 앱, 서버가 어떻게 대화하는지(메시지 형식, 단위, 오류 코드) 못 박는 짧은 인터페이스 문서를 하나 쓰고, 각 고객 필요를 그것을 충족하는 부분에 연결하는 단순한 표를 유지합니다. 더 싼 센서 칩이 펌웨어 변경을 강제할 때, 공유된 인터페이스가 앱과 백엔드가 무엇을 조정해야 하는지 즉시 보여 주므로 구성 요소 교체가 현장에서 제품을 조용히 깨뜨리지 않습니다.

대기업. 한 글로벌 자동차 제조사가 새 전기차 플랫폼을 만듭니다. 소프트웨어(배터리 관리, 운전자 지원, 인포테인먼트), 하드웨어(모터, 센서, 칩), 인적 요소의 시스템에, 각각 서브시스템을 인도하는 많은 공급자가 더해집니다. 회사는 시스템 엔지니어링 프로그램을 운영합니다. 이해관계자 필요가 할당된 요구 사항에 공급되고, 모든 공급자 인터페이스에 인터페이스 통제 문서가 있으며, SysML 모델이 요구 사항을 설계와 테스트에 묶습니다. 배터리 셀 공급자가 부품을 바꾸면 추적성 모델이 어떤 요구 사항, 인터페이스, 테스트가 영향받는지 정확히 보여 주어, 변경이 프로그램 전체의 소동을 촉발하는 대신 한정됩니다.

정부. 한 국가 항공 항법 당국이 레이더, 관제사 워크스테이션, 통신, 소프트웨어에 걸쳐 24시간 운영되는 안전이 핵심인 시스템의 시스템인 항공 교통 관리 시스템을 현대화합니다. 프로그램은 전 수명 주기에 걸쳐 ISO/IEC/IEEE 15288을 따릅니다. 검증은 각 서브시스템이 명세를 충족함을 증명하고, 실제 관제사와의 시뮬레이션을 통한 확인은 어떤 실제 트래픽이 의존하기 전에 통합 시스템이 안전한 운영을 지원함을 증명합니다. 엄격한 V&V 덕에 당국은 매 단계 대체 수단을 두고 단계적으로 전환할 수 있습니다. 여기서 테스트되지 않은 창발적 실패는 공공 안전 사건이기 때문입니다.

비즈니스 사례: 동기, ROI, TCO

동기는 결함이 늦게 발견될수록 기하급수적으로 비싸진다는 점입니다. 요구 사항 단계에서 잡은 요구 사항 오류는 고치는 데 거의 비용이 들지 않습니다. 운영 중에 잡은 같은 오류는 수천 배가 들 수 있고, 안전이 핵심인 시스템에서는 생명, 리콜, 실패한 임무의 비용이 들 수 있습니다. 시스템 엔지니어링은 결함 발견을 싼 초기 단계로 옮깁니다.

투자 수익(ROI, 지출한 비용 대비 얻은 가치)에서 수익은 피한 재작업, 더 적은 통합 실패, 초과하는 대신 일정과 예산을 맞추는 프로그램입니다. 대규모 프로그램에 대한 업계 연구는 강한 시스템 엔지니어링 노력이 더 작은 초과와 상관됨을 반복해서 발견합니다. 총소유비용(TCO, 시스템을 구축, 운영, 퇴역시키는 전 수명 비용)에서 시스템 엔지니어링은 장기 비용을 지배하지만 즉흥적 프로젝트가 무시하는 운영과 퇴역 단계를 반영합니다. 유지보수성, 인터페이스, 폐기를 처음부터 설계하면 시스템이 운영되는 수십 년의 비용이 낮아집니다. 프로젝트 관리(10.6장)를 보십시오.

안티패턴과 함정

반복 없는 대규모 선행 설계. 수명 주기를 경직된 단방향 폭포수로 다뤄, 모든 것을 만든 뒤에야 요구 사항이 틀렸음을 아는 것.
추적성 없는 요구 사항. 아무도 설계나 테스트에 연결하지 않은 요구 사항 더미로, 커버리지를 입증하거나 어떤 부분도 정당화할 수 없는 것.
인터페이스 무시. 서브시스템이 그냥 맞으리라 가정했다가 아무도 소유하지 않은 경계 불일치로 통합에서 몇 달을 잃는 것.
확인 없는 검증. 시스템이 명세를 충족함은 증명하면서 명세가 실제 필요와 맞는지는 확인하지 않아 잘못된 시스템을 출시하는 것.
소프트웨어를 별개로 다루기. 소프트웨어 팀이 지역적으로 최적화하며 하드웨어 제약, 타이밍, 인간 운영자를 무시하는 것.
선반 속 소프트웨어로서의 MBSE. 모델을 한 번 만들고 어긋나 썩게 두어 모델이 없는 것보다 나빠지는 것.
퇴역 계획 건너뛰기. 해체, 데이터 이전, 폐기 계획이 없어 수명 종료가 비싸고 위험한 혼란이 되는 것.

성숙도 모델

1단계: 시작. 시스템 엔지니어링이 즉흥적이고 반응적입니다. 요구 사항은 흩어진 문서에 있고, 인터페이스는 통합에서 발견되며, 검증은 어쩌다 이루어지는 테스트가 전부입니다. 대규모 프로그램은 정기적으로 초과하고 팀을 늦게 놀라게 합니다.

2단계: 발전. 주요 프로그램에 기본 실천이 있습니다. 요구 사항이 포착되어 기준선이 정해지고, 핵심 인터페이스에 통제 문서가 있으며, 검증 계획이 있습니다. 실천은 팀마다 일관되지 않고 공유된 방법이 아니라 개인에게 의존합니다.

3단계: 표준화. 시스템 엔지니어링이 ISO/IEC/IEEE 15288에 맞춘 문서화된 조직 전체의 규율이며 팀 전반에서 시행됩니다. 전체 수명 주기가 계획되고, 추적성이 처음부터 끝까지 유지되며, 인터페이스가 공식적으로 통제되고, 검증과 확인이 구별되어 계획됩니다. MBSE가 복잡한 프로그램에서 쓰입니다.

4단계: 관리. 시스템 엔지니어링이 데이터로 측정되고 통제됩니다. 조직은 기준선에 대해 지표를 추적합니다. 요구 사항 변동성과 추적성 커버리지, 통합에서 발견된 인터페이스 결함, 검증과 확인 통과율, 수명 주기 단계별 결함 유출(얼마나 많은 결함이 각 단계를 빠져나가 더 높은 비용으로 나중에 잡히는가)입니다. 리뷰가 이 숫자로 프로그램을 이끌고, 임계값이 사후 소방 대신 시정 조치를 촉발합니다.

5단계: 오케스트레이션. 시스템 엔지니어링이 조직 전체에서 지속적으로 개선되고 통합됩니다. 살아 있는 MBSE 모델이 단일한 진실 원천이고, 추적성이 자동화되며, 시뮬레이션이 구축 전에 창발적 동작을 예측하고, 과거 프로그램의 지표가 다음 프로그램에 공급됩니다. 하드웨어와 소프트웨어가 당연하게 함께 엔지니어링되고, 프로세스는 프로그램, 공급자, 위험이 이동함에 따라 적응합니다.

논의를 위한 아이디어

조직에서 시스템 엔지니어링과 소프트웨어 아키텍처 사이의 경계는 어디에 있으며, 둘 사이의 공간은 누가 소유합니까?
가장 큰 프로그램에서 단일 이해관계자 필요를 그것을 검증하는 테스트까지 추적할 수 있습니까? 없다면 무엇이 필요합니까?
최근 실패 중 어느 것이 인터페이스에서 일어났으며, 누가 소유했습니까?
MBSE가 값을 하겠습니까, 아니면 문화와 도구를 감안하면 비싼 선반 속 소프트웨어가 되겠습니까?
수명 주기 계획이 운영과 퇴역을 진지하게 다룹니까, 아니면 조용히 출시에서 멈춥니까?

핵심 요점

시스템 엔지니어링은 시스템 전체(소프트웨어, 하드웨어, 사람, 프로세스)를 처음부터 끝까지 엔지니어링하며, 소프트웨어 아키텍처와 구별됩니다.
개념에서 요구 사항, 설계, 통합, V&V, 운영, 퇴역까지 전체 수명 주기를 계획하십시오.
모든 필요를 요구 사항, 설계 요소, 테스트까지 추적하고, 각 요구 사항을 책임 있는 부분에 할당하십시오.
경계가 시스템이 깨지는 곳이므로 분명한 소유권과 통제 문서로 인터페이스를 명시적으로 관리하십시오.
검증(제대로 만들었는가)과 확인(올바른 것을 만들었는가)은 다른 검사이며 둘 다 필요합니다.
하나의 연결된 진실 원천을 위해 MBSE와 SysML을 쓰고, 창발적 동작을 예상하려고 시스템 사고를 쓰십시오.
프로세스의 무게를 시스템의 크기, 수명, 위험에 맞추십시오.

참고 문헌과 더 읽을거리

INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modelling Language
NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
Donella H. Meadows, Thinking in Systems: A Primer
Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
U.S. Department of Defence, Defence Acquisition Guidebook (systems engineering guidance)