[소프트웨어공학] Chapter 3 - System Engineering

해당 책을 바탕으로 글을 작성하였습니다

 

시스템이란?

시스템은 목적을 달성하기 위해 서로 상호작용하는 구성요소로 구성된다. 크거나 작을 수 있고, 복잡하거나 간단할 수 있고, 실제로 존재하거나 컨셉츄얼하게 존재할 수 있다. 개미들, 우주와 같은 자연적인 시스템도 존재하고, 인간이 만든 시스템 역시 많이 존재한다. 인간이 만든 시스템은 실제로 존재하거나 개념적으로만 존재할 수 있다.

Computer-based 시스템은 소프트웨어가 하위 시스템으로 포함된 인간이 만든 시스템이다. telecommunication 시스템, 이메일 시스템 등이 포함되어 있다. 몇몇 시스템은 software-only system이고, 몇몇 시스템은 소프트웨어와 하드웨어, 인간의 하위 시스템으로 구성된다.

모든 시스템은 다음의 특성들을 공유한다.

1. 각 시스템은 상호관련되거나 상호작용하는 하위 시스템이나 원소들의 집합으로 구성된다.
2. 시스템은 더 큰 시스템의 하위 시스템이 될 수도 있다.
3. 각 시스템은 환경에 존재하고, 그 환경과 상호작용한다.
4. 시스템은 외적인 요소나 내적인 요소에 의해 진화한다. 결함 버그와 같은 결점이 시스템의 변화를 유발하기도 한다.

시스템 엔지니어링이란?

• 여러 subsystem으로 구성되어있는 시스템은 전체적인 시스템을 고려하여야 함. 그리고 그 시스템들을 같이 고려하기 위하여 work together 하여야 함.
• 해당 책에서는 공항 화물 관리 시스템 (ABHS)을 예시로 들었음. 공항 화물 관리 시스템은 바코드 스캐닝, 컨베이어를 통한 화물 이동, 건축물, 다른 장비들간의 제어 등 여러 하위 시스템들로 구성되어 있는데, 각자의 engineering이 함께 작동하여야 하나의 큰 시스템이 작동함.
• 시스템 공학은 이렇듯 여러 공학 기술만 필요한 것 뿐만 아니라, 경제학, 수학 등 비공학적인 요소들도 필요하다. 또, 시스템 공학은 안전성과 보안성, 신뢰성 등 여러 속성들도 고려하여야 됨.
• 요약하자면, 시스템 개발은 하드웨어, 소프트웨어 및 인간의 리소스를 포함한 종합적인 노력이다. 그리고 이것은 여러 과제를 암시하기도 한다. 이러한 시스템에서 시스템 요구사항을 어떻게 식별하고 형식화할것이며, 어떻게 시스템을 설계하고 디자인할것이며, 개발 활동을 어떻게 관리할 것인가와 같은 여러 과제들이 암시됨.
• 시스템 엔지니어링은 아래 요소들을 강조함
  1. 시스템의 초기 개념과 유지보수 폐기에 달하기 까지 완전한 시스템 수명주기를 다루며, 엔지니어링 팀이 고객의 요구와 우선순위에 집중하고 충족시키기를 장려한다.
  2. Top-down divide-and-conquer접근법, 전체 시스템을 하위 시스템과 구성요소로 분해하고 개발함
  3. 서로 협력하며 개발하도록 장려

시스템 요구사항 정의

시스템 요구사항 정의 과정은 비즈니스에서의 요구와 시스템 요구사항을 구체화함.

비즈니스 요구 나타내기

비즈니스 요구사항 식별은 정보 수집 활동으로 시작됨. 이는 비즈니스 목표나 현재 비즈니스 상황 등에 관한 정보임. 이 정보들은 아래 질문들에 답이 됨

1. 시스템이 자동화할 비즈니스는 무엇인가?
2. 시스템의 환경과 그 사용하는 상황은 무엇인가?
3. 비즈니스의 목표는?
4. 현재 비즈니스 상태는? 그리고 어떻게 작동하는가?
5. 현재까지 비즈니스가 작동하는 과정은? 그리고 그것들이 어떻게 서로 상호작용 하는가?
6. 현재 시스템의 문제는?
7. 현재와 미래 각각 고객들은 누구인가?
8. 미래에 고객들이 원하는 요소는? 그리고 어떤것이 개발 우선순위에 있는가?
9. 퀄리티, 성능, 보안은 어떠한가?

이러한 정보를 얻기 위해서 다양한 정보 수집 기술들을 사용함

1. 고객 프레젠테이션
2. 현재 비즈니스 작동 방식에 대한 연구
3. 유저 설문
4. 유저 인터뷰
5. 문헌 조사

시스템 요구사항 정의

비즈니스 요구가 굉장히 많아도, 스케쥴이나 정책적인 제한, 기술적 제한, 스케쥴 이슈 등으로 모든걸 충족시킬 수 없음. 따라서 몇개를 골라서 수행해야됨.

시스템 아키택처 디자인

시스템에 대한 요구사항 분석이 끝났으면 시스템을 디자인해야됨. 이러한 시스템들이 이상적으로 봤을때는 모든 엔지니어링에 통달한 엔지니어가 하면 좋겠지만, 이러한 엔지니어는 굉장히 비용이 많이 듦. 따라서, 시스템들은 보통 여러 서브 시스템으로 쪼개서 모든 엔지니어링에 통달하지 않고, 특정 분야에만 통달한 엔지니어도 할 수 있을 정도로 쪼갬.

아키택처란? : 목표를 달성하기 위한 중요한 서브 시스템 간의 관계의 정의. 목표를 달성하기 위해 복잡한 시스템들을 쉽게 이해할 수 있도록 도와줌.

#0 시스템 아키택처 디자인 과정 개요

1. 여러 서브 시스템 계층 구조로 시스템을 분할함. 쪼갠 서브 시스템들은 덜 복잡하고 비용도 적게 들고 더 간단하기 때문에 디자인하고 구현하기가 쉬움
2. 앞서 구한 시스템의 요구사항들을 쪼개 서브 시스템에 각각 할당함. 이를 통해, 각각 서브 시스템을 개발하는 사람들은 요구사항에 대한 부담을 줄일 수 있고, 그 시스템이 하는 역할이 명확해짐
3. 시스템 아키택처를 시각화

이제 아래 순서대로 시스템 아키택처 디자인이 시작된다.

#1 여러 서브 시스템으로 분할

시스템 분할의 목표는 다음과 같음

1. 각각의 엔지니어 팀들이 자기들의 각각의 서브시스템들을 개발하도록 해야됨.
2. COTS 부분의 사용이 가능하도록 해야됨. (COTS란? : 구매하거나 휙득할 수 있는 타사 제품. 즉, 우리가 처음부터 끝까지 만들 필요는 없고, 구매할 수 있는건 사서 쓰자)
3. 시스템 요구사항들은 서브 시스템들에 분할할 수 있어야 함.
4. 각각의 서브시스템들은 무슨 기능을 하는지 명확해야 함.
5. 서브시스템들은 독립적이어야함.
6. 서브시스템들은 통합하기 쉬어야 한다.

시스템 분할 전략은 다음과 같음. 이 중에서 하나를 따라서 분할함.

1. 시스템 기능에 따라서 분할하기
2. 학문에 따라서 분할하기 (하드웨어, 소프트웨어 등)
3. 존재하는 아키택처에 따라서 분할하기 (마이크로 서비스 아키택처 등)
4. 기능 조직 단위로 분할하기
5. 애플리케이션의 모델에 따라 분할하기

#2 서브시스템에 요구사항 할당

 

일반적으로 요구사항을 각각 할당하고 분할하는 것은 Requirements to subsystem traceability matrix를 이용함. 위 그림은 학교 시스템에 대한 요구사항 분할의 예시임. 위와 같이 표를 작성해서, 각각 서브 시스템이 어떤 기능이 필요한지 한눈에 시각적으로 볼 수 있음. 이 표의 장점은 많음.

1. 서브시스템에 할당된 모든 요구사항들을 체크 가능
2. 서브시스템에 요구사항 할당이 적절한지 체크 가능
3. 어떤 요구사항이 어떤 서브 시스템에 할당됐는지 확인 가능
4. 서브시스템이 너무나 많은 역할을 하고 있는지 체크 가능
5. 서브시스템간 기능적 결합도를 체크 가능

#3 시스템 아키택처 시각화

시스템 모델을 다이어그램으로 시각화 하는 것은 매우 일반적임. 이는 팀이 시스템 모델의 도메인, 비즈니스 과정, 발생하는 문제들, 시스템 디자인을 이해하고 분석하는데 큰 도움을 줌. 일반적으로 많이 쓰는 다이어 그램들이 그 아주 지겹도록 많이하고 유명한 UML, 이외에도 block 다이어그램, SysML, 데이터플로우 다이어 그램 등이 있음.

 

Block diagram

블럭 다이어그램은 서브시스템과 요소들을 사각형으로 표현하고 그 요소들 간에 워크플로우를 나타내기 위해서 방향선으로 연결함. 위 그림과 같은 것임

 

UML

UML은 툴도 많고 초기 시스템 디자인 할때 많이 쓰는 다이어그램임. 일반적으로 Use case Diagram, Class Diagram, Sequence Diagram 세개로 나뉨.

Use case 다이어그램 시스템과 사용자의 상호작용을 다이어그램으로 표현한 UML 다이어그램. 사용자가 시스템 내부 기능 중 어떤 기능을 사용 가능한지 나타내기 때문에, 고객과 개발자의 요구사항 관련 의견을 조율 하라 수 있음.

Class Diagram은 시스템에서 사용되는 객체 타입을 정의하는 다이어그램임. 객체 지향 시스템에서 가장 일반적으로 많이 쓰는 다이어그램.

 

Sequnece Diagram은 일반적으로 시스템의 흐름을 시각화 하는 다이어그램임.

 

SysML (System Modeling Language)

UML 다이어그램들이 이곳저곳에서 많이 만들어졌을 때, 이 UML들을 요약한 다이어 그램이 SysML임.

 

Data flow diagram (DFD)

데이터가 소프트웨어 내 각 프로세스를 따라 흐르면서 변화되는 모습을 나타낸 것임. 즉, 데이터의 흐름도.

#4 서브시스템 기능과 인터페이스 구체화

각각의 서브시스템들의 기능을 구체화하고, 어떻게 서로 상호작용하는지 구체화하는 단계. 여러 서브 시스템들 사이에 공통의 인터페이스가 있다면, 우리는 쉽게 그 서브시스템들이 어떻게 연결되고 상호작용하는지 쉽게 알 수 있음. 또한, 팀원들도 서브시스템 개발할 때 어떤식으로 개발해야하는지, 어떤 결과를 내뱉어야하는지, 어떤 요구를 충족해야되는지 쉽게 알 수 있음. Java에서 interface로 개발하는거 생각해보셈.

서브시스템 개발

디자인하고, 요구사항들 분배가 됐으면 이제 각각 팀들에게 할당되고 개발에 도입함.

Object-oriented Context Diagram

소프트웨어 개발 활동은 반드시 서브시스템들의 흐름을 고려해야됨. 각각의 서브 시스템이 실제로 어떻게 동작하고 상호작용 하는지에 대해서 말임. 결국 이걸 알기 위해서 작성하는게 Object-oriented Context Diagram. 사실 앞서 작성한 UML같은 거임. 각각 시스템들이 서로 어떻게 상호작용 하는지에 관한 다이어그램일 뿐. 이런 다이어그램의 이점은 아래와 같음.

1. 소프트웨어 구성 요소들과 그 요소들간 흐름을 통일되게 한번에 보여줌.
2. 인터페이스와 구성 요소들 간의 상호작용을 강조해줌
3. 서브시스템 개발에 도움을 줌
4. 다른 엔지니어링 팀과 소통 및 협업을 가능하게 함
5. 복잡한 서브 시스템들을 쉽게 이해할 수 있도록 해줌

시스템 통합, 테스트, 배포

서브시스템들은 각각 다양한 엔지니어링 팀들에 의해 개발되었음. 그러면 그 각각 개발한 것을 통합해보고, 통합 테스트를 진행해보고, 성능 테스트까지 해보면 됨. 서브시스템 테스트할 땐 전혀 문제 없다가도, 그 시스템을 통합하면 버그가 발생하거나 성능이 저하되는 경우가 매우 허다함. 따라서, 통합 테스트는 매우 중요. 유저들을 통해 베타 테스트도 진행하고, 결점을 찾아내서 고치고, 그렇게 반복해야됨.

시스템 구성 관리

baseline : 프로젝트의 중요한 단계를 나타내는 요소. 시스템 요구사항, 디자인, 할당, 서브시스템 디자인 기준 등이 있음. 그리고 이 기준선들은 요구사항 구체화, 프로젝트 계획, 테스트 계획, 시스템 디자인 구체화, 통합 시스템 테스트 계획들을 포함함. 시스템 기준선을 통해서 성공적으로 시스템이 구성이 완료됐구나를 판단할 수 있음

Change Control : 만약에 전기 회로 디자인이 변경되었다면, 소프트웨어 구조도 변할 것임. 즉, 이러한 변화가 있을 때, 다른 팀들도 이 사실을 알아야됨. Change Control은 이런 것이 변했 다는 것을 어떻게 상호작용 할 것인가에 관한 내용임. 만약에 회로팀이 너무 자주 바꾼다면 소프트웨어 팀은 이 변화를 대처하기 너무 힘들 것임. 반대라면, 결점이나 여러 문제들이 많아 질 것. 따라서, 적절히 이런 변화를 조절하는 것이 중요

시스템 구성 관리는 4가지 요소로 이루어짐.

1. 프로젝트의 baseline과 연관된 구성 항목들을 정의
2. 프로젝트 구성요소 Change Cotrol : Change Cotrol 과정의 예시를 하나 들어봄. 바뀌여야 할 부분들이 분석됨 → engineering change proposal (ECP)가 준비되어 어떤 부분이 바뀌어야 하는지, 얼마나 걸리는지, 어떤 영향을 주는지, 비용은 얼마나 드는지 알려줌 → ECP가 change control board (CCB)에 의해 평가됨 → CCB에 의해 ECP 수락 or 거절 → 이에 대해 알려짐
3. 프로젝트 구성요소 심사 : 1번에서 정한 baseline들이 잘 지켜졌는지 검증하는 과정.
4. 구성요소 상태 보고 : database 등의 상태를 지속적으로 체크하고 보고