태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


2008/07/29 15:31

[SA강좌] Part 1-17 간단한 아키텍처링 예제




주의 : 아래 글은 전적으로 개인적으로 짧은 지식과 소견으로 쓰는 글입니다. 제 전공은 경제학이나 국제금융도 아니고 외환이나 주식관련 애널리스트도 아닙니다. 따라서 아래 정보를 활용해서 발생하는 손실이나 손해에 대해서는 아무런 책임을 질 수가 없음을 밝힙니다. 그리고, 여기에 쓰는 글은 여기저기 널려있는 수많은 정보중에서 제 맘대로 발췌해서 만든내용일 가능성이 대다수입니다. 이 정보를 자신을 위해 사용할 때의 결정은 자기자신만이 할 수가 있는 것이기 때문에 이 글을 읽으실때에는 그냥 편하게 읽어주십시요.
참고로... 저는 무정부주의자도 아니고, 누구를 모함하거나 잘못된 정보를 전달하기 위해 만들어진 글도 아닙니다. 정부의 정책을 반대하는 것도 아니고, 동조하지도 않습니다. 그냥 개인적인 의견이므로 다음부터 나열되는 글을 읽기가 걱정되시면 그대로 페이지를 닫아주시기 바랍니다. 저는 미네르바 처럼 잡혀가기 싫습니다.


간단한 아키텍쳐링 예제

가장 먼저 아키텍트가 할일은 '시스템'이란 무엇인가?를 찾고 식별해야한다.


첫째. 정치활동을 충실히 하라!


정치적인 변수들 ( 고객, 사업관리 조직 등등 – 심지어 고객의 사모님의 취향~ )을 비밀문서에 잘 체크해두어야 한다.

간혹, 화면의 색만 가지고 시비거는 고객도 있다. ( 아예… 레이어를 분리해버리는 것도 방법이다.!)


정치활동을 통하여 아키텍트가 가진 컨셉을 모든 이해관계자들에게 설득하고 조율해야 한다. 당연히 엄청난 구강신공은 필수가 된다.


가장 뛰어난 아키텍트는 그 사람이 결정한 것이 아니라 그 결정 마져도 해당 관계된 사람들 사이의 회의에서 얻어진 결과물로 착각하게 만드는 것이 최선이기 때문이다.


둘째로 시스템의 구축 범위를 명확히 하라.


외부 시스템과 내부 시스템을 명쾌하게 구분해서 고객을 이해시켜야 한다. 또한, 솔루션이 할일과 외부 프로그램들이 할일에 대해서 명쾌하게 해야한다.

특히나 솔루션인 경우에 그 테스트 범위와 관련 일정등을 제대로 파악하지 못하면 프로젝트가 낭패를 당할 수도 있다.


결국, 이 내용들은 제안요청서(RFP), 비전기술서( 안만들기도 하지만 ), 프로젝트 계획서나 수행계획서가 만들어질때에 그 '단어'의 선정과 설명을 명확하게 해야한다는 점이다.


세번째로 기능과 비기능을 명확히 하라.


결국 품질부분이나 시스템의 구성형태에 대해서 전체적인 관련내용들에 대해서 고객만족을 위한 영역설정을 명확하게 하는 것이기 때문이다.


유스케이스로 표현되는 기능과 품질로 표현되는 비기능요소를 명확하게 구분해야 한다.


대표적으로 시스템이 높은 성능을 내어야 한다는 아주 모호한 부분을 실제 개량화하여 제시해야하는 것도 아키텍트의 임무중의 하나이다. 결국, 품질과 공정( 설계, 구현, 배치 )는 떨어질 수 없는 끊임없는 반복의 결과이기 때문이다.


카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 제안한 ADD(Attribute-Driven Design, 속성 주도 설계)방법이든 아니면, 각자 고안한 방식이든. 큰 그림을 그리고, 시스템을 분할하여 나아가는 것이 필요하기 때문이다.

이를, '아키텍처 패턴'이라고 부르기도 한다.

크리에이티브 커먼즈 라이선스
Creative Commons License



Trackback 0 Comment 0