[Software Engineering] CH3 : System Engineering Review

Key Takeaway Points

• 시스템 엔지니어링은 하드웨어, 소프트웨어 및 인적 구성 요소를 포함하는 시스템을 개발하기 위한 다학제간 접근이다.
• 시스템 엔지니어링은 시스템에 대한 요구사항과 제약조건을 정의한다. 하드웨어, 소프트웨어, 인적 시스템에 요구사항을 할당하고, 하위 시스템을 통합해 시스템을 구성한다.
• 소프트웨어 엔지니어링은 시스템 엔지니어링의 일부분이다.

시스템을 어떻게 설계하고 기존 데이터베이스, 비즈니스 프로세스와 통합할 것인지 시스템 엔지니어링 접근 방식이 필요하다.

이번 장에서 다루는 내용은 아래와 같다.

• 시스템 엔지니어링 프로세스
• 시스템 모델링과 디자인 기술
• 서브시스템에 시스템 요구사항 할당
• 시스템 구성 관리

1. What is a System?

시스템은 목적을 달성하기 위해 상호작용하는 구성 요소로 구성된다. 모든 시스템은 아래 속성 또는 특성을 공유한다.

• 각 시스템은 상호작용, 상호연관되는 서브시스템, 구성 요소 또는 요소의 집합으로 구성된다.
• 시스템은 다른 시스템의 서브시스템일 수 있다.
• 각 시스템은 환경에 존재하며, 환경과 상호 작용한다.
• 시스템은 내부적 또는 외부적 원인들로 항상 진화한다.

2. What is System Engineering?

시스템 개발은 학제간의 노력이다. 하드웨어, 소프트웨어, 인적 자원 개발을 포함한다. 시스템 공학은 이러한 질문들에 대답하는 공학 분야이다.

• 우리는 그러한 시스템들에 대한 시스템 요구사항들을 어떻게 확인하고 공식화할 것인가?
• 우리는 어떻게 그러한 시스템들을 설계하고 구성할 것인가?
• 우리는 어떻게 개발 활동들을 관리할 것인가?
• 우리는 그러한 시스템들의 성능, 신뢰성, 안전성, 그리고 다른 요소들을 어떻게 측정할 것인가?
• 우리는 어떻게 시스템이 사회와 환경에 미치는 영향을 평가할 것인가?

시스템 공학은 다음과 같은 요소들을 강조한다.

1. 시스템의 전체 라이프 사이클을 다루는 시스템 엔지니어링 프로세스이다.
2. Top-Down Divide-and-Conquer 접근을 사용한다.
3. 시스템 개발에 대한 학제 간 접근이 필요하다.

시스템 엔지니어링 프로세스의 단계

1. 비즈니스 요구사항을 식별하고, 요구사항은 비즈니스 문제를 해결하는데 필요한 시스템의 기능을 지정한다.
2. 아키텍처는 기능을 제공하는 법 또는 솔루션 초안 제시한다. 하위 시스템들 간의 관계를 묘사한다.
3. 하위시스템 기능 및 인터페이스를 지정한다. 하위 시스템이 서로 상호작용하는 방식을 지정한다.
4. 서브시스템은 각 엔지니어링 팀에서 동시에 개발된다.
5. 시스템 통합, 테스트, 개발, 유지 과정을 거친다.

3. System Requirements Definition

3.1. Identifying Business Needs

비즈니스 요구 파악은 정보 수집 활동에서 시작된다. 비즈니스 목표와 현재 비즈니스 상황에 대한 정보를 수집한다. 현재 상황과 비즈니스 목표 사이의 격차를 파악하고 비즈니스 요구를 도출한다.

정보 수집 기법

1. Customer presentation
   개발팀에게 고객 업무를 소개해 초기 도메인 개념을 제공한다.
2. Study of current business operations
   현재 비즈니스 운영에 대한 연구를 진행한다.
3. User Survey
   새로운 시스템에 대한 사용자의 의견과 기대를 얻는 데 유용하다.
4. User Interview
   설문조사에서 얻기 어려운 정보를 얻는 데 유용하다.
5. Literature survey

4. System Arcitectural Design

아키텍처는 중요한 요소를 명시하고 요소들 간 관계를 표현한다. Complexity와 Cost를 줄이는 것을 목표로 한다. 시스템 아키텍처 디자인은 아래의 활동들로 수행된다.

1. 시스템을 서브시스템들로 분해한다. 각 분야 엔지니어들이 서브 시스템을 개발한다.
2. 시스템 요구사항을 하위 시스템에 할당한다. 하위 시스템 간 공유되는 요구사항의 수를 줄이는 것을 목표로 한다. 하위 시스템의 책임이 명확하게 정의되어야 한다. 할당된 요구사항은 기능적으로 관련되어야한다.
3. 시스템 아키텍처를 시각화한다.

4.1. System Decomposition

시스템 분해는 다음 목표들을 달성하는 것을 목표로 한다.

1. 엔지니어링 팀이 하위 시스템을 개발할 수 있어야 한다.
2. 상용 기성품(COTS) 부품 사용이 용이해야 한다.
3. 시스템 요구사항을 분할해야한다.
4. 잘 정의된 기능을 가져야 한다.
5. 비교적 독립적이어야 한다. 다른 서브시스템에 영향을 미치지 않도록 해야한다.
6. 통합하기 쉬워야 한다. 서브시스템들은 간단한 인터페이스와 상호작용 동작을 거쳐 통신을 단순화해야 한다.

4.2. Requirements Allocation

Traceability Matrix은 개발 프로세스 전반에 거쳐 요구사항을 추적한다.

Traceability Matrix의 장점

• 모든 요구사항이 하위 시스템에 할당되어있는지 확인 가능하다.
• 할당이 적절한지 확인 가능하다. 요구사항을 여러 서브 시스템에 할당하는 것은 서브 시스템 간 기능을 나누는 것이 어려워 피해야 한다. Row에 표시가 많으면 요구사항 분해가 필요하다.
• 어떤 요구사항이 하위 시스템에 할당되어있는지 확인 가능하다.
• 너무 많은 책임이 할당되어있는지 확인 가능하다. Column에 표시가 많으면 책임이 너무 많다는 의미이다. 요구사항 분산을 위해 하위 시스템을 분해할 필요가 있다.
• 서브 시스템의 기능 응집력을 확인할 수 있다. 할당된 요구사항은 기능적으로 관련이 있어야 한다. Column에 표시된 요구사항이 관련 없으면, Column으로 표시된 서브 시스템은 기능적 응집력이 낮다. 요구사항은 여러 기능적 클러스터로 분할하고, 서브시스템은 기능적 클러스터에 해당하는 기능적 서브 시스템으로 분해되어야 한다.

7. System Configuration Management

변경 제어는 조정해야하는 이슈다. 만약 전자 부품의 설계가 변경된다면, 소프트웨어 부품 설계도 함께 변경해야 한다. 그래서 통지 메커니즘이 필요하다. 설계 변경이 잦으면 대처가 어렵고, 아예 변경할 수 없으면 결함, 오류를 수정할 수 없다. 이런 문제들을 시스템 구성 관리를 통해 해결할 수 있다.

시스템 구성 관리는 아래 네 개의 메인 기능들로 구성된다.

1. 구성 항목 식별
   프로젝트 기준선 및 관련 구성 항목을 정의한다. ex. 요구사항 기준선, 설계 기준선, 할당 기준선
   기준선은 모든 관련 구성 항목이 구성 관리 시스템에 체크인될 때 설정된다. 요구사항 기준선은 SRS와 프로젝트 계획서로 구성된다면, 두 문서 모두 구성 관리 시스템에 체크인되어야 기준선이 설정된다.
2. 변경 제어 구성
   변경 제어 절차를 정의하고 절차를 실행한다. 필요한 변화를 파악하고 분석한다.
3. 구성 감사
   프로젝트 기준선 공식을 설정하고, 엔지니어링 변경이 적절하게 이루어지는지 확인한다.
4. 구성 상태 보고
   구성 항목 정보를 조회하고, 구성에 대한 이벤트를 게시한다. 기준선 설정, 구성 항목 변경 사항을 포함한다.