주의 : 아래 글은 전적으로 개인적으로 짧은 지식과 소견으로 쓰는 글입니다. 제 전공은 경제학이나 국제금융도 아니고 외환이나 주식관련 애널리스트도 아닙니다. 따라서 아래 정보를 활용해서 발생하는 손실이나 손해에 대해서는 아무런 책임을 질 수가 없음을 밝힙니다. 그리고, 여기에 쓰는 글은 여기저기 널려있는 수많은 정보중에서 제 맘대로 발췌해서 만든내용일 가능성이 대다수입니다. 이 정보를 자신을 위해 사용할 때의 결정은 자기자신만이 할 수가 있는 것이기 때문에 이 글을 읽으실때에는 그냥 편하게 읽어주십시요.
참고로... 저는 무정부주의자도 아니고, 누구를 모함하거나 잘못된 정보를 전달하기 위해 만들어진 글도 아닙니다. 정부의 정책을 반대하는 것도 아니고, 동조하지도 않습니다. 그냥 개인적인 의견이므로 다음부터 나열되는 글을 읽기가 걱정되시면 그대로 페이지를 닫아주시기 바랍니다. 저는 미네르바 처럼 잡혀가기 싫습니다.
아키텍트의 역할 정의
아키텍트는 개발 프로젝트에서 초기에 기술적인 부분에 대하여 의사결정을 진행한다. 또한 프로젝트가 진행될 수 있도록 기술적인 이슈들을 해결한다. 아키텍트가 프로젝트의 각 phase마다 해결하는 문제는 다음과 같다.
표 Ⅱ-1. 프로젝트의 각 phase마다 아키텍트가 수행하는 역할
|
단계 |
아키텍트가 수행하는 역할 |
|
|
|
|
|
|
|
|
개발 프로젝트에서 아키텍트가 하는 역할은 다음과 같다.
아키텍트는 아키텍처를 만들고 컴포넌트와 컴포넌트 사이의 관계를 파악하고 인터페이스를 설계해야 한다. 프로젝트 관리자는 아키텍트가 아키텍처 문서를 생산하도록 관리해야 한다.
프로젝트에서는 아키텍처에 대한 일차 문서가 만들어지면 아키텍처 팀이 해체되고 각 subsystem에 대한 개발 리더로서 역할을 할 경우가 많다. 이 경우 시스템 전체를 보고 아키텍처를 upgrade하는 역할이 없어진다. 아키텍처가 일차 완성된 후에도 아키텍처는 자주 수정된다. 개발자들은 아키텍처 팀이 만든 문서를 받아들이지 않고 새로운 요구사항이 들어오면 아키텍처의 본래 목적에서 벗어난 방식으로 나름대로 개발하려 한다. 따라서 아키텍처 팀은 프로젝트 끝까지 해체되지 않고 아키텍처에 대한 수정 및 업그레이드에 대한 책임을 져야 한다.
또한 아키텍트는 개발자들이 아키텍처를 이해하도록 도와야 하고 아키텍처 밑에 숨은 결정 사항을 설명해야 한다. 즉 아키텍트는 개발자들에게는 컨설턴트로서 리더로서의 역할을 해야 한다.
이를 정리하면 다음과 같이 정리될 수 있다.
-
비즈니스 케이스 생성
-
비용과 기존 시스템과의 인터페이스 여부 설정
-
시스템의 한계 상황 설정
-
비즈니스 목표 설정
-
-
요구사항 분석
-
아키텍쳐는 이해관계자들의 요구사항을 어떻게 반영할것이냐는 점이다.
-
기존 시스템을 어떻게 분석할 것인가?
-
프로토타입은 어느 수준까지? 어떻게?
-
품질요구사항에 따르는 아키텍쳐의 기준은 어떻게?
-
-
아키텍쳐 구축
-
새로운 아키텍쳐를 만들것인가?
-
기존 아키텍쳐를 선택할 것인가?
-
'Dev... > 소프트웨어 아키텍처' 카테고리의 다른 글
| [SA강좌] Part 1-12 소프트웨어 아키텍처와 개발 프로세스의 관계 (0) | 2008/07/29 |
|---|---|
| [SA강좌] Part 1-11 아키텍트의 의무와 가져야 할 역량 (0) | 2008/07/29 |
| [SA강좌] Part 1-10 아키텍트의 역할 정의 (0) | 2008/07/29 |
| [SA강좌] Part 1-9 다른 아키텍처와의 관계 (0) | 2008/07/29 |
| [SA강좌] Part 1-8 소프트웨어 아키텍처에 포함되지 않는 것 (0) | 2008/07/29 |
| [SA강좌] Part 1-7 소프트웨어 아키텍처의 특징과 역활 (0) | 2008/07/29 |



이올린에 북마크하기
Prev
Rss Feed