29장 통합
목차
- 29.1 통합 접근 방법의 중요성
- 29.2 통합 빈도-단계별 또는 점증적 접근 방법
- 29.3 점증적 통합 전략
- 29.4 일일 빌드와 스모크 테스트
"통합"이라는 용어는 개별적인 소프트웨어 컴포넌트를 하나의 시스템으로 결합하는 소프트웨어 개발 행위를 말한다.
이번 통합에서는 학부 과정 중 "소프트웨어 공학 개론" 과목에서 배운 내용들이 많이 있어서 뭔가 익숙한 느낌이었다. 여러 개의 분할 된 기능 또는 클래스들은 결국 마지막에 하나로 합쳐져야 하는데 어떻게 효율적으로 이를 하나로 만들 수 있을지에 대한 내용을 다룬다.
29.1 통합 접근 방법의 중요성
이 책에서는 워싱턴 대학교 축구장 건립 예제가 사용되었다. 축구장을 짓던 중 축구장이 무너지는 사고가 발생했는데, 축구장이 완성된 후 얼마나 견고한지도 중요하지만, 만들던 중에도 하중을 충분히 견딜 수 있는 설계를 하고 건설을 해야한다는 중요성을 알 수 있었다. 소프트웨어도 이와 마찬가지로 완성된 후도 중요하지만, 구현 중에 소프트웨어가 무너지지 않도록 견고하게 통합을 해야 한다.
신중한 통합을 했을 때 얻을 수 있는 이익
- 더 쉬운 결함 진단
- 더 적은 결함
- 더 적은 비계
- 첫 번째 제품 완성 시간 단축
- 전체적인 개발 일정 단축
- 더 나은 고객과의 관계
- 의욕 고취
- 프로젝트 완성 기회 향상
- 더 신뢰할 수 있는 일정 측정
- 더 정확한 상황 보고
- 향상도니 코드 품질
- 더 적은 문서
29.2 통합 빈도-단계별 또는 점증적 접근 방법
단계별 통합
학부 과정 중 비슷한 내용을 수료한 경험이 있다면, 단계별 접근 방법 대신 빅백 통합이라는 말이 더 익숙할 것이다. 각 클래스들을 모두 만들고, 한 번에 모든 클래스를 통합하는 것이 단계별 통합(빅뱅 통합)이다. 작은 프로젝트에서는 시간을 아낄 수 있고 효율적이나, 큰 프로젝트의 경우 치명적인 문제가 발생할 수 있다. 한번에 통합하기 때문에 통합 과정에서 결함이 발생할 경우 어디에서 발생했는지 찾기가 어렵다. 결국 근본적인 원인을 찾는데 많은 시간이 걸리거나, 근본적인 원인 해결 대신 증상을 해결하는 방법으로 이를 처리하게 되고, 이는 품질을 떨어뜨리게 된다.
점증적 통합
점증적 통합은 뼈대를 처음 만들고, 하나씩 붙여가는 과정이다. 점증적 통합을 하게 되면 단계별 통합의 문제점을 쉽게 해결할 수 있다. 한 번에 하나의 클래스 또는 기능을 통합하기 때문에, 만약 결함이 발생한다면 이번에 통합한 클래스 또는 상호 연결 과정의 문제일 가능성이 가장 크다.
29.3 점증적 통합 전략
단계별 통합에서는 프로젝트 컴포넌트를 만드는 순서를 계획할 필요가 없다. 모든 컴포넌트가 동시에 통합되므로 통합 전까지 각 개별 컴포넌트만 완성하면 된다. 하지만 점증적 통합은 다르다. 위의 워싱텅 대학교 경기장처럼 프로그램이 무너지지 않을 기반을 먼저 만들고, 거기에 통합을 해야한다.
하향식 통합
하향식 통합은 상위 컴포넌트를 먼저 만들고, 하위 컴포넌트를 그 다음에 만드는 방법이다. 상위 컴포넌트 먼저 만들기 때문에 설계 상의 오류가 있을 경우 이를 빨리 알아채고, 수정할 수 있다. 또 처음부터 제대로는 아니지만 어느정도 동작하는 전체 프로젝트의 시스템을 뼈대를 볼 수 있다. 하지만 개별적인 기능들은 마지막에 만들고 통합하기 때문에 하단 인터페이스에서 문제가 발생하면 프로젝트를 지우고 다시 생성해야 하는 문제가 발생할 수도 있다.
상향식 통합
상향식 통합은 하위 인터페이스에서 시작해 점점 상위 컴포넌트로 올라가는 방식이다. 하단 인터페이스에서 문제가 발생할 가능성이 크기 때문에 이를 먼저 테스트하고 사용할 수 있는 장점이 있다. 하지만 이 역시도 설계 과정에서 문제가 있었다면 프로젝트를 폐기하고 처음부터 다시 만들어야 하는 문제가 발생할 수 있다.
샌드위치 통합
상향식과 하향식 통합의 절충안이 샌드위치 통합이다. 상위 컴포넌트를 만들고, 최하단 인터페이스를 만든 후 가운데를 비워둔다. 그리고 이를 모두 테스트 한 후 가운데를 채워가는 방향으로 진행하는 통합 방법이 샌드위치 통합이다.
위험 지향적인 통합
위형 지향적인 통합은 우연히도 샌드위치 통합과 방법이 같다. 상위 컴포넌트 만들고, 하위 인터페이스를 만들고 중간 부분을 채워나가는 식이다. 하지만 이렇게 하는 이유가 있다. 가장 위험한 클래스부터 만들고 테스트하기 때문에 결함이나 문제를 일으킬 가능성이 가장 큰 상위 컴포넌트와 하위 인터페이스를 먼저 만든다. 각 클래스 또는 컴포넌트 별로 위험성을 평가하고, 위험성이 높은 부분을 먼저 만들고 통합하는 것이 위험 지향적인 통합 방법이다.
29.4 일일 빌드와 스모크 테스트
어떠한 통합 전략을 선택하든 소프트웨어를 통합하는 좋은 접근 방법의 하나는 "일일 빌드와 스모크 테스트"이다. 모든 파일을 매일 컴파일하고 링크하며 실행 프로그램으로 만든다. 그리고 나서 해당 프로그램을 실행했을 때 "연기를 내뿜는지" 확인하는 비교적 간단한 "스모크 테스트"를 거친다.
