아키텍처 설계 문제 분석 원리와 방법 : 개념, 개요, 정의

아키텍처 설계 문제 분석 원리와 방법 : 개념, 개요, 정의

 

아키텍처 설계 문제 분석의 원리

아키텍처 설계 문제 분석은 요구사항들 속에서 아키텍처 설계를 요구하는 문제를 식별하고, 정리하고, 그 해결책의 후보를 도출하는 활동입니다. 이를 위해서는 첫 번째로 선정된 아키텍처 드라이버들로부터 어떤 설계 문제가 들어있는지를 파악하여 정리하고, 둘째로 이 문제들에 대한 가능한 해법들을 도출하고, 셋째로 이 해법들을 평가하여 그 효과를 정리하여야 합니다. 세 번째 단계의 작업이 평가를 위해서는 직관을 사용할 수도 있고, 매우 중요한 결정인 경우에는 뒤에서 12번째 아키텍처 설계 원리로 학습하게 될 비용 이득 관점의 진보된 평가 방법을 사용할 수도 있습니다.

 

 

 

아키텍처 설계 문제 분석 방법

과거에 여러 연구자들에 의해서 여러 가지 방법이 만들어졌지만, 여기서는 지멘스 회사의 연구자들이 쓴 이슈카드 방법을 보도록 하겠습니다. 이 방법에서 이슈는 아키텍처 설계가 해결해야 할 설계 문제를 말합니다. 맨 위에 이슈의 이름이 있고, 이슈에 대한 설명이 이어집니다. 그다음에는 그 이슈를 발생시키는 요인들이 열거됩니다. 이 요인들은 선정된 아키텍처 드라이버에서 나오기도 하고, 그 안에 포함되지는 않았지만 아키텍처 설계 문제 분석을 하는 과정에 새로이 발견한 영향을 주는 요소들이 나올 수 있습니다. 그리고 하단에는 적용될 수 있는 해결책들이 나오는데, 이 해결책들은 실제 설계에 적용될 수도 있고 적용되지 않을 수도 있는 생각할 수 있는 모든 해결책들입니다.

이 이슈의 내용을 보면 개발 일정을 공격적으로 만드는 요인으로 먼저 출시시간이 짧고, 변경될 가능성이 없으며, 개발인력은 크게 늘릴 수 없고, 개발회사는 컴포넌트를 구매하는 것보다 개발하는 것을 선호합니다. 그 외에 개발 일정을 공격적으로 만드는 것은 아니지만 관련된 사항으로 개발 대상 Feature가 협상 가능하며, 우선순위가 낮은 Feature는 나중에 Release가 가능하고, 또 다른 사항으로 개발회사가 상용 컴포넌트를 구매할 수 있는 예산을 어느 정도 갖고 있다는 것입니다. 한편 공격적인 일정 문제를 해결할 수 있는 방법으로 회사에서 자체 개발한 컴포넌트를 재사용하는 전략, 개발하지 않고 구매하는 전략, Feature를 추가하고 제거하기 쉽게 아키텍처 설계를 하는 전략들이 있습니다. 이 해결책들은 반드시 상호 배타적이지는 않고 두 개 이상의 전략이 동시에 적용될 수도 있습니다.