'IT & 인생'에 해당되는 글 473건

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) 단점 : 

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

  - 단위프로젝트 위주 접근

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

  - 프로그램 로직 중심

쓱가 탄생 22주년 최대 80% 역대급 혜택

http://www.ssg.com/event/eventDetail.ssg?promId=1100415576&ckwhere=ssg_brandsc&EKAMS=naver.723.5988.21315.2033304.614611522&trackingDays=1

10:00 
버거킹 와퍼 
선착순 1000명  

5,700 -> 2,850 

11:00 
이마트24 3천원권 
선착순 1000명  

3,000 -> 1,500 

12:00 
굽네치킨 오리지널 _ 콜라 1.25L 
선착순 1000명  

17,000 -> 8,500 

13:00 
애플 에어판 2세대 무선충전 모델 
선착순 100명 

249,000 -> 124,500 

14:00 
서울 웨스틴조선호텔 아리아 식사권 
선착순 150명 

113,100 -> 33,930 

15:00 
깨끗한나라 더순수퍼플 3겹 30롤X2 
선착순 1000명  

23,900 -> 11,950 

16:00 
농심 신라면 1BOX (20봉지) 
선착순 1000명  

18,900 -> 9,450 

17:00 
롯데시네마 1인 관람권 
선착순 1000명  

10,000 -> 5,000

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 전송을 위한 통신

1. 생체인식시스템(Biometrics)의 개요

 1-1. 생체인식시스템(Biometrics)의 정의

    - 인간의 신체적, 행동적 특징을 자동화된 장치를 거쳐, 측정함으로써 개인 식별의 수단으로 활용하는 기술

    - 생체의 일부분에서의 유일한 특장점을 추출하고 이를 활용하여 대상을 식별하는 기술

 1-2. 생체인식시스템(Biometrics)의 주요특징

 1) 이상적인 생체특징

   - 보편성(University) : 모든 대상자들이 보편적으로 지니고 있어야 함

   - 고유성(Uniqueness) : 개인별 특징이 확연히 구별되어야 함

   - 획득성(Collectability) : 센서로부터 생체 특성정보를 추출, 계층 가능해야 함

   - 지속성(Permanence) : 발생된 특징은 그 특성을 영속해야 함

 2) 시스템 설계시 고려사항

  - 성능(Performance) : 정확도, 속도, 강인성

  - 수용성(Acceptance) : 사람들의 수용정도

  - 기만성(Circumvention) : 시스템을 속이기 쉬운정도

2. 생체인식시스템(Biometrics)의 구성도, 구성요소

 2-1. 생체인식시스템(Biometrics)의 구성도

 2-2. 생체인식시스템(Biometrics)의 구성요소

 1) Data Collection : 생체인식 정보를 시스템에서 처리할 수 있는 정보로 변환하는 장치

 2) Transmission 시스템 : Data Collection, Signal Processing, Decision, Storage, Matching Process 사이의 정보 전송 기능

 3) Signal Processing : Data Collection으로부터 정보를 입력 받아서 Matching System 에서 요구하는 데이터로 변환

 4) Decision Process : Matching System의 결과값과 Risk Policy를 사용 Matching 여부 결정 

 5) Storage System : 등록한 사용자를 위해 Template 저장