IT
posted by 구름너머 2007. 12. 11. 00:04
[전사아키텍처 이해] 전사아키텍처 참조 모델 IT

2007/12/11 00:01

http://blog.naver.com/damool2/40045231044

출처 블로그 > 내 곁의 행복
원본 http://blog.naver.com/swmoon3/21393178

강좌 개략 정보

강좌차수 대주제중주제소주제
3차전사아키텍처 이해전사아키텍처 개요전사아키텍처 참조 모델

강좌 본문

1. 참조 모델 정의

가. 참조 모델 개념

참조 모델(Reference Model)은 아키텍처 구성요소를 식별하여 표준화한 것으로 기관이나 기업의 전사아키텍처 수립시 참조하는 추상화된 모델이다. 참조 모델은 다양한 관점을 충족시킬 수 있도록 시스템에 대한 개념적인 모델을 추상화하고, 구성요소를 재사용 가능한 방식으로 생성하여, 여러 기업들이 사용할 수 있도록 한 것이다.

전사아키텍처에서는 비슷한 특성이 존재하는 산업군마다 정의된 참조 모델을 활용하도록 추천하는데, 각 기업은 동종의 참조 모델을 참조하여 고유의 아키텍처를 구성할 수 있다. 이러한 참조 모델 중 잘 알려진 것은 국방, 공공 참조 모델이다.

아키텍처별 참조 모델에는 업무 참조 모델(BRM, Reference Model), 데이터 참조 모델(DRM, Data Reference Model), 서비스 참조 모델(SRM, Service Reference Model), 기술 참조 모델(TRM, Technical Reference Model), 성과 참조 모델(PRM, Performance Reference Model) 등이 있다.

나. 참조 모델 현황

정부는 [그림 1-1-9]와 같이 전사아키텍처 참조 모델로 업무 참조 모델, 서비스 참조 모델, 기술 참조 모델, 데이터 참조 모델, 성과 참조 모델 등 5가지 참조 모델 정의를 추진하고 있다. 2005년 10월 기준으로, 기술 참조 모델(TRM)과 서비스 컴포넌트 참조 모델(SRM)은 한국전산원이, 업무 참조 모델은 행정자치부가 각각 개발하여 발표한 상태이다. 또한 성과 참조 모델과 데이터 참조 모델은 한국전산원이 개발 중에 있다. 성과 참조 모델과 데이터 참조 모델의 개발이 완료되면 범정부 전사아키텍처 참조 모델은 그 골격을 모두 갖추게 된다. 범정부 전사아키텍처 추진의 특징은 일반 기업의 전사아키텍처 프로젝트와 달리 범정부의 정보화 사업을 체계적으로 추진할 수 있는 참조 모델과 지침을 만들어서 보급하는 데 역점을 두고 있다는 것이다.



범정부 참조 모델의 구조는 업무와 정보기술의 통합 가능성을 파악하고, 중복 개발을 방지할 수 있도록 전자정부 사업 투자의 효율을 고려하여 설계하였다. 또한 공동 자원 인프라의 활용성 증대를 위해 전자정부 자원 관리의 최적화 및 공유 가능한 행정정보의 발견, 상호운용성 향상을 위한 표준화 등을 고려하여 설계하였다. 각 기관은 별도의 기관별 참조 모델이 아닌 범정부 참조 모델을 참조하여 아키텍처 정보를 구축할 수 있다. 이러한 참조 모델을 활용함으로써 기관들은 중복 투자를 방지하고 단절요소를 해소하며, 상호 협력 및 통합의 기회를 발견할 수 있게 된다.

미국의 경우 예산 관리국은 2002년부터 정부기관 간의 업무 프로세스를 단순화하고 통합하기 위해 연방정부의 아키텍처 정보화(FEA, Federal Enterprise Architecture) 개발을 시작했고, 아키텍처 영역별로 참조 모델을 정의했다. 여기서도 역시 성과 참조 모델, 업무 참조 모델, 데이터 참조 모델, 서비스 요소 참조 모델, 기술 참조 모델 등을 정의하였다.

참조 모델 중 가장 잘 활용되고 있는 것이 기술 참조 모델이라고 할 수 있는데, [표 1-1-3]은 대표적인 기술 참조 모델을 비교하였다.



기술 참조 모델의 선진 사례는 기본적인 분류의 기준만을 제공한다. 선진 사례가 어떤 것은 너무 범용적이고, 어떤 것은 정부, 국방 등 특정 영역에 의존적이기 때문에 자사 혹은 해당 산업의 기술적 특성을 반영하지 못할 수 있다는 것을 고려해야 한다.

다. 참조 모델 구축 방법

참조 모델은 두 가지 방법으로 구축된다. 하나는 공통적인 특성을 추출하여 그 산업군에 맞게 범용적으로 만드는 것이고, 또 하나는 복잡하고 대표적인 기업을 선정하여 그 기업의 아키텍처를 표본으로 삼아 비슷한 타 기업에서 재활용하게 만드는 것이다. 먼저 공통적인 특징을 추출하여 만들어진 참조 모델은 요소간 경계가 불명확하고 하위 수준의 정의가 명확하지 않은데 비하여, 이해하기 쉽고 많은 산출물이 필요하지 않은 장점이 있다. 대표적인 기업의 아키텍처를 재활용하는 방향은 각 산출물의 관계가 정확하고 하위 수준까지 참조할 수 있다는 장점이 있는 반면 기업의 보안상 대부분 공개가 되지 않는다는 단점이 존재한다.

2. 참조 모델 사례

참조 모델에 대한 이해를 높이기 위해 범정부의 업무 참조 모델, 서비스 참조 모델, 기술 참조 모델, 데이터 참조 모델을 소개한다. 성과 참조 모델은 소개를 생략한다.

가. 업무 참조 모델

업무 참조 모델은 특정 기관에 독립적으로 업무의 기능을 중심으로 정의한 참조 모델이다. 업무 참조 모델은 조직과 무관한 기능 위주의 접근이며, 다른 아키텍처를 정의하는 기준으로 활용될 수 있다.

업무 참조 모델은 몇 개의 업무 영역으로 구분된다. 각 업무 영역은 여러 개의 업무 단위로 구분되고, 각 업무 단위는 세부 업무로 구성된다. 업무 참조 모델에 정의된 업무 단위는 특정 기관에 의해 수행되는 것이라고 보다는 기관이 어떤 목적으로 어떤 내용의 일을 수행하든 그 업무는 여기에 정의된 업무단위로 묘사될 수 있다. 이는 업무 분석을 위한 공통 기준으로 활용할 수 있다. 서로 다른 기관들이 유사한 업무를 수행하고 있는 지를 파악할 수 있어 유사 업무를 지원하는 시스템을 개발할 경우 기관이 공동으로 활용할 수 있다. 업무 참조 모델은 다른 기관이 수행하는 프로젝트 중에서 비슷한 내용을 검색하여 그 내용을 참고할 수 있다.

정부의 업무 참조 모델은 정책 분야, 정책 영역, 대기능, 중기능, 소기능 등으로 분류하고 있는데, 일반 기업의 업무 참조 모델은 흔히 사업 영역, 업무 영역, 업무기능 등으로 분류하고 있다.

나. 서비스 참조 모델

서비스 참조 모델은 업무 수행과 목표 달성을 지원하는 서비스 요소를 분류하기 위한 기능 중심의 평가 지향적 참조 모델이다. 기관들은 이를 통해 범정부 차원의 업무 및 응용 서비스 요소를 발견할 수 있다. 서비스 참조 모델은 업무기능과는 별개로 서비스 영역 관점에서 시스템을 구조화된 것으로 애플리케이션, 애플리케이션의 서비스, 소프트웨어 컴포넌트의 재사용을 촉진하기 위한 수단으로 활용된다.

서비스 요소 참조 모델은 여러 개의 서비스 영역으로 구분되며, 각 서비스 영역은 여러 개의 서비스 유형으로 구성되며, 서비스 유형은 서비스 컴포넌트로 분류된다.

다. 기술 참조 모델

기술 참조 모델은 업무와 서비스 구성요소의 전달과 교환, 구축을 지원해주는 표준, 명세, 기술요소를 기술하기 위한 것이다. 기술 참조 모델은 몇 개의 핵심 서비스 영역으로 구성된다. 핵심 서비스 영역은 다시 하위 수준의 서비스 범주나 기술 표준으로 구성된다. 기술 참조 모델은 서비스컴포넌트와 연관을 가지며, 정보시스템 간 상호운용성 증대를 위한 기술표준을 강조한 구조를 갖고 있다.

기술 참조 모델은 그 특성상 다양한 산업군 및 기업에 바로 적용할 수 있기 때문에 구축하기 용이하고 기대효과가 커서 가장 먼저 적용 가능한 영역이다. 기술 참조 모델의 수립은 시스템 구축시 사용할 기술에 대한 표준 프로파일을 분류하는데 활용 가능하다. 시스템 관리시 정보 자산을 분류하는데 활용 가능하고, 시스템 통합시 정보시스템 간의 유사성을 판단하는 기준 항목으로 활용 가능하다.

라. 데이터 참조 모델

데이터 참조 모델은 기관 간의 공통 정보의 파악과 활용을 지원하기 위한 모델이다. 기관 간의 정보 공유를 위해 데이터 참조 모델은 데이터 개괄 모델, 데이터 분류, 데이터 구조, 데이터 교환, 데이터 관리 기준 등의 영역으로 구성된다.

데이터 개괄 모델은 범 기관 업무에서 관리하는 데이터를 분류하고 데이터 영역 간의 관계를 도식화하며, 데이터 분류는 관리 범위내의 모든 데이터를 분류하고 데이터 구조의 요소와 매핑하며, 매핑된 정보를 이용한 다양한 검색기능을 제공한다. 데이터 구조 관리는 범위내의 모든 데이터 요소와 요소 소유주, 표준화 항목 정의 요소간 관계 및 정보를 저장한다. 데이터 교환은 기관 간 데이터 요소 교환을 위한 사전 정의 대상, 교환 구조, 메시지 방식 정의, 교환 내역 관리 등을 포함한다. 데이터관리 기준은 데이터 품질, 표준화, 보안 등의 유지를 위한 데이터 관리 정책 및 규칙, 프로세스, 조직 구조를 정의한다.

정부의 데이터 참조 모델의 데이터 분류체계는 데이터 영역(Data Area), 주제 영역(Data Class), 엔티티 등으로 분류한다. 일반 기업의 데이터 참조 모델도 데이터 영역, 주제 영역(Subject Area), 엔티티 등으로 나뉜다.

3. 참조 모델 활용

참조 모델은 다양한 용도로 활용될 수 있으며, 용도에 따라 효과도 달라진다. 참조 모델은 정부기관과 같이 중앙부처가 산하기관에 참조 모델을 적용하거나, 기업군의 성격을 가지는 기업의 지주회사나 계열사가 하위 기업에 적용하는 것을 제외하고는 일반 기업이 참조 모델을 업무에 적용하는 것은 아직 일반화 되어 있지 않다.

그러나 기술 참조 모델의 경우, 기업 전체의 기술 환경을 이해하는 논리적인 틀로 받아들여 기술아키텍처의 현황 진단과 목표 아키텍처를 정의하는 작업의 분류 체계로 잘 활용되고 있다. 참조 모델별로 활용 방안과 기대효과는 [표 1-1-4]와 같다.

기업의 데이터아키텍처 담당자는 데이터아키텍처를 정의할 때 전사아키텍처와의 통합성과 연계성을 고려는 물론 상위 기관 또는 산업별 데이터 참조 모델을 참조해야만 정보의 상호운용성과 교환을 촉진할 수 있고, 데이터 중복을 배제 및 재사용을 증대시키는 등의 데이터아키텍처 구축의 진정한 효과를 얻을 수 있다.

'IT' 카테고리의 다른 글

RDF(Resource Description Framework)  (0) 2008.01.09
ea 그림정리  (0) 2007.12.11
EA 개념의 발전  (0) 2007.12.05
행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침  (0) 2007.12.05
공공부문 ITA 표준  (0) 2007.12.05
IT
posted by 구름너머 2007. 12. 5. 01:37

EA 개념의 발전


일부에서는 EAITA(Information Technology Architecture; 정보기술아키텍처)

라 부르기도 한다.

이는 1996년 미국에서 정의한 정보기술관리혁신법에서 Information Technology

Architecture라는 용어를 사용했고, 이어서 발표된 OMB A-130 회람에서 ITA는 EA,

기술 참조 모델(TechnicalReference Model), 그리고 표준 프로파일(Standard Profile)로

구성된다고 규정한데서 기인한 것이다. 이에 따르면 광의의 개념인 EA가 협의의 개념인

정보기술 아키텍처의 일부분이 되어버리는 모순이 발생한다.
이에 2000년 OMB A-130 회람을 개정하면서 아키텍처 노력을 Enterprise Architecture라

명명하고, 이는

업무 프로세스(Business Processes),

정보 흐름 및 관계(Information Flow and Relationships),

애플리케이션(Applications),

데이터 명세 및 관계(Data Descriptions and Relationships), 그리고

기술 하부구조(Technology Infrastructure)로 구성된다고 정의함으로써

용어상의 혼란을 해소하였다.

이후 실무적 차원에서 구성요소에 대한 내용이 정리되어

이제는 다섯 가지 요소를 네 가지 영역, 즉

BA:비즈니스 아키텍처(위의 업무 프로세스와 정보 흐름 및 관계가 여기에 해당됨),

AA:애플리케이션 아키텍처,
DA:데이터 아키텍처(위의 데이터 명세 및 관계가 여기에 해당됨),

TA:기술 아키텍처로 구분하고 있다.

EA===> BA+AA+DA+TA

'IT' 카테고리의 다른 글

ea 그림정리  (0) 2007.12.11
전사아키텍처 참조 모델  (0) 2007.12.11
행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침  (0) 2007.12.05
공공부문 ITA 표준  (0) 2007.12.05
ITA/EA  (0) 2007.12.04
IT
posted by 구름너머 2007. 12. 5. 01:12

아키텍쳐가 5개

참조모형이 5개...

행정자치부 EA관리[1].운영_지침(훈령 227호).hwp

행정자치부 훈령 제 227호

행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침 다음과 같이 제정합니다.

2007년 6월 13일

행정자치부장관

행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침

'IT' 카테고리의 다른 글

전사아키텍처 참조 모델  (0) 2007.12.11
EA 개념의 발전  (0) 2007.12.05
공공부문 ITA 표준  (0) 2007.12.05
ITA/EA  (0) 2007.12.04
ATAM 2  (0) 2007.11.20
IT
posted by 구름너머 2007. 12. 5. 00:43

1.유첨:공공부문 전사적 아키텍처 프레임워크 표준 자료.

2002-158_(TTAS[1].KO-10.0153).pdf

5.3.1 참조모델
참조모델은 아키텍처의 구성요소를 식별하고 설명한 것으로 공공부문 전사적 아키텍처의
모든 부문에서 고려된다. 참조모델은 개념을 추상화한 아키텍처를 제공하며 구성요소간의
인터페이스를 정의한다. 참조 모델의 목적은 사용자 요구사항을 만족시킬 수 있도록 시스템
규격에 대한 개념적인 모델을 추상화하고, 구성요소를 재사용 가능한 컴포넌트로 생성하여,
여러 이해당사자들이 사용할 수 있도록 하는 것이다. 참조모델은 전사적 아키텍처의 업무,
데이터, 응용, 기술기반 등의 관점에 따라 분류 및 참조 될 수 있다.

5.3.1.1 업무 참조 모델(Business Reference Model)
업무 참조 모델은 전사적 관점에서의 업무활동을 상세히 기술해준다. 업무 참조 모델은 조
직을 설명해주기 위한 다양한 모델들, 예를 들어 조직 차트, 위치도 등을 포함하며, 동시에
기능 위주의 접근 방법을 활용하여 전사적인 업무를 표현한다. 업무 참조모델은 다른 참조
모델들 - 데이터, 응용, 기술 등 - 을 분석함에 있어 주요 관점을 제공한다.
5) 각 공공부문은 정보화 사업 수행 시 필요에 따라 적절한 전사적 아키텍처 지원도구를 취사선택
할 수 있으며 반드시 사용이 의무화되지는 않는다.

5.3.1.2 성과 참조 모델(Performance Reference Model)
성과 참조 모델은 전사적인 아키텍처 프로그램 목표 및 목적에 도달하기 위해서 사용하는
성과의 전반적인 결과와 및 산출 방법을 제공하는 성과 측정 방법 프레임워크이다. 공공부
문은 성과 참조 모델을 이용하여 전략 단계에서부터 전사적인 업무를 보다 잘 관리하는 동
시에 목표 아키텍처로의 진전 상황을 측정하는 수단을 제공할 수 있다. 성과 참조 모델은
내부업무구성 컴포넌트, 업무상의 성과물, 고객 중심의 결과물, 프로그램 평가 등급 도구
(PART : Program Assessment Rating Tool)과 공통 측정방법(common Measures
Initiative) 등을 포함할 수 있다.

5.3.1.3 데이터 참조 모델(Data Reference Model)
데이터 참조 모델은 응용 및 업무 활동을 지원하는 데이터를 모든 단계별로 설명해준다.
이 모델은 공공부문 및 하위 조직과 그들의 고객, 후원자, 협업 기관 사이에서 발생하는 상
호 작용의 유형 및 정보 교환을 기술하는데 도움을 주며 전사적인 데이터를 유사 종류별로
분류하여 우선적으로 중복된 데이터 자원을 식별하도록 도와준다.

5.3.1.4 응용 참조 모델(Application Reference Model)
응용 참조 모델6)은 응용 애플리케이션 기능을 업무 또는 업무수행 목적을 지원하는 방법
에 따라서 기능별로 분류한 것이다. 응용 참조 모델은 업무 기능과는 독립적이며 전사적인
업무 컴포넌트와 업무 서비스의 재사용을 지원하는 응용의 추천을 가능하게 한다.
6) 美 연방정부 참조모델인 ‘Service Component Reference Model‘과 동일

5.3.1.5 기술 참조 모델 (Technical Reference Model)
기술참조모델은 응용 기능에 필요한 정보서비스들을 식별ㆍ설명하고 이들 간의 인터페이스
를 정의한 계층적 아키텍처를 제공한다. 기술 참조 모델의 목적은 사용자 요구사항을 만족
시킬 수 있도록 시스템 규격에 대한 개념적인 모델을 추상화하는 것이며, 이를 통해 컴포넌
트 기반 아키텍처의 채택 및 구현을 계층별로 지원하는 기술적 컴포넌트를 개략적으로 제시
할 수 있다.

'IT' 카테고리의 다른 글

EA 개념의 발전  (0) 2007.12.05
행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침  (0) 2007.12.05
ITA/EA  (0) 2007.12.04
ATAM 2  (0) 2007.11.20
아키텍쳐 평가방법론  (0) 2007.11.20
IT
posted by 구름너머 2007. 12. 4. 09:12
본문스크랩 EA/ITA IT

2007/12/04 09:08

http://blog.naver.com/damool2/40044986197

출처 블로그 > Beautiful Mind, Beautiful Life, Into The World...
원본 http://blog.naver.com/unius1004/100038629182

○ EA/ITA

정의

° EA(Enterprise Architecture)

- 조직 및 업무활동과 정보기술 간의 관계를 현재모습과 향후 추구할 모습을 별도로 정의한 청사진(Blueprint)

- 규칙(Rule) + 모델(Model) + 계획(Plan)으로 구성

° ITA(Information Technology Architecture)

- EA + TRM +SP

구성요소

EA Framework

° EA를 개발하기 위한 의사소통 모델

° 기업의 비즈니스, 정보, 어플리케이션 및 기술에 대해 명확한 구성요소로 식별, 정의하고 이들간의 관계를 정립한 구조적인 틀

※ 아키텍쳐 도메인

비즈니스 아키텍쳐(BA)

° 기업의 경영목표 달성을 위해 업무구조를 정의한 영역으로 기업의 업무와 서비스의 실체를 명확히 하는것

데이터 아키텍쳐(DA)

° 기업의 업무 수행에 필요한 전체 데이터 구조를 체계적으로 정의한 것

어플리케이션 아키텍쳐(AA)

° 기업의 업무를 지원하는 전체 어플리케이션을 식별하고 어플리케이션 구조를 체계화하는 것

기술 아키텍쳐(TA)

° 비즈니스, 데이터, 어플리케이션 아키텍쳐에서 정의된 요건을 지원하는 전사의 기술 인프라 체계

기술참조모델(TRM)

° 기업이 업무활동에 필요한 기능들을 수행하기 위해 요구되는 정보기술을 상위 수준에서 논리적으로 분류한 틀인데, 전사기술영역 모델과 같은 범주로 볼 수 있다. 다만 기술 참조 모델은 일반적인 표준을 최대한 수렴해 정의한는 것이 특징

표준프로파일(SP)

° 기술참조모델에 명시된 서비스를 지원하는 정보기술 표준들의 집합

° 해당 아키텍쳐에 적용될 표준에 대해 서술해 둔 내용물

절차

EA 비전 수립

° EA 방향 수립 - 환경분석, 구축 방향 정의, EA 프레임워크 정의

EA 구축

° EA 정보 구성 정의 - 아키텍쳐 매트릭스 정의, 참조모델 정의, EA원칙 수립

° EA 정보 구축 - EA 자료수집, AS-IS 구축, TO-BE 구축

EA 관리 정의

° EA 관리체계 구축 - EA 관리 조직, 프로세스, 인력 구성

° EA 관리시스템 구축 - EA 모델링 도구, EA 정보관리 시스템(EA Repository, EA Portal, EA Analysis Tool)

EA 활용 정의

° EA 이행계획 - 차이분석, 프로젝트 정의, 이행 전략 수립, 이행 계획 수립, 변화관리 계획수립

° EA 정보활용 - IT 기획, IT 구축관리, IT 운영 및 통제

※ EA 관련 DA가 이루어야 할 3가지 통합성

° 범위통합 - 전사아키텍쳐 범위 전체에 대한 각 모델 내의 불일치성 제거

° 수평통합 - 관련된 타 도메인(업무, 데이터, 어플리케이션, 기술)과의 불일치성 제거

° 수직통합 - 계획자, 책임자, 설계자, 개발자 사이의 불일치성 제거

참조모델 활용방안 및 기대효과

활용방안

기대효과

업무참조

모델

° 개선 대상 관련 업무를 파악

° 비즈니스 아키텍쳐 정의

° 기관간 업무 흐름 촉진

° 업무 프로세스 촉진을 통한 생산성 제고

° 비즈니스 성과 측정 용이

데이터참조

모델

° 개선 대상 관련 데이터 파악

° 데이터 아키텍쳐 정의

° 정보의 상호운용성 및 교환 촉진

° 통합된 데이터 활용으로 중복배제 및 재사용

° 데이터 표준화

서비스참조

모델

° 개선 대상 관련 어플리케이션 서비스 파악

° 어플리케이션 아키텍쳐 정의

° 시스템간 상호운용성 향상

° 신뢰성 있고 변화에 신속한 대응 가능

° 시스템 개발 생산성 및 품질 향상 기대

기술참조

모델

° 개선 대상 관련 기술 인프라 파악

° 기술 아키텍쳐 정의

° 시스템간 상호운용성, 이식성, 확장성 향상

° 벤더 독립성

° 재활용과 리소스 공유

※ 참조모델 구축방법

° 공통특성 추출 - 이해가 쉽고 산출물이 많지 않지만 요소간 경계, 하위수준의 정의가 불명확

° 대표적이고 복잡한 기업 선정 - 산출물간의 관계가 정확하고 하위수준까지 참조할 수 있지만 기업의 보안상 대부분 공개가 되지 않음

EAF 사례

ZEAF

° 기업활동을 5W1H관점에서 모델링

° 5개 관점 - Data, Function, People, Network, Time, Motivation

° 6개 묘사방법 - Planner, Owner, Designer, Builder, Sub-Contractor

° 지나치게 모델링에 집중, 실제 아키텍쳐 활동 계획 및 기반 정의 부족

FEAF

° 미 연방정부 프레임워크

° 참조모델 기반 EAF(BRM, DRM, SRM, TRM, PRM)

° 모델링 관점과 구체적 이행계획까지 포함

° 조직 및 관련 규정등 제반요소의 진화 부족

TEAF

° 미 재무성 프레임워크

° How-Where-When을 표현하는 기능, What-How-much How Freq.을 표현하는 정보, Who-Why를 표현 하는 조직, Enable을 표현하는 인프라 관점 중시

° 산출물 중심의 프레임워크로서 활용에 대한 접근 부족

DoDAF

° 미 국방성 프레임워크

° 효과적인 작전 수행을 위해 무기 체계간 상호 운용성 보장을 위해 도입된 EA

° 산출물에 대한 템플릿을 상세히 정의, 통일되고 검증된 방식으로 모델링 가능, 운영모델에 대한 상세한 정의 및 표현양식 제공

° 과도한 산출물과 정확도 요구, 과잉투자 가능성

TOGAF

° 민간 표준연합인 오픈그룹 EAF

° 구체적 아키텍쳐 개발 프로세스 제안

° 각종 참조모델의 활용 관계를 잘 정의

° 메타모델에 근거한 연속체 개념으로 아키텍쳐를 파악하여 조직의 특수성 반영이 어려움

EAP vs

ISP

ISP

EAP

° 원칙에 대한 정의 주로 없음

° 벤더 의존적

° 문서 지향적 산출물

° 조직, 기술변화시 사용되지 못함

° 외부 컨설턴트 의존적

° 도출과정 모호성

° 산출물 유지보수가 거의 이루어지지 않음

° 정보관리 전체에 적용될 원칙 정의

° 사용자 소유의 표준적, 오픈 아키텍쳐

° 프로젝트 지향적 산출물

° 지속적인 아키텍쳐 수정

° 내부주도, 외부지원

° 도출과정의 체계성

° EA실행과 유지보수를 위한 Control Mechanism 구현이 중요

'IT' 카테고리의 다른 글

행정자치부 엔터프라이즈아키텍처(EA) 관리‧운영 지침  (0) 2007.12.05
공공부문 ITA 표준  (0) 2007.12.05
ATAM 2  (0) 2007.11.20
아키텍쳐 평가방법론  (0) 2007.11.20
유스케이스 실체화(Use Case Realization)  (0) 2007.11.14
IT
posted by 구름너머 2007. 11. 20. 02:10
본문스크랩 아키텍쳐평가 IT

2007/11/20 02:06

http://blog.naver.com/damool2/40044481568

출처 블로그 > lomographer님의 블로그
원본 http://blog.naver.com/lomographer/40034898233





===============================================

아키텍쳐평가 방법론

아키텍쳐는 다양한 방법으로 평가될 수 있다. 크게 4가지의 범주로 구분할 수 있는데, 구분은 다음과 같다

  • Scenario-based assessment

    시나리오 기반의 평가는 직접적으로 품질 요소(Quality Attribute)를 위해 정의된 Profile에 의존하여 평가하는 방식이다. 기술적으로 시나리오에 기반하고 있기 때문에 시나리오의 정밀함에 따라 평가 결과도 정밀해질 수 있다. ATAM이나 SAAM 등이 시나리오 기반의 평가 방법이다.

  • Simulation-based assessment

    시뮬레이션 기반의 평가 방식은 간단하게 BMT를 연상할 수도 있다. 물론 시뮬레이션 기반의 방식은 일부 또는 추상화된 형태의 구현과 이를 기반으로 한 평가가 이루어진다.

  • Mathematical model-based assessment

    수학적 모델을 기반으로 한 static 평가가 이루어진다. 기준의 모델을 기초로 다른 점들을 수치화하고 이를 기초로 평가하게 된다. 품질을 추정하는 데 사용될 가능성이 높다.

  • Experience-based assessment

    제목 그대로 경험 기반의 평가 작업이다. 아키텍쳐 수립은 수학적인 활동과 예술적인 활동이 복합적으로 발생한다. 그래서 아키텍쳐 수립작업은 수학적 작업도 있지만 창조적/감각적으로 작업해야 하는 경우도 많다. 이런 감각적 작업에서 만들어진 결정들은 정량적인 분석이 어려운 경우가 많고, 품질을 평가하기 위해 정형화된 모델을 갖지 못하는 경우가 더 많다. 이러한 경우에 경험은 또 하나의 중요한 평가 수단으로 활용된다.

이러한 평가 방법들은 한가지만 사용되는 것이 아니라 복합적으로 적용되는 경향이 있다.

대표적인 평가 방법론

  • Architecture Tradeoff Analysis Method(ATAM)
    • 시나리오 기반임
    • 모든 quality attributes를 평가함
    • 특히 다음 사항을 찾아내는데 중심을 둠
      sensitivity to various attributes exists
      quality attribute tradeoffs occur
    • 정량적/정성적 분석/평가를 수행함
    • 시스템의 quality attribute에 관심이 있는 모든 관련 당사자들을 평가에 참여 시킴
  • Software Architecture Analysis Method(SAAM)
    • 단순하며, 시나리오 기반임
    • 주로 maintainability, modifiability, robustness,flexibility 등의 Quality에 관심을 둠
    • 주로 수정/변경에 필요한 리소스를 가정하고 이를 기반으로 평가함

'IT' 카테고리의 다른 글

공공부문 ITA 표준  (0) 2007.12.05
ITA/EA  (0) 2007.12.04
아키텍쳐 평가방법론  (0) 2007.11.20
유스케이스 실체화(Use Case Realization)  (0) 2007.11.14
XSS(Cross Site Scripting)  (0) 2007.11.13
IT
posted by 구름너머 2007. 11. 20. 02:02
본문스크랩 아키텍쳐 평가 방법론 IT

2007/11/20 02:00

http://blog.naver.com/damool2/40044481488

출처 블로그 > Beautiful Mind, Beautiful Life, Into The World...
원본 http://blog.naver.com/unius1004/100038661621

○ 아키텍쳐 평가 방법론

정의

° 아키텍쳐 접근법이 품질속성에 미치는 영향을 측정하여 아키텍쳐를 평가하는 표준 절차를 정의

범주

Scenario-based assessment

° 품질요소(Quality attribute)를 위해 정의된 Profile에 의존하여 평가하는 방식

° ATAM, SAAM

Simulation-based assessment

° 일부 또는 추상화된 형태의 구현과 이를 기반으로 한 평가방식

° BMT

Mathematical model-based assessment

° 기준의 모델을 기초로 다른 점들을 수치화하고 이를 기초로 평가하는 방식

° 품질을 추정하는데 사용될 가능성이 높다

Experience-based assessment

° 품질을 평가하기 위해 정형화된 모델을 갖지 못하고 정량적인 분석이 어려운 경우 경험이 중요한 평가수단으로 활용된다

종류° SAAM(Software Architecture Analysis Method)

° ATAM(Architecture Tradeoff Analysis Method) - SAAM을 계승하여 발전시킴

° CBAM(Cost Benefit Analysis Method) - ATAM의 부족한 경제성 평가를 보강함

° ARID(Active Review for Intermediate Design) - ATAM과 ADR(Active Design Review)를 혼합한 것이다.

상세

ATAM

° 아키텍쳐가 품질속성을 만족하는지 판단할 뿐만 아니라 어떻게 상충(tradoff)하면서 상호작용 하는지 분석하는 아키텍쳐 평가 방법

° 모든 Quality Attribute를 평가함

° 민감점(Sensitivity point)와 절충점(Tradeoff point)를 찾는데 중점을 둠

SAAM

° 최초로 정리된 아키텍쳐 평가 방법

° 다양한 수정가능성(Modifiability)관점에서 아키텍쳐를 평가하고 분석하는 방법

° ATAM 보다 상세하지는 않지만 보다 많은 영역에 적용될 수 있다

CBAM

° 소프트웨어 아키텍쳐를 ROI관점에서 평가함

° 시스템이 제공하는 품질에서 얻을 수 있는 이득에 대한 경제적 측면을 고려

° 비용과 이익을 기반으로 ROI를 계산하여 수익이 최대로 되는 소프트웨어 아키텍쳐를 선정

ARID

° ATAM과 ADR 방법론이 혼합된 형태로 전체 아키텍쳐가 아닌 한 부분에 대한 품질요소에 집중하여 평가

'IT' 카테고리의 다른 글

ITA/EA  (0) 2007.12.04
ATAM 2  (0) 2007.11.20
유스케이스 실체화(Use Case Realization)  (0) 2007.11.14
XSS(Cross Site Scripting)  (0) 2007.11.13
Data Profiling  (0) 2007.11.13
IT
posted by 구름너머 2007. 11. 14. 10:55

자료가 찾기 넘 힘드네요...ㅠㅠ

http://blog.empas.com/ahnyounghoe/read.html?a=2039819&c=513179

유스케이스 실체화(Use Case Realization)
조회(742)
[uml] |2004/06/02 (수) 17:19
공감하기 |스크랩하기(1)
* 이 글은 제가 2002년 웹매니아에 기고했던 내용을 편집하여 올립니다.

유즈케이스는 시스템의 외부에서 바라본 관점을 반영합니다. 시스템의 가치는 결국 이를 사용하는 사람에 의해 결정되거나 혹은 관련된 시스템이 있는 경우, 얼마나 잘 연동 되는지에 따라서 시스템을 평가할 수 있을 것입니다. 아무리 잘 만들었다고 하더라도 사용자가 불편하면 결코 좋은 시스템이라고 말할 수 없겠죠. 수백억을 들여 만든 영화도 관객의 시선을 끌지 못한다면 실패한 영화로 보여지기 마련입니다.

강좌의 서두에서도 유즈케이스의 중요성을 재차 언급했던 것으로 기억합니다. 유즈케이스가 시스템 개발 과정에서 주도적인 역할을 하는 경우가 일반적이라 할 수 있습니다. 그런 맥락에서 시스템의 주요 기능, 시스템을 구성하는 객체와 클래스, 또 객체간의 상호작용을 뽑아내는 데에도 유즈케이스를 출발점으로 사용하는 것은 좋은 방안입니다.

그러나, 아무리 유즈케이스를 잘 뽑아내고, 완벽하게 사용자의 요구를 분석했다고 하더라도 실제로 구현되지 않으면 아무 소용이 없겠죠. 설계도가 좋다고 무조건 훌륭한 건물이 보장되는 것은 아니듯이 말입니다. 이렇게 유즈케이스를 시스템으로 만들어 나가는 첫 단계가 'Use Case Realization'입니다. 유즈케이스 실현 혹은 유즈케이스 실체화 등으로 번역할 수 있겠네요.(이하에서는 '유즈케이스 리얼리제이션'으로 표기 하도록 하겠습니다.)

유스케이스 리얼리제이션의 UML 표기법은 그림 8-1과 같이 점선으로 된 타원입니다.


그림 8-1. 유즈케이스 리얼리제이션의 UML 표기법


Rose에서 유즈케이스 리얼리제이션을 만들어 볼까요. 유즈케이스를 만들 때와 방법은 동일합니다. 다른 것은 유즈케이스는 Use Case View에서 오른쪽 마우스 클릭을 하여 만들지만, 유즈케이스 리얼리제이션은 클래스와 같이 Logical View에서 오른쪽 마우스 클릭을 해서 만들 수 있습니다.

이렇게 만들어진 유즈케이스를 더블 클릭하여 스페시퍼케이션 윈도우를 띄운 다음 스테레오 타입에서 use-case realization을 선택합니다.



그림 8-2. Use Case Realization 스테레오타입


이를 적용하면 브라우저의 유즈케이스도 점선형태의 타원으로 나타나게 됩니다. 그림 8-3은 유즈케이스 리얼리제이션의 스테레오타입을 적용한 후의 브라우저의 모습입니다.

그림 8-3. 브라우저에 나타난 유즈케이스 리얼리제이션


유즈케이스 리얼리제이션 다이어그램(Use Case Realization Diagram)

유즈케이스 리얼리제이션과 마찬가지로 유즈케이스 리얼리제이션 다이어그램도 Logical View에서 오른쪽 마우스 클릭한 후 New - Use Case Diagram 메뉴를 이용하여 만들 수 있습니다. 그림 8-4는 유즈케이스 리얼리제이션 다이어그램의 예입니다.



그림 8-4. 유즈케이스 리얼리제이션 다이어그램

'IT' 카테고리의 다른 글

ATAM 2  (0) 2007.11.20
아키텍쳐 평가방법론  (0) 2007.11.20
XSS(Cross Site Scripting)  (0) 2007.11.13
Data Profiling  (0) 2007.11.13
XSS 보안 위협「당신의 사이트는 안전한가?」  (0) 2007.11.13