Enterprise Architecture(MSDN에서)

아키텍처와 공학 2012. 9. 5. 11:18




Enterprise Architecture(MSDN)


저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

잠시 그려본 Enterprise Application Architecture(전사적 응용 아키텍처)  (0) 2009.10.30
자바/웹 그리고 프로젝트  (0) 2009.10.30
프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.  (0) 2009.10.27
메시지 기반 미들웨어  (1) 2009.10.26
ISP (Information Strategy Planning)  (0) 2009.10.26
Posted by sjokim
,

잠시 그려본 Enterprise Application Architecture(전사적 응용 아키텍처)

아키텍처와 공학 2009. 10. 30. 19:14
들어가며
엔터프라이즈 애플리케이션 아키텍처란 전사적 애플리케이션에 대한 단위시스템간의 구성과 그들의 상호 의존성 관리에 대한 정책을 수립하는 것이다.
본글은 단순히 예를 보여주기 위한 것일 뿐이다. 실제 전사적 애플리케이션 아케텍처를 설계한다면 이것과는 모습이 다를 것이며 훨씬더 상세하게 정리되어야 할것이다. 다만 본문서가 생각의 시발점이 되었으면 좋겠다. 어쨌든 모든 기업의 전산 시스템에서 한번쯤은 이런 수준의 고민이 있어야 하지 않을까? 
본글에서 말하는 컴포넌트는 단위시스템 혹은 서브시스템 정도로 이해 할 수 있을것이다.

Enterprise Application Architecture
기업 정보 시스템은 정보화의 대상의 관점에서 크게 내부 자원(직원, 자산등)관리의 문제와 사업정보(생산, 유통) 관리의 문제로 분리할 수 있다. 이러한 예는 은행의 계정계 시스템과 정보계 시스템 혹은 대학의 학사와 행정 등이 대표적인 예일 것이다.
같은 종류의 사업을 하는 기업은 사업 정보가 동일한 것이지 내부자원의 관리 방식이 동일하다는 것을 의미하는 것은 아니다 반대로 다른 종류의 사업영역을 가진 기업도 내부 자원의 관리방식이 동일 할 수 있다.
그러한 관점에서 보면 이두개의 정보(내부자원정보, 사업정보)를 모두 필요로 하는 비즈니스의 경우에 가장 변화가 심하고 재사용이 어려울 것이라는 것을 직감할 수 있다.
또한 동일한 사업영역을 가진 기업 또한 세부 사업내용은 약간씩 다를 수 있다. 따라서 개별 업무가 아닌 전체 적인 관점에서 비즈니스가 추상화 되어야 하는 경우 또한 변경이 심하게 발생할 것이다.
이러한 비즈니스의 다양성을 최대한 고려한 전사적인 아키텍쳐가 EAA이다. 



Channel
UI를 포함하는 시스템의 클라이언트이다.
Channel은 User에게 다양한 형태로 UI를 통해 서비스하면 필요한 요청을 BS(Business System)에 하게 된다.
다양한 Channel을 지원하기 위한 메커니즘이 고려되어야 한다.
다른 시스템이 접근하기위한 통로가 제공되어야 하면 Channel에서 구현하게 된다.


Business System
개별 비즈니스를 수행하는 시스템 컴포넌트이다.
BS(Business System)의 Client는 Channel이되며 BS는 Channel의 요구를 수용하기 위해 CRM(Company Resource Manager), CBM(Company Business Manager), CW(Co-worker)를 호출한다.
BS는 CRM과 CBM을 위한 선처리와 후처리를 수해해야 한다.
또한 다른 시스템을 접근하기 위해서는 CW를 통해야 한다. BS의 개별 서비스는 하나의LUW(Logical Unit of Work)가 된다.
CRM와 CBM은 상호 호출을 할 수 없기 때문에 CRM와 CBM에 걸치는 비즈니스 로직 중에서 추상화가 요구되지 않는 경우에 BS가 담당한다.따라서 어떤 경우에는 BS는 CW와 역할이 겹칠 수도 있다.


Co-worker
기업 정보 시스템 중에서 추상화된 비즈니스 프로세스를 위한 비즈니스 컴포넌트이다.
은행의 이자계산, 대학의 시수계산 등이 이에 속한다.
CW(Co-worker)의 Client는 BS(Business System)이며 CW는 데이터 서비스가 필요할 경우에 CRM(Company Resource Manager)나 CBM(Company Business Manager)를 사용한다.
또한 외부 시스템이나 Legacy System혹은 DW등과 연결하기위해 사용될 수 있다.
CW는 기업마다 차이가 많을 가능성이 높고 그 특성상 변경이 심하게 발생할 가능성이 높기 때문에 보다 높은 추상화를 요구한다. 따라서 CW가 CRM이나 CBM을 접근하는 방식과 BS가 CRM,CBM을 접근하는 방식이 다를 수 있다.
CW는 높은 추상화를 위해 Rule Base System이 도입될 수도 있다.


Company Resource Manager
기업의 내부 자원을 관리하는 Business Component이다.
인사, 급여 등이 속한다.
CRM(Company Resource Manager)의 Client는 CW(Co-worker)나 BS(Business System)이 될 수 있다.
개별 Business Component간의 Dependency전략이 수립되어야 한다.
CRM은 물리적으로 크게 Logic Part와 Data Part, 그리고 Interface, Dependency전략에 따른 Proxy들로 구성된다.


Company Business Manager
기업의 사업을 관리하는 Business Component이다.
대학의 경우 학사 업무, 은행의 경우 계정계 시스템 등이 속한다.
CBM(Company Business Manager)의 Client는 CW(Co-worker)나 BS(Business System)이 될 수 있다.
개별 Business Component간의 Dependency전략이 수립되어야 한다.
CBM은 물리적으로 크게 Logic Part와 Data Part, 그리고 Interface, Dependency전략에 따른 Proxy들로 구성된다

저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

Enterprise Architecture(MSDN에서)  (0) 2012.09.05
자바/웹 그리고 프로젝트  (0) 2009.10.30
프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.  (0) 2009.10.27
메시지 기반 미들웨어  (1) 2009.10.26
ISP (Information Strategy Planning)  (0) 2009.10.26
Posted by sjokim
,

자바/웹 그리고 프로젝트

아키텍처와 공학 2009. 10. 30. 13:49
본 글은 2000년대 초반을 기준으로 작성되었다.

※시작하며

  • 90년대 중반 자바의 등장
  • 강력한 RDB 접근 개념/라이브러리 정립 = JDBC
  • 90년대 중반 웹의 등장
  • 90년대 후반 CGI에 의한 웹의 비즈니스 프로그램 가능성 확인
  • Servlet에 의한 자바와 웹의 연결 => CGI를 밀어냄

90년대 후반
WEB+JAVA+RDB 의 환상 콤비 완성

※WEB의 특징

  • 대규모 정보 공유를 목적으로 개발됨
  • 서버와 브라우저 그리고 둘 사이를 연결하는  프로토콜
  • H/W, O/S 종속성이 없음

일반 사용자를 네트웍으로 연결

※JAVA의 특성

  • SERVLET/JDBC의 강력한 연결성
  • 객체 지향적
  • 상대적으로 쉬움(메모리,시스템 제어 않함)
  • H/W, O/S 종속성 없음

기술 중심 개발 => 업무 중심 개발

※RDB의 특성

  • 표준 쿼리 언어(SQL) 존재
  • 수학적 기반
  • 설계, 튜닝이 용의함
  • 주요  H/W에서 설치 가능(AIX,SUN,HP..)

대용량 데이터를 효과적으로 관리

※자바/웹,RDB의 특성

  • H/W 독립적
  • 대규모 사용자 수용 가능

시스템에 대한 대규모 사용자 접속 가능



※새로운 프로젝트 이슈 발생

  • 짧은 기간에 너무 많은 신기술(웹, 객체지향 등등)
    • 웹, 객체,UML,패턴,프레임웍
    • CBD, S/W아키텍쳐,수많은 오픈소스
  • 존재하지 않던 업무를 위한 시스템 개발(소핑몰, 포탈, 인터넷뱅킹 등)
    • 새로운 형태의 비즈니스를 위한 시스템은 (공정,인력 등)예측이 어려움
    • 고객 스스로도 업무를 모르는 현상 발생(요구사항 불분명)
  • 서버 성능 문제 발생
    • C/S는 PC자원을 활용하지만(데이터만 서버에 둠)
    • WEB은 서버 자원을 많이 사용함(PC는 화면만..)
  • 새로운 개발 방법론 대두
    • RUP, UML…
    • Iterative 개발 방법
  • 프로젝트 팀원들 간의 경험의 단절 발생
    • Java세대의 개발자는 대형 프로젝트 경험이 부족
    • 4GL 혹은 COBOL세대의 관리자는 객체의 특성을 모름
저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

Enterprise Architecture(MSDN에서)  (0) 2012.09.05
잠시 그려본 Enterprise Application Architecture(전사적 응용 아키텍처)  (0) 2009.10.30
프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.  (0) 2009.10.27
메시지 기반 미들웨어  (1) 2009.10.26
ISP (Information Strategy Planning)  (0) 2009.10.26
Posted by sjokim
,

프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.

아키텍처와 공학 2009. 10. 27. 15:39
엔터프라이즈 시스템의 개발 프로젝트는 고객의 요구사항으로 부터 그것을 서포트하는 실행 환경을 만들어 과저으로 정의할 수있다. 여기서 실행 환경은 단순한 바이너리 코드 뿐만 아니가 데이터베이스나 H/W처럼 바이너리가 구동할 수 있는 인프라까지를 포함한다
이중에서도 가장 많은 인원과 기간이 소요되는 것은 프로그래밍이다. 따라서 프로젝트가 성공하거나 실패하는 가장 중요한 기준 또한 프로그램 개발이 성공적이나 아니냐 일 것이다. 
나는 일견 당연한 듯한 요구사항->분석->설계->코딩의 일련의 과정들에 대한 몇가지 관점과 그로인해 생각해 보아야 하는 주제들에 대해서 의견을 말하고자 한다.

요구사항이 구동가능한 바이너리가 되기 위해서는 반복적인 Refine과 Translate을 거쳐야 한다.


  • Refine이란 내용이 상세화 되고 구체적으로 정제 된다는 것을 의미한다. 요구사항은 매우 불확실하고 가변적인 요소가 많다. 하지만 어떤 식으로든 구체적으로 결정되어야 실행코드에 반영이될 것이다. 따라서 요구사항은 실행 코드가 될때 까지 Refine되어야 한다.
  • Translate란 형태가 바뀐다는 것을 의미한다. 즉 구두나 텍스트 문서로 존재하던것이 마지막에는 프로그램 언어로 작성된 코드가 되는데 이렇게 형태가 바뀐다는 것을 말한다.
요구 사항은 실행코드에 반영될수 있는 수준으로 정제되어야 하며 프로그램 언어로 변경되어 프로그램되어야 한다.

그런데 요구사항은 너무 부정확하기 때문에 곧바로 프로그램 언어로 작성되기 어렵고 중간에 분석과 설계의 단계를 거치면서 Translate되어야 한다.

가장 일반적으로 거치는 중간 산출물이 분석 모델과 설계서이다.  

  • 요구사항은 인터뷰자료 혹은 사용중인 각종 서류등이 될 수 있으며 텍스트, 엑셀, 유스케이스 등으로 정리될 수있다.
  • 분석모델은 각종 S/W 아키텍처관점에서 개념뷰나 Logical View, 유스케이스 상세 스팩혹은 분석 다이어그램의 형태로 존재한다.
  • 설계 모델은 클래스 다이어그램 시퀀스 다이어그램 혹은 텍스트 그림 파일 등으로  이루어진다.
  • 실행코드는 프로그램 언어이다.
왜 Translate가 발생하는가? 왜 모델을 다른 형태로 작성하는가?
왜 요구사항은 텍스트나 엑셀등으로 정리하는데 분석/설계는 다른 다이어그램을 사용하는가? 어차피 프로그램 언어로 번역되어야 한다면 요구사항을 세세하게 정리하여 바로 프로그램 언어로 바꾸면되는것 아닌가?
그이유는 내용의 상세함 정도에 따라 효과적인 기술방식이 다르기 때문이다. 예를들어 텍스트로 프로그램 언어 수준의 명확하고 상세함을 정리할 수 없다.  요구사항이 정제될 수록 복잡도는 증가한다. 전체를 바라보면서도 세부적인 내용을 확인하는 것이 어렵다 따라서 이것을위한 UML과 같은 기술방식을 사용하는 것이다.

분석/설계는 과정이지 목표가 아니다
요구사항을 잘 정제하고 궁극적으로 프로그램으로 기술하기 위해 분석과 설계를 한다. 하지만 이것은 반대로 보면,요구사항이 비록 텍스트이지만 요구 내용이 명확하고 어떻게 프로그램해야 하는지  정확히 알 수 있다면 분석/설계 단계가 필요 없다는 말이 될 수 있다.
이런 현상은 동일 도메인에서 반복적인 프로젝트가 수행될때 많이 나타난다. 이전 프로젝트의 소스 코드와 기타 산출물을 기반으로 프로젝트 하는경우 고객 인터뷰 과정에서 이전과 다른 점만을 체크하고 이것을 프로그램을 하는 경우가 있다. 
또다른 상황으로 시간이 극히 부족한 경우이다. 내가 아는 모 방송사 프로젝트에서 이런 현상이 나타났는데 정부에서 먼저 발표를 한것이다. 무조건 한달만에 시스템을 오픈해야 하는 절체절명의 상황이 된것이다. 이런 경우에는 모험을 할 수밖에 없다. 분석/설계는 생략될 수밖에 없고 개발자는 고객의 요구를 텍스트로만 정리하고 바로 프로그램에 들어갔다. 그런데 불행인지 다행인지 시스템은 오픈되었고 그 시스템은 몇년이 지난 지금도  유지보수되면서 사용되고 있다.
이렇게 분석/설계가 무시되는 현상은 분석/설계는 프로젝트의 최종산출물이 아니기 때문에 나타나는 것이다. 하지만 많은 소프트웨어 공학에서 너무나 당연한듯하게 분석과 설계를 이야기 하는 것은 그만큼 요구사항을 곧바로 프로그램으로 Translate하기 어렵고 위험이 크기 때문이다. 시간을 가지고 적절한 Refine과 Translate를 단계적으로 수행해야만 그래도 안정적인 프로그램이 가능하다.

모든 산출물의 기술 방식(모델링/프로그램 언어)은 사람에 의존적이다.
모든 프로그램으로 가는 중간 산출물은 나름의 기술방식 혹은 형태는 그 시스템에 관련한 사람에 의존적이다. 이점을 간과하면 않된다. 예를 들어 코볼 개발자를 모아놓고 자바로 프로그램할 수는 없다. PHP개발자를 모아놓고 C++ 프로그램을 요구할 수는 없다. 또는 웹프로그램을 만들어야 하는데 어셈블리어로 개발할 수는 없다.(가능은 하겠지만)
이것은 당연한듯한데 이런 오류를 분석/설계 산출물을 작성할 때 범하는 경우가 많다. 순서도만 아는 사람들을에게 프로젝트에서 UML로 분석/설계하라고 요구하는 것은 잘못이다.
프로젝트 팀원과 고객담당자들이 어느정도 준비된 모델링 방법으로 요구사항을 정제되고 변환되어가야 한다.

실행 코드로 부터 설계서를 리버스 하는 것은 잘못이다.
아름다운 전원 주택을 짓고 싶었다. 그냥 통나무로 되는데로 만들었다. 그리고 나서 실물을 보면서 청사진을 그린다면 맞는 것인가? 혹시 나중에 리모델링할때 사용하려고?
설계서는 그만한 깊이로 정제되어야 한다. 그것이 프로그램 언어가 아니다. 
이런 오류는 기술 컴포넌트를 설계하는데 많이 나타난다. 예를 들어 "JDBC 컴포넌트 사용"이라고만 설계서에 기술하면 프로그래머는 어떻게 해야 하는지 안다.즉 그곳에 JDBC 클래스들간의 시퀀스다이어그램을 그릴 필요가 없는 것이다.
분석과 설계는 항상 적절한 상세 수준을 가져야 한다.

요구사항은 프로그램을 하는 순간까지 추가/수정될 수밖에 없다.
프로젝트 초기에 수집된 개략적인 요구사항이 프로그램하는 순간까지 변하지 않을 것이라고 믿는 것은 어리석은 생각이다. 반드시 추가되고 변화될 수밖에 없다. 
다만 우리는 전체모델을 흔드는 추가나 변화가 발생하지 않도록 노력할 뿐이다.
각 단계의 산출물들은 요구사항을 상세화 하는 것이고 프로그램이 가장 상세화된 요구사항의 표현이다. 따라서 이전단계에서 확인되지 않은 요구사항은 다음단계의 산출물에 포함될것이며 이과정에서 고객과 프로젝트에서 인지하지 못했던 내용이 나타날 것이다.

사람(혹은 조직)이 바뀌면 Refine이 최소화 되어야 한다.
개발 각 단계별로 Refine이 발생하는 것은 당연하다 하지만 사람이나 조직이 변경되면 이전단계 산출물에서 다음 단계의 산출물을 생성해 내는것이 쉽지 않다.
예를 들어 컨설팅 업체가 요구사항분석까지만 하고 나머지는 개발 업체가 진행하는 프로젝이 있다면 개발 업체는 컨설팅 업체로 부터 잘 정제된 요구사항을 받아야 한다.
즉 고객의 추가적인도움없이 분석산출물을 만들 수 있는수준의 요구사항 산출물을 받아야 한다.

일반적으로 요구사항으로 부터 고객의 도움을 받아 분석 산출물을 만든다 여기서 고객의 도움이 필요한 이유는 요구사항이 정제되는 과정에서 고객의 판단이 필요하기 때문이다. 하지만 업체가 바뀌는 상황에서는 가능한 정제된 요구사항이 개발업체로 전달되어야하면 그 요구사항은 추가적인 정제과정없이 분석 모델로 변경될 수 있는 수준이어야 한다.

많은 개발 프로젝트의 설계자들이 분석과 설계를 요구사항에서 프로그램으로 가는 과정으로 이해하기 보다는 분석/설계 산출물 자체의 화려함이나 정교함을 추구하는 경향이 있다 분석/설계서를 작성하면서 빈번한 COPY&PASTE가 발생한다든지 개발 코드로 부터 리버스엔지니어링을 통해서 만들어지고 있다면 뭔가 잘못되고 있다는 것을 의미한다.(필자의견)
저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

잠시 그려본 Enterprise Application Architecture(전사적 응용 아키텍처)  (0) 2009.10.30
자바/웹 그리고 프로젝트  (0) 2009.10.30
메시지 기반 미들웨어  (1) 2009.10.26
ISP (Information Strategy Planning)  (0) 2009.10.26
Feature Driven Development(FDD)  (0) 2009.10.26
Posted by sjokim
,

메시지 기반 미들웨어

아키텍처와 공학 2009. 10. 26. 23:00
Messaging & Queuing 방식
  • 비동기 처리(Asynchronous Processing)
  • 데이터 전달 보증(Assured Data Delivery)

업무 A 와 업무 B 가 통신을 할때,중간에 큐(Queue)라는 매개체를 놓고 간접 통신하는 방식이다.

메세지(데이터) 송/수신의 타겟이 큐(Queue)이며,큐(Queue)는 임시로 안전하게 데이터를 저장하는 장소이다.

큐(Queue)에 수신되는 데이터는 기본적으로 FIFO(First In First Out)방식으로 처리되나 목적에 따라 우선 순위를 적용하여 처리할 수 있다.

애플리케이션은 타켓이 되는 큐의 이름만 알고 있으면 되고,큐의 실제 위치나,네트워크 상황,수신 시스템의 상황등에 관계 없이 가동된다.

저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

자바/웹 그리고 프로젝트  (0) 2009.10.30
프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.  (0) 2009.10.27
ISP (Information Strategy Planning)  (0) 2009.10.26
Feature Driven Development(FDD)  (0) 2009.10.26
RUP Core workflows[9] 배포 웍플로우  (0) 2009.10.26
Posted by sjokim
,

ISP (Information Strategy Planning)

아키텍처와 공학 2009. 10. 26. 22:13
정보전략계획(ISP)은 대상 기업이 수립한 중장기 경영계획의 경영전략을 토대로 사업전개에 필요한 총체적인 정보체계를 제시하고 향후 단위 또는 통합 정보체계의 개발을 계획 및 통제함으로써 경영요구에 의한 정보기술체계를 구축하는 것이다.

1.계획단계 준비
정보전략계획 과정을 효율적으로 진행하기 위해 프로젝트 팀을 구성, 프로젝트 계획수립 
2.기업 환경 분석
기업내부의 경영환경과 기업외부 경쟁환경을 분석
3.정보기술 분석
기업이 현재 보유한 기술환경 현황을 파악하며 현 정보관리 조직을 분석하고, 최근 정보기술에 대한 추세를 조사
4.현 업무 분석
내부환경분석 결과를 토대로 각 조직별 현 업무를 조사
5.기업모형 개선
업무기능에 대한 가치, 중요도, 실행수준을 평가 하고, 프로젝트 기간을 고려하여 개선이 필요한 업무기능을 선정.
6.정보시스템 구조설계
정보기술 방향과 개선 기업모형을 토대로 정보 시스템의 전략방향을 수립하고 현 기업모형과 개선 기업모형을 통합하여 업무 아키텍쳐를 작성.
7.정보시스템 구축계획수립
정보시스템의 목표와 추진방향을 수립하고 분석 영역에 대한 시스템별 우선순위를 검토하여 프로젝트 범위를 확정.
8.정보전략계획의 평가
정보전략계획 수립단계에서 작성한 산출물에 대한 품질과 계획된 진도를 점검하여 프로젝트의 성공적인 완수를 지원.

저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

프로그램 개발은 요구사항에서 실행코드를 만들어 가는 과정이다.  (0) 2009.10.27
메시지 기반 미들웨어  (1) 2009.10.26
Feature Driven Development(FDD)  (0) 2009.10.26
RUP Core workflows[9] 배포 웍플로우  (0) 2009.10.26
RUP Core workflows[8] 환경 웍플로우  (0) 2009.10.26
Posted by sjokim
,

Feature Driven Development(FDD)

아키텍처와 공학 2009. 10. 26. 21:59

#1 Develop an Overall Model
A initial project-wide activity with domain and development members under the guidance of an experienced object modeler in the role of Chief Architect.
A high-level walkthrough of the scope of the system and its context is performed. Detailed domain walkthroughs are then held for each area to be modeled. After each domain walkthrough, small teams are formed with a mix of domain and development staff who then compose their own models in support of that domain walk-through. The teams each present their models for peer review and discussion. One of the proposed models, or a merge of the models, is selected by consensus thus becoming the model for that domain area. A merge of the domain area model into an overall model is performed, adjusting model shape as required.The object model is then iteratively updated with content by the Design by Feature process #4.
#2 Build a Features List
An initial project-wide activity to identify all the features to support the requirements.
A team usually comprising just the Chief Programmers from process #1 is formed to functionally decompose the domain into Subject Areas, the business Activities within them and the Steps within each business Activity, thus forming the categorized features list. The top-level categorization for the features list comes from the partitioning of the domain by the domain experts in process #1.
#3 Plan By Feature
An initial project-wide activity to produce the development plan.
The project manager, development manager and the chief programmers plan the order that the features are to be implemented, based on feature dependencies, load across the development team and also on the complexity of the features to be implemented. The main tasks in this process are not a strict sequence. Like many planning activities they are considered together, with refinements made from one or more tasks and then considering the others again. A typical scenario is to consider the development sequence, then consider the assignment of business activities to chief programmers and in doing so, consider which of the key classes (only) are assigned to which developers (remember a chief programmer is also a developer). When this balance is achieved and the development sequence and assignment of business activities to chief programmers is essentially completed, then the class ownership is completed (beyond the key classes that were already considered for ownership).
#4 Design By Feature
A per-feature activity to produce the feature design package.
A number of features are scheduled for development by assigning them to a Chief Programmer. The Chief Programmer selects features for development from his "inbox" of assigned features. He may choose multiple features that happen to use the same classes (hence developers). Operationally, it is often the case that "sets" of features are scheduled for development at a time by the Chief Programmer. Such a set is called a Chief Programmer Work Package.The Chief Programmer then forms a Feature Team by identifying the owners of the classes (developers) likely to be involved in the development of the feature(s) he selects for development. This team then produces the Sequence Diagram(s) for the assigned feature(s). The Chief Programmer then refines the Object Model based on the content of the sequence diagram(s). The developers then write class and method prologues. A Design Inspection is held.
#5 Build By Feature
A per-feature activity to produce a completed client-valued function (feature).
Starting with the design package, the development class owners implement the items necessary for their class to support the design for this feature. The code developed is then unit tested and code inspected ? the order of which is determined by the Chief Programmer. After a successful code inspection, the code is promoted to the Build. 

Six Key Project Roles( FDD )


The Chief Architect(CA) is responsible for the overall design of the system.
The Chief Architect (CA) is responsible for the overall design of the system. Although the Chief Architect has the last say in FDD, he or she is responsible for running workshop design sessions where the team collaborates in the design of the system. This is a deeply technical role, requiring excellent technical and modeling skills, as well as good facilitation skills.
The  Chief Architect resolves disputes over design that the Chief Programmers cannot resolve themselves. For projects with both a complex problem domain and complicated technical architecture, the role may be split into domain architect and technical architect roles. The Chief Architect has the last say on all design issues. He or she steers the project through the technical obstacles confronting the project.

저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

메시지 기반 미들웨어  (1) 2009.10.26
ISP (Information Strategy Planning)  (0) 2009.10.26
RUP Core workflows[9] 배포 웍플로우  (0) 2009.10.26
RUP Core workflows[8] 환경 웍플로우  (0) 2009.10.26
RUP Core workflows[7] 형상 및 변경 관리 웍플로우  (0) 2009.10.26
Posted by sjokim
,

RUP Core workflows[9] 배포 웍플로우

아키텍처와 공학 2009. 10. 26. 16:59
가) 목적
   배포 웍플로우의 목표는 제품을 최종사용자에게 전달하는 것이다. 배포 웍플로우는 다음과 같은 다양한 범위에 걸친 액티비티를 포함한다.
  • 소프트웨어의 완성된 외부용 릴리즈를 생산 및 조립
  • 소프트웨어의 포장
  • 소프트웨어의 유통
  • 소프트웨어의 설치
  • 사용자와 또는 영업사원의 교육
  • 사용자 지원
  • 베타 테스트의 계획과 수행
  • 기존의 소프트웨어 혹은 데이터의 마이그레이션
  • 공식적인 인수(Formal Acceptance)
    배포는 도메인과 비즈니스에 대단히 밀접하게 관련되어 있다. 따라서 알맞은 배포 웍플로우를 구성하기 위해서는 Rational Unified Process를 커스터마이즈하는 것이 필요하다.

나) 작업자와 산출물
               
배포 웍플로우의 작업자와 산출물의 관계

   배포 웍플로우에 관련된 작업자는 다음과 같다.
  • 배포 관리자(Deployment Manager) : 배포를 계획하고 조직화한다.
  • 구현 담당자(Implementer) : 릴리즈할 소프트웨어를 생성한다.
  • Technical writer : 사용자 매뉴얼, 설치 지침서 등을 작성한다.
  • 교육 개발자(Course Developer) : 교육 자료를 작성한다.
   배포 웍플로우의 주요 산출물은 다음과 같다.
  • 배포 계획(Deployment Plan)
  • 사용자 매뉴얼
  • 교육 자료 : 슬라이드, 온라인 튜토리얼, 컴퓨터를 이용한 교육(CBT : Computer-Based Training)을 위한 자료

다) 웍플로우
   배포 웍플로우에서 일어나는 일반적인 액티비티에는 다음과 같은 것들이 있다.
  • 소프트웨어의 생산 : 소프트웨어의 완제품에는 다음과 같은 산출물들이 포함되어 있어야 한다.
    • 테스트 완료된 제품
    • 설치 프로그램
    • 사용자를 위한 문서
    • Configuration Data
    • 데이터 변환과 같은 마이그레이션 작업을 위한 별도 프로그램
  • 소프트웨어의 포장
  • 소프트웨어의 유통 : 상자에 포장해서 유통하는 것으로부터 인터넷을 통한 유통 등 다양한 형태를 취할 수 있다.
  • 소프트웨어의 설치
  • 마이그레이션(migration) : 마이그레이션은 다음과 같은 작업을 포함할 수 있다. 경우에 따라서는 마이그레이션을 위한 별도의 프로그램을 개발할 필요가 있다. 물론 이때에도 주 제품을 개발할 때와 같은 프로세스를 사용할 수 있다.
    • 기존의 시스템을 신 시스템으로 대체
    • 기존의 데이터를 새로운 형식으로 변환
  • 사용자 지원(Providing Assistance to the Users) : 사용자 지원은 다음과 같이 다양한 방법으로 이루어질 수 있다.
    • 공식적인 교육
    • 컴퓨터를 이용한 교육(Computer-Based Training)
    • 온라인 지원
    • 전화를 통한 지원
    • 인터넷을 통한 지원
    • - 부수적인 자료 : 팁, 어플리케이션 노트, 예제, 마법사…
라) 요약
  • 배포 웍플로우는 최종 사용자와 마케팅, 유통, 영업을 담당하는 지원 조직에 전달될 모든 산출물을 다룬다.
  • 배포 웍플로우는 개발된 제품과 해당 비즈니스의 유형에 크게 의존한다. 따라서 Rational Unified Process를 채택한 조직에서는 반드시 배포 웍플로우를 커스터마이즈해야 한다.
본 글의 모든 저작권은 Rational에 있습니다.
저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

ISP (Information Strategy Planning)  (0) 2009.10.26
Feature Driven Development(FDD)  (0) 2009.10.26
RUP Core workflows[8] 환경 웍플로우  (0) 2009.10.26
RUP Core workflows[7] 형상 및 변경 관리 웍플로우  (0) 2009.10.26
RUP Core workflows[6] 테스트 웍플로우  (0) 2009.10.26
Posted by sjokim
,

RUP Core workflows[8] 환경 웍플로우

아키텍처와 공학 2009. 10. 26. 16:55
가) 목적
   환경 웍플로우의 목표는 프로세스와 도구를 통해 개발조직을 지원하는 것이다. 환경 웍플로우에서의 지원 내역은 다음과 같다.
  • 도구 선정과 획득
  • Toolsmithing : 도구를 조직에 맞게 커스터마이즈하고 필요에 따라 추가로 도구를 개발하는 것을 말한다.
  • 프로세스 구성(Process Configuration)
  • 프로세스 개선(Process Improvement)
  • 교육(Training)
  • 프로세스를 지원하기 위한 기술 서비스 : IT(Information Technology) 하부구조, 사용자 계정 관리, 백업…

나) 작업자와 산출물

환경 웍플로우의 작업자와 산출물의 관계

    환경 웍플로우의 주 작업자는 프로세스 엔지니어(Process Engineer)이다. 프로세스 엔지니어는 소프트웨어 개발 프로세스에 대한 책임을 지는 작업자를 말한다. 프로세스 엔지니어는 프로젝트 시작 전에 개발 프로세스를 구성하고 프로젝트 기간동안 프로세스를 계속해서 개선한다.

   환경 웍플로우의 주 산출물은 개발 케이스(development case)이며 이는 개별적인 프로젝트를 위해 알맞게 고쳐진 프로세스를 말한다.

   환경 웍플로우에서 프로세스 엔지니어는 프로세스의 지침(guideline)을 만들기 위해 다음과 같은 작업자의 도움을 필요로 한다.
  • 비즈니스 모델 분석가(Business Model Analyst) : 비즈니스 모델링 지침
  • 시스템 분석가(System Analyst) : 유스 케이스 모델링 지침
  • 사용자 인터페이스 설계자(User-Interface Designer) : 사용자 인터페이스 지침
  • 아키텍트(Architect) : 설계 지침
  • Technical writer : 사용자 매뉴얼 양식 지침
   또한 다음과 같은 작업자가 도구 환경(tool environment)을 설정하는 데 참여한다.
  • Toolsmith : 단조롭고 오류 발생의 소지가 높은 작업을 자동화하기 위해, 특별한 요구사항을 해결하기 위해, 또는 도구들간의 통합을 지원하기 위해 필요한 도구를 개발한다.
  • 시스템 관리자(System Administrator) : 하드웨어와 소프트웨어 개발 환경을 유지하며 사용자 계정 관리, 백업과 같은 시스템 관리 업무를 수행한다.
   환경 웍플로우의 주요 산출물은 소프트웨어 개발 환경(software development environment)이며 이는 하드웨어, 소프트웨어, 네트웍 자원, 소프트웨어 도구, 개발과 테스트 액티비티를 위한 소프트웨어 지원으로 구성되어 있다.

다) 웍플로우
   환경 웍플로우는 일반적으로 다음과 같은 액티비티로 구성된다.
  • 프로세스의 구성(Configuring the Process)
  • 프로세스의 구현
  • 도구의 선정과 획득
    • 모델링을 위한 도구
    • 요구분석을 위한 도구
    • 코드 개발을 위한 도구(편집기, 컴파일러, 디버거)
    • 형상관리와 변경요구 관리를 위한 도구
    • 테스팅을 위한 도구
    • 계획(planning)과 추적(tracking)을 위한 도구
    • 문서화 준비를 위한 도구
  • Toolsmithing
  • 개발 지원
  • 교육(Training)

라) 요약
  • 환경 웍플로우의 목적은 도구, 프로세스, 방법론(method)의 측면에서 개발조직에게 적절한 지원을 하는 것이다.
  • Rational Unified Process에서 많은 액티비티와 단계들은 래쇼날사의 여러 개발 도구 사용을 통해 자동화된다. 따라서 소프트웨어 개발과정에서 오류가 발생하기 쉽고, 인적 자원을 많이 요구하는 단조로운 작업 대부분을 피할 수 있게 해 준다.
본 글의 모든 저작권은 Rational에 있습니다.
저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

Feature Driven Development(FDD)  (0) 2009.10.26
RUP Core workflows[9] 배포 웍플로우  (0) 2009.10.26
RUP Core workflows[7] 형상 및 변경 관리 웍플로우  (0) 2009.10.26
RUP Core workflows[6] 테스트 웍플로우  (0) 2009.10.26
RUP Core workflows[5] 구현 웍플로우  (0) 2009.10.26
Posted by sjokim
,

RUP Core workflows[7] 형상 및 변경 관리 웍플로우

아키텍처와 공학 2009. 10. 26. 16:50
가) 목적
   형상 및 변경 관리 웍플로우의 목적은 프로젝트 진행과정에서 변화하는 프로젝트 자산의 무결성을 추적 유지하는 것이다. 개발주기 동안에 많은 가치 있는 산출물들이 생성된다. 이러한 산출물을 생성하는 데에는 많은 노력이 투입되고 따라서 가치 있는 투자 대상으로 생각할 수 있다. 그렇기 때문에 이러한 산출물은 보호되어야 하며 쉽게 재사용될 수 있어야 한다. 또한 이러한 산출물은 반복적인 개발과정에서 계속해서 발전되고 계속해서 업그레이드된다. 산출물을 담당하는 작업자가 있지만 사람의 기억에 의존하여 이러한 소중한 자산을 관리하는 것은 위험한 일이다.

   프로젝트 팀원은 산출물을 식별하고 접근할 수 있어야 한다. 이를 통해 알맞은 버전의 산출물을 선택할 수 있고, 산출물의 현재상태와 변경 사유를 설명한 변경이력을 볼 수 있으며, 현재 누가 산출물에 대한 책임을 지고 있는가를 파악할 수 있다. 동시에 프로젝트 팀은 제품의 발전과정을 추적하고, 다양한 곳으로부터 발생하는 변경요구를 수집하여 관리하고, 일관성 있게 산출물에 변경요구를 구현할 수 있어야 한다. 또한, 프로젝트 관리 웍플로우를 지원하기 위해 중요한 프로젝트 산출물에 대한 상태정보를 제공해야 하고 주요 산출물의 변경에 관련된 평가기준을 수집해야 한다.

나) 작업자와 산출물
   형상 및 변경 관리 웍플로우의 주요 작업자는 다음과 같다.
  • 프로젝트 관리자(Project Manager) : 전체 소프트웨어 개발 계획(SDP)의 한 요소인 형상 관리 계획에 대한 책임이 있다.
  • 형상 관리자(Configuration Manager) : 개발과 통합을 위한 작업공간(Workspace)을 정의하고 할당하는 것을 포함한 형상관리 시스템 구축에 대한 책임을 진다(형상 관리 시스템을 구축할 때에는 개발하는 시스템의 구조를 적절히 반영해야 한다.). 또한 형상 관리자는 프로젝트 관리자를 위해 상태 및 평가 보고서를 작성한다..
다음과 같은 작업자도 형상 및 변경 관리 웍플로우에 관련되어 있다.
  • 구현 담당자(Implementer) : 자신이 맡은 변경 사항을 구현하기 위해 필요한 산출물과 작업공간을 이용한다.
  • 통합 담당자(Integrator) : 통합 작업공간에서 변경 사항을 수용하여 제품을 빌드한다.
  • 임의의 작업자(any worker) : 변경 요구를 제출할 수 있다.
  • 아키텍트 : 구현 관점(Implementation View)을 통해 개발하는 시스템의 구조에 대한 정보를 제공한다.

   변경 제어 위원회(Change Control Board:CCB)는 프로젝트 관리자, 아키텍트, 형상 관리자, 고객 대표, 마켓팅 담당자 등과 같은 기술 및 관리적으로 관심을 갖는 다양한 인원으로 구성된 그룹이다. CCB의 역할에는 변경의 영향 평가, 우선순위 결정, 변경 승인 등이 있다.

   형상 및 변경 관리의 주요 산출물에는 다음과 같은 것이 있다. 
  • 형상관리 계획(Configuration Management Plan : CM Plan) : 형상관리 계획은 버전 관리, 작업공간 관리, 변경요구 관리, 빌드, 릴리즈와 같은 프로젝트의 형상관리 작업에 사용할 정책 및 실무를 기술한다.
  • 변경 요구(Change Requests) : 변경 요구는 문서상의 결함, 요구사항의 변경, 소프트웨어의 버그 등 매우 다양한 형태를 갖는다. 모든 변경 요구에는 제출자와 원인에 대한 정보가 포함된다. 추후의 영향 분석(Impact Analysis)은 연관된 산출물, 비용, 스케쥴 등의 관점으로 변경의 영향을 첨부한다. 변경 요구는 작업이 진행됨에 따라 상태가 변경된다. 이력 정보(특히 변경제어 위원회(CCB)의 결정사항)는 변경 요구에 첨부되어 관리된다.

   또한 다음과 같은 산출물도 형상 및 변경 관리 웍플로우에 포함된다.
  • 구현 모델(Implementation Model) : 형상관리자가 형상관리 환경을 구축하기 위해 필요한 개발하는 제품에 대한 정보를 제공한다.
  • 평가기준 및 상태 보고서(Metrics and Status Reports) : 상태 평가 보고서는 CM과 CRM 지원 환경으로부터 정보를 추출하여 작성한다.
   다음 그림은 형상 및 변경 관리 웍플로우에서 작업자와 산출물의 관계를 보여준다.


다) 웍플로우
   형상 및 변경 관리에는 두개의 서로 밀접한 관계를 갖는 웍플로우가 있다. 하나는 형상관리 측면의 웍플로우이고 다른 하나는 변경 요구 관점의 웍플로우이다. 형상 관리 측면에서의 웍플로우는 다음과 같다.
  1. 프로젝트 관리자는 프로젝트에 사용될 구체적인 CM 실무를 정립하여 CM 계획을 작성한다.
  2. 소프트웨어 아키텍처 문서(구현 관점 : Implementation View)의 정보에 기반하여 형상 관리자는 제품 구조를 확립하고, 개발자와 통합자에게 필요한 다양한 작업공간을 생성하여 할당한다.
  3. 작업자는 자신의 작업 공간에 접근하여 산출물을 수정한다. 특히, 자신에게 할당된 변경 요구를 구현한다.
  4. 통합자는 통합 작업공간에서 변경을 수용하여 제품을 빌드한다. 빌드한 제품은 테스트 대상이 된다.
  5. 새로운 기준버전(baseline)이 반복의 끝에서 생성된다.
              형상관리 측면에서 바라본 형상 및 변경 관리 웍플로우

   변경 요구의 관점에서 본 웍플로우는 약간 달라진다.
  1. 변경 요구 입력
  2. 변경 요구가 산출물, 비용, 스케쥴에 미치는 영향을 분석한다.
  3. 변경제어 위원회(CCB)는 영향 분석, 변경된 우선순위를 검토하여 변경요구를 승인한다.
  4. 변경 요구를 구현을 위해 작업자에 할당한다.
  5. 변경 사항을 새로운 빌드에 통합하여 테스트한다.
  6. 변경 요구가 종료

라) 도구 지원
   모든 변경을 관리하는 것은 대단히 어렵다. 변경 요구를 정확히 관리하는 것의 어려움은 시간이 지날수록, 팀의 크기가 커질수록, 제품의 크기(즉, 산출물의 수)가 커질수록, 팀이 지리적으로 분산되어 있을수록, 일정이 촉박할수록 기하급수적으로 커진다. 이처럼 변경요구 관리는 오류가 발생하기 쉽고, 많은 인적자원이 소모되는 작업이므로 도구의 지원을 통한 자동화로서 많은 이익을 얻을 수 있다. 래쇼날은 형상 및 변경 관리 웍플로우를 다음의 도구를 통해 지원한다. 

  • ClearCase는 형상 관리를 지원한다.
  • ClearQuest는 변경 요구 관리와 프로젝트의 상태 평가를 지원한다.

마) 요약
  • 형상 및 변경 관리 웍플로우의 목적은 변경요구를 처리하면서 발전(evolve)하는 과정에서 프로젝트 산출물의 무결성을 유지하는 것이다.
  • 형상관리는 제품의 구조, 구성요소의 식별, 구성요소의 유효한 형상, 그리고 작업공간을 다룬다.
  • 변경요구 관리는 일관성 있게 산출물을 변경하는 프로세스를 포함한다.
  • 상태와 상태 평가에 도움이 되는 평가기준(metrics)은 형상과 변경 관리 정보로부터 추출할 수 있다.
  • ClearCase와 ClearQuest같은 도구는 형상 및 변경 관리 웍플로우의 단조로운 작업 대부분을 자동화한다.
본 글의 모든 저작권은 Rational에 있습니다.
저작자표시 비영리 변경금지

'아키텍처와 공학' 카테고리의 다른 글

RUP Core workflows[9] 배포 웍플로우  (0) 2009.10.26
RUP Core workflows[8] 환경 웍플로우  (0) 2009.10.26
RUP Core workflows[6] 테스트 웍플로우  (0) 2009.10.26
RUP Core workflows[5] 구현 웍플로우  (0) 2009.10.26
RUP Core workflows[4] 분석 & 설계 웍플로우  (0) 2009.10.26
Posted by sjokim
,

티스토리툴바