System Engineering/SEBoK (System Eng. Body of Knowledge)

SEBoK: 시스템 분석 (System Analysis)

habana4 2024. 10. 22. 01:15
728x90
반응형
 

시스템 분석은 객관적으로 시스템을 평가하고,

효율적인 시스템 아키텍처를 선택하거나 업데이트 할 수 있도록 돕는 과정입니다.

이를 통해 엔지니어링에 필요한 구체적인 데이터를 얻을 수 있습니다.

이번 포스팅에서는 시스템 분석에 대해 살펴 보도록 하겠습니다.

 

 

 

시스템 분석은 개발 과정에서 기술적 선택이나 결정을 내릴 때 시스템이 요구사항을 충족하는지 평가하는 데 사용됩니다. 시스템 설계가 요구된 기준을 만족하는지 확인하기 위해 정량적 평가(숫자나 데이터를 기반으로 한 평가)를 수행합니다. 또한 시스템 분석은 기술적 의사결정을 내릴 때 매우 중요한 역할을 합니다. 이를 통해 기술적 선택을 객관적으로 비교하고 판단할 수 있습니다. 이 과정에서 트레이드 오프(Trade-off) 연구도 수행되는데, 이는 여러 대안 중에서 어떤 것이 가장 적합한지를 평가하는 과정입니다.

 

시스템 분석은 다양한 도구와 방법을 사용하여 수행되며, 다음과 같은 사항들이 포함됩니다:

  • 모델링 및 시뮬레이션: 시스템이 어떻게 작동할지를 미리 예측하기 위해 모델을 만들고 시뮬레이션을 수행합니다.
  • 비용 분석: 시스템을 설계하고 운영하는 데 필요한 비용을 분석합니다.
  • 기술적 위험 분석: 시스템이 직면할 수 있는 기술적 위험을 분석하고, 이러한 위험을 줄이기 위한 방법을 찾아냅니다.
  • 효율성 분석: 시스템이 얼마나 효율적으로 작동하는지를 평가합니다.

시스템 분석의 궁극적인 목표는 가장 효율적인 시스템 아키텍처를 선택하거나 기존 시스템을 업데이트하고, 이를 통해 얻은 데이터를 바탕으로 더 나은 엔지니어링 결정을 내리는 것입니다.

 

1. 시스템 분석 거버닝 원칙 (Principles Governing System Analysis)

시스템 분석의 주요 역할

  • 평가 기준 설정: 시스템 분석은 먼저 시스템 요구사항을 바탕으로 평가 기준을 설정합니다. 이 기준은 시스템이 해결해야 할 문제나 기회를 정의한 내용에 기반합니다.
  • 후보 솔루션 평가: 여러 후보 솔루션의 설계 속성을 평가하여, 설정한 평가 기준에 따라 각 솔루션을 비교합니다.
  • 점수 부여: 각 후보 솔루션에 점수를 매기고, 그 점수를 뒷받침할 수 있는 이유를 설명합니다.
  • 적절한 솔루션 선택: 최종적으로 가장 적절한 솔루션을 선택합니다.

시스템 분석의 원칙

  • 평가 기준은 시스템이 해결하려는 문제 또는 기회를 기반으로 해야 합니다.
  • 이상적인 시스템 설명을 바탕으로 평가 기준을 설정합니다. 이는 시스템이 이상적인 환경에서 어떻게 동작해야 하는지를 가정합니다.
  • 평가 기준은 시스템의 기능적 요구사항뿐만 아니라, 안전성이나 보안성 같은 비기능적 요구사항도 고려해야 합니다.
  • 평가 기준은 비용이나 시간 같은 제약 사항도 포함해야 합니다. 예를 들어, 이해관계자가 허용할 수 있는 비용과 일정에 대한 고려가 필요합니다.
  • 소프트 시스템 설명도 추가로 사용될 수 있습니다. 예를 들어, 이해관계자가 특정 종류의 솔루션을 선호하는지 여부나, 사회적, 정치적, 문화적 요인도 고려될 수 있습니다.

트레이드 스터디(Trade Studies)

  • 트레이드 스터디는 대안 솔루션을 분석하는 방법입니다. 여러 솔루션을 비교할 때 사용되는 평가 기준을 기반으로, 각 솔루션이 어떤 장단점을 가지고 있는지를 분석합니다.
  • 객관적 기준과 주관적 기준 모두 고려해야 합니다. 예를 들어, 성능이나 비용 같은 객관적 요소뿐만 아니라, 이해관계자의 선호 같은 주관적 요소도 포함됩니다.
  • 트레이드 스터디에서는 평가 기준이 전체 평가 결과에 얼마나 민감한지, 즉 특정 기준에 따라 결과가 크게 달라질 수 있는지를 신중하게 평가해야 합니다.

1.1 트레이드 오프 스터디 (Trade-Off Studies)

트레이드오프 스터디시스템의 각 요소나 후보 아키텍처를 비교하여, 평가 기준에 따라 가장 적절한 솔루션을 선택하는 과정입니다. 

 

트레이드 오프 스터디의 목적

트레이드 오프 스터디에는 비용 분석, 기술적 위험 분석, 효율성 분석 등이 포함되며, 이러한 분석을 통해 시스템의 각 대안이 얼마나 잘 작동할지, 위험성이 얼마나 높은지, 그리고 비용이 얼마나 드는지를 평가하는 것이 트레이드 오프 스터디의 목적입니다.

 

트레이드오프 스터디의 주요 분석 항목

  • 기술적 효율성 분석: 시스템이 얼마나 효율적으로 작동하는지를 평가합니다. 여기에는 시스템이 요구된 기능을 얼마나 잘 수행하는지, 성능이 얼마나 뛰어난지 등이 포함됩니다.
  • 비용 분석: 시스템을 설계하고 운영하는 데 드는 비용을 평가합니다. 예를 들어, 설치 비용, 유지보수 비용 등이 포함됩니다.
  • 기술적 위험 분석: 시스템이 직면할 수 있는 기술적 위험을 평가합니다. 예를 들어, 시스템이 제대로 작동하지 않을 위험성, 예상치 못한 문제 발생 가능성 등을 고려합니다.

트레이드오프 스터디의 중요성

시스템을 설계할 때, 하나의 대안이 모든 측면에서 완벽하지 않을 수 있습니다. 어떤 대안은 비용이 저렴하지만 성능이 낮을 수 있고, 또 다른 대안은 성능이 뛰어나지만 위험이 클 수 있습니다. 따라서 시스템의 성능을 최대화하면서도 비용과 위험을 최소화하는 대안을 찾는 것이 핵심입니다.

 

1.2 효과성 분석 (Effectiveness Analysis)

효과성 분석대안 시스템이 얼마나 잘 작동하고, 다양한 요구사항을 얼마나 충족하는지를 평가하는 과정입니다. 

 

시스템 솔루션의 효과성을 평가할 때 고려되는 중요한 특성은 다음과 같습니다:

  • 성능(Performance): 시스템이 요구된 기능을 얼마나 효율적으로 수행하는지 평가합니다.
  • 사용성(Usability): 시스템이 사용하기 얼마나 편리한지 평가합니다. 즉, 사용자가 쉽게 이해하고 사용할 수 있는지에 대한 평가입니다.
  • 신뢰성(Dependability): 시스템이 얼마나 안정적으로 작동하는지, 고장이 얼마나 적은지 등을 평가합니다.
  • 제조 가능성(Manufacturing): 시스템이 제조가 얼마나 용이한지, 즉 실제로 만들기 쉬운지 평가합니다.
  • 유지보수성(Maintenance): 시스템이 유지보수가 얼마나 쉬운지 평가합니다. 단, 한 번만 사용되는 제품의 경우에는 유지보수성이 중요하지 않을 수 있습니다.
  • 환경(Environment): 시스템이 환경적 조건을 얼마나 잘 견디는지, 또는 환경에 미치는 영향이 적은지 평가합니다.

효과성 분석의 핵심 과제

  • 적절한 분석 요소 선택: 효과성 분석에서 가장 어려운 점 중 하나는 어떤 특성을 평가할지를 정하는 것입니다. 모든 특성을 다 평가할 필요는 없고, 시스템에 실제로 중요한 요소만 평가해야 합니다. 예를 들어, 일회용 제품이라면 유지보수성은 중요한 평가 요소가 아닐 수 있습니다.
  • 핵심 성능 지표: 시스템의 **핵심 성능 지표(Key Performance Parameters)**와 같은 중요한 특성들에 집중하는 것이 중요합니다. 이를 통해 시스템이 성공적으로 설계되고, 효율적으로 작동할 수 있는지 확인할 수 있습니다.

1.3 비용 분석 (Cost Analysis)

비용 분석시스템의 전체 수명 주기 동안 발생하는 모든 비용을 평가하는 과정입니다. 이 분석은 시스템의 초기 개발에서부터 유지보수, 운영, 그리고 폐기에 이르기까지 발생하는 총 소유 비용(Total Ownership Cost, TOC) 또는 수명 주기 비용(Life Cycle Cost, LCC)을 고려합니다.

 

수명 주기 비용(Life Cycle Cost, LCC) 또는 총 소유 비용(TOC)

  • 수명 주기 비용(LCC)은 시스템이 처음 개발되고, 사용되며, 폐기될 때까지 발생하는 모든 비용을 말합니다.
  • 총 소유 비용(TOC)도 유사한 개념으로, 시스템을 소유하고 운영하는 데 필요한 전체 비용을 의미합니다. 이는 시스템을 유지보수하거나 업그레이드하는 데 드는 비용도 포함됩니다.

비용 분석의 항목

비용 분석에서 고려되는 항목은 여러 가지가 있는데, 노동 비용비노동 비용으로 나눌 수 있습니다. 

항목 설명과 예
노동 비용 시스템을 개발, 운영, 유지보수하는 데 필요한 인력과 관련된 비용입니다. 예를 들어, 엔지니어의 급여나 유지보수 직원의 인건비가 해당됩니다.
비노동 비용 자재 비용, 장비 비용, 그리고 시스템을 운영하는 데 필요한 에너지 비용 같은 것이 포함됩니다. 또한, 시스템을 운송하거나 설치하는 데 드는 비용도 해당됩니다.

 

비용 기준선(Cost Baseline) 및 목표

비용 분석을 수행할 때는 비용 기준선을 설정합니다. 이는 프로젝트나 시스템의 특성에 맞게 비용을 추정하고, 이를 기준으로 비용을 관리하는 데 사용됩니다. 즉, 비용이 예산 내에서 얼마나 잘 관리되고 있는지를 평가할 수 있게 해줍니다.

비용 분석의 궁극적인 목표는 시스템의 총 비용을 미리 평가하고, 프로젝트의 경제적 효율성을 높이는 것입니다. 이 과정에서 발생할 수 있는 잠재적인 비용 증가비용 절감 기회를 찾아내어, 시스템이 가장 효율적인 방식으로 운영되도록 돕습니다.

 

다음은 비용 종류를 나타내며 각각의 비용 항목이 시스템의 특정 단계에서 어떤 비용 요소가 발생하는지를 구체적으로 보여줍니다. 

비용 종류 설명과 예
제품 개발 비용 제품을 개발하거나 서비스를 실현하는 데 필요한 비용입니다.
(예: 엔지니어링, 개발 도구 (장비 및 소프트웨어), 프로젝트 관리, 테스트 벤치, 모형, 프로토타입 제작, 교육 비용)
제품 생산 또는 서비스 구현
비용
실제 제품을 제조하거나 서비스를 제공하는 데 필요한 비용입니다.
(예: 원자재 및 공급품, 예비 부품 및 재고 자산, 운영에 필요한 자원 (물, 전기 등), 폐기물 처리 및 보관 비용, 세금, 관리비, 문서 작업, 품질 관리 비용)
판매 및 애프터서비스 비용 제품을 판매하고, 그 이후 고객 서비스를 제공하는 데 필요한 비용입니다.
(예: 구조적 비용 (지사, 매장, 워크숍, 정보 취득 등), 고객 불만 처리 및 보증 관련 비용)
고객 운영 비용 고객이 제품을 사용하는 동안 발생하는 비용입니다.
(예: 설치 비용 (고객이 설치해야 하는 경우), 제품 운영에 필요한 자원 (물, 연료, 윤활유 등), 재정적 위험)
공급망 비용 제품을 운반하고 배송하는 데 필요한 비용입니다. (예: 운송 및 배송 비용)
유지보수 비용 제품의 유지보수와 관련된 비용입니다.
(예: 현장 서비스, 예방 유지보수, 규제 검사, 예비 부품 및 재고 비용, 보증 관련 비용)
폐기 비용 제품의 사용이 끝나고 이를 처리하는 데 발생하는 비용입니다.
(예: 수거, 해체, 운송 및 폐기물 처리, 폐기물 재활용)

 

1.4 기술적 위험 분석 (Technical Risks Analysis)

기술적 위험 분석은 시스템이 요구사항을 더 이상 충족하지 못할 때 발생하는 기술적 위험을 분석하는 과정입니다. 이 분석은 시스템이 제대로 작동하지 않을 가능성과 그로 인한 결과를 평가하고, 이를 줄이기 위한 방법을 찾는 데 중점을 둡니다.

 

기술적 위험 분석의 3가지 주요 요소

  1. 위협 또는 원하지 않는 사건의 분석 및 발생 확률: 시스템에서 발생할 수 있는 위협 또는 원하지 않는 사건을 식별하고, 이러한 사건이 발생할 확률을 평가합니다.
  2. 위협의 결과 분석 및 중대성 분류: 발생할 수 있는 위협이 시스템에 미치는 영향을 평가하고, 그 심각성을 평가하여 분류합니다. 이 결과가 시스템에 얼마나 큰 영향을 미치는지에 따라 우선순위를 정합니다.
  3. 위험 완화 전략: 위협 발생 확률을 줄이거나, 위협이 발생했을 때의 피해 수준을 낮추기 위한 조치를 계획합니다. 이러한 조치는 허용 가능한 수준까지 위험을 줄이는 것이 목표입니다.

기술적 위험은 시스템이 기술적 요구사항을 더 이상 충족하지 못할 때 발생합니다. 그 원인은 여러 가지가 있을 수 있습니다:

  • 기술적 능력의 잘못된 평가: 기술이 실제로 제공할 수 있는 성능을 잘못 판단한 경우.
  • 기술 성숙도의 과대평가: 시스템 요소의 기술 성숙도(기술이 얼마나 안정적이고 검증되었는지)를 과대평가한 경우.
  • 부품 고장: 부품의 고장, 파손, 또는 장비나 소프트웨어의 노후화로 인한 문제.
  • 공급업체의 문제: 부품이 규격에 맞지 않거나, 공급이 지연되는 등 공급업체로부터 발생하는 문제.
  • 인적 요인: 직원의 부족한 교육, 조정 오류, 부적절한 절차 또는 악의적인 행동 등으로 인한 문제.

기술적 위험과 프로젝트 위험의 차이

기술적 위험 프로젝트 위험
시스템 자체와 관련된 위험을 의미합니다. 즉, 시스템이 요구사항을 충족하지 못할 가능성과 그로 인한 결과를 평가하는 것입니다. 시스템을 개발하는 과정에서 발생하는 위험을 의미합니다. 예를 들어, 예산 초과, 일정 지연 등이 이에 해당합니다.

비록 위험 관리 방법은 두 경우 모두 유사하지만, 기술적 위험은 시스템의 기능적 측면에 초점을 맞추고 있다는 점에서 다릅니다.

 

 

2. 시스템 분석의 프로세스적 접근 (System Analysis: Process Approach)

시스템 분석 프로세스는 시스템을 설계하고 결정할 때, 기술적인 결정을 내릴 수 있는 엄격한 기반을 제공하는 과정입니다. 이 과정의 주요 목적과 원칙은 다음과 같습니다.

2.1 시스템 분석 프로세스의 목적

  • 기술적 의사결정 지원: 기술적인 결정을 내리거나, 요구사항 간의 충돌을 해결하며, 대안 물리적 솔루션(시스템 요소와 물리적 아키텍처)을 평가하는 데 기반을 제공합니다.
  • 요구사항 충족 여부 확인: 시스템이 요구사항을 얼마나 잘 충족하고 있는지를 평가합니다. 여기에는 시스템의 파생된 요구사항도 포함됩니다.
  • 위험 관리 지원: 시스템 설계에서 발생할 수 있는 기술적 위험을 관리하고, 그에 대한 대응 전략을 마련합니다.
  • 비용, 일정, 성능, 위험 평가: 의사결정을 내리기 전에 비용, 일정, 성능, 그리고 위험이 시스템 엔지니어링 또는 재설계에 미치는 영향을 평가합니다.

 

2.2 시스템 분석 프로세스의 주요 역할

  • 이해관계자 요구사항 정의시스템 요구사항 정의: 이 과정에서 요구사항 간의 충돌을 해결하거나, 비용, 기술적 위험, 효율성(성능, 운영 조건, 제약 사항)과 관련된 문제를 해결하는 데 사용됩니다. 특히, 높은 위험이 따르거나 다른 아키텍처를 필요로 하는 요구사항을 평가합니다.
  • 논리적 및 물리적 아키텍처 모델 개발: 이 과정에서는 후보 논리적 또는 물리적 아키텍처의 특성이나 설계 속성을 평가하여, 비용, 기술적 위험, 효율성 측면에서 가장 적합한 아키텍처를 선택하는 데 도움을 줍니다. 예를 들어, 성능, 신뢰성, 인적 요인 등을 고려합니다.

시스템 분석 프로세스는 반복적으로 수행됩니다. 각 단계는 여러 번 반복되며, 매번 분석의 정확도가 향상됩니다. 즉, 여러 차례의 분석을 통해 시스템 설계가 점점 더 정교해지고 최적화됩니다.

 

2.3 프로세스 세부 활동

세부 활동 설명
1. 트레이드 오프 스터디 계획 분석할 후보 솔루션의 수 결정: 여러 후보 솔루션(예: 동작 아키텍처/시나리오, 물리적 아키텍처, 시스템 요소 등)을 분석하기 위해 몇 개의 솔루션을 선택할지 결정합니다.

방법 및 절차 결정: 후보 솔루션을 어떻게 분석할지에 대한 방법절차를 설정합니다. 이 과정에서 예상 결과를 정의하고, 선택된 솔루션을 뒷받침할 근거를 마련합니다.


분석 일정: 시스템 요구사항, 설계 속성, 모델엔지니어링 데이터가 준비되는 시점에 맞춰 분석 일정을 계획합니다. 또한, 분석을 수행할 전문 인력절차도 준비합니다.
2. 선정 기준 모델 정의
평가 기준 선택: 시스템의 비기능 요구사항(성능, 운영 조건, 제약사항 등)이나 설계 속성을 기준으로 평가 기준을 선택합니다.

평가 기준 정렬: 평가 기준을 정렬하고 순서를 정합니다. 어떤 기준이 더 중요한지에 따라 우선순위를 매기는 작업입니다.


비교 척도 설정: 각 평가 기준마다 비교 척도를 설정하고, 그 기준의 상대적인 중요도에 따라 가중치를 부여합니다. 즉, 어떤 기준이 더 중요한지를 반영하는 가중치를 설정합니다.
3. 후보 솔루션 및 관련 데이터 식별
평가할 후보 솔루션과 관련된 모델데이터를 찾아 식별합니다.
4. 후보 솔루션 평가 
비용 분석, 기술적 위험 분석, 효과성 분석을 수행하여, 각각의 후보 솔루션을 미리 정의한 평가 기준에 따라 비교 척도에 배치합니다.

각 후보 솔루션을 평가 점수점수화합니다.
5. 결과 제공 
평가 기준, 비교 척도, 솔루션의 점수, 평가 결과, 그리고 그 결과를 바탕으로 한 추천 사항 및 그에 대한 근거를 다른 관련 프로세스에 전달합니다.

 

2.4 아티팩트와 온톨로지 엘리먼트

생성되는 주요 결과물 (Artifacts)

시스템 분석 과정에서 여러 가지 결과물이 만들어지며, 이 결과물은 분석 결과를 문서화하고 결정을 내리는 데 도움을 줍니다. 주로 다음과 같은 것들이 포함됩니다:

  • 선정 기준 모델 (Selection Criteria Model): 시스템을 평가하기 위한 평가 기준의 목록, 각 기준의 비교 척도, 그리고 기준의 상대적 중요도에 따른 가중치를 정의한 모델입니다. 이 모델은 후보 솔루션을 평가할 때 사용됩니다.
  • 비용, 위험, 효율성 분석 보고서 (Costs, Risks, and Effectiveness Analysis Reports): 후보 솔루션을 평가한 결과를 정리한 보고서입니다. 각 솔루션에 대한 비용 분석, 기술적 위험 분석, 그리고 효율성 분석의 결과가 포함되어 있습니다.
  • 정당화 보고서 (Justification Reports): 각 후보 솔루션이 평가된 이유와 선택된 솔루션을 정당화하는 내용이 포함된 보고서입니다. 이 보고서는 솔루션이 왜 선택되었는지 또는 왜 거부되었는지에 대한 근거를 설명합니다.

 

온톨로지 엘리먼트 (Ontology Elements)

온톨로지 엘리먼트란 시스템 분석 과정에서 다루는 개념적 요소들을 의미합니다. 온톨로지 엘리먼트들은 시스템 분석에서 중요한 데이터를 다룰 때 필요한 개념적인 틀을 제공합니다.

온톨로지 엘리먼트 설명
평가 기준
(Assessment Criterion)
시스템 요소, 물리적 인터페이스, 물리적 아키텍처, 기능적 아키텍처/시나리오, 또는 다른 엔지니어링 요소들을 평가하거나 비교할 때 사용하는 특성입니다. 이는 시스템의 다양한 부분을 비교할 수 있는 기준을 제공합니다.

핵심 속성: 식별자, 평가 기준의 이름, 평가 기준의 내용에 대한 설명, 상대적 가중치(다른 평가 기준과의 상대적인 중요도를 나타냄), 스칼라 가중치(각 기준에 대한 정량적 평가 값)
평가 선택
(Assessment Selection)
시스템 요소나 물리적/기능적 아키텍처 등을 평가한 결과를 바탕으로 선택을 정당화하는 기술적 관리 요소입니다. 즉, 평가 점수를 기반으로 어떤 시스템 솔루션을 선택하는지 결정하는 과정입니다.
평가 점수
(Assessment Score)
평가 기준을 사용하여 시스템 요소, 물리적 인터페이스, 물리적 아키텍처, 기능적 아키텍처/시나리오를 평가한 결과로 얻은 점수입니다. 이 점수를 바탕으로 시스템 솔루션의 우선순위를 정할 수 있습니다.
비용
(Cost)

시스템 요소, 물리적 인터페이스, 물리적 아키텍처와 관련된 비용을 특정 통화로 표현한 값입니다. 이는 시스템의 개발, 생산, 유지보수, 폐기와 관련된 비용을 평가할 때 사용됩니다.

핵심 속성
:
식별자, 비용 항목의 이름, 비용 항목의 내용에 대한 설명, 비용의 금액, 비용의 유형(개발, 생산, 운영, 유지보수, 폐기), 신뢰 구간(비용 추정에 대한 신뢰도), 참조 기간(비용이 발생하는 기간), 추정 기법(비용을 추정한 방법)
위험
(Risk)
시스템 임무 또는 시스템 특성과 관련된 위협 또는 위험 요소를 말합니다. 위험은 시스템이 취약할 수 있는 부분과 이에 대한 위험 요소가 결합된 것을 의미합니다.

핵심 속성: 식별자, 위험 항목의 이름, 위험 항목의 내용에 대한 설명, 상태(위험이 현재 진행 중인지, 해결되었는지 등의 상태)

 

2.5 Checking Correctness of System Analysis

시스템 분석 타당성 확인은 시스템 분석의 정확성을 확인하기 위해 검토해야 할 주요 항목들을 다루고 있습니다. 이 검토 항목들은 시스템 분석이 올바르게 수행되었는지를 검증하고, 분석 결과가 신뢰할 수 있는지 확인하는 데 도움이 됩니다.

 

  • 모델과 데이터의 적합성 (Relevance of the Models and Data): 시스템이 사용될 맥락에서 사용된 모델데이터가 실제로 적합한지를 검토합니다. 즉, 시스템이 작동할 환경과 상황에서 모델이 제대로 작동하고 데이터를 정확히 반영하는지를 확인해야 합니다.
  • 평가 기준의 적합성 (Relevance of Assessment Criteria): 시스템이 사용될 맥락과 관련된 평가 기준이 적절한지 검토합니다. 평가 기준이 시스템이 작동할 환경이나 요구사항을 제대로 반영하고 있는지 확인하는 것이 중요합니다.
  • 시뮬레이션 결과 및 계산의 재현 가능성 (Reproducibility of Simulation Results and Calculations): 시뮬레이션 결과계산 결과가 동일한 조건에서 반복했을 때 일관되게 재현될 수 있는지를 검토합니다. 즉, 같은 조건에서 여러 번 분석했을 때 동일한 결과가 나오는지를 확인하는 것입니다.
  • 비교 척도의 정밀도 (Precision Level of Comparisons’ Scales): 비교 척도가 얼마나 정확한지를 평가합니다. 척도가 충분히 정밀해야 후보 솔루션 간의 차이를 명확히 비교할 수 있습니다.
  • 추정의 신뢰성 (Confidence of Estimates): 시스템 분석에서 사용된 추정 값이 얼마나 신뢰할 수 있는지를 확인합니다. 추정된 값이 실제와 어느 정도 일치할 가능성이 높은지를 평가하는 과정입니다.
  • 평가 기준 가중치와 솔루션 점수 간의 민감도 (Sensitivity of Solutions’ Scores Related to Assessment Criteria Weights): 평가 기준의 가중치가 솔루션의 평가 점수에 얼마나 큰 영향을 미치는지를 검토합니다. 즉, 평가 기준에 따라 솔루션의 점수가 크게 달라질 수 있는지를 분석하고, 이를 통해 평가 결과가 특정 기준에 지나치게 의존하지 않는지 확인합니다.

 

2.6 시스템 분석 방법과 모델링 기술

모델의 일반적인 사용 (General Usage of Models)

  • 물리적 모델 (Physical Models): 물리적 현상을 모의 실험할 수 있는 모델입니다. 특정 분야에 맞게 사용되며, 모형, 진동 테이블, 테스트 벤치, 프로토타입, 감압실, 풍동 등과 같은 도구들이 포함됩니다. 이를 통해 시스템이 실제로 어떻게 작동할지 물리적으로 실험할 수 있습니다.
  • 표현 모델 (Representation Models): 시스템의 동작을 모의 실험하는 데 사용됩니다. 예를 들어, 향상된 기능 흐름 블록 다이어그램(eFFBDs), 상태차트(statecharts), 상태 머신 다이어그램(state machine diagrams) 등이 사용됩니다. 특히, SysML(시스템 모델링 언어)을 기반으로 동작을 시각화하는 데 유용합니다.
  • 분석 모델 (Analytical Models): 예측 값을 계산하기 위해 사용됩니다. 결정론적 모델과 **확률적 모델(확률분포)**을 포함하며, 수식이나 다이어그램을 사용하여 시스템의 실제 동작을 모사합니다. 이러한 모델은 단순한 산수 계산부터 여러 변수를 사용하는 복잡한 확률 분포까지 다양합니다.

 

프로젝트 진행 단계에 따른 모델 선택

  • 초기 단계: 프로젝트 초기에는 간단한 도구를 사용하여 대략적인 추정치를 계산합니다. 이 단계에서 간단한 도구를 사용하면 시간과 노력을 절약할 수 있으며, 비현실적이거나 적합하지 않은 후보 솔루션을 쉽게 제거할 수 있습니다.
  • 프로젝트 진행 단계: 프로젝트가 진행되면서 데이터의 정확도를 높여야 합니다. 특히, 여전히 경쟁 중인 후보 솔루션 간의 비교를 위해 더 정확한 모델과 분석이 필요합니다. 혁신성이 높은 프로젝트일수록 이 작업은 더 복잡해집니다.
  • 전문가 지원: 복잡한 시스템은 시스템 엔지니어 혼자서 모델링하기 어렵습니다. 이 과정에서는 다양한 전문가의 지원이 필요합니다. 각기 다른 분야의 숙련된 전문가들이 협력해야 합니다.

 

전문가의 견해 수집 (Specialist Expertise)

평가 기준이 객관적이거나 정확하게 도출될 수 없을 때, 또는 주관적인 요소가 중요할 때는 전문가의 견해를 구할 수 있습니다. 이 과정은 다음 단계로 진행됩니다:

  1. 전문가 선정: 해당 분야의 전문가를 선정합니다.
  2. 설문지 작성: 정확한 설문지는 분석을 쉽게 만들 수 있지만, 지나치게 폐쇄적인 설문지는 중요한 점을 간과할 수 있습니다.
  3. 전문가 인터뷰: 선정된 전문가들과 심층 인터뷰를 진행해 정확한 의견을 수집합니다.
  4. 데이터 분석: 여러 전문가들의 데이터를 분석하고, 그들의 인상을 비교하여 평가 기준이나 후보 솔루션에 대해 합의를 도출합니다.

다음은 시스템 분석에서 자주 사용되는 분석 모델의 유형을 설명하고 있습니다.

모델 유형 설명
결정론적 모델
(Deterministic Models)
이 모델은 통계 자료 이전 프로젝트 데이터를 기반으로 시스템 요소 또는 구성 요소를 분석합니다. 주로 기술이 이미 존재하는 시스템에 적용됩니다.

 주요 유형:
 통계 모델: 많은 데이터를 기반으로 모델을 구성하며, 이전 프로젝트의 결과들을 활용합니다.
 유사성 기반 모델(Analogy Models): 분석 중인 시스템 요소를 이미 존재하는 시스템 요소와 비교하고, 전문가의 경험을 바탕으로 조정합니다. 예를 들어, 비용이나 신뢰성과 같은 특성을 비교하고 조정합니다.
 학습 곡선(Learning Curves): 기술 또는 특성의 진화를 예측하는 데 사용됩니다. 예를 들어, “생산된 단위 수가 두 배가 될 때마다 단위 비용이 일정 비율로 감소”하는 현상을 설명합니다.
확률 모델
(Probabilistic Models,
Stochastic Models)
확률 이론을 기반으로 다양한 후보 솔루션을 평가하는 모델입니다. 각 이벤트가 발생할 확률과 그에 따른 결과를 기준으로 후보 솔루션을 분류합니다.

 적용 조건: 평가 기준이 적고, 이벤트 조합이 단순한 경우에 적합합니다. 각 노드에서 발생 가능한 모든 이벤트의 확률 합이 반드시 1이 되어야 합니다.
다기준 의사결정 모델
(Multi-Criteria Decision Models)
평가 기준이 10개 이상일 때, 다기준 의사결정 모델을 사용하는 것이 좋습니다. 이 모델은 여러 가지 기준을 계층적으로 구성하여 각 후보 솔루션을 평가합니다.
 절차:
1. 기준을 계층 구조 또는 분해 트리로 구성합니다.
2. 각 계층의 기준을 상호 비교하여 상대적 가중치를 부여합니다.
3. 각 기준에 대해 스칼라 가중치를 계산하고, 이를 기준으로 후보 솔루션을 평가합니다.
4. 각 후보 솔루션에 점수를 매기고, 종합 점수를 계산한 후 비교합니다.
5. 컴퓨터 도구를 사용하여 민감도 분석을 수행하고, 견고한 선택을 보장합니다.

 

 

3. 시스템 분석 문제점과 모범사례

3.1 시스템 분석 문제점

문제점 설명
분석 모델은 의사결정 도구가 아님 분석 모델은 데이터를 기반으로 분석 결과를 제공하지만, 의사결정 도구로 사용해서는 안 됩니다. 즉, 모델링은 의사결정을 지원하는 도움 도구로서 사용되며, 최종 결정은 인간의 판단과 추가적인 요소를 고려해 내려져야 합니다.

 핵심 포인트: 모델은 의사결정을 돕지만, 그 자체로 결정을 대신할 수 없습니다.
모델과 시스템 수준의 분해 특정 수준(예: 레벨 n)의 시스템에 잘 맞는 모델이 상위 수준(예: 레벨 n+1)의 시스템에서는 호환되지 않을 수 있습니다. 각 모델에서 사용된 데이터와 시스템 수준 간의 일관성을 유지하는 것이 중요합니다.

 핵심 포인트: 다른 수준에서 사용되는 모델들이 호환성을 갖추고 있는지, 즉 데이터가 일관되게 사용되는지를 시스템 엔지니어가 확인해야 합니다.
최적화는 개별 최적화 요소의 합이 아님 
시스템 전체의 최적화는 각 요소를 개별적으로 최적화하는 것의 으로 이루어지지 않습니다. 즉, 각각의 시스템 요소를 따로 최적화한다고 해서 전체 시스템이 최적화되는 것은 아닙니다. 전체 시스템을 바라보고 최적화해야 합니다.

 핵심 포인트: 시스템의 전체적인 최적화를 위해서는 개별 요소의 최적화만으로는 충분하지 않으며, 전체적인 시각이 필요합니다.

 

3.2 시스템 분석 모범 사례

문제점 설명
운영 범위 내에서 작업하기 모델은 시스템의 모든 동작이나 반응을 시뮬레이션할 수 없으며, 제한된 변수제한된 조건 내에서만 작동합니다. 따라서 모델을 사용할 때, 입력된 파라미터데이터가 시스템의 실제 운영 범위 내에 있는지를 항상 확인해야 합니다. 그렇지 않으면 비정상적인 결과가 나올 위험이 큽니다.

핵심 포인트: 모델이 실제 운영 환경에 맞춰져 있는지 확인해야 합니다.
모델의 진화 프로젝트가 진행됨에 따라 모델은 진화해야 합니다. 이는 파라미터 설정의 수정, 새로운 데이터 입력(평가 기준 수정, 수행할 기능, 요구사항 등), 또는 기존 도구가 한계에 다다랐을 때 새로운 도구를 사용하는 방법을 통해 이루어집니다.

핵심 포인트: 프로젝트가 진행됨에 따라 모델을 업데이트하고 새로운 데이터도구를 반영해야 합니다.
여러 종류의 모델 사용 여러 종류의 모델을 동시에 사용하여 결과를 비교하거나, 시스템의 다른 측면을 고려하는 것이 좋습니다. 한 가지 모델만 사용하는 것보다 다양한 관점을 반영할 수 있습니다.

핵심 포인트: 다양한 모델을 사용하여 보다 종합적인 분석을 수행합니다.
맥락 요소의 일관성 유지
시뮬레이션 결과는 모델링의 맥락에서 항상 제공되어야 합니다. 즉, 사용된 도구, 가정된 조건, 입력된 파라미터와 데이터, 그리고 결과의 변동성을 함께 제공해야 합니다.

핵심 포인트: 결과는 항상 모델링 조건맥락을 명확히 제시해야 합니다.

728x90
반응형