'1. IT Story/Basic Studies'에 해당되는 글 187건

1. CBD(Component Based Development)방법론의 개요

 1-1. CBD(Component Based Development)방법론의 정의

    - 재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션의 개발생산성과 품질을 높이고 시스템 유지보수비용을 최소화하는 혁신적 방법

 1-2. CBD(Component Based Development)방법론의 등장배경

    - 객체지향 개발 방법론이 해결하지 못한 개발 생산성, 재사용성, 시스템 유지보수성 등을 해결하기 위한 대안으로 등장

    - 업무, 기술, e-Business 조직의 변화

2. CBD(Component Based Development)방법론의 개발 프로세스 구조, 프로세스 요소

 2-1. CBD(Component Based Development)방법론의 개발 프로세스 구조

 2-2. CBD(Component Based Development)방법론의 프로세스 요소

  1) CD
    - CD (Component Development)
    - SW 개발에 필요한 부품을 만드는 과정
    - 재사용 목적상 해당 도메인에 대한 분석이 핵심사항

  2) CBD
   - CBD (Component Based Development)
   - 컴포넌트들을 조립하여 새로운 응용 소프트웨어 제품개발
   - 반복적 개발 프로세스를 적용하여 혁신적인 생산성 향상

3. CBD(Component Based Development)방법론의 구축방안

  1) 아키텍처 중심적 : 아키텍처 중심 개발을 통한 가시성 확보, 위험 조기 식별 및 대응

  2) 엔지니어링 도구 : 자동화된 툴을 통해 생산성과 정확성 향상 가능

  3) 프레임워크 기반 : 프레임워크 기반 개발은 개발생산성 향상 및 품질향상의 기반 역할

  4) 수행조직 : 컴포넌트 개발팀, 솔루션 개발팀, 조직지원팀의 역할 분담

  5) 표준 및 방법론 :

    - 실행환경 표준: .NET, J2EE, CCM
    - 개발표준:UML기반 개발표준 및 RUP와 같은 방법론

  6) 개발 역량 강화 : 개발팀원의 기반 기술 습득 정도, 표준 이해 및 준수 정도

  7) 재사용관리체계 : 컴포넌트 재사용 자산 축적 및 품질관리 체계 구축 중요

  8) 경험 축적 : 프로젝트 관리나 아키텍처 정립에 대한 경험과 적용 능력 중요

  9) 정책 : 개발자들이 컴포넌트에 대해 긍정적인 마인드를 갖도록 고취

1. 객체지향방법론의 개요

 1-1. 객체지향방법론의 정의

- 프로그램을 객체와 객체간의 인터페이스 형태로 구성하기 위하여 문제영역에서 객체와 클래스, 이들간의 관계를 식별하여 설계모델로 변환하는 방법론

 1-2. 객체지향방법론의 기본 원칙

 1) 캡슐화 : 메시지만으로 객체와 상호작용, 접근지정자(Public/Private)

 2) 추상화 : 복잡함을 간단히 분석의 초점을 명확히, 자료/기능/제어 추상화

 3) 다형성 동일인터페스 서로 다른 응답하는 특성, Overriding, Overloading  

 4) 정보은닉 : 객체의 내부구조와 실체분리, 멤버변수 접근제한

 5) 상속성 : 수퍼클래스의 성질 서브클래스에 자동부여, 단일/다중/반복/선택

 1-3. 객체지향방법론의 특징

2. 객체지향방법론의 방법론 절차, 단계별 작업 항목

 2-1. 객체지향방법론의 방법론 절차

 2-2. 객체지향방법론의 단계별 작업 항목

  1) 객체지향 분석 (3가지 모델링)

   - 객체모델링-객체다이어그램: 시스템 정적 구조 포착

   - 동적모델링-상태다이어그램: 시간의 흐름에 따라 객체간 변화조사

   - 기능모델링-자료흐름도: 입력에 대한 처리결과에 대한 확인

  2) 객체지향 설계 (3가지 모델 통합)

   - 시스템 설계: 시스템 구조설계,성능 최적화 방안, 자원분배

   - 객체 설계: 구체적 자료 구조와 알고리즘 구현

  3) 객체지향 구현

   - 객체지향 프로그래밍: 객체지향언어(C++, JAAVA), 객체지향 DBMS

1. 정보공학방법론의 개요

 1-1. 정보공학방법론의 정의

- 기업의 정보시스템 구축을 위한 계획, 분석, 설계 등 전 과정을 데이터 중심으로 정형화시킨 기법들로 구성된 광범위한 절차적 방법론

 1-2. 정보공학방법론의 특징

2. 정보공학방법론의 단계별 구성도, 단계별 상세 설명

 2-1. 정보공학방법론의 단계별 구성도

구성도	단계	설명
	ISP : Information Strategy Planning (정보전략 계획)	기업의 목표달성 위한 정보시스템 개발계획 수립
	BAA : Business Area Analysis (업무영역 분석)	정보요구와 업무 규칙 등 분석하여 업무모델 구축
	BSD : Business System Design (업무시스템 설계)	업무처리절차, DB 및 사용자 인터페이스 설계
	BSC : Business System Construction (업무시스템 구현)	정의된 산출물 기반으로 CASE와 4GL도구 사용

 2-2. 정보공학방법론의 단계별 상세 설명

 1) ISP(Information Strategy Planning)

    - 정의: 전사적 기업모형(청사진)을 설계하는 단계로서 전략적인 측면과 시스템적인 측면의 측면의 모형을 설정

    - 전략적 측면 : 조직의 목표, 주요성공요인 등

    - 시스템적 측면 : 조직의 목표 달성을 위한 정보화 계획, 절차, 정보기술 적용 등 주요산출물

 2) BAA(Business Area Analysis)

  - 정의 : 기업의 일정업무영역에 대한 사용자의 요구를 정의하는 단계

  - 데이터 모델 다이어그램 (ERD) : ISP(정보전략계획)과정에서 만들어진 ERD를 상세하게 확장한 다이어그램

  - 프로세스 계층도 (PHD) : 업무영역내의 기능들을 프로세스들로 분할하여 트리구조의 분할도를 만듦

  - 프로세스 의존도 (PDD) : 다른 프로세스들 간의 의존관계를 나타내는 다이어그램

  - 자료흐름도 (DFD) : 프로세스와 데이터간에 일어나는 행위를 매트릭스로 보여줌.

 3) BSD(Business System Design)

   - 정의 : 데이터와 시스템의 구조를 설계하는 단계. 기존 시스템에서 새로운 시스템으로의 전환 설계 포함

   - 데이터 사용 분석 : 트랜잭션의 발생량을 토대로 부하를 최적 분산하기 위해 응용 프로그램 별 발생량을 액션다이어그램에 주석으로 표시하거나 ERD에서 각 경로에 대한 관계 비를 숫자로 표현함

  - 물리적 데이터베이스 설계 : DB 설계자가 시스템의 비용, 성능, 응답시간 등을 고려하여 복잡한 시스템이 서로 균형을 이루면서 동작할 수 있도록 최적의 해를 찾아 설계

  - 분산분석 (Distribution Analysis) : 데이터와 프로세스를 여러 곳의 서버에 분산시켜 부하를 평준화 시키기 위한
방법으로 지역, 프로세스, 데이터를 매트릭스로 구성하여 분석함

 4) BSC(Business System Construction)

  - 확정된 설계명세서로부터 데이터베이스 생성기와 프로그램 코드 생성기를 이용해 데이터베이스와 실행 가능한 프로그램 코드를 생성함

1. 구조적방법론의 개요

 1-1. 구조적방법론의 정의

- 시스템을 기능에 따라 분할하여 개발하고 이를 통합하는 분할과 정복(Divide and Conquer) 개념을 이용한 프로세스 중심의 하향식 방법론

 1-2. 구조적방법론의 특징

   - 기능 중심: Function이 시스템의 분석, 설계, 구현의 근간

   - 도구 이용: 자료 흐름도, 자료 사전, Mini-spec이용

   - 기본 원칙: 분할과 정복(divide & conquer),추상화(abstraction),정형화,구조적 조직화, 하향식

2. 구조적방법론의 방법론 절차도, 구성요소

 2-1. 구조적방법론의 방법론 절차도

 2-2. 구조적방법론의 구성요소

   1) 구조적 분석 : 자료흐름도, 자료사전, MiniSpec / 논리적 모델링 수행

   2) 구조적 설계 : 구조도, 프로그램 명세서 / 물리적 모델링

   3) 구조적 언어 : Structured COBOL, Fortran77, PL/1, Pascal

   4) 구조적 구현 : Dijkstra에 의한 정형화, 논리적 구조(순차, 조건, 반복)

 2-3. 구조적방법론의 장/단점

 1) 장점 :

   - 컨트롤 가능한 모듈화

   - 구조적 분석/설계/프로그래밍을 통한 정형화/체계화

 2) 단점 : 

  - 기업 전반의 거시적 관점 부족

  - 단위프로젝트 위주 접근

  - 데이터 모델링 방법의 부족

  - 프로그램 로직 중심

1. SW개발방법론의 개요

 1-1. SW개발방법론의 정의

   - 소프트웨어 SDLC기반으로 SW를 개발하기 위해 각 단계별 작업활동, 절차, 산출물, 수행 기법 등을 정의한 체계

 1-2. SW개발방법론의 등장배경

2. SW개발방법론의 진화과정, 구성요소

 2-1. SW개발방법론의 진화과정

2-2. SW개발방법론의 구성요소

 1) 작업 절차 : 프로젝트 수행 시 각 작업 단계의 순서체계  |  단계->활동->작업

 2) 작업 방법 : 단계별 수행해야 하는 일(절차/작업 단위) |  R&R

 3) 산출물 : 단계별 수행 후 만들어지는 출력물 | 양식 / 문서

 4) 관리 : 프로젝트의 진행 기록, 계획수립, 진행관리, 품질, 외주, 예산, 인력관리 등의 기록 | 실행 / 통제

 5) 기법 : 단계별 작업 수행 시, 사용되는 노하우 기법 | ERD, DFD, CD 등

 6) 도구 : 기법 별 지원도구에 대한 구체적인 사용 표준 및 방법 | CASE tool, UML 등

3. SW개발 방법론 적용 시 문제점 및 방법론 선택기준

 1) 문제점

   - 프로젝트 특성을 무시한 방법론 지향적 추진

   - 형식에 우선하여 실무보다 문서 중심의 활동

   - 프로젝트의 규모별 방법론 필요성 대두 

   - 특징: 방법론 맹신, 형식화/문서화, 특성화/구체화

 2) 선택기준

   - 프로젝트 환경 고려(도메인, 규모, 복잡도) 선택

   - 실무중심의 개발자와 실무자의 활발한 의사소통

   - 성공 가이드라인/자동화/Stakeholder의 공감대 형성

   - 특징: 특성 별 선택, 채널통합 관리, 인식의 변화

1. EAP (Enterprise Architecture Planning)의 개요

 1-1. EAP (Enterprise Architecture Planning)의 정의

 - EA의 산출물을 정의하고 전환계획을 수립하기 위해 7단계의 프로세스로 구성되어 있는 Spewak에 의해 제시된 EA기반의 계획수립 방법론

 1-2. EAP (Enterprise Architecture Planning)의 특징

  1) Architecting : Engineering이 아닌 Architecting 방식으로 정보화 계획 수립

  2) 아키텍처 기반의 구성요소 묘사 

  3) 아키텍처 내용물 정의 (Define)

  4) EA 전환계획 제시

2. EAP (Enterprise Architecture Planning)의 개념도, 수행절차

  2-1. EAP (Enterprise Architecture Planning)의 개념도

 2-2. EAP (Enterprise Architecture Planning)의 수행절차

 1) 시작: EAP를 위한 작업계획: 방법론 선택, 팀 구성, 범위, 일정 등

 2) 현재위치 : 

    - 업무모델: 업무와 업무 수행에 사용된 정보를 집계

    - 현행시스템 및 기술: 어플리케이션과 지원기술 플랫폼 위해 현재 어떤 것이 적절한가 정의

 3) 목표비전

    - 데이터 아키텍처: 비즈니스 지원하기 위해 필요한 데이터 종류를 정의

    - 어플리케이션 아키텍처: 필요한 어플리케이션의 종류를 정의

    - 기술 아키텍처: 필요한 기술 플랫폼을 정의

 4) 획득계획 

   - 현재 시스템에서 새로운 시스템으로의 이전을 위한 계획: 일정, 비용, 순서를 정의함

3. EAP (Enterprise Architecture Planning)와 ISP(Information Strategy Planning) 비교

1. EA(Enterprise Architecture)의 개요

 1-1. EA(Enterprise Architecture)의 정의

  - 기업의 비즈니스, 정보, 응용, 기술을 시간과 공간적으로 전체적 관점으로 배치하고, 구성요소간 관계를 식별하여 표현한 엔터프라이즈의 청사진

  - 기업의 비전과 전략적 목표를 달성하기 위한 업무/응용/데이터/기술 관점의 통합 거버넌스 아키텍처

 1-2. EA(Enterprise Architecture)의 배경

  1) 정부
   - 각 부처간 IT 통합 관점, 작은 정부를 위한 핵심 인프라

  2) 금융권
   - 차세대 프로젝트의 Framework 제공, IT Compliance에 대한 유연한 대응

  3) 일반기업
   - IT에 비즈니스 프로세스 결합
   - 정보기술 자원의 복잡성 증가에 따른 효율적 IT 관리

2. EA(Enterprise Architecture)의 구성도, 구성요소

 2-1. EA(Enterprise Architecture)의 구성도

 2-2. EA(Enterprise Architecture)의 구성요소

  1) EA 비전/미션/원칙
    - 범정부 EA 가이드라인, EA 도입목적, 목표정의

  2) EA참조모델
    - 아키텍처 지원 및 방향성 관리, EA준수 평가 지침개발
    - PRM, BRM, SRM, DRM, TRM

  3) EA 매트릭스 (현행/목표 아키텍처)
    - 아키텍처 수립, 현 아키텍처 분석, 목표 아키텍처 정립
    - EA관련 정보 정의 및 공유

  4) EA 관리체계
   - EA거버넌스(환경, 도구, 조직, 프로세스), 아키텍처 평가 및 개선

  5) EA 지침서
   - EA산출물 및 표준관리 방향 정의, 표준 및 방향성 준수 여부 평가

3. EA(Enterprise Architecture)의 구축시 고려사항, 기대효과

 3-1. EA(Enterprise Architecture)의 구축시 고려사항

   - 현재 아키텍처의 진단 및 미래 아키텍처의 제시와 함께 최적의 아키텍처 전환 전략을 제공

   - 최적화된 정보 환경에 대한 규칙과 표준, 시스템 라이프사이클과 관련된 정보를 제공

   - EA관리시스템의 활용도와 만족도를 주기적으로 점검하여 시스템의 품질 지속적 개선

 3-2. EA(Enterprise Architecture)의 구축시 기대효과

   - 보다 나은 의사결정을 할 수 있도록 기업의 미션과 업무 기능에 대하여 설명함

   - 업무 조직과 IT 조직간에 의사소통을 향상 및 조직간 서비스 공유 통한 협업 기회를 발견함

   - 조직간 IT 관련 정보를 일관성, 정확성, 적시성 있게 공유함

1. DRS(Disaster Recovery System)의 정의

 1-1. DRS(Disaster Recovery System)의 정의

  - 재해복구 계획의 원할 한 수행을 위해 확보하는 인적, 물적 자원 및 이들에 대한 지속적인 관리 체제가 통합된 것

 1-2. DRS(Disaster Recovery System)의 필요성

  - 업무의 정보시스템 의존도 증가 및 해킹, 테러 등 위협 요인의 증가

  - 조직 분산화 등으로 인한 경영환경 변화

  - 시스템 중단으로 인한 손실 및 대외 신인도의 하락과 재해복구 대책에 대한 법적 규제 추세 (금융감독원 권고안 발표)

2. DRS(Disaster Recovery System)의 개념도, 핵심 기술 요소

 2-1. DRS(Disaster Recovery System)의 개념도

 2-2. DRS(Disaster Recovery System)의 핵심 기술 요소

  - HA,(High Availability) : 최단 복구를 위한 H/W Clustering 또는 Stand-By 형태

  - FT,(Fault Tolerant) : 실시간 복구가 가능한 Dual 시스템

  - IP-SAN : SAN Traffic을 IP Packet에 실어 전송

  - DWDM : Dense Wavelength Division Multiplexing, 고속의 Data 전송을 위한 통신