[소프트웨어공학] 사회-기술적 시스템2 (시스템공학)

2.2 시스템 공학

 시스템 공학은 사회-기술적 시스템을 분석, 설계, 구현, 검증, 설치, 유지보수하는 행위이다. 시스템 엔지니어는 소프트웨어뿐만 아니라 하드웨어와 시스템을 사용하는 사용자와의 상호작용까지도 고려해야 한다. 시스템 엔지니어는 또한 시스템이 제공해야 할 서비스와 시스템이 구축되고 운영되기 위해서 필요한 제약 조건도 고려해야 한다. 앞에서 논의한 것처럼, 소프트웨어 공학의 문제는 시스템 공학의 의사결정 결과이기도 하기 때문에 시스템 엔지니어는 시스템 공학을 이해할 필요가 있다.

 시스템 공학 프로세서의 단계는 아래와 같다. 이 프로세스는 소프트웨어 프로세스의 '폭포수' 모델에 많은 영향을 미쳤다.

  요구사항정의 -> 시스템 설계 -> 서브시스템개발 -> 시스템통합 -> 시스템설치 -> 시스템진화 -> 시스템폐기

 

 1.시스템 개발 동안에 재작업의 한계 : 휴대폰 시스템의 기지국 위치 결정과 같이 시스템 공학에서는 의사결정이 한 번 내려지면, 변경하는 데 많은 비용이 든다. 따라서 사이트를 변경하도록 시스템을 재설계하는 것은 거의 불가능하다. 소프트웨어가 시스템에서 중요한 한 가지 이유는 시스템 개발 동안에 새로운 요구사항에 대응하여 변경이 가능하기 때문이다.

 2. 학제 간의 참여 : 많은 공학 분야는 시스템 공학에 포함되어 있다. 서로 다른 엔지니어가 서로 다른 용어와 관행을 따르고 있기 때문에 오해의 여지가 많다.

 

 시스템 공학은 다양한 분야로부터 만들어진 팀이 참여하는 학제 간의 활동이다. 시스템 설계 결정의 의미를 모두 고려해야 하는 광범위한 지식 때문에 시스템 공학팀이 필요하다. 

 많은 시스템에서 서로 다른 유형의 서브시스템을 조합하여 사용할 경우 수많은 가능성이 있다. 다른 학문 분야가 제공할 분야를 잘 타협하여 결정해야 한다. 시스템이 어떻게 분해되어야 할지에 대한 '올바른' 답은 없다. 오히려, 여러 가지 대안 중에서 최상의 해답을 찾아내지 못할 수도 있다. 항공 관계 시스템에서의 한 가지 대안으로, 레거시 시스템을 수리하기보다는 새로운 레이더를 설치한다고 하자. 만약 다른 일이 없는 토목 공학자가 이 프로세스에 참여한다면 다른 일이 별로 없기 때문에 그들은 이 대안을 좋아할 것이다. 그들은 기술적인 이유를 들어서 이 선택을 합리화시키려고 할지도 모른다.

 

 

 2.2.1 시스템 요구사항 정의

 시스템 요구사항 정의는 시스템이 해야 할 일(기능)과 기본적인 시스템의 특성을 분석하는 일이다. 소프트웨어 요구 분석과 함께, 시스템 요구사항 정의를 만드는 것은 시스템 고객과 최종 사용자와의 상담을 포함한다. 이 요구사항 정의 단계는 세 가지 유형의 요구사항을 유도하는 데 집중한다.

 

 1. 추상적 기능 요구사항 : 시스템이 반드시 제공해야 하는 기본적인 기능은 추상적인 단계로 정의된다. 더 상세한 기능적 요구사항은 서브시스템에서 발생한다. 예를 들어, 항공 관제 시스템에서 추상적 기능 요구사항은 비행 계획 데이터베이스에 통계될 비행기와 모든 운항 일정을 저장해야 한다. 그러나 다른 서브시스템의 요구사항에 영향을 미치지 않는 범위 내에서 데이터베이스에 관한 상세한 내용을 구분하지 않는다.

 2. 시스템 특성 : 가용성, 성능, 안전성과 같은 비기능적 창발성을 말한다. 이러한 비기능적 특성은 모든 서브시스템의 요구사항에 영향을 미친다.

 3. 시스템이 갖지 말아야 할 특성 : 시스템이 가져야 할 특성과 갖지 말아야 할 특성을 지정하는 것이 때로는 중요하다. 예를 들어, 항공 관제 시스템을 분석할 경우 통제관에게 너무 많은 정보가 보이지 않도록 지정할 수 있다.

 

 요구사항 정의 단계에서 중요한 것 중의 하나는 시스템이 갖추어야 할 전체 목표를 설정하는 것이다. 그것은 기능적인 용어로 표현될 필요는 없지만, 왜 특정 환경에서 획득해야 하는지를 정의해야 한다.

 이러한 상황의 예를 들어, 건물에 대한 방화와 침입에 대비한 사무실 빌딩에 대한 시스템에 대한 분석을 한다고 가정하자. 이 시스템의 기능에 대한 목표는 다음과 같을 수 있다.

 

  관계자 외 출입금지와 화재에 대한 내외 경보를 발령할 수 있는 빌딩에 대한 방화 혹은 침입 정보 시스템을 제공한다.

 

 이 목표는 사건에 대한 경고를 발생시키는 정보 시스템이 필요하다는 것을 명시하고 있다. 이러한 문장은 기존의 정보 시스템을 대치한다고 하면 적당하겠지만 반대로 다음과 같이 목표를 기술할 수 있을 것이다.

 

  빌딩 내에서 수행되는 작업이 화재와 침입에 의해서 정상적인 기능이 심하게 훼손되지 않도록 하기 위함이다.

 

 만약 목표를 위와 같이 설정한다면, 설계에 대한 선택이 좁아질 수도 있고 넓어질 수도 있다. 예를 들어, 이 목표가 내부 경보 없이 고도의 잠금장치를 사용하여 침입자를 막을 수도 있다. 또한 전기 시스템에 영향을 주지 않고 작업에 방해를 주지 않도록 하기 위해서 스프링클러의 사용을 배제할 수도 있다.

 시스템 요구사항을 설정하는 데 있어서 근본적인 어려움은 장애를 극복하기 위한 복잡한 시스템은 대게 '위험한 문제'라는 것이다. '위험한 문제'는 너무 많은 개체가 서로 얽혀 있어서 정확한 문제에 대한 정의가 없다는 것이다. 이러한 문제의 기본적인 성격은 해결책이 개발되면서 나타난다. '위험한 문제'의 극단적인 예는 지진에 대한 대비이다. 아무도 지진의 진앙을 예측할 수 없고, 언제 일어날지도 모르며, 그 지역에 어떠한 영향을 미칠지 모른다. 그렇기 때문에 누구도 큰 지진에 어떻게 대응해야 하는지 완전하게 분석할 수 없다. 이 문제는 그것이 일어난 이후에만 해결될 수 있다.

 

 2.2.2 시스템 설계

 시스템설계는 시스템 기능이 시스템의 컴포넌트에 의해서 어떻게 제공되는지를 다룬다. 이 프로세스에 포함된 활동은 다음과 같다.

 1. 요구사항 분할 : 요구사항을 분석하고 관계된 그룹으로 나눈다. 여러 가지 분할 조합이 있을 수 있는데 그중에서 몇 가지 대안을 제시한다.

 2. 서브시스템 식별 : 요구사항에 적합한 하나 혹은 여러 개의 서브시스템을 식별한다. 여러 개의 요구사항이 여러 개의 서브시스템에 관련되어 있기 때문에 분할된 요구사항이 서로 융합되어 있을 수 있다. 그러나 서브시스템 식별은 다른 조직이나 환경요인에 의해서 영향을 받을 수도 있다.

 3. 서브시스템에 요구사항 할당 : 요구사항을 서브시스템에 할당한다. 실제로 분할된 요구사항이 서브시스템을 식별하는 데 사용되었다면 할당이 쉽다. 실제로는 분할된 요구사항과 서브시스템이 완전히 일치하는 경우도는 없다. 외부에서 구매된 서브시스템은 제약 조건 때문에 요구사항을 변형해야 하는 경우도 있다.

 4. 서브시스템 기능 분석 : 각 서브시스템에서 제공되는 특정 기능을 분석한다. 이것이 시스템 설계 단계의 부분이 될 수도 있고, 또는 서브시스템이 소프트웨어 시스템이면, 그 시스템에 대한 요구사항 분석 활동의 일부가 될 수도 있다.

 5. 서브시스템 인터페이스 정의 : 각 서브시스템에서 요구되고 제공되는 인터페이스를 정의한다. 이 인터페이스가 정의되면 각 서브시스템을 동시에 개발하는 것이 가능하다.

 

 

 

  양방향 화설표는 설계 프로세스에서 한 단계와 다른 단계 사이에 반복과 검토가 여러 번 이루어진다는 것을 의미한다. 문제와 질문이 계속 생기면 앞 단계에서 작업을 다시 해야 한다.

 요구사항 분석과 설계 프로세스를 분리했지만, 실제로는 미묘하게 연결되어 있다. 레거시 시스템이 갖고 있는 제약 조건이 설계 시의 선택에 제약을 가할 수 있고 그 선택은 요구사항에 지정되어야 한다. 요구 공학 프로세스를 구조화하고 조직화하기 위해서 초기 설계를 해야 하는 경우도 있다. 설계 프로세스가 진행됨에 따라, 기존 요구사항의 문제점을 발견하고 새로운 요구사항이 생길 수도 있다. 결과적으로 이렇게 연결된 프로세스를 나선형으로 나타내어 생각할 수 있다.

 나선형 프로세스는 요구사항이 설계 결정에 영향을 미치고, 역으로도 영향을 미칠 수 있다는 것을 의미한다. 중심에서 시작하여 나선의 각 회전은 요구사항과 설계에 상세사항을 추가시켜 주며, 어떤 회전은 요구사항에 초점을 맞추기도 하고, 설계에 맞추기도 한다. 때로는 요구사항과 설계 단계에 새로운 지식이 모아진다는 것은 문제 그 자체도 변경된다는 것을 의미한다.

 대부분의 모든 시스템에서 여러 가지 설계가 요구사항에 맞을 수 있다. 그러한 것은 하드웨어, 소프트웨어, 사람의 운영을 결합한 해결 방법을 포함한다. 추후 개발을 위해서 선택한 해결 방법은 요구사항에 맞는 가장 적합한 기술적 해결 방법이 될 것이다. 그러나 광범위한 조직과 정책적 고려는 해결 방법의 선택에 영향을 미칠 수 있다. 예를 들어, 정부 고객은 그 시스템이 약간 기술적으로 질이 떨어지더라도 국외 공급자보다는 자국의 것을 선호한다. 설계와 요구사항을 승인하거나 거부하는 검토와 평가 단계에 영향을 미친다. 이 프로세스는 검토와 평가가 고급 단계의 설계와 요구사항이 다음 단계를 시작할 만큼 충분히 상세하다는 것을 보여줄 때 끝이 난다.

 

 2.2.3 시스템 모델링

 

 시스템 요구 분석과 설계 활동 동안에 시스템은 컴포넌트 집합과 컴포넌트 사이의 관계에 의해서 모델링 된다. 보통 모델은 시스템 아키텍처의 개요를 독자에게 보여주기 위한 시스템 구조로서 그림으로 표현한다. 

 시스템 아키텍처는 주요 서브시스템을 보여주는 블록 다이어그램과 서브시스템 간의 관계로 표현된다. 블록 다이어그램을 그릴 때 각 서브시스템은 사각형으로, 서브시스템 간의 관계는 화살표로 나타낸다. 관계는 '/' 를 사용하여 데이터 흐름을 포함하기도 하고 다른 유형의 의존 관계를 나타내기도 한다.

 이 단계에서, 각 시스템은 서로 상호작용하는 서브시스템의 집합으로 분해된다. 각 서브시스템은 시스템이 기능적 컴포넌트로 분해될 때까지 같은 방법으로 표현된다. 기능적 컴포넌트는 단일 기능을 제공하는 서브시스템의 관점으로 보았을 때 컴포넌트이다. 물론 다른 관점(컴포넌트의 생산자)으로 보았을 때 기능적 컴포넌트는 그 자체가 시스템일 수 있다.

 역사적으로, 시스템 아키텍처 모델은 동시에 개발될 수 있는 하드웨어와 소프트웨어 컴포넌트를 식별하는 데 사용되었다. 그러나 이 하드웨어 / 소프트웨어 컴포넌트에 대한 구분은 그리 중요하지 않다. 거의 모든 컴포넌트는 내장된 계산 능력을 포함하고 있다. 예를 들어, 네트워크 연결 기계는 증폭기와 네트워크 게이트웨이를 합해서 하나의 물리적 케이블로 구성되어 있다. 증폭기와 네트워크 게이트웨이는 특정한 전자적 컴포넌트와 마찬가지로 프로세서를 유도하는 소프트웨어와 프로세서를 포함한다.

 아키텍처 수준에서 하드웨어 / 소프트웨어 사이의 선택은 그 기능에 따라 서브시스템을 분류하는 것이 더 적절하다. 하드웨어나 소프트웨어에 있는 기능을 제공하기 위한 결정은 컴포넌트를 개발하기 위해 필요한 시간과 기성품의 가용성과 같은 비기능적 요소에 의해 좌우된다.

 블록 다이어그램은 모든 크기의 시스템에 대해서 사용될 수 있다. 이 시스템 간의 화살표는 서브시스템 간의 정보 흐름을 나타낸다.