데이터아키텍처전문가 - 국가공인자격 [DAsP] 데이터아키텍쳐준전문가 요약자료

2013.11.09 23:46

가을의 곰을... 조회 수:22956

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

[DAsP] 데이터아키텍쳐준전문가 요약자료

[출처] http://boramjeong.com/140196555941

첨부다운로드 => DASP_2.pdf

시험 과목 및 내용

[1] 전사아키텍처 이해

1) 전사아키텍처 개요

(1) 전사아키텍처 정의

1. 전사아키텍처(Enterprise Architecture) 정의

- 출연 배경

① 기업의 비즈니스와 시스템의 복잡도 증대

② 시스템에 대한 전체적 파악이 어려워지고 변경이 곤란해지고 있음

③ 이러한 복잡한 시스템을 쉽게 파악할 수 있고, 변화시킬 수 있는 설계도와 같은 것 필요

- 전사 아키텍처 정의

① 전사아키텍처란 복잡한 기업의 모습을 다양한 측면에서 분석하고 표현하여 이해하기 쉽도록 정보 체계를 구축하고 이를 활용하는 것

② 기업의 목표와 요구를 잘 지원하기 위해 IT인프라의 각 부분들이 어떻게 구성되고 작동되어야 하는가를 체계적으로 기술하는 것

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

2. 전사아키텍처 도입 목적

① 기업의 목적을 가장 잘 달성할 수 있는 IT 인프라 구성

② 비즈니스와 IT의 유기적 연계

③ 비즈니스 환경 변화에 대한 신속한 대응

④ IT투자 대비 효과의 최적화

⑤ IT관리의 효율성 제고

3. 전사(Enterprise) 개념

① Enterprise 란? 공동의 목표를 추구하기 위해 고객과 상품 또는 서비스가 존재하고, 이를 지원하기 위한 조직, 자원, 기술을 보유하며, 필요한 업무 프로세스를 수행하는 조직의 집합체

② 엔터프라이즈는 전사아키텍처 수립의 대상으로, 일반적으로는 기업 또는 기관을 지칭하지만 항상 일치하지는 않음 (다:1 가능)

4. 아키텍처 정의

① 아키텍처: 구성요소의 구조, 구성요소들 사이의 관계, 구성요소의 설계 그리고 시간 경과에 따른 구성요소의 발전을 위한 원리와 지침

② 아키텍처는 대상에 대한 구조 뿐만 아니라, 대상 구조의 유지 관리를 위한 원칙과 지침, 그리고 향후 목표 아키텍처로 가기 위한 계획을 포함

5. 아키텍처 구성요소

① 규칙(Rule): 전략, 원칙/지침, 표준

② 모델(Model): 참조 모델, 비즈니스 아키텍처, 데이터 아키텍처, 애플리케이션 아키텍처, 기술 아키텍처

③ 계획(Plan)

6. EA(Enterprise Architecture)

정보기술아키텍처는 1996년 미국 정보기술관리혁신법에서 ITA(Information Technology Architecture)라는 용어를 사용했으니 2000년 OMB A-130 회람에서 아키텍처 관련 이런 개념을 전사 아키텍처라 명명

7. ITA

전사아키텍처를 좀 더 광의 아키텍처 개념으로 ITA를 정보기술 중심의 아키텍처 개념으로 볼 수 있는데, 국내의 경우 행정자치부는 EA라는 용어를 정보통신부는 ITA라는 용어를 사용

8. DAP(Data Architecture Professional) 역할

① 데이터 아키텍처 전문가는 전사 아키텍처에 대해 정확히 이해하고 있어야 하고, 기업의 전사아키텍처 추진에 대하여 관심을 가지고, 구축된 전사아키텍처 정보를 적극 활용해야 함

② 전사아키텍처 수립 시 DAP가 데이터 아키텍처 수립에 참여하는 것이 이상적이며, 직간접적으로 지원할 필요가 있음

③ DAP는 항상 전사아키텍처 개념으로 데이터 아키텍처 업무에 접근하는 것이 바람직함

(2) 전사아키텍처 프레임워크

1. 전사아키텍처 프레임워크 개념

① 전사아키텍처 활동에서 얻어지는 산출물을 분류하고 조직화하고 이를 유지관리하기 위한 전체적인 틀

② 전사아키텍처를 정의하기 위해서는 우선 전사아키텍처 프레임워크를 결정해야 함

③ 여러 선진모델이 있고 정부에서도 가이드를 제시하고 있어, 기관이나 기업은 이를 참조가능

2. 전사아키텍처 정책

① 아키텍처 매트릭스: 전사아키텍처의 정보를 체계적으로 분류한 틀. 기업이 관리하려고 하는 전사아키텍처 정보의 수준과 활용 계층을 결정

② EA 비전: 전사아키텍처 수립을 통하여 기업이 궁극적으로 달성하고자 하는 모습

③ EA 원칙: 전사아키텍처 정보를 효율적으로 구축하고, 정보를 효과적으로 활용하기 위해서 조직 구성원이 공유해야 할 규범

3. 전사아키텍처 정보

① 현행 아키텍처: 각 아키텍처 도메인 별 기업의 현재의 상태를 정의한 것

② 목표 아키텍처: 각 아키텍처 도메인 별 기업이 궁극적으로 달성하고자 하는 목표 아키텍처의 상태를 정의한 것

③ 전사아키텍처 이행계획: 각 아키텍처 도메인 별로 현재 모습에서 바람직한 목표 모습으로 이행하기 위한 이행전략과 이행계획을 정의한 것

4. 전사아키텍처 관리

① 전사아키텍처 관리체계

i. 전사아키텍처 가버넌스라고도 하며, 구축된 전사아키텍처를 유지하고 개선하기 위한 제도적 기반을 수립하는 것

ii. 조직, 프로세스 포함

② 전사아키텍처 관리시스템

iii. 전사아키텍처 정보관리의 효율성을 제고하고, 전사아키텍처 정보의 공유를 활성화하기 위해 구축하는 정보 시스템

③ 전사아키텍처 평가

iv. 전사아키텍처의 관리와 활용 수준의 제고를 위해서는 전사아키텍처에 대한 주기적인 평가

v. 전사아키텍처 성숙모형이 필요

5. 아키텍처 도메인 구성

① 비즈니스 아키텍처 예: 전사 사업 모델, 조직 모델, 업무기능 모델, 프로세스 모델, 업무메뉴얼

② 애플리케이션 아키텍처 예: 전사 애플리케이션 영역 모델, 애플리케이션 모델, 컴포넌트 모델, 클래스 모델, 프로그램목록

③ 데이터 아키텍처 예: 전사 데이터 영역 모델, 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델

④ 기술 아키텍처 예: 전사 기술영역 모델, 기술 참조모델, 표준 프로파일, 기술 아키텍처 모델, 기술 자원 목록, 제품 목록

(3) 전사아키텍처 참조 모델

1. 참조모델(Reference Model) 정의

정부 또는 산업, 기업군별로 아키텍처 구성요소를 식별하여 표준화한 것으로 기관이나 기업의 전사아키텍처 수립 시 참조하는 추상화된 모델

2. 참조모델 사례

① 범정부 업무 참조모델 (BRM, Business Reference Model):

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

② 범정부 서비스 참조모델 (SRM, Service Reference Model):

업무 수행과 목표 달성을 지원하는 서비스 요소를 분류하기 위한 기능 중심의 참조모델. 범정부 차원의 업무 및 응용 서비스 요소 발견 가능

③ 범정부 데이터 참조모델 (DRM, Data Reference Model):

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

④ 범정부 기술 참조모델 (TRM, Technical Reference Model)

기술 참조모델은 업무와 서비스 구성요소의 전달과 교환, 구축을 지원해주는 기술 표준, 기술 명세, 기술 요소를 기술한 것

3. 참조모델 정의 방법

① 범용화 방법

i. 공통적인 특성을 추출하여 산업군에 맞게 범용화 방법

ii. 장점: 이해하기 쉽고 많은 산출물이 필요하지 않음

iii. 단점: 요소간 경계가 불명확하고 하위 수준의 정의가 명확하지 않음

② 재활용 방법

i. 복잡하고 대표적인 기업을 선정하여 기업의 아키텍처를 표본으로 삼아 비슷한 기업에서 재활용 방법

ii. 장점: 각 산출물의 관계가 정확하고 하위 수준까지 참조할 수 있음

iii. 단점: 기업의 보안상 대부분 공개가 되지 않음

4. 참조모델 활용 방안

① 업무 참조 모델

i. 활용방안

1) 업무 개선의 대상이 되는 관련 업무를 BRM을 참조하여 파악

2) 개별 기관의 비즈니스 아키텍처를 업무참조모델을 참조하여 정의

ii. 기대효과

1) 관련 기관간 업무 흐름 촉진

2) 업무프로세스 혁신을 통한 업무 처리 생산성 제고

3) 비즈니스 성과측정 용이

② 데이터 참조 모델

i. 활용방안

1) 개선의 대상이 되는 관련 데이터를 데이터 참조모델을 참조하여 파악

2) 개별 기관의 데이터 아키텍처를 데이터 참조모델을 참조하여 정의

ii. 기대효과

1) 정보의 상호 운용성과 교환 촉진

2) 정부나 기업군 또는 산업 차원의 통합된 데이터 활용

3) 데이터 중복 배제 및 재사용

4) 데이터에 대한 표준화된 정의

③ 서비스 요소 참조 모델

i. 활용방안

1) 개선의 대상이 되는 관련 애플리케이션 서비스 참조모델을 참조하여 파악

2) 개별 기관의 애플리케이션 아키텍처를 서비스 참조모델을 참조하여 정의

ii. 기대효과

1) 시스템 간 상호운용성 향상

2) 신뢰성 있는 시스템 구축 가능

3) 변화에 신속한 대응 가능

4) 시스템 개발 생산성, 품질 향상 기대

④ 기술 참조 모델

i. 활용방안

1) 개선의 대상이 되는 관련 기술 인프라를 기술 참조모델을 참조하여 파악

2) 개별 기관의 기술 아키텍처나 TRM을 상위 기술 참조모델을 참조하여 정의

ii. 기대효과

1) 시스템 간 상호운용성 향상

2) 이식성 향상

3) 시스템 확장성 향상

4) 표준화 따른 벤더 독립성

5) 재활용과 리소스 공유

(4) 전사아키텍처 프로세스

1. 전사아키텍처 프로세스 정의

전사아키텍처를 구축하고 관리하는 전체 절차에 관한 것으로 작업의 단계와 공정, 작업내용 등을 정의

2. 전사아키텍처 프로세스 단계 및 공정 예

① 전사아키텍처 비전 수립

i. 전사아키텍처 방향 수립

1) 내외부 전사아키텍처 환경 분석

2) 기업의 전사아키텍처 목적 및 방향 정의

3) 기업의 전사아키텍처 프레임워크 정의

② 전사아키텍처 구축

i. 전사아키텍처 정보구성 정의

1) 아키텍처 매트릭스 정의/ 전사아키텍처 정보 구성요소 정의

2) 전사아키텍처 참조모델 정의

3) 전사아키텍처 원칙 수립

ii. 전사아키텍처 정보 구축

1) 전사아키텍처 자료 수집

2) 현행 아키텍처 정보 구축

3) 목표 아키텍처 정보 구축

③ 전사아키텍처 관리

i. 전사아키텍처 관리체계 구축

1) 전사아키텍처 정보를 운영 및 활용 위한 조직, 프로세스 정의

2) 기업 내 전사아키텍처 홍보, 내부 추진체계에 대한 교육 수행

ii. 전사아키텍처 관리시스템 구축

1) 전사아키텍처 정보를 관리하기 위한 도구 선정

2) 전사아키텍처 정보를 관리하는 시스템 구축

④ 전사아키텍처 활용

i. 전사아키텍처 이행계획: 목표 아키텍처를 달성하기 위한 중장기적인 계획 수립

ii. 전사아키텍처 정보활용: 전사아키텍처 정보를 적용하여 IT 관련 업무를 수행함

2) 전사아키텍처 구축

(1) 전사아키텍처 방향 수립

1. 전사아키텍처 방향 수립 개요

① 전사아키텍처 구축의 목표와 목적 정의하고, 이를 달성하기 위한 전사아키텍처 프레임워크를 정의하는 것

② 다수의 이해관계자에게 공동의 목표와 목적을 제공함으로써 추진 과정에서 발생할 수 있는 의견 충돌을 사전에 방지

③ 작업 공정

i. 전사아키텍처 환경 분석

ii. 전사아키텍처 구축 방향 정의

iii. 전사아키텍처 프레임워크 정의

2. 전사아키텍처 방향 수립과 작업 내용

① 전사아키텍처 환경분석

i. 작업내용

기업의 외부환경과 내부환경을 분석하고, 관련된 이해관계자로부터 전사아키텍처 수립을 위한 요건 도출

ii. 세부공정

비즈니스 내/외부 환경분석

IT 내/외부 환경분석

엔터프라이즈 범위 정의

② 전사아키텍처 구축 방향 정의

i. 작업내용

전사아키텍처 환경분석을 바탕으로 아키텍처 구축의 목적과 범위, 비전을 정의

ii. 세부공정

목적 및 범위 정의

전시아키텍처 비전 수립

③ 전사아키텍처 프레임워크 정의

i. 작업내용

계획단계에서 정의된 전사아키텍처 프레임워크에 대해 기업의 특별한 변경 요구가 있을 경우 이를 반영하고, 전사아키텍처 프레임워크에 대하여 관련자들이 공감대를 형성하고 확인

ii. 세부공정

프레임워크 리뷰 및 보완

(2) 전사아키텍처 정보 구성 정의

1. 전사아키텍처 정보 정의

① 기업을 잘 이해하기 위해 필요한 업무와 정보기술에 대한 정보로서 활용할만한 가치가 있고 관리가 용이한 정보

② 업무와 정보기술의 구성요소와 구성요소 간의 관계를 포함하며, 가능한 변화하지 않은 구성요소를 도출하여 정의

2. 전사아키텍처 정보 구성 정의

① 전사아키텍처 정보를 표현하기 위해서는 전사아키텍처 산출물과 이를 구성하는 요소를 분류하는 것

② 메트릭스 형태로 작성되며, 아키텍처 매트릭스 라고 한다.

③ 정보구성 정의 작업 공정

i. 아키텍처 매트릭스 정의

ii. 참조모델 정의

iii. 전사아키텍처 원칙 정의

3. 아키텍처 매트릭스 정의

① 전사아키텍처 프레임워크의 핵심 구성요소로 전사를 설명하는 모델정보를 통일된 시각으로 볼 수 있는 논리적 틀

② 의사결정 유형(관점)과 아키텍처 정보 유형(뷰)의 두 축을 기준으로 2차원의 매트릭스 형태

4. 아키텍처 매트릭스 관점/뷰 정의

① 의사 결정 유형(관점, Perspective)의 정의

조직의 의사결정 유형을 계층적으로 구분한 것으로, 조직이 수행하는 업무의 의사 결정 특성에 따라 단계를 정의

② 아키텍처정보 유형(뷰, View)의 정의

특성이 비슷한 아키텍처 정보를 그룹화 한 것으로, 기업이 관리하는 모든 아키텍처 정보를 수집하여 분류

③ 산출물 정의

아키텍처 매트릭스 산출물 (정통부 아키텍처 매트릭스; 공통 , 보안 제외)

④ 아키텍처 정보 구성요소 정의

전사아키텍처 정보를 공유정보로 구축하기 위해 전사아키텍처 산출물에 포함된 정보를 중복이 없고 상호관계가 유기적으로 연결되는 구성요소로 정의

5. 아키텍처 매트릭스 고려사항

① 메트릭스를 정의할 떄는 일반적인 아키텍처 개념을 포함하면서 조직 내 모든 계층의 사람이 매트릭스에 포함되는 산출물이 범위와 목적에 적합하게 정의되었음을 확신 할 수 있어야 함

② 조직적, 정치적, 지리적 특성, 조직의 편견 등 다양한 조직의 문화와 의사 결정 구조가 반영되어야 함

③ 아키텍처 매트릭스는 실제의 시스템과 아키텍처 개발 표준에 대한 준수성을 높이고 조직별로 통일된 접근이 가능하도록 정의되어야 함

④ 각 아키텍처 도메인은 상호간에 연계성을 가져야 함. 아키텍처에서 정의된 산출물은 상호연관성을 가지며 비즈니스-데이터-애플리케이션-기술아키텍처 간에 통합적인 관리가 가능해야 함

6. 참조모델 정의

① 다수 엔터프라이즈를 가지고 있는 기업은 참조모델을 정의하고, 개별기업은 정의된 참조모델을 확인하는 과정 a 정부나 기업군 또는 상위기관은 하위기관이나 기업에서 참고할 참조모델을 정의하고, 개별 기관이나 기업들은 이런 참조모델을 참고하여 전사아키텍처 구성요소의 타당성을 확인

② 참조모델은 업무와 정보기술에 대한 체계적인 분류와 표준화를 통해 정보화의 통합성, 중복개발 방지, 공유정보의 발견, 상호운용성 향상 등의 목적으로 설계되어 있기 때문에 개별기관은 상위기관의 참조모델을 참고하여 아키텍처 정보를 정의하는 것이 바람직함

③ 참조모델 정의는 기업이 속한 산업이나 가치 사슬 네트워크에 따라 범위가 달라짐

④ 기술 참조 모델의 경우, 개별 기관이나 기업에서도 기업의 표준화와 기술요소간 상호운용성을 향상하기 위해 정의하여 활용하는 것이 일반적임.

7. 전사아키텍처 원칙 수립

① 전사아키텍처 비전 달성을 위해 구성원들이 공통으로 지켜야 하는 규범 정의

② 원칙은 목표 달성을 위한 의사결정의 객관적 기준을 제시하여 의사결정을 효과적으로 지원하고, 업무 협조와 조정을 위한 의사소통 과정의 투명성 제공

8. 전사아키텍처 원칙 구성

① BA 원칙

모든 정보기술 아키텍처 정의를 위한 최상위 수준의 원칙으로서, 경영전략과 비전을 달성하기 위한 비즈니스 가치지향적 유지를 위한 원칙

예) 비즈니스 가치지향, 업무 효율성

② DA 원칙

비즈니스 수행에 필요한 데이터의 구조 및 획득/가공/적재/제공 측면에서 고려하여야 하는 원칙

예) 정확성, 적시성, 통합성, 보안성

③ AA 원칙

애플리케이션 개발 및 운영 시 달성하여야 하는 정보기술 관점의 지향성

예) 관리성, 유연성, 신속성, 신뢰성

④ TA 원칙

정보기술 요소의 도입 및 적용 시 준수하여야 하는 원칙

예) 운영의 안전성, 상호운영성, 기술의 표준화

⑤ IT 관리체계 원칙

IT전략수립, IT관련 의사결정, 정보시스템 설계/개발 추진 등 IT업무체계에서 준수되어야 하는 기본적인 원칙

예) 유지보수성, 효율성, 효과성

(3) 전사아키텍처 정보 구축

1. 전사아키텍처 정보 구축 개요

① 전사아키텍처 정보구성 정의 단계에서 정의된 전사아키텍처 정보를 실제로 작성하는 과정

i. 아키텍처 매트릭스에서 정의된 산출물에 대해 현행기준과 목표기준의 아키텍처 정보를 각각 작성

ii. 전사아키텍처 수립 프로젝트의 핵심 작업 공정임

② 전사아키텍처 정보 구축은 원 자료를 수집한 후 현행 아키텍처를 정의한 후, 개선점을 도출하여 목표 아키텍처를 정의함

③ 정보구축 작업공정

i. 전사아키텍처 정보 구축 준비

ii. 현행 아키텍처 정보 구축

iii. 목표 아키텍처 정보 구축

2. 전사아키텍처 정보 구축 준비

① 전사아키텍처 자료 수집

i. 기업에 존재하는 아키텍처 정보 관련 자료를 수집하며, 수집해야 할 자료는 정의된 아키텍처 매트릭스에 따라 달라짐

ii. 업무에 관련된 것은 업무지침서나 규정 등을 수집하고, 데이터나 애플리케이션에 관련된 것은 정보시스템 구축 시 작성한 산출물이나 완료보고서 등을 수집하고, 기술 인프라는 시스템 도입 문서와 운영 매뉴얼 등을 수집함

3. 전사아키텍처 정보 구축 방식 비교

① 상향식 구축 방법

i. 최하위에 있는 구성요소를 조사 분석하여 구성요소들의 공통점을 파악하여 공통적인 구성요소들을 모아 상위 구성요소를 정의해 나가는 방식

ii. 장점: 조직의 모든 업무가 포함되는 것을 보장할 수 있음

iii. 단점: 상위 업무 기능 분류의 수준이 서로 다르게 나타날 수 있음

② 하향식 구축 방법

i. 최상위의 구성요소로부터 시작하여 분류 기준에 따라 하위 구성요소를 도출해 내는 방식

ii. 장점: 일반적인 분류기준이나 목적에 따른 분류기준을 따르기 때문에 관점이 명확

iii. 단점: 일부 업무가 누락될 가능성이 있으며 어디에도 포함되지 않는 구성요소가 발생할 수 있음

4. 현행 아키텍처 정보 구축

① 현재의 업무나 정보시스템에 대하여 기존의 자료를 분석하여 전사아키텍처 정보를 구축

② 상위 수준의 업무기능과 시스템에 대한 분류를 우선 수행한 후 그 기준에 따라 나머지 전사아키텍처 정보를 구축하는 것이 효율적

5. 현행 아키텍처 정보 구축 작업 내용

① 현행 비즈니스 아키텍처 정의

전사 사업모델 분석, 조직모델 분석, 업무기능 모델 정의, 프로세스 모델 정의, 업무 매뉴얼 파악 정리

② 현행 애플리케이션 아키텍처 정의

전사 애플리케이션 영역 식별, 애플리케이션 모델 정의, 컴포넌트 모델 정의, 프로그램 목록 파악 정리

③ 현행 데이터 아키텍처 정의

전사 데이터 영역 식별, 개념데이터 모델 정의, 논리데이터 모델 정의, 물리데이터 모델 정의, 데이터베이스 객체 파악 정리

④ 현행 기술 아키텍처 정의

전사 기술영역 식별, 기출 참조모델 정의, 기술 표준 분석, 기술 아키텍처 요소 식별, 기술자원 목록, 제품목록 파악 정리

6. 목표 아키텍처 정보 구축

① 현행의 아키텍처에 대한 문제점과 개선사항을 도출하고, 이를 목표 아키텍처에 반영하는 방식으로 진행

② 비즈니스 아키텍처를 먼저 정의하고, 이를 효율적으로 지원하는 아키텍처를 정의

7. 목표 아키텍처 정보 구축 작업 내용

① 목표 비즈니스 아키텍처 정의

전사 사업모델 정리, 조직모델 정의, 업무기능 모델 정의, 프로세스 모델 정의, 업무 매뉴얼 정보 구축

② 목표 애플리케이션 아키텍처 정의

전사 애플리케이션 영역 모델 정의, 애플리케이션 모델 정의, 컴포넌트 모델 정의, 프로그램 목록 정보 구축

③ 목표 데이터 아키텍처 정의

전사데이터영역 모델 정의, 개념데이터 모델 정의, 논리데이터 모델 정의, 물리데이터 모델 정의, 데이터베이스 객체 정보구축

④ 목표 기술 아키텍처 정의

전사기술영역 모델 정의, 기출참조모델 정의, 표준 프로파일 정의, 기술아키텍처 모델 정의, 기술자원목록, 제품목록 정보구축

3) 전사아키텍처 관리 및 활용

(1) 전사아키텍처 관리 체계

1. 전사아키텍처 관리 체계 개요

① 전사아키텍처 관리 체계 개념

i. 전사아키텍처를 유지 관리하기 위한 조직과 프로세스를 정립하는 것

ii. IT기획에서 서비스 제공에 이르는 모든 과정에서 전사아키텍처 정보를 활용하여 의사결정이 이루어 짐으로 일관성과 합리성이 증대됨

② 전사아키텍처 관리 체계 구성

관리 조직, 관리 프로세스, 관리 인력

③ IT 관리 체계(거버넌스)와 EA 관리 체계(거버넌스)

IT 관리 체계(거버넌스) : IT 조직, IT 프로세스, IT 인력

EA 관리 체계(거버넌스): EA 관리 조직, EA 관리 프로세스, EA 관리 인력

2. 전사아키텍처 관리 조직 체계

① 전사아키텍처 관리를 위해 필요한 직무와 직무간의 관계, 업무분장을 정립하는 것

② 전사아키텍처 조직은 기업 전체 또는 정보관리 전체 조직과 일관성을 확보해야 하며, 계획자 수준에서 실무자 수준까지 다양한 시작에서 책임과 역할을 분리

3. 전사아키텍처 관리 프로세스

① 전사아키텍처를 관리하기 위한 활동을 정의하는 것

② 전사아키텍처 관리 프로세스는 전사아키텍처 관리 관련 모든 활동을 포함하며, 전체 정보관리 업무 체계와 일관성이 확보되도록 하며, IT 활동의 중심이 전사아키텍처 기반으로 수행될 수 있도록 해야 함

4. 전사아키텍처 관리 인력

① 전사아키텍처 관리를 담당하는 직무별 역량을 정의하고 이를 확보하기 위한 방안을 정의하는 것

② 전사아키텍처 관리를 위해 필요한 역량 요소를 분류하고, 역량 요소를 직무별로 할당하고, 이러한 역량 요소를 확보하기 위한 교육 계획을 수립하고 역량 수준을 평가할 수 있는 체계를 포함

③ EA 정보를 지속적으로 발전시킬 수 있는 영역별 아키텍트 지정 필요

5. 효과적인 전사아키텍처 관리관체계 구축을 위한 고려사항

① 정의된 전사아키텍처 조직체계, 프로세스체계 등을 문서화하여 전 조직이 준수 할 수 있도록 제도화 함

② 전사아키텍처 관련 제반 이해당사자의 전사아키텍처 인지도 향상 및 업무 수행 시 전사아키텍처 정보 활용도 증진을 위한 적절한 교육 프로그램을 제공

③ 전사아키텍처 관리체계를 주기적으로 점검하여 개선점을 도출하여 반영할 수 있는 제도적 장치를 마련

④ 전사아키텍처 관리시스템을 활용도와 만족도를 주기적으로 점검하여 시스템의 품질을 지속적으로 개선

(2) 전사아키텍처 관리시스템

1. 전사아키텍처 관리시스템 개념

전사아키텍처 관리시스템은 전사아키텍처 정보를 구축하여 관리하고 활용하는 모든 전사아키텍처 업무 프로세스에 대한 효율성 제고를 지원하기 위한 정보시스템

2. 전사아키텍처 관리시스템 구성

① 정보 정의 영역: 전사아키텍처 정보를 도형으로 표현하는 모델링 도구 등

② 정보 관리 영역: 전사아키텍처 정보를 저장 관리하는 전사아키텍처 레파지토리와 전사아키텍처 정보를 활용하는 전사아키텍처 포탈로 구성

③ 정보 활용 영역: 전사아키텍처 정보를 활용하는 전문 도구 등의 사용자 환경

3. 전사아키텍처 관리시스템 도입 효과

① 아키텍처 정보를 공유할 수 있어 해당 조직의 각 아키텍처 요소에 대해 이해 관계자들이 정확하게 파악할 수 있음

e 각 아키텍처 별로 최신 정보를 아키텍처 담당자의 관점에 맞게 정보 제공

② 의사소통 도구로 전사아키텍처 관리시스템을 활용할 수 있음

i. 현업과 IT가 공유할 수 있게 하여 의사소통의 오류를 줄임

ii. 아키텍처 별로 요소간의 연관관계를 파악하여 관련 업무조직과 사전에 협의하여 문제를 사전에 인식함으로써 관련자들의 만족도를 높일 수 있음

③ 전사아키텍처 관리 시스템을 의사결정 도구로 활용할 수 있음

i. 업무와 IT 서비스 간의 차이 분석 가능

ii. 현행 아키텍처와 목표 아키텍처 간의 차이 분석 가능

(3) 전사아키텍처 활용

1. 전사아키텍처 활용개요

전사아키텍처의 활용이 활성화 되기 위해서는 실제 전사아키텍처 정보가 IT 관리 업무에 실질적으로 활용될 수 있도록 함

e 근시안적인 IT 투자나 중복 개발의 방지, 시스템간의 상호운용성 제고, 비즈니스와 정보기술의 변화에 대응력 제고 등에 활용될 수 있음

2. 전사아키텍처 활용영역

① 목표 아키텍처 이행 계획 수립

i. 전사아키텍처 수립 후 목표 아키텍처를 달성하기 위한 이행계획을 수립하고 그에 따라서 프로젝트를 추진하는 것

ii. 주로 신시스템 추진을 목적으로 전사아키텍처를 수립하는 경우에 해당

② 전사아키텍처 정보 상시 활용

i. 전사아키텍처 정보를 활용하여 일상의 IT업무를 지원하는 것

ii. 전사아키텍처 정립을 통해 기업의 전반적인 IT관리 수준을 증대하고자 하는 경우에 해당

3. 목표아키텍처 이행계획

현행 아키텍처에서 목표 아키텍처로 이행을 위한 전략수립하고 구체적인 이행계획을 수립하는 것

e 현행 아키텍처와 목표 아키텍처의 차이분석을 통하여 프로젝트를 정의하고, 정의된 프로젝트들 간의 유사성과 상호연관성을 고려하여 우선순위를 결정하고 이를 위한 이행전략과 세부 이행계획을 수립

4. 목표 아키텍처 이행계획의 주요 활동

① 아키텍처 Gap 분석: 목표 및 현행 아키텍처 검토, 차이분석

② 프로젝트 정의: 프로젝트 목록 정의, 개별 프로젝트 별 필요 리소스 정의, 프로젝트 우선 순위 및 연관성 분석

③ 이행전략 수립: 프로젝트 이행에 필요한 단계별 이행전략 대안 수립, 이행전략 별 타당성 분석 및 대안 확정

④ 이행계획 수립: 프로젝트 별 추진 방법 정의, 프로젝트 별 상세 일정계획 수립

⑤ 변화관리계획 수립: 변화관리대상 및 변화요인 식별, 변화관리계획 수립, 변화관리 교육계획 및 자료 작성

5. 전사아키텍처 정보 상시 활용

기업이 전사아키텍처 정보를 구축하여 IT업무 전반에 일상적으로 활용하는 것

e 이를 위해서는 전사아키텍처 정보체계의 지속적인 개선 체계와 전사아키텍처 관리 시스템의 구축이 선행되어야 함

6. 활용유형별 내용

① IT 기획 관리

i. 업무 프로세스 혁신: 비즈니스 변화와 정보기술 변화에 따르는 영향을 분석하여 대응하고, 조직 간의 업무 수행 범위 및 중복성 확인으로 업무 프로세스 개선 가능

ii. 정보화 계획 수립: 정보화 전략 계획 수립 시 활용할 수 있으며, 중복을 배제한 효과적인 시스템 투자계획 수립에 활용

② IT 구축 관리

i. 프로젝트 계획: 정보시스템 구축을 위한 구체적인 프로젝트 계획 수립 및 제안요청서 작성시 활용

ii. 시스템 개발: 기존 시스템 개선 및 신규시스템 개발을 위한 기준 및 참조 정보를 제공하며, 시스템 간 연계성 및 재사용 대상을 식별 할 수 있음

③ IT 운영 및 통제

i. 시스템 운영: 시스템 장애 시 전체 모습을 쉽게 파악할 수 있어 문제점을 신속하게 찾아 낼 수 있으며, 시스템 변경 영향도를 파악할 수 있어 위험 최소화 기능

ii. IT 통제: 도입되는 시스템이 전사 표준을 준수하는 지 통제함으로써 상호운용성, 유지보수 편리성 등을 확보함

7. 전사아키텍처 도입의 의미

전사아키텍처의 도입은 정보화에 대한 일시적이고 단편적인 개선이 아니라 보다 정확한 정보를 바탕으로 통합되고 일관성 있게 정보화를 계획하고, 실행하고, 검증 및 평가하는 체계를 갖추는 것이다.

8. 전사아키텍처 정보의 효과적 활용을 위한 전제 조건

① 전사아키텍처 정보 자체의 품질이 보장되어야 함

e 현행 및 목표 시스템의 상황이 아키텍처 정보에 항상 최신의 상태로 정확히 반영되어야 함

② 전사아키텍처 정보를 관리하고 적용을 통제 할 수 있는 전담 조직이 구성되고 운영되어야 함

e 이 조직은 전사아키텍처 정보에 품질과 활용도 제고를 책임지며, 필요 시 전사아키텍처 정보의 근거 자료를 제시할 수 있어야 함

③ 전사아키텍처 정보를 전사적으로 공유하고 활용할 수 있는 절차와 시스템 필요

9. 전사아키텍처와 DAP 영역

① 데이터 아키텍처 전문가의 영역은 데이터 아키텍처 전반에 관한 것으로, 광의의 데이터 아키텍처 영역과 일치함

② 광의의 데이터 아키텍처 영역은 DA 원칙, DA 정보, DA 관리 등을 포함

③ 데이터 아키텍처가 의미 있기 위해서는 아키텍처 통합성이 이루어져야 함

10. 아키텍처 통합성의 3가지 유형

① 범위 통합: 전사아키텍처 범위 전체에 대한 각 모델 내의 불일치성을 제거

② 수평 통합: 관련된 타 영역과의 불일치성을 제거

③ 수직 통합: 상위 아키텍처와 하위 아키텍처 간의 불일치성의 제거

[2] 데이터 요건 분석

1) 정보 요구 사항 개요

(1) 정보 요구 사항

1. 정보 요구 사항 정의

④ 정보 요구 사항이란 사용자가 일상적으로 수행하는 업무의 개선 사항이나, 신규 개발사항 등을 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용임

⑤ 현행 시스템 분석, 사용자 요구 사항 수집, 제안 요청서, 사업 수행 계획서 등을 이용하여 수집 가능 함

⑥ 사용자의 정보 요구 사항을 정해진 일정과 비용 범위 내에서 사용자가 원하는 시스템으로 개발하기까지는 많은 어려움이 존재 함

i. 불완전하고, 애매모호하게 정의된 정보 요구 사항

ii. 현실성을 배제한 이상적인 정보 요구 사항

iii. 특정 사용자만을 위한 정보 요구 사항

⑦ 잘못 분석되고 설계된 정보로 시스템을 개발한다면 사용자 요구사항을 만족하지 못하는 시스템이 되는, 이는 프로젝트 위험과 추가적인 비용을 지불하게 됨

2. 정보 요구 사항의 중요성

① 2004년 Standish Group 조사 결과에 의하면 전체 프로젝트의 29%만이 계획된 예산 내에서 납기를 준수하고, 원하는 기능과 요구사항을 달성했음

② 프로젝트의 18%는 완료 전 또는 사용해 보기도 전에 취소되고, 53%는 납기가 지연 되거나 예산이 늘어나거나 기능, 품질에 문제가 있다고 보고함

③ 다양화된 사용자 정보 요구 사항과 더욱 복잡해진 정보시스템의 현행을 정확하게 분석하고 이해할 수 있는 능력이 데이터 아키텍처 전문가에게 필요함

3. 정보 요구 사항 생명주기 모형

① 반복적으로 수행하여 사용자 정보 요구 사항이 누락 없이 반영되어야 함

② 정보 요구 사항 수집

e 사용자의 정보 요구 사항을 수집하는 단계

③ 정보 요구 사항 분석 및 정의

e 수집된 정보 요구 사항을 정리하고 기법을 이용하여 요구 사항을 정의하는 단계

④ 정보 요구 사항 상세화

e 정보시스템 관점에서 요구 사항에 상세하게 분석하는 단계

⑤ 정보 요구 사항 검증으로 구성 됨

e 비즈니스, 조직, 애플리케이션 관점에서 검증하는 단계

4. 정보 요구 사항 유형

① 외부 인터페이스 요건

i. 시스템의 모든 입력과 시스템으로서의 모든 출력에 관한 요건으로서 대외기관으로부터 수신 및 대외기관으로 송신하는 입출력 방식이 추가 및 변경되었을 경우와 각종 제도 및 기준 등이 변경되었을 경우에 발생하는 요건

ii. 중복성 – 기존의 동일한 형태의 인터페이스가 존재하는지 여부를 체크

iii. 표준준수 – 인터페이스와 관련된 국제표준 및 국가표준이 존재할 경우 그에 적합한 형태로 제공해야 함

iv. 관리방법 – 항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입/출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리되어야 함

② 기능 개선 요건

i. 시스템에서 입력을 받아들여 처리하고, 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건

ii. 불가변성 – 기능개선 요건이 향후에 재 변경되지 않도록 근본적인 개선 방안을 요청해야 함

iii. 범용성 – 많은 사용자가 편리하게 사용될 수 있는 요건을 우선적으로 요청해야 함

iv. 관리방법- 입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응(Overflow, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어 관리되어야 함

③ 성능 개선 요건

i. 사용자가 원하는 성능개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요 시한 등이 있음

ii. 실현가능성 – 해당 성능개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지 확인한 후 제시되어야 함

iii. 측정가능성 – 측정이 불가능한 모호한 형태로 요건이 제시되면 안됨

iv. 관리방법 – 각 기관의 서비스 특성을 고려하여 정적, 동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시적으로 관리해야 함.

④ 보안 개선 요건

i. 중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근 통제(제한 구현, 통제 구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건을 말함

ii. 불가변성 – 보안 개선 요건이 향후에 재 변경되지 않도록 근본적인 개선 방안을 요청해야 함

iii. 실현가능성 – 해당 보안 개선 요구사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시되어야 함

iv. 관리방법 – 가정 먼저 보안 관리가 필요한 정보에 대한 등급 관리가 필요하며, 해당 등급별로 접근 가능한 이용자 등급 관리가 필요하며 접근 방식에 있어서의 접근 통제 기준 및 사용 통제 기준이 제시되어야 함

(2) 정보 요구 사항 관리

1. 정의 및 관리 목적

① 정보 요구 사항을 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차

② 정보 요구 사항을 종합적으로 검토, 확인함으로써 요건에 맞는 정보시스템을 개발하여 사용자의 만족도를 높이고자 함

③ 정보 요구 사항 관리는 데이터, 애플리케이션, 비즈니스 등의 요구사항을 전부 포함하는 통합 관리 프로세스로 정립함

2. 정보 요구 사항 관리 프로세스

① 요구 사항 발송

e 사용자가 정보시스템을 활용하면서 발생하는 불편사항이나 신규 개발사항 등의 요건을 정보 요구 사항 정의서 양식에 기록하여 발송

② 요구 사항 수렴

e 정보 요구 사항 정의서의 수집, 규칙에 맞게 정확하게 정의했는지 확인하고, 처리담당자를 지정하여 이송함

③ 요구 사항 검토

e 요청된 정보 요구사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영여부를 판단

e 반영이 가능한 경우 개발물량, 협조담당자, 관련인 등 영향도 분석 실시

e 반영이 불가능한 경우 미 반영 사유와 함께 요건을 발송한 담당자에게 재 전달

④ 영향도 분석

e 신규 개발 및 변경에 따라 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등에 대한 영향도 분석 실시

⑤ 공식화

e 관련 담당자를 소집, 의견 공유, 반영 유형 결정

⑥ 반영 작업 계획 수립

e 업무영역 및 관련 담당자들과의 미팅 후 반영계획을 수립

3. 수행 조직 및 수행 업무

① 사용자

i. 변경 요청

ii. 변경 여부 확인

iii. 미결 사항에 대한 의사 결정 실시

② 담당자

i. 사용자 정보 요구 사항 접수

ii. 사용자 정보 요구 사항에 대한 기본적인 검토

iii. 반영 여부 결정을 위한 사용자와 1차 미팅

iv. 접수 요건에 대한 처리 방식 및 처리 기한 결정

v. 관련 부서별 담당자 수집 및 요건 협의 주도

vi. 사용자 정보 요구 사항 반양

vii. 테스트 및 검증

viii. 사용자 반영 결과 통보

③ 데이터아키텍처 전문가

i. 사용자 정보 요구 사항에 대한 표준/데이터베이스/애플리케이션 차원에 대한 영향도 분석 및 보고

ii. 접수된 요구 사항에 대한 표준 준수 여부 체크

iii. 영향도 분석을 통한 수정 및 변경 계획 수립

iv. 표준 제시 및 준수 여부 검토

2) 정보 요구 사항 조사

(1) 정보 요구 사항 수집

1. 관련 문서 수집

① 문서 수집 목적

i. 구현 시스템의 대상과 범위를 보다 명확하게 정의하고, 기업과 업종에 대한 충분한 이해

② 문서 수집 자료

i. 경영 계획에 대한 자료 – 중장기 경영 전략, 향후 3년에 대한 경영 계획서

ii. 전산 시스템에 대한 자료 – 현행 발행 보고서, 전산 처리 의뢰서

iii. 과거 수행한 컨설팅 보고서

iv. 전산 처리 업무 매뉴얼

v. 현업 부서 업무 자료 – 실무 교육 자료

③ 문서 수집 원칙

i. 기존에 보유하고 있는 문서를 변형하지 않고 수집, 전산 시스템에 대한 자료는 별도의 정리양식을 이용하여 작성

ii. 수집된 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표를 작성

iii. 수집된 문서들은 계획 수립 기간 문서 관리자를 지정하여 운영

iv. 활용을 위하여 문서분류 방식을 결정한 후, 일정한 장소에 보관

v. 개인별로 보관하는 것을 통제하고, 문서보안 관리에 주의

2. 사용자 면담

① 면담은 분석가가 특정 관점에서의 업무요건이나 업무절차를 조사하기 위하여 일반적으로 한 명(혹은 두 명)의 실무자와 대면하여 질의와 응답을 통해 정보를 수집하는 방법

② 프로세스와 프로시저에 대한 이해를 얻기 위한 준비 단계, 또는 워크숍 진행을 돕기 위한 준비 단계에서 유용함

③ 실무자와의 개별적인 면담은 워크숍보다 훨씬 융통성이 있으며 진행 측면에 있어서도 유연한 진행이 가능함

④ 참여자에게 적은 시간을 할당함으로써 일정 수립이 용이함

⑤ 누락된 부분이 발견되었을 때 추가적인 면담의 계획 및 준비가 쉽게 이루어질 수 있음

3. 사용자 면담 진행

① 사용자로부터 중요한 업무 내용을 수집

② 사용자들로 하여금 시스템 개발에 대한 관심과 신임을 고조시킴

③ 전문가와 대화를 통해서 필요한 정보를 수집

④ 면담 진행 방법

i. 계획 및 준비

A. 면담 주제 선정

B. 면담 진행 팀 구성

C. 면담 대상자 선정

D. 면담 일정 수립

E. 면담 준비

ii. 면담 수행

A. 면담 시작

B. 면담 주제 토의

iii. 면담 결과 분석

iv. 분석 결과 피드백

4. 면담 수행 시 고려 사항

① 면담 시간 준수

② 비밀 보장

③ 기대 수준 설정

④ 면담 범위 수준

⑤ 적절한 대상자 선정

⑥ 응답 유도

⑦ 면담 내용 문서화

⑧ 잘못된 선입견의 배제

5. 워크숍 개요 및 목적

① 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의

② 정치적이거나 개인적인 요소들의 영향을 피하고, 다양한 정보의 원천으로부터 정보의 빠른 추출이나 공유를 요하는 경우, 단순한 회의나 토론 이상의 것을 요구하는 상황 등에 사용될 수 있음

③ 서로 관련 있는 부서들을 대상으로 워크숍을 실시할 수 있도록 함

④ 주요 목적 3가지

i. 경영층 또는 현업 부서장의 공통된 의견을 도출

ii. 유사한 업무 또는 관련된 업무 등을 수행하는 부서에 대한 면담에 드는 노력을 절감

iii. 전문가들의 판단력을 이용하여 최적의 결론을 도출

6. 워크숍 준비

① 워크숍 과제선정과 계획 수립

② 참가대상자 선정

③ 참가대상자에 대한 사전 브리핑 및 교육훈련

④ 킥오프모임 수행

⑤ 워크숍 자료준비

⑥ 설비와 물품준비

⑦ 워크숍 장소선정

⑧ 워크숍 기간선정 프로그램 준비

7. 현행 업무 조사서

① 전체 부서에 대하여 동일한 기준으로 조사하는 것을 원칙으로 함

② 각 지점이나 부서마다 다르게 업무를 수행하는 경우가 발생할 수 있고, 회사 전체의 업무 수행 빈도와 데이터 수발량을 조사하기 위해서는 전수조사가 필요함

③ 동일한 업무를 수행하는 부서 혹은 지점이 여러 개인 경우에는 표본추출 또는 발췌조사로 진행

④ 양식은 단순하고 이해하기 쉬워야 하며, 양식의 작성방법과 작성된 샘플을 첨부하여 배포하는 것이 효과적임

⑤ 내용이 불충분한 경우가 발견되므로, 업무조사서를 1차 수거한 후에 반송하여 다시 작성하는 경우가 발생할 수 있음. 이러한 상황도 일정계획 수립에 반영

⑥ 사용자가 처리하고 있는 업무기능 틀을 정리된 양식으로 기록하여 향후 작업에 도움이 되도록 함

8. 현행 프로그램/데이터 관련 문서

① 향후 사용자 요구사항을 보다 세부적으로 진행하기 위한 사전단계로서 반영되어야 할 현행 시스템의 업무요건을 빠짐없이 파악하기 위한 작업임

② 현행 시스템 프로세스(프로그램)의 구조는 프로세스 계층도와 유사하게 계층적 구조로 표현하며, 이러한 현행 시스템 프로세스(프로그램) 계층도는 향후에 업무모델의 완전성을 검증하기 위한 비교자료로 활용됨

③ 현행 시스템의 데이터에 대한 분석은 현행 시스템에서 사용되는 현행 데이터 저장소의 구조를 파악함으로써 현행의 업무 프로세스에서 사용되는 데이터의 구조를 이해할 수 있음

④ 현행 데이터 저장소의 구조는 현행 시스템 데이터 목록 및 세부 내역을 분석함으로써 현행 데이터에 대한 업무 요건 및 업무 규칙, 현행 데이터저장소의 구조와 화면, 양식, 보고서 레이아웃 등을 이해할 수 있음

(2) 정보 요구 사항 정리

1. 사용자 면담 정리

① 사용자 면담 시 제공된 자료의 샘플이나 관련 문서를 체계적으로 정리 기록

② 정리가 완료되면 주요한 관점(업무흐름, 수치, 주관부서, 책임부서 등)의 내용에 대해서는 다시 한번 기록된 부분의 오류가 있는지 사용자에게 확인을 받도록 함

2. 업무 조사서 정리

회사차원에서 활용하는 업무문서 및 팀에서 사용하는 업무문서를 포함하여 전체 리스트를 파악할 수 있도록 체계적인 양식으로 정리함

3. 워크숍 정리

① 사용자 워크숍을 통해 도출된 요구사항이나 해결 과제들은 명백하고 간결한 문장으로 정리한 후 사후 대처할 수 있도록함

② 해결과제에 대해서는 별도의 ID를 부여하여 관리함

③ 워크숍 결과 정리 시에는 다음 사항을 포함함 (워크숍 목적/진행내용/ 해결과제에 대한 상태/기타 특이사항)

4. 화폐가치 산출 방법

① 최종적으로 구해진 가치가 높을수록 우선순위가 있음, 그러나 최종 순위는 산출된 수치에 의존하지 않고 고유의 상황에 따라 다르게 적용될 수 있음

② 정보 요구 사항을 전부 나열

③ 각각의 정보 요구 사항에 대하여 기업 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여

④ 각각의 정보 요구 사항에 대하여 시스템 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여

⑤ 각각의 정보 요구 사항이 다른 정보 요구 사항에 대해 얼마나 도움을 주는가를 평가하여 1점부터 5점까지의 점수를 부여

⑥ 앞서 부여한 세 가지 점수를 모두 곱함

⑦ 전체 정보 요구 사항에 대하여 앞서 계산된 점수를 더하고, 점수 합계를 100으로 하여 각각의 정보 요구 사항 가치를 퍼센트로 환산

⑧ 회사 전체의 이익에 앞에서 구한 퍼센트를 곱하여 각각의 정보 요구 사항 가치를 금액으로 환산

5. 상대적 중요도 산성 방법

① 정보 요구 사항이 업무에 기여하는 수준에 따라 1점부터 5점까지의 점수 부여

e 예를 들어 목적을 지원하면 5점, 목표를 지원하면 4점, 전략을 지원하면 3점 등의 방법으로 업무를 분류한 체계에 따라 결정

② 정보 요구 사항 대 정보 요구 사항 매트릭스를 작성하여, 각각의 정보 요구 사항이 다른 정보 요구 사항에 얼마나 관련되어 있는가를 계산

e 가장 관련이 큰 정보 요구 사항에 9점을 부여하고, 나머지 정보 요구 사항에는 이에 대한 상대 점수 부여

③ 현재 정보시스템이 각각의 정보 요구 사항을 얼마나 충족하는가에 대하여 1점에서 3점까지의 점수 부여

e 예를 들어 만족스러운 경우에는 3점, 보통인 경우에는 2점, 지원하지 않는 경우에는 1점 등의 방식으로 부여

④ 앞서 부여한 세 가지 점수에 대하여 가중치를 결정

e 예를 들어 업무 지원 정도는 50%, 다른 정보 요구 사항과의 관련도는 20%, 현행 시스템 지원 정도는 30% 등의 방법으로 정함

⑤ 가중치에 따라 앞에서 계산한 세가지 요인의 가중평균을 구하여 각각의 정보 요구 사항에 대한 중요도를 평가

(3) 정보 요구 사항 통합

1. 정보 요구 사항 목록 검토

전사 관점에서 동일한 정보 요구 사항을 여러 부서 및 사용자가 제시 했는지를 검토하기 위하여 별도의 양식으로 취합

2. 정보 요구 사항 통합/분할

① 통일 부서 내 중복 요구 사항 검토

i. 부서 내 정보 요구 사항 목록을 정렬

ii. 정보 요구 사항 제목을 기준으로 부서 내 동일 요건의 요구 사항이 존재하는지 파악

iii. 정보 요구 사항의 세부 요청 내용을 기준으로 세밀하게 중복 여부 파악

iv. 부서 내 동일 요건이 도출된 경우 관리 대상 요구 사항에 통합할 정보 요구 번호를 ‘비고’에 기입

v. 동일 부서 내 중복성을 배재한 요구 사항 목록 완성

② 서로 다른 부서간 중복 요구 사항 검토

i. 동일 부서 중복 요구 사항 검토와 동일하게 진행

ii. 분석 범위를 부서간으로 확장

③ 최종적으로 전사관점의 검토된 정보 요구 사항 목록을 작성

3) 정보 요구 사항 분석

(1) 분석 대상 정의

1. 현행 업무 분석 대상 정의

① 분석 대상 자료

i. 현행 업무 흐름도

ii. 현행 업무 설명서

iii. 현행 업무 분장 기술서

② 분석 대항 업무 영역 선정

i. 현행 업무 흐름 및 관련 데이터를 파악하여 분류기준에 따라 분석 대상 현행 업무 목록을 작성

ii. 정보 요구 사항 분석을 위한 대상으로 선정할 것인지 결정을 하고 분석 대상 업무 목록표에 표기

③ 분석 대상 현행 시스템 선정

i. 분석 대상을 선정하기 위하여 업무 영역/현행 시스템 매트릭스를 작성

2. 분석 대상 현행 시스템 관련 자료

① 현행시스템 구성도, 분석, 설계 및 개발 보고서

② 화면, 장표 및 보고서 레이아웃

③ 현행 시스템 테이블 목록 및 테이블 정의서

④ 사용자 및 운영자 지침서

⑤ 시스템 자원 및 유지보수 이력

⑥ 시스템 개선 요구사항 등

3. 수집 문서의 평가 관점

① 유용성: 문서의 활용가능성 여부

② 완전성: 문서의 내용에 누락된 부분이 없는 지의 여부

③ 정확성: 문서의 내용이 현재의 시스템과 일치하는 지의 여부

④ 유효성: 문서가 최신의 내용을 반영하고 있는 지의 여부

4. 추가적인 분석 대상

① 현행 데이터 측면의 업무 요건 혹은 업무 규칙을 h다 상세하게 분석하기 위하여 사용자 뷰(View)도 분석대상에 포함

② 사용자 뷰가 종합되어 나타나는 것이 화면, 수작업 파일, 수작업/전산 양식, 보고서 등의 레이아웃임

(2) 정보 요구 사항 상세화

1. 정보 요구 사항 상세화 개요

① 분석 산출물을 토대로 하여 정보 요구 사항을 보완

② 추가적으로 비기능적 정보 요구 사항을 포함하여 추가 보완

2. 프로세스 관점의 정보 요구 사항 상세화

① 프로세스는 실제로 업무가 수행되는 행위를 뜻함

② 프로세스는 기본 기능이 분해되면서 나타나 다시 프로세스로 분해됨

③ 업무기능은 기업의 목표달성을 위하여 지속적으로 수행되기 때문에 시작시점과 종료시점이 명확이 구분되지 않지만, 프로세스는 명확한 업무활동을 의미

④ 프로세스는 Input/Output을 동반하며, 최소 단위의 업무를 갖게 되는 기본 프로세스가 있음

3. 수행 절차

① 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서를 작성

② 도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 것과 산출되는 정보 항목을 정리하고, 산출 항목 중 기본 로직을 필요로 하는 경우 정리

③ 해당 정보 항목에 대해서 통합 및 분리 여부를 검토한 후 최종적으로 사용자의 정보요구 사항을 충족하는 정보항목 목록에 정의

4. 수행 작업 내용

① 프로세스 분해/상세화

i. 단위업무기능별 하향식으로 프로세스를 분해 및 도출

ii. 프로세스계층도 및 프로세스정의서를 작성

② 정보항목 도출 및 표준화

i. 기본프로세스별 정보항목을 정리

ii. 정보항목에 대한 표준화 정리

iii. 정보항목 목록 정의

③ 정보항목별 통합성, 분리성 여부 검토

i. 프로세스별로 관리되는 정보항목을 분류

ii. 정보항목별 동음이의, 이음동의 존재여부 파악

iii. 통합/분리여부 검토 후 최종 정보항목 목록 정의

5. 수행 작업 지침 – 프로세스 분해/상세화

① 프로세스 분해

i. 단위 업무기능으로부터 출발하여 점진적으로 수행

ii. 단위 업무기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스 만으로 구성된 업무 기능을 의미

iii. 전체 단위업무기능에 대하여 프로세스 분해 수준을 맞추어 점진적으로 분해

iv. 업무 기능계층도가 단위 업무기능 수준까지 분해되지 않았을 경우에는 단위 업무기능 수준까지 더 분해한 후 프로세스 도출

② 프로세스 분해 깊이

i. 일반적으로 3차 수준까지 분해함

ii. 기본 프로세스 수준까지 도출되는 경우가 있으며 최종적으로 기본 프로세스의 도출에 있음

iii. 초기에는 균형 잇게 분해하는 데에 주의를 기울임

iv. 업무적으로 중요한 의미를 가지는 조회용 또는 수작업 프로세스는 필요에 따라 명명규칙을 달리하여 도출함

6. 프로세스 분해/상세화

① 프로세스 명명 - 명명규칙을 준수하여 가급적 업무 용어로 유일하게 이름을 부여함

② 프로세스 계층도 - 높은 응집도(Cohesion), 낮은 결합도(Coupling)를 유지

프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려함

③ 프로세스 정의서 - 업무를 구체적으로 이해할 수 있도록 작성

7. 정보 항목 도출 및 표준화

① 기본 프로세스별로 등록, 조회, 변경, 삭제 기능을 구분하여 기술

② 기능별 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사상의 내용을 파악하여 관리하고자 하는 정보 항목을 도축

③ 도출한 정보 항목은 명명 규칙을 준수, 업무용어를 그대로 사용하며, 명사형

8. 정보 항목별 통합성 검증

④ 정보 유형별 정보 항목별로 전사 관점에서의 통합/분리여부를 검토

⑤ 동일한 정보 항목에 대해서 통합 시 다음과 같은 장점이 존재함

i. 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함

ii. 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용가능

⑥ 단, 아래와 같은 단점도 존재함

i. 통합 작업으로 인한 정보 항목의 애매모호성 존재

ii. 통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재

9. 객체지향 관점의 정보 요구 사항 상세화

① USECASE 다이어그램

i. 사용자와의 의사소통을 원활하게 진행할 수 있음

ii. 액터(Actor) – 정보 시스템과 상호 작용하는 개인, 그룹, 회사, 조직 등 정보 서비스를 받는 객체

액터의 역할을 명확하게 나타내는 이름으로 정의

iii. Usecase – 도출된 액터별로 개발 시스템에서 제공해야 하는 기능을 나타냄

사건흐름에 대한 개요를 간략하게 기술

iv. Actor와 Usecase 간의 관계

A. 확장(Extend): 다른 유즈케이스의 행동을 추가함을 나타내는 관계, 다른 유즈케이스를 선택적으로 수행되는 경우에 사용

B. 포함(include): 다른 유즈케이스를 사용함을 나타내는 관계, 다른 유즈케이스를 반드시 수행되는 경우에 사용

C. Communicates: 행위자가 어떤 유즈케이스에 참가함을 나타냄, 행위자와 유즈케이스 사이의 유일한 관계임

② USECASE 상세화

i. Usecase의 사건 흐름을 구조화하는 작업으로 모든 선택 또는 대안 흐름을 기술

ii. Usecase의 특별 정보 요구 사항을 정의, Usecase에는 관련이 있지만 사건 흐름에는 고려되지 않는 정보 요구 사항을 Usecase의 특별 요구 사항으로 정의

iii. 이러한 특별 정보 요구 사항은 비기능적인 정보 요구 사항으로 기술

iv. 사건 흐름을 기술할 때 정상적인 흐름에 대해 먼저 기술한 후, 예외 사항에 대해 사건 흐름을 기술

: Usecase에 대한 개략적인 설명, 사건 흐름, 사전.사후 조건, 비기능적인 정보 요구 사항, 주된 사건 흐름에 대체될 수 있는 대안 흐름, 예외처리 사항

③ 클래스다이어그램 작성

i. 엔티티클래스 도출

A. 유즈케이스 모형을 검토하여 엔티티 클래스를 도출하여 정의

B. 식별된 클래스에 이름을 부여하고, 간략한 설명을 기술

C. 클래스 이름은 간결하고 업무적 의미를 함축한 단수형 명사로 부여

D. 이음동의어 및 동음이의어를 고려하여 선정

E. 유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑

ii. 관계도출 및 클래스도 도출

A. 관계란 의미 있고, 관심 있는 연결을 나타내는 클래스 간의 관계임

B. 클래스간의 집단화 관계를 식별하고 명명

C. 집단화 관계란 전체적인 클래스와 부분적인 클래스의 포함관계를 표현

iii. 속성 정의

A. 클래스가 나타내는 객체의 특성을 의미

B. 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도추

C. 속성에 대한 이름을 부여하고 간략한 설명을 기술

(3) 정보 요구 사항 확인

1. 정보 요구 사항 확인 개요

사용자 및 부서로부터 접수해서 최종적으로 작성된 산출물에 대하여 정보 요구 사항을 제시한 담당자와 세부 재검토를 통하여 누락 사항 및 보완 사항을 도출하기 위한 계획을 수립하고 재검토를 실시함

2. 수행 절차

① 분석결과 도출된 산출물에 대해서 재검토 기준을 정의하고, 계획을 수립

② 재검토대상 산출물의 안전성, 정확성, 일관성, 안정성 등 다양한 측면서 실시

③ 재검토 결과 추가 및 보완 사항이 존재하는 경우 내용을 문서로 정리한 후 해당 산출물에 추가 반영여부 확인하고, 미 반영 시 사유의 타당성을 검토

3. 수행 작업 지침 - 재검토 계획 수립

① 안전성 – 사용자의 정보요구 사항이 누락됨이 없이 모두 정의되었는지 확인

② 정확성 – 사용자의 정보요구 사항이 정확히 표현되었는지의 여부

③ 일관성 – 표준화 준수 여부 확인

④ 안전성 – 추가 정보요구 사항 변경에 따른 영향도 파악

⑤ 재검토 계획서 포함 사항 – 정보요구 사항 재검토 개요 및 목적, 재검토 일자, 재검토 장소 및 시간계획, 재검토 참석 대상 및 재검토 업무, 참석대상별 재검토 세부시간 계획, 재검토 시 준비물, 재검토 후 산출물, 재검토 후 지적사항 반영계획 수립

4. 수행 작업 지침 - 재검토 실시

① 재검토 기준 및 재검토 대상 산출물을 준비, 대상자에게 배포

② 재검토 관련 장소, 시간, 준비 등 제반 준비와 역할 주지

③ 재검토 세션 이전에 재검토대상 산출물을 예습

④ 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항에 대한 정리

⑤ 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항에 대한 정리

⑥ 재검토 시 재검토 진행자는 정해진 일정 내에 마칠 수 있도록 주의

⑦ 통합성 검증을 위하여 해당 업무 영역과 관련 있는 업무영역 담당자가 참여

⑧ 진행자는 세션 별로 적절한 시간 배분 및 조정의 역할을 충실히 수행

⑨ 재검토 결과가 정리되면 해당 정보 요구 사항 별 보완 사항을 유형에 따라 보완목록에 작성

⑩ 재검토 결과의 지적 사항 외에 분석결과 산출물의 일관성 유지를 위해, 특정내용이 변경됨으로써 함께 변경되어야 할 대상도 함께 기록함

⑪ 보완 사항 반영 시 정보 요구 사항간의 일관성이 유지되도록 유의

⑫ 반영 완료 후 누락은 없는지, 잘못 반영된 사항은 없는지 전체적으로 검토

5. 수행 작업 지침 - 보완 결과 확인

① 재검토 결과, 보완 목록, 보완 사항이 반영된 정보 요구 사항 정의서 배포

② 미 반영 사유가 존재할 경우에는 미 반영 사유가 타당한지 검토

③ 미 반영 사유가 업무 규칙이나 정책의 변경을 수반하는 경우 프로젝트 기간 내에 해결 가능한 것은 개선 과제로 정리하여 해당 부서에 의뢰

6. 수행 시 고려 사항

① 일관성 있는 기준 및 명확한 일정을 수립

② 모든 참여인력이 공감대를 형성하고 재검토 작업을 수행하야 함

③ 재검토는 2번 이상을 진행하되 세션마다 재검토 기준을 명확히 하여 수행

④ 재검토 세션 진행의 효율성을 감안하여 적정한 참여대상을 선정

⑤ 세션의 집중력을 상실하거나 결론에 도달하지 못하는 경우에 주의

4) 정보 요구 검증

(1) 정보 요구 사항 상관분석 기법

1. 정보 요구 사항 개요

① 도출된 정보 유구 사항을 타 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항의 도출이 완전하게 효과적으로 이루어졌는지 파악

② 이를 기반으로 향후 안정적이고 확장 가능한 데이터 모델을 설계할 수 있음

③ 매트릭스 분석 기법 활용

④ 정보 요구 사항/ 애플리케이션의 기본프로세스, 비즈니스의 업무 기능, 조직과의 매트릭스 분석 기법을 소개

2. 정보 요구 사항의 충족도 파악을 위한 상관분석수행의 주체분류

① 요구 사항 분석가 수행

② 품질보증 팀 수행

③ 외부 감리 수행

3. 요구 사항 분석가 수행

정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관 분석을 수행

① 자체 분석에 의한 객관성 저하의 문제점이 발생 할 수 있음

② 관련 업무팀과의 의사소통이 원활하므로 원할하게 진행할 수 있음

③ 업무에 대한 이해도가 높기 때문에 상관분석을 통한 정확한 업무 분석이 가능

4. 품질보증 팀 수행

프로젝트 팀 내의 통합 검토 팀이나 품질보증 팀의 협조를 얻어 분석 수행

① 업무에 대한 이해도가 낮아 검증에 어려움이 있을 수 있음

② 전체적인 시각과 각 요건 및 팀간 인터페이스의 검증에 용이

5. 외부 감리 수행

외부 감리 인력을 이용한 상관분석을 수행

① 업무 파악의 한계가 있으나 제 3자의 시각으로 검토할 수 있음

② 내부 인력의 효과적인 지원이 없을 경우 품질이 낮은 분석 결과를 초래 할 수 있음

③ 상관분석의 객관성을 극대화 할 수 있음

6. 정보 요구/애플리케이션 상관 분석

① 정보 요구 사항을 바탕으로 도출된 정보 항목들과 애플리케이션 영역에서 도출한 기본 프로세스를 사용하여 매트릭스를 작성

② 기본프로세스의 액션(CRUD)을 빠짐 없이 작성

③ 모든 정보 요구 사항들이 기본프로세스에 의해 사용되고 있는가?

④ 모든 기본 프로세스를 수행하는데 필요한 정보 요구 사항이 도출되었는가?

7. 정보 요구 상관 분석 기법

① 매트릭스의 각 셀에는 기본프로세스가 사용하는 정보 항목에 대한 액션이 CRUD로 표현

② 복수 액션이 발생할 경우에는 C>D>U>R의 우선순위에 따라 하나만을 기록(그러나 분석기법의 활용 시 CRUD가 복수로 발생할 경우 모두 기록 할 수 있으며, 이는 분석기법을 활용하는 분석가의 매트릭스 활용 목적에 다라 선택가능)

③ 모든 정보 항목이 모든 기본프로세스에서 사용되었는지, 혹은 모든 정보 항목을 사용하고 있는지 확인

④ 정보 요구와 애플리케이션 중에서 한가지가 누락되거나 잘못 정의된 경우는 분석이 가능

⑤ 정복 항목과 기본프로세스가 모두 누락된 경우는 분석이 불가능함

⑥ 따라서, 매트릭스가 작성되기 전과 분석하는 중에도 수시로 확인해야 함

8. 정보 요구/업무 기능 상관 분석

① 일관성 확보, 품질수준 향상, 누락 및 중복된 정보요구 사항 점검

② 가치 사슬 분석의 기법을 통해 도출된 최하위 전사 업무 기능과 정보 요구 사항에 따라 도출된 정보 항목을 매트릭스에 배치

9. 정보 요구/업무 기능 상관 분석

① 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서 매핑하고, 향후 정보 항목에 대한 오너쉽 부여하여 효율적인 데이터관리

② 조직 단위명은 기업의 조직도에 나타난 순서로 입력, 만일 기업이 둘 이상의 소재지에서 운영된다면 조직단위를 분할하고 소재지 타입에 따라 클러스터링 함. 매트릭스에 소재지 타입(예: 본서, 영업소, 공장)에 의해 그룹핑된 조직 단위명을 입력

③ 조직과 정보 항목 간의 상호작용을 다음과 같이 정의

i. 정보항목의 생성, 수정, 삭제를 “C”로 표시

ii. 값의 변경 없이 정보항목을 검색만 하는 경우에는 “U”로 표시

iii. 아무 관련이 없는 것은 빈칸으로 남겨둠

(2) 추가 및 삭제 정보 요구 사항 도출

1. 애플리케이션 충족도 분석 매트릭스

① 애플리케이션 충족도 분석 매트릭스는 다음 기준에 따라 점검하며 추가되거나 삭제되어야 할 정보 요구 사항을 도출 함

② 정보 항목을 생성하는 기본프로세스가 반드시 존재해야 함

③ 정보 항목의 상태를 종료 시키는 기본프로세스가 존재해야 함

④ 생성된 정보 항목은 조회, 수정, 삭제 액션 중 하나가 발생해야 함

⑤ 하나의 정보 항목을 생성/수정/삭제하는 프로세스의 합은 7개를 초과하지 않는 것이 보통이며 초과하는 경우에는 재차 검토

⑥ 수작업 및 조회 전용으로 정의된 기본프로세스 이외의 기본프로세스는 반드시 생성, 수정, 삭제 액션 중의 하나를 수행함

2. 매트릭스 분석

① 매트릭스 분석은 추가 및 삭제되어야 할 정보요구 사항을 도출 함

② 조치 사항이 애플리케이션과 관련된 것일 경우에는 해당 팀에 전달해서 프로세스와의 일관성을 가져야 함

3. 정보 요구/업무 기능 상관분석

① 매트릭스 분석

② 정보 항목과 연관성이 없는 업무 기능의 경우, 관련 팀과의 협의 하에 업무 기능 도출의 적절성이나 관련 정보 항목을 다시 파악하여 매트릭스를 보완함

③ 정보 항목과 매핑이 없는 업무 기능의 경우, 관련 팀과의 협의하여 정보 요구 사항 보유 여부를 확인한 후 추가적인 정보 요구 사항이 있을 경우 정보 요구 조사 프로세스에 따라 정보 요구 목록에 신규로 추가함

4. 정보 요구/조직 기능 상관분석

① 매트릭스 분석

② 정보 항목의 활용도를 파악할 수 있으며, 정보 항목의 수요가 많은 경우에는 해당 정보의 물리모델링 단계에 성능/활용 측면의 모델링 기법을 적용하여 정보 활용의 효율성을 고려함

③ 정보 항목을 생성하는 조직 단위가 복수로 존재할 경우, 데이터 관리의 복잡성으로 인해 향후 문제가 발생할 수 있으므로 해당 정보 항목에 대한 데이터 관리 주체의 선정에 주의를 기울임

(3) 정보 요구 보안 및 확인

1. 정보 요구 보완

① 애플리케이션/정보 요구 사항, 업무 기능/정보 요구 사항, 조직/정보 요구 사항 매트릭스 분석을 통해 파악된 추가 및 삭제 정보 요구 사항에 대하여 담당자와 구체적인 미팅을 실시

② 일정 계획 시 설정된 반영계획에 따라 정보 요구 목록을 보완함

2. 정보 요구 확정

① 보완된 정보 요구 사항에 대하여 재차 사용자 검토를 실시하며 추가 반영사항에 대한 반영여부 의사결정을 실시하고, 최종 정보 요구 목록에 대한 확정을 실시함

② 정보 요구 목록을 통해 향후 데이터 모델과 관련된 모든 산출물을 추적할 수 있으므로 누락된 정보 항목이 없게 정확하게 작성함

[3] 데이터 표준화

1) 데이터 표준화 개요

(1) 데이터 표준화 필요성

1. 데이터 관리 현황

① 데이터가 기업의 전력적 의사결정의 핵심요소로 대두됨

② 데이터 통합 및 데이터 품질에 대한 관심이 증대되고 있음

③ 고 품질의 데이터를 현업 사용자가 활용하는데 문제점들이 있음

2. 데이터 활용상의 문제점

① 데이터의 중복 및 조직, 업무, 시스템 별 데이터 불일치 발생

i. 동일한 의미의 데이터가 다른 명칭으로 중복관리(시스템간 포함)

ii. 업무적으로 동일한 계산식이 서로 다르게 계산

② 데이터에 대한 의미 파악 지연으로 정보 제공의 적시성 결여: 신규 정보요건에 대한 대응이 어려움

③ 데이터 통합의 어려움

i. 단위 시스템 위주의 데이터 표준 사용 또는 부재

ii. EDW 등 전사 데이터 통합에 대한 동일성 파악에 어려움

④ 정보시스템 변경 및 유지보수 곤란: 요건 변경 및 신규 요건에 따른 변경 영향도 파악이 어려움

3. 데이터 문제점의 원인

① 동시 다발적인 정보시스템 개발

i. 상호 연관성에 대한 노력 부족

ii. 전체가 아닌 단위 시스템 위주의 표준

② 전사 데이터 관리 마인드 미 형성

i. 단위 시스템 개발자나 운영자가 관리

ii. 단위 시스템 위주의 관리 마인드 형성

③ 전사 데이터 관리 인력 부재: 개발 단계 및 유지보수 단계에서도 전문관리 인력의 활용 능력

④ 전사 데이터 표준 관리 도구 부재

i. 시스템의 부족한 기능

ii. 시스템이 아닌 수작업 위주의 관리

4. 데이터 관리 개선 방안

① 전사적인 데이터 표준화를 통한 개선활동이 이루어져야 함

② 데이터 표준화를 위한 기본 지침 설정

③ 데이터 규격화를 위한 기본 지침 설정

④ 전사적인 정보 공유를 위한 공통 데이터 요소 도출 및 관리

⑤ 전사 데이터 요소 및 관리 체계 구축

⑥ 정보시스템 개발 및 유지보수에 승인된 데이터 활용

⑦ 정보시스템 개발의 효율성 확보

5. 데이터 표준화 기대효과

① 현업 사용자 및 정보시스템 담당자의 정확한 데이터 사용

② 올바른 의사소통으로 인한 기업 경쟁력 확보

③ 명칭의 통일로 인한 명확한 의사소통의 증대

: 동일 데이터에 대한 동일명칭으로 신속한 의사소통 가능, 다양한 계층간 정확한 의사소통 가능

④ 필요한 데이터의 소재 파악에 소요되는 시간 및 노력 감소: 원하는 데이터 의미가 정확해져 적시에 제공가능

⑤ 일관된 데이터 형식 및 규칙의 적용으로 인한 데이터 품질 향상

: 데이터의 입력 오류 방지를 통한 품질 확보, 표준에 근거하여 데이터 사용 오류 방지

⑥ 정보시스템간 데이터 인터페이스 시 변환, 정제 비용 감소

: 타 시스템간 동일 데이터에 대한 무변환 사용, 소스부터 타깃까지의 동일한 데이터 값 유지 가능

(2) 데이터 표준 개념

1. 데이터 표준화 정의

① 시스템 별 산재해 있는 데이터 정보요소에 대한 전사적 적용 원칙을 말함

② 데이터 정보요소: 데이터 명칭/ 정의/ 형식/ 규칙

2. 데이터 명칭

① 기업 내 데이터를 유일하게 구별해 주는 이름

② 동의이의어 및 이음동의어에 대한 조정을 필요로 함

③ 일반적인 원칙에 적합해야 함

i. 유일성

A. 개념을 유일하게 구분해 주는 이름이어야 함

B. 모든 사용자들이 통일된 명칭을 사용할 수 있도록 해야 함

ii. 업무적 관점의 보편성

iii. 현업사용자들이 업무적으로 가장 많이 사용하는 명칭을 사용

iv. 현업부서에서 작성되는 보고서 용어도 명칭으로 사용 가능

v. 의미 전달의 충분성

A. 명칭만으로 어떤 데이터의 성격인지를 충분히 파악할 수 있어야 함

B. 사용자의 해석에 따라 달라질 수 있는 이름은 세분화 함

3. 데이터 정의

① 해당 데이터가 의미하는 범위와 자격요건을 규정함

② 사용자가 이해할 수 있도록 업무적 관점에서 명시

③ 데이터 명칭의 부수적인 정보를 사용자에게 전달

④ 데이터 정의 기술 시 고려사항

i. 가능한 상세하게 제 3자도 이해할 수 있도록 기술

ii. 서술식으로 의미 전달이 어려울 경우 실 발생 데이터 값을 예시로 기술

iii. 데이터 명칭에 조사만을 활용한 정의는 지양

iv. 전문적인 용어 사용도 지양

4. 데이터 형식

① 데이터 표현 형태의 정의를 통해 데이터 입력 오류/통제 위험을 최소화 하기 위함

② 데이터 형식 정의 시 고려요소

i. 도메인을 정의하여 표준을 적용

ii. 성격이 유사한 데이터 간의 데이터 형식을 통일

iii. 가능한 여유 있게 정의함

iv. 특수 데이터 타입(CLOB, Long Raw) 등은 가급적 사용 자제

③ 데이터 형식 구성요소

i. 데이터 타입: Numeric. Text, Date, Char, Timestamp 등

ii. 데이터 길이 및 소수점 자리

5. 데이터 규칙

① 발생 가능한 데이터 값을 사전에 정의함

② 데이터의 정합성 및 완전성을 향상 할 수 있음

③ 데이터 규칙 구성요소

i. 기본값: 사용자가 화면이나 프로그램으로부터 어떤 입력 값도 없는 경우 데이터 타입에 따라 미리 지정된 기본값이 입력될 수 있도록 함

ii. 허용 값; 업무 규칙과 일관성을 갖도록 입력이 가능한 데이터 값을 제한하는 것

iii. 허용 범위: 업무규칙과 일관성을 갖도록 입력이 가능한 데이터 값을 범위로 제한하는 것

6. 데이터 표준화 구성요소

① 데이터 표준: 표준용어, 표준단어, 표준도메인, 표준코드

② 데이터 관리 조직: 데이터 관리자 주요 역할, 세부 역할, 역할별 비료

③ 데이터 표준화 절차: 프로세스 절차 및 절차 별 활동

7. 데이터 표준

① 데이터 모델 및 데이터베이스에서 정의할 수 있는 오브젝트를 대상으로 수행

② 데이터베이스 구성요소에 대한 표준화는 타 과목에서 상세히 기술

③ 데이터 표준을 정의해야 할 요소

8. 표준 용어

① 업무적으로 사용하는 용어에 대한 표준을 정의하는 행위

② 용어 사용에 있어 혼란을 방지

③ 원활한 의사소통을 촉진

i. 업무적 용어: 현업 사용자가 주로 사용하는 용어, 보고서나 업무 매뉴얼 상에서 많이 사용

ii. 기술적 용어

A. 일반적으로 정보시스템에서 주로 많이 사용하는 용어

B. 데이터베이스의 특성을 인해 일부 함축되어 사용

C. 업무적 용어를 정보시스템에 사용하기 위해 기술적 용어로 변환

D. 업무적 용어와 기술적 용어의 갭이 발생

9. 표준 단어

① 표준 용어를 구성하고 잇는 최소 단위

② 표준 용어에 대한 한글명과 영문명을 일관되게 정의 할 수 있음

③ 동일한 개념을 의미하는 용어의 생성을 에방

④ 표준 용어의 영문명 작성 기준에 활용

10. 표준 도메인

① 컬럼에 대한 성격을 그룹핑한 개념임

② 동일한 성격은 일관된 타입과 길이로 관리할 수 있음

③ 변경에 대한 일관되고 용이한 대응 가능

④ 도메인의 일반적인 분류 예: 문자형/숫자형/일자형/시간형

⑤ 추가적인 세부 분류: 명,설명,내용/ ID/ 금액(원금, 이자, 수수료 등)/ 률/ 수량 등

11. 표준 코드

① 특정 도메인이 미리 정의된 유형

② 적용할 데이터 값을 정의해야 함

③ 코드 명칭에 대한 정의를 포함해야 함

④ 중복되지 않게 정의 해야 함

12. 기타 데이터 표준 관련 요소

① 주제 영역

② 관계명

③ 데이터베이스 스키마

④ 테이블 스페이스

⑤ 인덱스

⑥ 컨스트레인트 등

13. 데이터 표준 관리 조직

① 표준을 수립하고, 준수하고, 체크하기 위한 역할의 필요성 증대

② 데이터 관리자의 역할이 중요해짐

③ 데이터에 대한 정의, 체계화, 감독 및 보안

④ 데이터에 대한 총괄 관리

⑤ 정보 활용에 대한 가이드 제시

14. 데이터 관리자(DA) 역할

① 관리대상: 데이터 요구사항을 반영한 데이터 모델 및 각종 표준

② 주 업무: 업무에 필요한 데이터의 메타데이터를 정의하고, 신규 또는 변경된 요구 사항을 신속하게 데이터 모델에 반영

③ 품질수준확보: 데이터 표준의 관리 및 적용을 통해 품질 수준을 확보

④ 전문기술: 담당 업무분야에 대한 업무 지식과 데이터 모델링에 대한 전문성이 필요

15. 데이터베이스 관리자(DBA) 역할

① 관리대상: 데이터 모델을 특정 데이터베이스 제품의 특성에 맞추어 구출한 데이터베이스

② 주 업무: 요구되는 성능 수준을 발휘하면서 안정적으로 운영되도록 데이터베이스를 관리

③ 품질수준확보 데이터의 정합성 관리를 통해 데이터 품질 수준을 확보

④ 전문기술: 데이터 모델에 대한 해독능력 및 특정 데이터베이스 제품에 대한 전문지식이 필요

16. 데이터 표준화 절차

⑤ 데이터 표준화 요구사항 수집

i. 개별 시스템 데이터 표준 수집

ii. 데이터 표준화 요구사항 수지

iii. 표준화 현황 진단

⑥ 데이터 표준 정의

i. 표준화 원칙

ii. 데이터 표준 정의: 표준용어, 표준단어, 표준도메인, 코드, 기타표준

⑦ 데이터 표준 확정

i. 데이터 표준 검토 및 확정

ii. 데이터 표준 공표

⑧ 데이터 표준 관리

i. 데이터 표준 이행

ii. 데이터 표준 관리 절차 수립: 데이터 표준 적용, 변경, 준수검사 절차

(3) 데이터 표준 관리 도구

1. 데이터 표준 관리 기능

① 데이터 표준을 정의, 조회, 기 정의된 표준이 잘 준수되도록 지원

② 관리 단어 – 전사 단어 사전 및 금칙어

③ 용어관리 – 용어 사전

④ 도메인관리 – 도메인 사전

⑤ 표준코드관리 – 전사표준코드. 코드 변환 매핑

⑥ 멀티표준관리 – 멀티 표준

2. 데이터 구조 관리 기능

① 데이터 모델의 구조를 관리, 소스시스템으로부터 DB스키마를 레파지토리에 관리하기 위한 기능 지원

② ER모델구조관리 – 모델, 테이블의 구조 정보

③ DB스키마관리 – 다양한 DBMS 지원 및 DB 스키마 로드

④ 가변속성관리 – 모델의 사용자 속성을 자동 생성

⑤ 이력관리 – 이력관리

⑥ 모델비교관리 – 충실도 및 준수도 검사

3. 프로세스 관리 기능

① 표준에 대한 신규 및 변경, 테이블에 대한 신규 및 변경을 요청 및 승인하는 프로세스 기능

② 표준 등록 –표준요청 프로세스 지원

③ 모델 등록 – 모델 등록 요청 프로세스 지원

4. 데이터 표준 관리 시스템 도입 시 고려사항

① 확장성

i. 다양한 시스템 및 RDBMS의 정보 수집

ii. OLAP툴 등의 다양한 데이터 구조 정보 추출 가능성

② 유연성

i. 데이터 표준을 전사적으로 일시에 적용하기는 곤란

ii. 단계적 적용을 위한 여러 개의 통합표준을 사용할 수 있는 복수 표준 관리

iii. 한글명 및 영문명의 표현방식, 표준의 변경 용이성 검토

③ 편의성

i. 한글명의 영문명 자동변환

ii. 표준검증의 주기적인 작업 수행 기능

iii. 메타 정보 수집 시 import 수작업 최소화

iv. 사용자 편의성 검토

2) 데이터 표준 수립

(1) 데이터 표준화 원칙 정의

1. 데이터 표준화 요구 사항 수집

① 인터뷰 및 설문조사 등을 토하여 수집

② 전사 데이터 표준 대상 후보 식별, 개선점 도출

③ 영역 간의 인터페이스 부분에서 발생하는 불편사항 및 개선사항 파악

④ 다른 사람의 시각에서 필요성을 검토하고 조사

2. 현행 데이터 표준 원칙 분석

① 현 정보시스템 개발지침 문서 및 데이터 표준의 확보

i. 현행 정보시스템을 개발할 당시 작성하고 적용되었던 개발지침 문서 및 데이터 표준을 수집

ii. 데이터 표준 개발지침 문서로는 각종 오브젝트 (테이블, 컬럼 등) 에 대한 명명 규칙

iii. 또한 실제 정의된 데이터 표준에 대한 검토를 통해서도 각 데이터 표준 대상 별 관리항목 파악 가능

② 현행 정보시스템 모델의 분석

i. 현 데이터모델 또는 데이터베이스 스키마의 오브젝트 정의 패턴 분석

ii. 단위 시스템 별 적용 표준이 상이하여 분석의 한계점 존재

③ 데이터 표준 원칙 사용현황 분석

i. 수집된 데이터 표준 원칙 자료를 토대로 현행 정보시스템에서 적용하고 있는 데이터 표준 대상 및 관리항목 도출

ii. 각 데이터 표준 대상 별 어떠한 정보시스템에 적용하고 있는지

iii. 어떠한 관리항목을 관리 하는지, 어떻게 상이하게 관리 되고 있는지에 대한 조사

iv. 향후 전사 데이터 표준 대상에 대한 개선점 정리

3. 데이터 표준 개선 방안 정의

① 현행 데이터 표준 사용 현황 명세서와 표준화 요구사항 정의서를 기본으로 데이터표준 대상별 문제점 및 개선방안을 정리

② 문제점 및 개선방안 도출 시 반드시 전사적인 관점에서 접근

③ 기존에 수립된 데이터 관리 정책에 부합되는지 확인

4. 데이터 표준 원칙 수립

데이터 표준 기본 원칙 정의: 데이터 표준 개선방안을 참고로 전사적으로 적용할 기본원칙을 수립

5. 데이터 표준 지침의 기본 구성

① 개요: 데이터 표준화 미 데이터 표준 지침에 대한 목적

② 데이터 표준화 관련자의 역할과 책임

i. 데이터 표준화와 관련된 사용자 정의, 역할 및 책임 규정

ii. 일반적인 관련자는 전사 데이터 관리자, 모델러 등

③ 데이터 표준 관리 절차

i. 데이터 표준과 관련된 일련의 작업 프로세스를 규정

ii. 각 프로세스 별로 데이터 표준화 관련자들의 역할 기술

iii. 데이터 표준 정의, 데이터 표준 변경, 데이터 표준 준수 프로세스 등이 포함

④ 데이터표준 기본 원칙: 데이터 표준 대상에 대해 일반적으로 적용되는 기본 원칙 정의

6. 주요 데이터 표준 대상 별 지침의 일반적인 구성

① 표준 단어

i. 한글명 및 영문명에 대한 알파벳, 한글, 숫자, 특수 문자, 전각/반각 등의 허용 여부

ii. 대소문자 사용 규칙

iii. 한글명, 영문명에 대한 허용길이

iv. 합성어 정의에 대한 지침

v. 동음이의어/이음동의어 허용 여부 및 처리 방안

② 표준 용어

i. 데이터 명칭에 대한 구조체계

ii. 한글명, 영문명에 대한 허용 길이

iii. 용어를 테이블이나 컬럼명으로 사용할 경우 준수해야 할 특이한 명명 규칙

iv. 용어를 컬럼명으로 사용할 경우 데이터 형식 표준화에 대한 기준 및 표준 도메인 적용 여부

③ 표준 도메인: 데이터 형식 표준화에 대한 기준

④ 표준 코드

i. 데이터 명칭에 대한 구조체계 및 명명에 대한 기준

ii. 데이터 형식 표준화에 대한 기준

iii. 코드번호 체게 정의에 대한 규칙

7. 데이터 표준 개발 지침 작성 시 유의사항

① 단위 정보시스템의 영역을 벗어나 다른 정보시스템에서도 적용이 가능하도록 범용성을 고려하여 정의

② DBMS마다 허용하는 테이블 및 컬럼의 물리명 길이가 상이함

③ 용어에 대한 영문명의 허용길이에 대한 지침 정의시 적용대상 DBMS를 고려

④ 별도로 영문 축약명을 추가로 정의하거나 뷰를 사용하는 등 다른 대안을 마련

⑤ 표준용어 또는 표준 도메인에 서로 다른 DBMS에 적용함

(2) 데이터 표준 정의

1. 표준 단어 사전 정의

① 기존 데이터 모델 및 용어집을 통해 사용되고 있는 모든 단어 추출

② 단어 종류와 유형을 분류하고 업무정의 및 용도를 고려하여 표준단어 정의

③ 표준화 원칙을 참고하여 영문명과 영문 약어명 정의

④ 표준 단어 사전

i. 일반적으로 단어란 문법상 일정한 뜻과 구실을 가지는 말의 최소 단위

ii. 서로 다른 의미로 사용하는 경우, 하나의 단어에 다양한 의미를 부여하여 사용하는 등의 문제 방지

⑤ 표준 단어 사전 관리 기준

i. 표준성: 정보시스템이나 일반적인 업무에서 사용되는 단어 중 추출

ii. 일반성: 일상적으로 사용하고 있는 사전적 의미의 단어와 의미상 같아야 함

iii. 대표성 동의어를 가질 수 있으며 표준 단어로 선언된 단어는 비슷한 의미의 동의어들을 대표할 수 있어야 함

2. 표준 단어 작성 형식

① 표준 단어는 전사적으로 관리하고 있는 엔티티와 속성을 개별 단위로 하여 추출

② 추출된 단어는 동음이의어와 이음동의어를 정비한 후 논리명을 기준으로 물리명, 유사 용어까지 함께 정리

③ 표준 단어사전에는 개별 단어 외에도 동의어, 유의어, 반의어 등과 같은 단어 간의 구조도 함께 정의

3. 표준 단어 정의 시 고려 사항

① 최소 단위를 기준으로 하되 사용 빈도가 높은 단어의 조합 또는 단어의 조합이 하나의 고유한 의미를 가지는 경우 표준 단어로 정의하는 것이 유리할 수 있음

② DBMS의 특성을 감안하여 표준 단어의 영문명은 알파벳으로 정의

③ 동음이의어가 많기 때문에 사용빈도가 높은 것을 표준 단어로, 사용빈도가 낮은 것은 다른 단어와 조합하여 표준 단어로 정의

④ 접두어, 접미어와 같은 한자리 단어에 대한 기준 고민

i. 표준에 포함하여 개별단어로 정의

ii. 표준에서 제외하고 사용하는 단어와 조합으로 합성단어로 정의

4. 표준 도메인 사전 정의

① 업무적인 용도, 데이터의 물리적인 특성 등을 고려 도메인 분류

② 분류된 도메인 별 데이터 타입 부여

③ 코드성, 숫자, 날짜, 문자 도메인 등

④ 표준 도메인 사전

i. 유사한 유형의 데이터를 그룹화하여 데이터의 유형과 길이를 정의한 것

ii. 도메인은 여러 개의 하위 도메인, 하나의 도메인이 여러 개의 도메인에 중복적으로 사용될 수 있음

⑤ 표준 도메인 관리 기준

i. 표준성: 전사적으로 표준화 될 수 있도록 정의 (예: 계좌번호)

ii. 유일성: 같은 내용의 도메인이 서로 다른 형태로 정의 되지 않아야 함

iii. 업무지향성: 일반화하여 정의하기 보다는 업무의 특성을 충분히 반영

5. 표준 도메인 작성 형식

① 대부분의 속성은 도메인에 할당되어야 함

② 하나 이상의 도메인에 복수로 할당되지 않아야 함

③ 속성과 도메인은 상호 매핑하여 관리해야 함

④ 새로운 속성이 추가될 경우 해당 속성의 도메인을 선정, 등록해야 함

⑤ 도메인의 삭제 시 영향분석을 실시

6. 표준 도메인 정의

표준 도메인을 정의하기 위한 일반적인 절차

7. 현재 정보용어 분석

① 데이터 모델 또는 컬럼 정의서를 이용 데이터 타입 정보 수집

② 한글명, 데이터타입, 길이별로 리스트를 작성 함

③ 동일 용어를 유사한 그룹으로 그룹핑 함

④ 신규 정의된 표준용어와 체크

8. 표준 도메인 정의

① 그룹핑된 유사 속성 용어의 의미에 따라 표준 도메인명을 정의

② 도메인별로 데이터 타입 및 길의를 정의 함

③ 가급적이라면 업무적으로 의미가 있는 도메인명을 부여 함

④ 기존 데이터와의 호환성 및 범용성을 위하여 가장 큰 데이터 타입 길이를 표준으로 정의할 수 있도록 함

9. 표준 도메인 정의 시 고려사항

① 모든 컬럼을 포함하기 위한 도메인 정의 여부

i. 현실에 존재하는 모든 컬럼에 도메인을 적용할 경우 도메인이 많아지고 표준 도메인의 의미가 퇴색할 수 있음

ii. 일부 예외적으로 정의할 경우 예외규칙을 정하기 어려움

② DBMS별 물리적 특성을 고려하여야 함

10. 표준 코드 정의

① 수집된 용어로부터 코드를 선별하여 현 코드의 코드값을 조사

② 현 코드를 바탕으로 통합 요구사항과 필요성에 따라 대상을 선정

③ 신규 표준코드를 정의하고 현 코드와 매핑 설계를 실시

④ 오너쉽을 부여하여 향후 해당 표준 코드에 대한 관리 가능

⑤ 표준 코드: 표준 코드에는 각 산업별로 법적, 제도적으로 부여하여 공통적으로 사용되는 코드 뿐만 아니라 기업 내부에서 정의하여 사용하는 코드도 대상임

⑥ 표준 코드 관리 기준

i. 재사용성: 표준화 기구나 정부, 공공기관에서 정의한 코드는 인정

ii. 일관성; 업무 범위 내에서 가능한 한 유일하게 정의

iii. 정보 분석성: 데이터는 가능한 코드화하여 관리

11. 표준 코드 작성 형식

① 전사적으로 사용하고 있는 코드를 추출 및 조사

② 동일한 값을 가지는 코드는 통합 작업 수행

③ 사용자 임의로 코드 체계를 생성하거나 수정하지 않도록 함

12. 표준 코드 정의 – 현행 코드 수집

① 단독 코드 테이블

i. 하나의 코드를 하나의 테이블에서 관리하는 형태

ii. 코드번호, 코드값 외에 부가 정보들을 관리 추가적으로 관리함

② 통합 코드 테이블

i. 하나의 통합관리 테이블에서 관리하는 형태

ii. 코드유형번호, 코드명, 코드구조, 코드번호, 코드값과 추가적인 생성일자, 폐지일자, 오너쉽 속성 등이 있음

③ 애플리케이션 정의

i. 애플리케이션에서 정의하여 관리하는 형태

ii. 사용자 인터페이스를 확인

iii. 실 발생 코드 값을 정리하여 수집 – 시간 및 노력이 많이 소요됨

13. 현행 코드 상세 분석

① 동일하거나 통합이 가능한 코드 들을 식별

② 코드값이 일치하는 동일한 코드 인스턴스를 가지는 코드 분류

③ 해당 코드들의 모든 코드 인스턴스를 확인하고 비교

④ 통합 가능한 코드 및 기존코드와의 분리 등을 검토

14. 표준 코드 정의

① 정련된 코드 인스턴스 통합 및 세분화홤

② 가능한 현행 코드 인스턴스를 그대로 유지하며 통합작업

③ 새로운 코드를 부여함으로써 표준코드를 생성하기도 함

15. 표준 코드 활용

① 특정 코드의 한정된 범위를 사용하는 경우 파생된 코드를 정의함

② 파생 코드도 표준 코드에 정의되어 있어야 함

16. 표준 코드 정의 시 고려사항

① 향후 확장성을 고려하여 정의

② 코드값이 변경되는 경우 삭제하는 대신 사용중지 상태로 관리하고 신규로 정의

17. 표준 용어 사전 정의

① 단어, 도메인, 코드 표준이 정의되면 이를 바탕으로 표준 용어를 구성함

② 표준 용어 적용이 업무적으로나 IT적으로 무리가 없는지 검토

③ 누락된 단어 및 도메인, 코드 등이 없는지를 확인하고 추가 보완 작업을 수행 함

④ 타 표준 구성요소와의 관계

18. 표준 용어 사전 관리 기준

① 표준성:

i. 같은 기업 내부라도 업무별로 동일한 의미를 서로 다른 용어를 사용하여 표현하는 경우가 매우 많음

ii. 표준 용어사전은 용어의 표준화를 통해 용어 사용의 차이에 따라 발생되는 전사 차원의 혼란을 최소화 할 수 있음

② 일반성:

i. 일반적으로 이해하기 힘들어나 의미상에 혼란을 초래하지 않도록 함

ii. 부적절한 경우 다른 용어로 대체 함

iii. 임의적으로 생성되는 새로운 용어를 자제해야 함

③ 업무지향성:

i. 업무 범위 내에서 약어나 별도로 정의하여 사용할 수 있음

ii. 단 지나친 약어의 사용은 업무에 대한 이해력이 감소할 수 있음

19. 표준 용어 사전 작성 형식

① 테이블과 컬럼을 구별하여 이용할 수 있도록 해야 함

② 논리명과 물리명, 용어 범위 및 자격 형식 등이 설명되어야 함

20. 현행 용어에 대한 표준 단어 도출 및 표준 용어 정의

① 표준 용어의 도출은 단어 수준의 표준화를 통해 이루어 짐

② 현행 용어를 분할하여 구성 단어를 도출 함

③ 해당 단어와 관련된 표준 단어를 찾음

④ 현행 구성 단어에 대한 표준 단어를 조합하여 표준 용어 생성

21. 표준 단어에 대한 도메인/코드 정의

① 표준 단어에 대한 도메인 정의

② 표준 도메인을 표준 용어에 적용

22. 표준 용어 정의 시 고려사항

① 데이터 표준 원칙에서 정의한 한글명 및 영문명의 허용길이를 넘지 않도록 함

② 허용길이가 오버하는 경우: 한글 명 변경/ 표준 단어의 조합으로 신규 표준단어를 생성

(3) 데이터 표준 확정

1. 데이터 표준 검토 계획 수립

① 데이터 표준 검토 대상: 표준 단어 사전/ 표준 도메인 사전/ 표준 코드 사전/ 표준 용어 사전

② 데이터 표준 검토 절차

i. 검토 기준 및 검토 대상 산출물 준비

ii. 검토 대상자에게 배포 및 장소, 시간, 준비, 장비 등 제반 준비 수행

iii. 검토 담당자 별로 수행해야 할 역할 인지

iv. 도출된 이슈에 대한 목록으로 정리

v. 세션별로 검토결과를 정리

2. 데이터 표준에 대한 주요 검토 포인트

① 유일성: 각 데이터 표준이 물리적으로나 의미론적으로나 유일한지 확인

② 완전성: 표준 대상별 필수입력 사항들이 전부 정의 되었는지 확인

③ 정확성: 각 데이터 표준 대상별 입력사항이 충실히 입력 되었는지 확인

④ 범용성: 정의한 데이터 표준이 복수 정보시스템에서 적용이 가능한지 확인

3. 데이터 표준 공표

① 확정된 데이터 표준을 배포하여 전사 시스템에 적용 가능하도록 하며, 관련 내역에 대한 이해 및 적용을 위한 교육 작업을 수행함

② 데이터 표준 배포

i. 데이터 표준 관리구도에 등록

ii. 모든 사용자가 데이터 표준을 조회할 수 있도록 조치

iii. 정보시스템 관련자들이 데이터 표준에 준하여 이행할 것을 공지

③ 데이터 표준 교육

i. 데이터 표준에 대한 이해 및 효과적인 적용을 목적으로 함

ii. 사용자 및 운영자에 대한 교육 훈련계획을 수립

iii. 데이터 표준 지침 및 관련 교육교재를 작성하고 교육을 수행

3) 데이터 표준 관리

(1) 데이터 표준 관리

1. 데이터 표준 관리 개요

① 표준화 작업 후 데이터 표준 정의단계에서 수립된 데이터 표준에 근거하여 관리 프로세스를 정립하고 표준이 관리되도록 해야함

② 세부적인 개념과 절차는 별도의 과목에서 다루며 본 과목에서는 전체적인 개념과 절차만을 다룸

③ 데이터 표준 관리 프로세스 유형

i. 정의된 데이터 표준이 개발과정이나 운영과정에서 발생하는 데이터 표준의 신규요건이 발생한 경우 이를 처리하기 위한 프로세스

ii. 데이터 표준이 변경 또는 삭제되는 경우, 관련 데이터 표준화 요소와 데이터 모델, 데이터베이스, 관련 프로그램까지 영향도를 분석할 수 있는 절차와 이를 처리하기 위한 프로세스

iii. 데이터 표준을 잘 준수하고 있는지 수시로 체크하고 확인할 수 있는 프로세스

(2) 데이터 표준 관리 프로세스

1. Task

① 표준 신규 및 변경

i. 업무담당자는 데이터 관리자에게 표준단어, 표준용어, 표준도메인 등 데이터 표준대상을 신규 또는 변경 요청함

ii. 표준용어를 신규 또는 변경 시 표준용어를 구성하는 표준단어 또는 표준 도메인이 존재하지 않은 경우에는 해당 표준 단어 또는 표준 도메인을 선행 신규 요청을 해야 함.

② 표준준수 검토

i. 데이터관리자는 요청된 사항에 대한 표준 준수여부를 검토

ii. 검토결과를 업무담당자에게 피드백하여 재조정 하는 절차로 진행

[4] 데이터 모델링

1) 데이터 모델링 이해

(1) 데이터 모델링 개요

1. DBMS의 분류

① 계층형(Hierarchical) DBMS

② 네트워크형(Network) DBMS

③ 관계형(Relational) DBMS

2. 데이터 모델링의 정의

① 복잡한 현실세계를 단순화시켜 표현하는 것

② 모델이란 사물이나 사건에 관한 양상이나 관점을 관계된 사람이나 그룹을 위하여 명확하게 하는 것

③ 조직내의 실체, 사건, 활동 및 그들 관계에 관한 자료를 추상적으로 기술한 것

④ 비즈니스 조직과 IT 조직 간 통영사의 역할 수행

⑤ 데이터 모델링 이유: 낮은 비용/ 실험 가능/ 이식성

3. 데이터 모델링이 제공하는 것

① 모델은 시스템을 현재 또는 원하는 모습으로 가시화 하도록 도와준다

② 모델은 시스템의 구조와 행동을 명세화 할 수 있게 한다

③ 모델은 시스템을 구축하는 틀을 제공한다

④ 모델은 우리가 결정한 것을 문서화한다

⑤ 모델은 한 영역에 집중하기 위해 다른 영역의 세부사항은 숨기는 다양한 관점을 제공한다

⑥ 모델은 특정 목표에 따라 다양한 상세 수준을 제공한다

4. 데이터 모델링의 특징

① 논리적 데이터 모델링은 Data-driven 방식을 따른다

② 비즈니스 정보 요구 사항의 종합적인 이해를 하는데 도움이 된다

③ 설계 전 단계에 걸쳐 설계자, 개발자, 사용자 사이에 효과적인 의사 소통의 수단을 제공한다

④ 정확하고, 일관성이 있으며, 공유 가능하고, 유연성을 갖는 데이터베이스 설계의 기초를 제공한다

5. 효과적인 데이터 모델링을 위한 지침

① 데이터 모델링은 비즈니스의 근본적인 속성을 찾아내는 작업

② 데이터 모델링은 ERD라는 결과물을 작도하려는 작도법이 아니다

③ 데이터 모델링은 테이블과 컬럼을 디자인하는 수준이어서는 곤란이나 (작품, 창조적)

6. 관계형 모델 이론 정의

① 관계형 모델은 업무에서 사용되는 데이터를 인식, 구성, 조작하는 정연하고도 직관적인 방법이다

② 즉, 관계형 모델은 데이터가 사용자에게 어떻게 비쳐지며, 사용자가 데이터에 어떻게 조작을 하며, 데이터가 처리 될 때 어떻게 유지되어야 하는가에 대한 토대이다

③ 무엇보다도 중요한 것은 관계형 모델이 사용자 관점에서 본 데이터를 정이 하는 지적인 개념이라는 사실이다.

7. 관계형 모델 이론

① 데이터 구조(Data Structure): 사용자가 데이터를 인식하는 2차원의 관계 테이블

② 데이터 조작(Data Manipulation): 사용자가 관계테이블에 행하는 일련의 처리형태

③ 데이터 무결성(Data Integrity): 관계테이블에 존재하는 데이터의 정확성과 일관성을 유지하기 위한 업무규칙

8. 객체관계형 데이터베이스(ORDBMS)

① 관계형 모델과 객체 지향형 모델의 통합형

② 기존 SQL에 객체지향개념을 확장한 SQL3표준화 작업 중 데이터와 프로세스를 함께 모델링

③ 현재 다양한 구현방법이 혼재되어 있음

④ UniSQL, Informix, Oracle, IBM, CA 등이 지원

9. 데이터 구조 특징

① 6가지 특성을 가진 행(Row)과 열(Column)로 구성된 2차원의 관계테이블로 표현

② 각 열은 하나의 값만을 가진다

③ 각 열은 동일한 성격의 값을 가진다

④ 각 행은 일련의 열의 값에 의해 유일하게 식별된다.

⑤ 열의 순서는 의미가 없다

⑥ 행의 순서는 의미가 없다

⑦ 각 열은 유일한 이름을 가진다

10. 데이터 조작

① SET 처리(Not one record at a time)

② 관계 연산자: 조회

i. Select(or restrict): 열에 의거한 행의 subset

ii. Project: 열의 subset

iii. Product: 두 관계 테이블간 행의 조합을 묶음

iv. Join: 열의 기준에 의거하여 각 행을 수평적으로 묶음

v. Union: 중복을 없이하여 각 행을 수직적으로 묶음

vi. Intersection: 관계 테이블간의 공통된 행

vii. Difference: 하나의 관계 테이블에만 있는 행

viii. Division: 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열

③ 처리 연산자: 관계 테이블의 내용에 변화

i. Insert: 행의 입력

ii. Update: 행의 수정

iii. Delete: 행의 삭제

11. 데이터 무결성

① 무결성: 업무 규칙에 따라 데이터의 일관성과 정확성을 유지하는 것

② 실체 무결성 규칙(Entity Integrity Rule)

주식별자(특정 행을 유일하게 인식하는 하나 이상의 열)는 null 값을 포함하지 않는다

③ 참조 무결성 규칙(Reference Integrity Rule)

관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주식별자 값이 존재해야 한다

④ 영역 무결성 규칙(Domain Integrity Rule)

테이블 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용 값, 기본값, 유일성, null 여부 등에 관한 제한이다.

12. 입력 규칙(Insert Rule)

① Dependent: 대응되는 부모 실체에 instance가 있는 경우에만 자식 실체에 입력을 허용

② Automatic: 자식 실체 instance의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 이를 자동 생성

③ Nullify: 자식 실체 instance의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 foreign key를 null 값으로 처리

④ Default: 자식 실체 instance의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 foreign key를 지정된 기본값으로 처리

⑤ Customized: 특정한 검증조건이 만족되는 경우에만 자식 실체 instance의 입력을 허용

⑥ No Effect: 자식 실체 instance의 입력을 조건 없이 허용

13. 삭제 규칙(Delete Rule)

① Restrict: 대응되는 자식 실체에 instance가 없는 경우에만 부모 실체 instance 삭제를 허용

② Cascade: 부모 실체 instance의 삭제를 항상 허용하고, 대응되는 자식 실체의 instance를 자동삭제

③ Nullify: 부모 실체 instance의 삭제를 항상 허용하고, 대응되는 자식 실체의 instance가 존재하면, 그것의 foreign key를 null 값으로 수정

④ Default: 부모 실체 instance의 삭제를 항상 허용하고, 대응되는 자식 실체의 instance가 존재하면, 그것의 foreign key를 기본값으로 수정

⑤ Customized: 특정한 검증조건이 만족되는 경우에만 부모 실체 instance의 삭제를 허용

⑥ No Effect: 부모 실체 instance 삭제를 조건 없이 허용

14. Triggering Operation

① 유형1: 사용자규칙에 의한 Triggering Operation

② 유형2: Source 속성 값의 변화에 따른 추출속성값의 변화를 정의하는 Triggering Operation

③ 유형3: 엔티티 타입간의 관계에 따른 무결성 유지의 필요성을 정의한 Triggering Operation

④ 유형4: 시점에 의해 자동으로 일어나는 Triggering Operation

(2) 데이터 모델 구성 요소

1. 데이터 모델 구성요소 개념

① 업무가 다루는 사항

② 업무가 다루는 사항들 사이에 존재하는 연관

③ 각 사항이 가지고 있는 상세한 특성

④ 업무 모델을 만드는데 사용되는 모든 diagram은 instance가 아닌 type을 다룬다

2. 속성(Attribute) 정의

① 실체(Entity)내에서 관리하고자 하는 정보들의 항목

② 더 이상 분리되지 않는 단위 값

③ Entity를 서술하고 양을 계수화하고 자격을 부여하고 분류를 하고 구체적으로 기입하는 정보 항목

3. 관계 정의

① 하나 또는 두 개의 사례를 연관시키는 업무와 관련된 중요한 사항

② 실체 상호 간 어떻게 연관되어 있는지를 파악하여 표현한다

: 식별성(Identity), 선택성(Optionality), 기수성(Degree, Cardinality), 비전이성(Non-transferability)

③ 관계는 항상 2개의 실체 사이에 존재한다

④ 관계는 두 개의 관점(관계 Membership)을 갖는다.

⑤ 관계의 양쪽 끝에 관계 명을 적는다

[출처] DASP 정리본|작성자 보람보람

본 웹사이트는 광고를 포함하고 있습니다.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.

DASP_2.pdf [File Size:1.65MB/Download:12,811]

[DAsP] 데이터아키텍쳐준전문가 요약자료, 이 게시물을

번호	제목	글쓴이	날짜	조회 수
공지	오라클 기본 샘플 데이터베이스	졸리운_곰	2014.01.02	86288
공지	[SQL컨셉] 서적 "SQL컨셉"의 샘플 데이타 베이스 SAMPLE DATABASE of ORACLE	가을의 곰을...	2013.02.10	78747
공지	[G_SQL] Sample Database	가을의 곰을...	2012.05.20	95490
1	Programatically retrieving data from a website into a database	졸리운_곰	2017.05.30	9225