랄라라

- ISP는 Information Strategic planning의 약자로 말 그대로 정보전략계획이다. 즉 최적의 정보(Information)화를 추진 하고 나가기 위한 중장기 전략(Strategic)을 계획(Planning)하는 것으로 중장기 It Masterplan 이라 말할 수 있습니다.

출처 - http://www.dbvision.co.kr/service/servISP.jsp

데이터 품질 관리 (DQM : Data Quality Management)

1. 정의

   - 기관이나 조직 내외부의 정보시스템 및 DB 사용자의 기대를 만족시키기 위해 지속적으로 수행하는 데이터 관리 및 개선활동.

2. 관점에 따른 분류

                                              데이터 품질관리 모형의 3가지 관점

   가. 미시적 관점

      - 데이터 품질 관리의 각 요소를 확인하고 요소별 데이터 품질 향상 방안을 도출.

   나. 거시적 관점

      - 전사 조직 측면에서 데이터 관리의 성숙도 단계를 정의하고 각 조직의 성숙도를 측정하여 상위 단계로 발전하도록 유도.

   다. 부가가치적 관점

      - 데이터 품질관리의 비용, 효과, 위험 모형을 개발하여 각 조직의 상황에 맞는 데이터 품질관리 방안을 제시.

3. 데이터 품질 관리 대상

                      데이터 품질관리 대상의 3가지 관점

   가. 데이터 값

      - 기관 및 기업의 비전이나 목표를 달성하기 위해 사용되어지는 전산화된 데이터 또는 전산화에 필요한 데이터.

      - 데이터의 현상적 값, 구조적 값

   나. 데이터 구조

      - 데이터가 담겨져 잇는 모양, 틀로서 데이터를 취급하는 관점에 따라 구조가 달라짐.

      - 사용자 뷰(양식, 보고서, 화면, 장표 등.), 모델(개괄, 개념, 참조, 논리, 물리), DB 파일

   다. 데이터 관리 프로세스

      - 데이터 및 데이터 구조의 품질을 안정적으로 유지, 개선하기 위한 활동으로 절차, 조직, 인력 등을 포함함.

      - 데이터 정의 프로세스, 데이터 변경 프로세스, 데이터 평가 프로세스

4. 데이터 품질 관리 기본틀 (Framework)

   - 데이터 품질관리의 대상이 되는 구성요소와 요소들 간의 관계를 정의한 데이터 품질관리의 기본 개념틀.

                                         데이터 품질 관리 기본틀(Framework)

   가. 데이터 값

      1) 표준 데이터 

         - 정보시스템에서 사용하는 용어, 도메인, 코드 및 기타 데이터 관련 요소에 대해 공통된 형식과 내용으로 정의하여 

           사용하는 표준 관련 데이터를 의미

      2) 모델 데이터 

         - 데이터 모델을 운용, 관리하는데 필요한 데이터를 의미. 

         - 데이터 참조 모델, 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델에 대한 메타 데이터 및 DBMS 객체 정보

      3) 관리 데이터

         - DB 를 효과적으로 운영, 관리하는데 필요한 데이터를 의미.

         - 사용 관리 데이터, 장해 및 보안 관리 데이터, 성능 관리 데이터, 흐름 관리 데이터, 품질관리 데이터

      4) 업무 데이터

         - 기관이나 기업의 업무 및 비즈니스를 수행하는데 필요한 데이터를 의미

         - 소스 데이터, 운영 데이터, 분석 데이터

   나. 데이터 구조

      1) 개념 데이터 모델

         - 업무 요건을 충족하는 데이터의 주제영역과 핵심 데이터 집합을 정의하고 상호 간의 관계를 정의한 모델을 의미.

      2) 데이터 참조 모델

         - 데이터 아키텍쳐의 구축, 유지관리 및 조직에서 사용하고 있는 데이터 모델의 상호 운영과 타 조직 데이터 모델의 참조, 

           재사용을 목적으로 업무영역별, 주제영역별로 표준 데이터 집합과 관리 항록들을 정의한 데이터 모델

      3) 논리 데이터 모델

         - 개념 데이터 모델을 상세화하여 논리적인 데이터 집합, 관리 항목, 관계를 정의한 모델을 의미.

      4) 물리 데이터 모델

         - DBMS 의 특성과 성능을 고려하여 논리 데이터 모델을 구체화시킨 모델을 의미.

      5) DB

         - 물리 모델을 구현한 결과물이며 구축된 실제 데이터가 저장되는 데이터 저장소를 의미

      6) 사용자 View

         - 데이터를 제공하는 정보시스템 상의 화면이나 출력물을 의미.

   다. 데이터 품질 관리 Main 프로세스

      1) 데이터 관리 정책 수립

         - 사업 계획에 기반을 둔 기업의 비젼과 목표를 달성하기 위해 필요한 데이터 확보 계획과 획보된 데이터를 효과적으로 관리, 

           유지하기 위한 체계 및 계획을 정의하는 작업

         - DB 품질과 관련된 프로세스 정의, 프로세스를 수행할 작업주체를 선정, 교육체계의 수립

      2) 데이터 표준 관리

         - 해당 기관에서 사용되는 용어 및 도메인 코드, 데이터 관련 요소에 대한 표준을 전사적으로 정의하는 작업

      3) 데이터 모델 관리

         - 신규 시스템 개발시 데이터 모델링 작업을 통해 설계된 개념 데이터 모델, 데이터 참조 모델, 논리 데이터 모델,

           물리 데이터 모델을 전사적으로 생성, 유지하기 위해 필요한 작업

      4) 데이터 흐름 관리

         - 소스데이터(문서,Text, DB 등.)를 수기로 생성하거나 추출, 변환, 적재, 가공을 통해 목표 DB 에 저장하는 데이터의 

            라이프 사이클을 통제, 관리하는 작업.

      5) DB 관리

         - DB를 안정적으로 운영, 유지하기 위해 데이터 모델에 적합한 DB 구성 및 백업, 보안, 복구, 성능 등을 

           정기적, 비정기적으로 관리하는 작업.

      6) DB 보안 관리

         - DB에 저장된 데이터를 오류 및 훼손없이 안정적으로 서비스할 수 있도록 하기 위해 접근 권한, 패스워드 

           정책수립 및 암호화 등을 수행하는 작업.

      7) 데이터 활용 관리

         - 데이터의 활용 여부를 점검하거나 활용도를 높이기 위해 측정 대상 데이터와 품질 지표를 선정하여 

           품질을 측정하고 분석하여 품질을 충족시키지 못하는 경우 원인을 분석하여 담당자로 하여금 조치하도록 하는 작업을 말한다.

      8) 요구사항 관리

         - 비즈니스의 연속성 및 장해에 따른 위험성을 사전에 제거 및 최소화하기 위해 사용자의 요구사항을 수립, 분석하는 작업.

-----------------------------------------------------------

참고 :

데이터 품질 관리 지침 2.1 (데이터품질관리인증센터, http://www.dbq.or.kr)

CDN [ contents delivery network ]

콘텐츠 전송 네트워크. 네티즌들에게 영화, 뮤직비디오 등 대용량의 콘텐츠를 빠르고 안정적으로 전달하기 위해 등장한 서비스. 

이 서비스는 콘텐츠 전송속도의 저하를 막고 불안정성 문제를 해결하기 위해 고안된 기술이다. 

CDN은 ISP(internet service provider)의 네트워크 하단에 여러 대의 캐시서버를 설치, CP(Contents Provider)가 제공하는 콘텐츠를 이 캐시서버에 미리 옮겨놓고 수요가 있을 때 그 콘텐츠를 사용자에게 전달해준다. 

즉 콘텐츠를 사용자 가까이에 미리 옮겨놓음으로써 전송속도를 향상시키는 것이다.

[네이버 지식백과]

FQDN - Fully Qualified Domain Name

FQDN ( 혹은 절대 도메인 네임 - Absolute Domain Name ) 은 네트워크 상에서 컴퓨터 시스템을 지칭하는 유일한 이름이다. FQDN 은 도메인 네임 시스템(DNS) 트리 구조상의 최상단에 위치해 있는 도메인 네임을 의미하며, 호스트 네임과 도메인 네임을 모두 포함하는 전체 이름이다. 

FQDN 은 모호하지 않고(unambiquous), 중복되지도 않는 유일한 도메인 네임으로 구분되어야 한다. 

예를 들면 어떤 장비의 로컬 호스트 네임이 myhost 이고 부모 도메인 네임이 example.com 이라 하자. 이 경우 이 장비의 FQDN 은 myhost,example.com 이 된다. 즉. FQDN 은 해당 장비의 유일한 구분자가 된다. 비록 이 세상에 수 많은 myhost 라는 호스트 이름이 존재한다고 해도, myhost.example.com 이라는 도메인은 단 하나만 존재할 수 있는 이치이다. 

잘 알려진대로, DNS 시스템 상에서 FQND 은 점(.) 으로 끝난다. 따라서 상기에 언급한 이 장비의 FQDN 은 아래와 같이 표현된다. 

myhost.example.com. 

SSO란 Single Sign On의 약자로 여러 개의 사이트에서 한번의 로그인으로 여러 가지 다른 사이트들

을 자동적으로 접속하여 이용하는 방법을 말합니다. 일반적으로 서로 다른 시스템, 서로 다른 사이트

에서는 각각의 사용자 정보를 관리하게 됩니다. 하지만 필요에 의해서 각각의 사용자 정보를 연동하

여 사용해야 할 경우가 생깁니다. 이때 하나의 사용자 정보를 기반으로 여러 시스템을 하나로 개발하

기에는 어려움이 따르겠죠? 따라서 각각의 정보를 그대로 두고 통합인증을 사용하게 됩니다. 이때 각각의 시스템에 로그인할 때 통합인증 정보가 있는지 확인하고 통합인증정보가 있을 경우 타 시스템에서 자동으로 로그인 가능하도록 처리하고, 없을 때는 로그인 하면서 통합인증정보를 생성하여 다른 시스템에서 참조 가능하도록 하는 것입니다.

최근 회사들이 그룹화 되거나 대형화가 되어 여러 사이트들을 통합 관리하는 경우 SSO를 사용하게 됩니다. 이때 통합인증 SSO를 사용하게 되면, 관리자는 하나의 아이디로 모든 고객을 통합관리 할 수

있게 되기에 각각의 사이트 아이디를  관리할 필요가 없게되고  기존 사용자는 정보변경 없이 하나의

사이트에 되어 있다면, 다른 모든 사이트에 별도로 가입하지 않고 로그인 할 수 있게 되는 겁니

다. 즉 하나의 사이트에 가입해서 메일/쇼핑/게임/검색 모든 사이트들을 이용할 수 있게 되는 겁니다.

예를 들어 포털에서 검색된 상품을 바로 포털 ID로 구매할 수 있게 되는 겁니다.

참 편리한 기능이죠? 회사가 그룹화 됨에 따라 조직이 점점 더 커질수록 SSO 시스템은 점점 더 필요하

게 될 것이고 최근 SSO시스템을 도입하는 기업과 공공기관들이 점점 늘어나고 있습니다.

출처 - http://blog.naver.com/tomatosoft?Redirect=Log&logNo=140134101160

프로젝트를 수행하다보면 종종 "프로젝트의 범위는 어디까지인가?", "이것도 해야하는 것인가?"라는 질문을 많이 갖게 됩니다. 프로젝트 팀원에서 부터 프로젝트관리자까지 종종 프로젝트가 납품해야 할 것이나 해야할 일을 누락하는 경우를 볼수 있습니다. 이것은 프로젝트가 체계적으로 관리되지 못하고 있다는 것을 의미하며, 구체적으로 해야할 일을 명확하게 정의하지 않은 경우 발생하는 것입니다.

즉, 요구사항을 명확히 해석하여 그에 대응하는 작업을 규정하였고, 이를 수시로 점검하였다면 과업의 누락은 발생하지 않게되는 것입니다.

이때, 프로젝트에서 해야할 일들을 체계적으로 정의하는 도구로 작업분할구조도를 사용합니다. WBS는 MS 프로젝트에서도 사용하는 기본양식입니다.

본회에서는 WBS의 정의와 구조에 대해 설명하겠습니다.

1. WBS는 무엇인가?

사전적인 의미로는 프로젝트의 범위와 최종산출물을 세부요소로 분할한 계층적 구조도라고 정의하며, 다음과 같은 역활을 수행합니다.

1.1 WBS의 역활

1) 프로젝트에서 수행할 업무 식별을 위한 툴

흔희 프로젝트의 시작은 요구사항 분석부터라고 합니다. 그러나, 대부분의 개발팀원들은 요구사항분석을 개발과정의 일부로써 프로젝트가 시작한 후에 하는 것으로 알고 있으며, 프로젝트의 시작은 개발자들이 모두 구성된후 kick-off meeting을 하는 것으로 잘못알고 있습니다. 정확한 프로젝트의 시작은 프로젝트 관리자의 임명에서 시작합니다. 즉, 임명된 프로젝트의 주관리자가 있어야 프로젝트의 모든 예산을 수립하는데, 이러한 예산은 요구사항에 근거한 작업범위로 산출하게 되는 것이며, 작업의 종류와 범위는 PM이 WBS에 근거하여 업무를 식별한 후에야 파악이 가능하게 됩니다.

 
2) 프로젝트의 일정과 원가, 자원요구사항 식별을 위한 툴

대충대충산정하여 프로젝트를 수행하는 경우, 예상못한 작업으로 인해 많은 낭패를 경험한 적이 있을 것입니다. 이것은 누락된 작업이 일정에 차질을 주었고, 지연된 일정을 만회하기 위해 더 많은 공수를 투입하는 비용지출의 결과를 불러오게 됩니다. 이를 예방하기 위해 WBS는 프로젝트의 작업에 대한 일정/원가를 산정하는 기초자료를 제공합니다.

3) 작업에 자원을 배정하기 위한 툴 

어떤 일을 누가 무엇을 가지고 할지를 정해야 하는 것을 도와 줍니다. 즉, 직무할당표 (RAM:Responsiability Assign Matrix )도 사용되기도 하지만 작업에 대한 자원 즉, 공수를 배정하는 것은 WBS가 적격입니다.

4) 프로젝트의 생산성 통제를 위한 툴

WBS가 프로젝트의 생산성을 통제할수 있다는 것은 아닙니다. 다만, 통제의 기반이되는 작업의 종류와 규모를 나열하기에 생산성을 예측하고 프로젝트 중간에 변경이 발생하면 이를 통제할수 있다는 것입니다. 즉, 범위의 변경은 WBS의 변경으로 통제되는 것입니다.

5) 고객, 프로젝트 팀 등 Stakeholder와의 의사소통을 위한 툴

WBS는 아래그림처럼 구조도로 표현되기도 하고 표로 표현되기도 하여, 프로젝트의 모든 인원이 각 작업에 대한 세부작업과 담당자를 쉽게 식별할수 있도록 표현하고 있습니다.  따라서, 이 자료는 범위변경 즉, 요구사항의 변경발생시 가장먼저 체크해보아야 할 사항중 하나로 사용될 만큼 고객과 의사소통의 수단이 되는 것입니다. 또한, 이후에 또 설명하겠지만, PWBS, CWBS등으로 나뉘어 계약적/후의 결정된 작업을 구분하는 계약서의 일부역활을 담당하기도 합니다.

1.2 WBS에 대한 오해

WBS는 업무나 결과물을 시간적으로 나열하는 것이 아닙니다. 단지, 전체업무를 점차적으로 작은 업무로 쪼개놓아 세부적으로 식별한 결과물입니다. 흔히들 MS project가 WBS를 이용하기에 일정관리를 WBS로 해야 한다는 둥 애기하기 쉬운데, 정확히 얘기하면, 일정관리는 Project plan으로 하는 것이며, MS project가 이를 지원하는 도구이고, WBS는 일정의 기초가 되는 작업을 세분화하는 기법인 것입니다.

모든 작업은 프로젝트의 요구사항에 기반하여 정의하므로, 개발 및 관리업무 모두를 빠짐없이 기술해야 합니다.

출처 - http://blog.naver.com/jtum?Redirect=Log&logNo=50084957807

문1) JNDI, JTA, JTS, JMS

답)

1. J2EE의 표준 서비스들인 JNDI, JTA, JTS, JMS의 개요

 가. J2EE의 정의

   - Enterprise Development에 필요한 다양한 환경을 정의해 놓은 규약,

     API와 TOOL들을 일컬음

 나. J2EE의 3대 카테고리

   - Component : Servlet, JSP, EJB :비지니스 로직 구현, GUI

   - Service : JDBC, JNDI, JTA : 데이터 베이스, 네이밍 서비스, 트랜잭션

   - Communication : JMS, JAVA Mail, JFA : 객체간의 통신, 메일, 메신져

2. JNDI, JTA, JTS, JMS의 개념 및 특징

 가. JNDI(Java Naming and Directory Interchange)

      - 네이밍 서비스와 자원에 속성까지 설정하는 디렉토리 서비스를 사용할 수 있게 하는 API

      - A서버 : 리소스, 서빗 객체등을 디렉토리에 등록

      - B, C, D 원격지에선 A서버의 주소로 등록된 서비스, 객체를 이름으로 검색/사용

 나. JTA(Java Transaction API)

     - 트랜잭션 관리를 위한 API, ACID(원자성, 일관성,독립성,지속성) 지원

     - JTA 트랜잭션을 사용하여 제어하기 위한 메소드들

       javax,transaction.UserTransaction 인터페이스의 begin(), commit(), rollback() 메소드 사용

 다. JTS(Java Transaction Service)

    - J2EE 트랜잭션 매니저가 어떤 일을 해야 하는지를 규정한 스펙

    - JTA를 지원하는 Transaction Manager의 구현을 지정하고 OTS 1.1 스펙의 자바 매핑을 정의

    - JTS는 transactions using the internet inter-ORB Protocol(IIOP)를 사용하여 트랜잭션 전파

 라. JMS(Java Message Service)

    - 비동기식 메시징을 위한 표준 API, 자바 어플리케이션이 비동기식 통신 수단 제공

    - 핵심개념 : Message Broker(메시지를 건네받는 역할, 우체국), 목적지(수신 주소)

    - 목적지 종류 : 큐(point-to-point모델), 토픽(publish-subscribe모델)

    - 장점 : 대기없음, 메시지 기반, 위치 독립성, 전달보증

                                                                                                  "끝"

[참고자료]

-----------------------------------------------------------------------------

* JAVA2 platform : Sun에서 제시한 기본 어플리케이션에서 엔터프라이즈 솔루션, 모바일 솔루션에

                          대한 개발 방법론과 다양한 API와 명세를 정의한 것

   - J2SE(Java2 platform Standard Edition) : 자바 프로그램을 하는데 있어서 가장 기본적인 핵심부분

   - J2EE(Java2 platform Enterprise Edition) : 엔터프라이즈 솔루션을 개발하는데 있어 필요한 여러가지

                                                               서비스 부분과 API, 개발 방법론을 제시

   - J2ME(Java2 platform Micro Edition) : 다양한 모바일 솔루션 개발하는데 있어서 기본적인 환경, 
                                                          서비스에 대한 부분을 정의, API를 제공

* J2EE : Enterprise Development 에 필요한 다양한 환경을 정의해 놓은 규약

            위 규약만 가지고 시스템이 움직이는 것은 아님, 예로 자바 프로그램이 구동되려면 JVM이

            필요한 것 처럼. J2EE는 이 API와 Tool들을 일컬음,

            그리고 이와 같은 API와 TOOL등을 포함하고 기타 서비스들을 탑재한 서버를

            ===> J2EE server, Web Application Server, J2EE application server라 일컬음

* J2EE Standard Service

  - Servlet, JSP, JDBC, JMS, JNDI, JTA, Java Mail, JAF, RMI-IIOP등

    위 기술로 JMS로 Messaging 서비스, JNDI로 Naming and Directory 서비스, JTA로 Transaction 서비스를 생성 가능

* J2EE의 3가지 Category

  - Component : Servlet, JSP, EJB --> 비지니스 로직 구현, 프리젠테이션 로직 담당, 주로 개발자가 개발하는 부분

  - Service : JDBC, JNDI, JTA

                  이미 존재하는 서비스들, 예로 database나 naming service나 Transaction 서비스와 같은 것들로 개발자

                  는 이를 그냥 사용하기만 하면 됨

  - Communication : JMS, JAF, Java Mail, RMI-IIOP --> 객체들간의 통신에 사용되는 것들로, 메일이나 메시지를

                                                                                다루는 시스템 개발때 주로 사용

JNDI : 자원을 이름으로써 관리하는 서비스

JTA : 개발자는 JTA를 이용하여 트랜잭션처리를 쉽게 할수 있음

JMS : 메세지 전달 서비스, 상대방이 현재 대화에 응할수 없는 상황일지라도 메세지를 보낼 수 있어야 함

* J2EE 구현 아키텍처

1) JNDI(Java Naming and Directory Interface)

    - 자원에 이름을 붙여 주는 서비스와 자원에 이름은 물론 속성까지 설정할 수 있도록 하는 서비스를 
      사용할 수 있게 하는 API

    - 특정한 프로토콜을 지정하는 규약이 아니라, 단순히 여러 가지 프로토콜을 사용할 수 있도록 하는

       표준적인 API를 지원

    - 분산 환경의 서버들간에 객체를 공유할수 있는 방법을 제공

    - 네이밍 서비스에 JNDI를 이용해서 객체를 등록, 삭제, 검색

  EX) A서버에 리소스, 서비스 객체등을 디렉토리에 등록해 놓으면

        B,C,D라는 원격지 서버에서 A서버의 리소스, 서비스 객체등을 사용 할 수 있음

        이때 B,C,D라는 원격지에서 A서버의 주소를 알아야되며 등록된 리소스, 서비스,

        서비스 객체가 등록되어진 이름을 알아야 함, EJB나 JMS에서 사용됨

* Directory Service

  - 디렉토리 서비스 표준 : X.50, LDAP

 2) JTA(Java Transaction API)

     - 트랜잭션 관리를 위한 API

     - 하나의 트랜잭션이 끝나기 전에 다른 트랜잭션 시작하는 것과 같은 중첩된 트랜잭션을 지원 안함

     - JTA 트랜잭션을 사용하여 제어하기 위한 메소드들

       javax,transaction.UserTransaction 인터페이스의 begin(), commit(), rollback() 메소드 사용

 3) JTS(Java Transaction Service)

    - J2EE 트랜잭션 매니저가 어떤 일을 해야 하는지를 규정한 스펙

    - JTA를 지원하는 Transaction Manager의 구현을 지정하고 OTS 1.1 스펙의 자바 매핑을 정의

    - JTS는 transactions using the internet inter-ORB Protocol(IIOP)를 사용하여 트랜잭션 전파

 4) JMS(Java Message Service)

    - 비동기식 메시징을 위한 표준 API

    - 자바 어플리케이션이 비동기식으로 통신을 할 수 있는 수단을 제공

    - JMS의 핵심 개념 2가지

      1) 메시지 중개자(Message Broker) : 메시지를 건네받는 역할 수행, 우체국 역할

      2) 목적지(Destination) : 어디로 전달되어야 하는지 주소

          큐와 토픽 두종류의 목적지 :

          -> 큐에는 point-to-point 모델 : 큐에 메시지 저장, 수신자가 큐에서 메시지 요청 후 가져가고 삭제,

                                                      반드시 하나의 수신자에게만 전달

          -> 토픽에는 publish-subscribe 모델 : 메시지가 토픽에서 전달되고 구독자는 이를 기다린다.

                                                                 모든 구독자가 같은 메시지 사본을 받는다

    - JMS의 장점

       1) 대기 없음 : 메시지 응답을 기다릴 필요가 없음

       2) 메시지 기반 : 메소드 호출을 기반으로 하는 RPC와는 달리 JSM는 데이터 중심

       3) 위치 독립성 : 동기시 RPC는 서비스는 보통 네트워크상의 위치를 알아야 접근 가능,

                               서비스의 IP나 포트 바뀌면 클라이언트도 따라 변경이 해야 하는 단점.

                               큐나 토픽에서 메시지를 꺼내올 수만 있다면 서비스의 위치는 중요치 않음

       4) 전달 보증 : 메시지가 전송당시 서비스에 이용불가 상태라도 메시지는 서비스가 살아날때까지 어딘가에 저장되어 있음

출처 - http://cafe.naver.com/accent93/42

"어플리케이션 개발에 바탕이 되는 템플릿과 같은 역할을 하는 클래스들과 인터페이스의 집합"

즉, 프로그램의 전체적인 구조와 흐름을 확정지으며, 프로그래머가 정의해야 할 메소드의 이름까지도 결정짓는 역할을 한다.