본문 바로가기

Dev.../소프트웨어 아키텍처

[SA강좌] Part 1-13 아키텍처와 개발 프로젝트의 다른 역할과의 관계, 개발조직간의 관계

아키텍처와 개발 프로젝트의 다른 역할과의 관계, 개발 조직간의 관계

아키텍트와 다른 역할과의 관계

그림 Ⅱ-6. 아키텍트와 다른 역할과의 관계

그림 Ⅱ-6을 보면 관련 당사자는 요구사항을 정의하고 시스템의 개발 목적을 정의한다. 아키텍트는 아키텍처를 개발하면서 관련 당사자의 요구사항을 참고한다. 아키텍트는 아키텍처를 개발하면서 어떤 framework을 사용할 것인지도 결정한다. 시스템 엔지니어는 시스템을 설계하면서 아키텍처를 참고한다. 개발자는 시스템을 개발하면서 시스템에 대한 설계 문서를 참고한다.

프로젝트 조직 구성

아키텍처가 프로젝트의 핵심적인 역할을 수행하게 되면서 프로젝트 조직 구성도 변하게 된다. 프로젝트 조직은 한번 구성되면 프로젝트 마지막까지 변하지 않는 조직이 아니라 프로젝트의 각 phase가 끝날 때마다 재구성되는 동적인 조직이다. 아키텍처와 iteration을 고려한 프로젝트 조직의 특징은 별도의 아키텍처 팀이 존재하며 설계팀과 개발팀이 분리되어야 한다는 것이다.

아키텍처 팀, 설계 팀과 개발팀이 분리되어야 하는 이유

iteration에서는 한 iteration의 기간이 짧다. 또한 아키텍처가 완성되기 전까지는 개발이 시작될 수 없다. 따라서 아키텍처에 대한 작업이 진행되는 동안 설계자는 업무를 분석하고 개념 설계를 진행해야 한다. 아키텍처가 완성되고 상세 설계에 대한 방침이 정해지면 개발이 시작될 수 있다. 개발팀은 개념 설계 문서와 상세 설계 방침을 바탕으로 개발을 진행한다. 어떤 경우에는 아키텍처 설계, 개념 설계, 개발이 동시에 진행될 것이다. 또한 개발팀이 개념 설계까지 담당할 수 없는 이유는 인터페이스에 대한 설계는 설계팀만이 결정할 수 있기 때문이다. 또한 설계팀은 업무에 대한 분석 및 설계만, 개발팀은 개발만 진행하는 것이 효율적이다. 또 한가지 방법은 설계팀은 업무 분석 및 개념적인 설계만 진행하고 개발팀은 아키텍처 팀의 지침을 따라 상세 설계를 진행한 후 개발해도 된다.

그림 Ⅱ-7. 개발 조직의 작업 절차

그림 Ⅱ-7를 보면 아키텍처 팀과 설계 팀, 개발팀의 작업이 동시에 진행된다. 그러나 동시 작업을 위해서는 다음 사항이 전제되어야 한다.

첫째, Inception 단계에서 각 팀이 어떤 문서를 주고 받을 것인지 어떻게 communication할 것인지가 결정되어야 한다.

둘째, 각 팀의 책임과 역할을 명확히 해야 한다.

셋째, 아키텍처 팀이 subsystem을 나누고 컴포넌트를 식별하기 전까지는 설계 팀은 요구사항을 분석할 수는 있지만 그 이상의 작업은 불가능하다.

넷째, 컴포넌트에 대한 초안은 아키텍처 팀에서 정의하지만 컴포넌트에 대한 정제, 상세 설계 및 인터페이스에 대한 결정은 설계 팀에서 한다. 대신 아키텍처 팀은 인터페이스를 잘못 설계한 것은 없는지 검증한다.

다섯째, 개발에 대한 검증은 설계 팀과 아키텍처팀에서 책임진다.

따라서 설계는 아키텍처 팀이 개발은 설계 팀과 아키텍처팀이 review한다.

각 조직이 하는 역할

각 팀이 해야 할 일들이 해야 하는 역할은 다음과 같다.

아키텍처 팀은 시스템을 초기 구현하고 설계, 개발에 대한 템플릿을 작성하고 설계와 개발의 이행 절차를 정의하고 툴 사용 절차를 정의한다. 설계 팀과 개발팀을 컨설팅하는 역할을 담당한다.

설계팀은 요구사항을 분석하고 화면을 작성하는데 중점을 둔다. 또한 인터페이스를 결정한다.

개발팀은 아키텍처의 가이드라인을 따라 설계팀에서 넘어온 문서를 바탕으로 상세 설계서를 작성하고 시스템을 구현한다.

개발 조직에 대한 구성 방안

개발 조직에 대해 다음과 같은 변형이 가능하다.

개발 조직이 개념 설계서만을 기초로 시스템을 개발하는 경우:

개발팀은 상세 설계서 없이 개념 설계서에 기초하여 아키텍처 문서의 가이드라인을 준수하여 시스템을 개발할 수 있다. 이 경우 개발 산출물이 아키텍처를 준수했는지는 아키텍처 팀에서 평가한다.

아키텍처 팀에서 상세 설계서를 작성하여 개발팀에게 넘겨주는 경우:

설계팀에서 개념 설계서를 작성한 후 아키텍처 팀에서는 상세 설계서를 작성하여 개발팀에게 넘겨준다.

MVC 패턴을 사용하는 경우:

MVC를 사용하는 경우 작업은 더 능률적이지만 아키텍트는 MVC의 일관성에 대한 검증을 더욱 철저히 해야 한다. 자신이 없다면 개발자를 MVC로 분리해서는 안 된다.

개발 조직과 아키텍처 팀 간의 관계

아키텍처 팀은 개발 팀, 설계 팀, 지원 팀, 테스팅 팀, 프로젝트 관리 팀과 관계를 갖는다. 또한, 아키텍쳐 팀은 TFT로 구성하는 것이 일반적이긴 하지만, 프로젝트의 규모에 따라서 상시조직으로 운영할 수도 있다. 다만, 상시운영이 될때에는 다음과 같은 운영 환경이어야 한다.

  1. 의사결정을 해야할 고객 수준의 조직이 여러 개인 경우
  2. 아직 미결정된 하드웨어나 업무의 형태가 존재하는 경우
  3. 지속적인 성능향상이 필요한 경우
  4. 기술적인 요소에서 사례가 없거나 경험이 없는 경우 PM의 기술적인 참모조직이 필요한 경우

가장 중요한 것은 비용문제이기에 해당 문제에 대해서는 전반적인 협의가 필요하다.

아키텍처 팀과 개발 팀의 관계

개발 팀은 아키텍처 팀이 작성한 아키텍처 문서를 통해 시스템에 대한 전반적인 이해를 갖고 개발을 시작한다. 또한 개발 팀은 아키텍처 팀에서 작성한 코딩 표준안과 구현된 프로그램을 사용하여 개발한다.

아키텍처 팀과 설계 팀의 관계

아키텍처 팀이 초기에 설계한 문서와 아키텍처 상의 제약 사항을 염두에 두고 설계를 진행한다.

아키텍처 팀과 지원 팀의 관계

아키텍처로 인해 시스템 구성이 바뀌어야 하는 부분이 있으면 협의하여 수정한다.

아키텍처 팀과 테스팅 팀의 관계

아키텍처 팀의 지시를 받아 아키텍처가 사용자가 원하는 성능을 만족하는지 검사한다.

아키텍처 팀과 프로젝트 관리 팀의 관계

아키텍처가 결정된 후 프로젝트 관리자는 아키텍처를 반영하여 조직을 재구성한다.