문) REST
답)
1. Web 2.0의 가벼운 프로그래밍 모델, REST의 개요
가. REST(Representational State Transfer)의 정의
- HTTP의 POST/GET요구에 대해 XML 형식으로 실행결과를 리턴하는 웹서비스 제공 및 사용이 간단한 아키텍처
나. SOAP에서 REST로 관심 이동 이유
- URL기반(자원접근용이), 시스템확장성(느슨/독립 컴포넌트)
- 캐시허가(트래픽감소), 웹응용개발편리(정해진메소드)
2. REST의 주요특징 및 SOAP와 비교
가. REST의 주요특징
- 클라이언트/서버형 PULL기반 상호작용 방식 : 호출한 측이 데이터 가져옴
- 무상태(Stateless) : 서버측에서 세션관리 안함, 클라이언트/서버 교환 단순
- 계층화 시스템(Layed System) : 시스템을 복수계층으로 분할, Proxy배치 가능
- Code-In-Demand : 클라이언트에서 코드를 다운로드해서 실행
나. 복잡한 SOAP와 단순한 REST의 비교
구분 SOAP REST
Proxy Server 사용불가(별도구현필요) 사용가능
Caching 불가능 사용가능
상호운용성 비지원(커스터마이징필요) 지원
보안 우수(내용과메소드가메시지은닉) 별도 구현 필요
동작개념도 Client>SOAP요청>Server>SOAP반환, Client>URL요청>Server>XML Data반환
- 공통점 : 둘다 HTTP 프로토콜 이용, 웹서비스 제공에 활용
3. REST 방식 디자인시 주의사항 및 전망
가. 모든 리소스를 URL로 설계하여 서비스 제공하고, URL통해 자원조회/등록/삭제지원함
(URL =서버주소+서비스이름+자원)
나. 최근 SOAP 중심의 SOA 구성에서 효과적인 분산환경을 적용을 위해 REST 활용한 WOA서비스로 발전
끝.
====================================================================
* REST의 장점
- URL 텍스트를 브라우저 URL에 입력하면 바로 웹페이지로 엑세스가 가능함
- 웹페이지가 리소스와 그 상태로 단순화되어 빠르고 저렴함을 실현가능
*REST의 필요성
- 단순성 : 자원접근 및 인식(사람과 컴퓨터 공통)용이
- 시스템 확장성: Loosely coupled & Independent 컴포넌트 사용
- 서버 성능 향상 : 세션 정보를 클라이언트가 직접 관리
- 웹 응용 개발 편의성 향상 : 4개 기본 메소드, 2개 선택적 메소스 활용
* SOAP에서 REST로 관심 이동 이유
- 단순성(자원접근용이), 시스템 확장성(느슨, 독립 컴포넌트 사용)
- 성능향상(클라이언트가 세션정보관리), 편의성(웹응용개발)
*REST의 주요 특징
- 클라이언트/서버형 PULL기반 상호작용방식: 호출한 측이 데이터가져옴
- 무상태(Stateless) : 서버측에서 세션관리 안함, 클라이언트/서버 교환 단순
- 계층화시스템(Layed System) : 시스템을 복수계층으로 분할, Proxy 배치 가능
- Code-In-Demand : 클라이언트에서 코드를 다운로드 해서 실행
- Uniform Interface : 인터페이스 통일(GET, POST)
2013년 2월 25일 월요일
Daily Build
문) Daily Build
답)
1. 테스트베드의 통합테스트 Daily Build의 개요
가. Daily Build의 정의
- 소프트웨어 개발과정과 테스트과정이 자동화된 환경에서 형상관리를 통해 매일 자동 생성된 소프트웨어 빌드 버전
나. Daily Build 의 필요성
- 일정 준수 : 테스트 분야별 일정 계획에 준수한 작업 수행
- 자동화테스트 : 단순 자동화 테스트(Junit)를 위한 빌드 버전
2. Daily Build를 위한 요소 기술 및 릴리즈 빌드의 종류
가. Daily Build를 위한요소 기술
- Configuration Management : 형상관리 레퍼지토리, Check-in, Check-out, Brench
- 자동테스트 : Junit, Bunit등의 단순 공정 자동 테스트 수행
- Build Tool : Make, AutoConfig, Perl, Shell Script 등의 빌드 도구
- Repositoty : 버전 관리를 위한 레포지토리, 테스트 로그 기록
나. 릴리즈 빌드의 종류
- Stable Release : 안전성 검사 완료 빌듣, 테스트 과정 수행 완료
- Nightly Build : 최근 빌드 완료 된 비안정 버전의 릴리즈
- Beta Build : 최종 완료 이전의 사용자 테스트 중의 릴리즈
- Previous Build : 이전 버전 빌드. 최신 안정화 버전 이전의 빌드
3. Daily Build 활용의 고려사항 및 기대효과
가. 배포제한 : 안전성 검증 이전의 버전이 배포되어 의도하지 않은 피해 발생가능. 빌드별 안전성 검증 레벨 단계화 필요
나. 빌드 과정 및 테스트 과정의 자동화 통해 OSS(공개소프트웨어)프로젝트 자동화에 활요
끝.
답)
1. 테스트베드의 통합테스트 Daily Build의 개요
가. Daily Build의 정의
- 소프트웨어 개발과정과 테스트과정이 자동화된 환경에서 형상관리를 통해 매일 자동 생성된 소프트웨어 빌드 버전
나. Daily Build 의 필요성
- 일정 준수 : 테스트 분야별 일정 계획에 준수한 작업 수행
- 자동화테스트 : 단순 자동화 테스트(Junit)를 위한 빌드 버전
2. Daily Build를 위한 요소 기술 및 릴리즈 빌드의 종류
가. Daily Build를 위한요소 기술
- Configuration Management : 형상관리 레퍼지토리, Check-in, Check-out, Brench
- 자동테스트 : Junit, Bunit등의 단순 공정 자동 테스트 수행
- Build Tool : Make, AutoConfig, Perl, Shell Script 등의 빌드 도구
- Repositoty : 버전 관리를 위한 레포지토리, 테스트 로그 기록
나. 릴리즈 빌드의 종류
- Stable Release : 안전성 검사 완료 빌듣, 테스트 과정 수행 완료
- Nightly Build : 최근 빌드 완료 된 비안정 버전의 릴리즈
- Beta Build : 최종 완료 이전의 사용자 테스트 중의 릴리즈
- Previous Build : 이전 버전 빌드. 최신 안정화 버전 이전의 빌드
3. Daily Build 활용의 고려사항 및 기대효과
가. 배포제한 : 안전성 검증 이전의 버전이 배포되어 의도하지 않은 피해 발생가능. 빌드별 안전성 검증 레벨 단계화 필요
나. 빌드 과정 및 테스트 과정의 자동화 통해 OSS(공개소프트웨어)프로젝트 자동화에 활요
끝.
OTP
문) OTP
답)
1. 아이디 도용 방지를 위한 OTP의 개요
가. OTP(One Time Password)의 정의
- 정적인 비밀번호 취약점 개선. 필요시 비밀번호를 생성하여 서버의 임의 비밀번호와 비교를 통해 사용자 검증 기술
나. OTP의 필요성
- 취약한 비밀번호 : 유추 가능 단어 조합 비밀번호, 짧은 비밀번호 도용
- 개인 식별 보안 강화 : 비밀번호 + OTP통한 본인 인증 신뢰도 향상
2. OTP의 종류 및 주요 기술
가. OTP의 종류
1) 시간동기화 : 분 단위의 1회용 비밀번호 생성 매커니즘 이용
OTP 토큰과 서버와 시간 동기화 필요. 예)RSA SecureID, 디지패스
2) Event 동기화 : 토큰의 클릭 횟수에 따라 임시 비밀번호 생성
별도의 이벤트 생성 난수 동기화 필요. 대표사례)HW토큰, SEED 동기화 필요
3) 질의응답방식 : 서버의 Challenge에 대한 응답으로 식별
난수표나 암호표를 이용한 질의에 대한 응답 입력하는 불편
예)금융권의 시크릿카드, 보안토큰 카드
나. OTP의 주요기술(동작방식/동기화 메커니즘의 그림도 가능)
- TempProof : 자기보호 기능, 분해나 불법 접근시 클리어 또는 파손
- 동기화 : 시간, Event 재동기화 기술, 갭 확인 알고리즘, 서버 갭 보관
- 키 생성 : 난수/1회용 암호 생성 위한 Key보관 및 생성기술
3. OTP 활용의 고려사항 및 전망
가. OTP 전송과 매체는 동일 기기 활용 불가함. 기술적 보완 통한 휴대기기의 OTP활용 방안 보완 필요
나. OTP 인증센터의 ITSM인증을 통해 OTP의 공신력 및 신뢰도 향상 베터리 한계 극복 위한 저전력 및 자연 에너지 활용 필요.
끝.
답)
1. 아이디 도용 방지를 위한 OTP의 개요
가. OTP(One Time Password)의 정의
- 정적인 비밀번호 취약점 개선. 필요시 비밀번호를 생성하여 서버의 임의 비밀번호와 비교를 통해 사용자 검증 기술
나. OTP의 필요성
- 취약한 비밀번호 : 유추 가능 단어 조합 비밀번호, 짧은 비밀번호 도용
- 개인 식별 보안 강화 : 비밀번호 + OTP통한 본인 인증 신뢰도 향상
2. OTP의 종류 및 주요 기술
가. OTP의 종류
1) 시간동기화 : 분 단위의 1회용 비밀번호 생성 매커니즘 이용
OTP 토큰과 서버와 시간 동기화 필요. 예)RSA SecureID, 디지패스
2) Event 동기화 : 토큰의 클릭 횟수에 따라 임시 비밀번호 생성
별도의 이벤트 생성 난수 동기화 필요. 대표사례)HW토큰, SEED 동기화 필요
3) 질의응답방식 : 서버의 Challenge에 대한 응답으로 식별
난수표나 암호표를 이용한 질의에 대한 응답 입력하는 불편
예)금융권의 시크릿카드, 보안토큰 카드
나. OTP의 주요기술(동작방식/동기화 메커니즘의 그림도 가능)
- TempProof : 자기보호 기능, 분해나 불법 접근시 클리어 또는 파손
- 동기화 : 시간, Event 재동기화 기술, 갭 확인 알고리즘, 서버 갭 보관
- 키 생성 : 난수/1회용 암호 생성 위한 Key보관 및 생성기술
3. OTP 활용의 고려사항 및 전망
가. OTP 전송과 매체는 동일 기기 활용 불가함. 기술적 보완 통한 휴대기기의 OTP활용 방안 보완 필요
나. OTP 인증센터의 ITSM인증을 통해 OTP의 공신력 및 신뢰도 향상 베터리 한계 극복 위한 저전력 및 자연 에너지 활용 필요.
끝.
RUP 4+1 View
문) RUP 4+1 View
답)
1. SW요구사항-분석-설계-구현-시험의 일관성 유지 RUP4+1View
가. RUP 기본 시스템을 바라보는 관점
1) 사용자(고객) : 요구사항(Usecase), 사용사례, 명세등 자연어 접근
2) 설계자 : 요구사항 분석/설계/시험공정을 Object & Association
3) 개발자 : class & component, interface & Deploy 로 파악
4) 시스템엔지니어 : 실제 패키지의 HW배치, 실행모듈 상태로 접근
나. RUP 4+1 View의 Usecase driven 특징
1) usecase 중심으로 4 view 균형 잡음
2) 각각 view가 연관/종속 관계 유지, 요구사항~시험공정 전체 표현 가능
2. 4+1 View 구성요소 & SA의 4View 비교
가. 4+1 View 구성요소
1) Usecase : 액터관점, Usecase식별, 관계파악, Usecase/Activity diagram
2) Logic : 분석, 설계, class & interface, class/sequence diagram
3) Implementation : 구현패키지/Interface, 구현아키텍처 적용, 컴포넌트 diagram
4) Process : 컴포넌트/패키지가 실행상태 일때 표현(DLL, ActiveX)
5) Deployment : 컴포넌트/패키지가 HW에 설치된 상태, HW구성/제원표기
나. RUP 4+1 View와 SA 4View 비교
RUP 4+1 View SA 4View
1) usecase C&C view : 개념,시스템상위레벨,컴포넌트관계식별
2) logic Model view : 논리,분할(MVC), Layed, Pipe&Filter
3) Implementation Code view : 물리,소스코드 구조화
4) Process&Deployment Allocation view : 실행, 시스템 런타임 객체 속성정의
3. RUP 4+1 view 사용시 기대효과
가. 고객중심 : 시스템 중심에 usecase위치, view간 균형이 어긋날 경우, usecase가 판단기준, 고객과 의사소통(usecase spec.)
나. usecase>class분석/설계>component구현>Testcase연결 : 사용사례 실체화(usecase Realization)통한 추적성/연관성 관리
끝.
답)
1. SW요구사항-분석-설계-구현-시험의 일관성 유지 RUP4+1View
가. RUP 기본 시스템을 바라보는 관점
1) 사용자(고객) : 요구사항(Usecase), 사용사례, 명세등 자연어 접근
2) 설계자 : 요구사항 분석/설계/시험공정을 Object & Association
3) 개발자 : class & component, interface & Deploy 로 파악
4) 시스템엔지니어 : 실제 패키지의 HW배치, 실행모듈 상태로 접근
나. RUP 4+1 View의 Usecase driven 특징
1) usecase 중심으로 4 view 균형 잡음
2) 각각 view가 연관/종속 관계 유지, 요구사항~시험공정 전체 표현 가능
2. 4+1 View 구성요소 & SA의 4View 비교
가. 4+1 View 구성요소
1) Usecase : 액터관점, Usecase식별, 관계파악, Usecase/Activity diagram
2) Logic : 분석, 설계, class & interface, class/sequence diagram
3) Implementation : 구현패키지/Interface, 구현아키텍처 적용, 컴포넌트 diagram
4) Process : 컴포넌트/패키지가 실행상태 일때 표현(DLL, ActiveX)
5) Deployment : 컴포넌트/패키지가 HW에 설치된 상태, HW구성/제원표기
나. RUP 4+1 View와 SA 4View 비교
RUP 4+1 View SA 4View
1) usecase C&C view : 개념,시스템상위레벨,컴포넌트관계식별
2) logic Model view : 논리,분할(MVC), Layed, Pipe&Filter
3) Implementation Code view : 물리,소스코드 구조화
4) Process&Deployment Allocation view : 실행, 시스템 런타임 객체 속성정의
3. RUP 4+1 view 사용시 기대효과
가. 고객중심 : 시스템 중심에 usecase위치, view간 균형이 어긋날 경우, usecase가 판단기준, 고객과 의사소통(usecase spec.)
나. usecase>class분석/설계>component구현>Testcase연결 : 사용사례 실체화(usecase Realization)통한 추적성/연관성 관리
끝.
DB 진단방법론
문) DB 진단방법론
답)
1. 데이터 관리 성숙도 향상을 위한 데이터진단방법론 개요
가. 데이터진단방법론의 목적
- 활용 측면 : 고객 신뢰도 확보, 서비스품질향상, 접근편의성 개선
- 관리 측면 : 데이터 오류로 인한 업무비효율 개선, 관리활동 체계화
- 리스크측면 : 회계보고, 경영진의 의사결정지원, 컴플라이언스 대응
나. 데이터진단방법론의 종류
데이터값 : Biz Rule, 프로파일잉 등을 통한 오류점검(백분율, DPMO)
품질관리시스템(DQMS)를 통한 자동화된 측정 지원
데이터관리 : 품질기준과 관리 프로세스 측면에서 성숙도 점검
관리수준을 기관 간 상대 비교, 단계별 접근용이
- 수준평가 및 단계별 개선 로드맵 수립을 위해서는 데이터관리기준 진단 필요
2. 데이터관리 성숙모형 및 적용 고려사항
가. 데이터관리 성숙모형(DQMM)
구분 내용
품질기준 유효성(일관성,정확성),활용성(유용성,접근성,적시성,보안성)
사용자의 다양한품질요건을 표준화된 기준으로 정의
프로세스 표준,구조,흐름,사용자뷰,데이터베이스,요건관리 등
데이터관리 활동을 세분화하여 8가지 프로세스로 정의
성숙수준 도입,정형화,통합화,내재화,최적화의 5단계로 정의
기관의 데이터관리 활동 수준의 평가 및 비교 도구
- DQMM은 국내 표준이며 ISO8000의 MDM품질관리에 포함하는 작업 진행 중
나. 데이터관리 성숙모형 적용 고려사항
- 효율성 : 기관의 데이터 특성에 따라 핵심시스템의 관리활동 기준으로 적용
- 책임성 : 데이터 품질의 문화 확산과 주도적 추진을 위한 스폰서쉽 확보
- 투명성 : 현업 및 IT의 다양한 담당자 인터뷰 통해 활동을 명확히 파악
- 방향성 : 기관의 관리활동 현재 수준과 다음단계 진행 위한 개선사항 제시
3. 데이터진단 프레임웍 및 진단 절차
가. 데이터진단 프레임웍
구성요소 내용 관련기술
데이터값 데이터오류,CTQ,DQI기준 진단 DQMS
데이터구조 데이터모델 정규화, 중복진단 모델링 툴
데이터흐름 데이터연계, 이행의 매핑정보 진단 EAI,ETL정보
데이터베이스 DB보안, 백업, 복구, 성능진단 APM, DB로그
사용자뷰 화면의 일관성, 접근편의성 진단 웹접근성
사용자요건 데이터관련 요건처리, 대응진단 서비스센터(ITSM)
- 데이터값 진단은 데이터 관리활동의 진단에서는 제외함
나. 데이터진단 절차
- 진단범위 정의 : 진단 대상시스템, 관련자 범위 설정
- 진단 F/W결정 : 객관적 진단 모형, 명확한 진단항목 결정
- 현황분석 : 기관의 비즈니스, 주요 문제점, 관리 현황 사전 파악
- 진단수행 : 현업, IT담당자 인터뷰 수행, 관련자료 조서
- 선진사례분석 : 문제점 해결 위한 타기관의 관리활동 사례 확인
- 진단결과 : 성숙수준을 평가하고, 문제점 해결 방안 및 로드맵 제시
4. 데이터 진단 적용현황 및 성공요인
가. 공공 : 행안부 법제화를 통해 각 기관별 품질성숙도에 따른 가점 적용
나. 금융 : 일부 은행 및 신용평가기관등 데이터 중요성 인지 기입 중심 진단
다. 품질문화 확산 : 품질관리조직 중심으로 관련자 교육, 의식 전환 필요
라. 단계별 로드맵 : 성숙수준 별 중장기 계획에 따른 활동개선, 지원시스템 도입
끝.
답)
1. 데이터 관리 성숙도 향상을 위한 데이터진단방법론 개요
가. 데이터진단방법론의 목적
- 활용 측면 : 고객 신뢰도 확보, 서비스품질향상, 접근편의성 개선
- 관리 측면 : 데이터 오류로 인한 업무비효율 개선, 관리활동 체계화
- 리스크측면 : 회계보고, 경영진의 의사결정지원, 컴플라이언스 대응
나. 데이터진단방법론의 종류
데이터값 : Biz Rule, 프로파일잉 등을 통한 오류점검(백분율, DPMO)
품질관리시스템(DQMS)를 통한 자동화된 측정 지원
데이터관리 : 품질기준과 관리 프로세스 측면에서 성숙도 점검
관리수준을 기관 간 상대 비교, 단계별 접근용이
- 수준평가 및 단계별 개선 로드맵 수립을 위해서는 데이터관리기준 진단 필요
2. 데이터관리 성숙모형 및 적용 고려사항
가. 데이터관리 성숙모형(DQMM)
구분 내용
품질기준 유효성(일관성,정확성),활용성(유용성,접근성,적시성,보안성)
사용자의 다양한품질요건을 표준화된 기준으로 정의
프로세스 표준,구조,흐름,사용자뷰,데이터베이스,요건관리 등
데이터관리 활동을 세분화하여 8가지 프로세스로 정의
성숙수준 도입,정형화,통합화,내재화,최적화의 5단계로 정의
기관의 데이터관리 활동 수준의 평가 및 비교 도구
- DQMM은 국내 표준이며 ISO8000의 MDM품질관리에 포함하는 작업 진행 중
나. 데이터관리 성숙모형 적용 고려사항
- 효율성 : 기관의 데이터 특성에 따라 핵심시스템의 관리활동 기준으로 적용
- 책임성 : 데이터 품질의 문화 확산과 주도적 추진을 위한 스폰서쉽 확보
- 투명성 : 현업 및 IT의 다양한 담당자 인터뷰 통해 활동을 명확히 파악
- 방향성 : 기관의 관리활동 현재 수준과 다음단계 진행 위한 개선사항 제시
3. 데이터진단 프레임웍 및 진단 절차
가. 데이터진단 프레임웍
구성요소 내용 관련기술
데이터값 데이터오류,CTQ,DQI기준 진단 DQMS
데이터구조 데이터모델 정규화, 중복진단 모델링 툴
데이터흐름 데이터연계, 이행의 매핑정보 진단 EAI,ETL정보
데이터베이스 DB보안, 백업, 복구, 성능진단 APM, DB로그
사용자뷰 화면의 일관성, 접근편의성 진단 웹접근성
사용자요건 데이터관련 요건처리, 대응진단 서비스센터(ITSM)
- 데이터값 진단은 데이터 관리활동의 진단에서는 제외함
나. 데이터진단 절차
- 진단범위 정의 : 진단 대상시스템, 관련자 범위 설정
- 진단 F/W결정 : 객관적 진단 모형, 명확한 진단항목 결정
- 현황분석 : 기관의 비즈니스, 주요 문제점, 관리 현황 사전 파악
- 진단수행 : 현업, IT담당자 인터뷰 수행, 관련자료 조서
- 선진사례분석 : 문제점 해결 위한 타기관의 관리활동 사례 확인
- 진단결과 : 성숙수준을 평가하고, 문제점 해결 방안 및 로드맵 제시
4. 데이터 진단 적용현황 및 성공요인
가. 공공 : 행안부 법제화를 통해 각 기관별 품질성숙도에 따른 가점 적용
나. 금융 : 일부 은행 및 신용평가기관등 데이터 중요성 인지 기입 중심 진단
다. 품질문화 확산 : 품질관리조직 중심으로 관련자 교육, 의식 전환 필요
라. 단계별 로드맵 : 성숙수준 별 중장기 계획에 따른 활동개선, 지원시스템 도입
끝.
BI
문) BI
답)
1. 실시간 의사결정 지원을 위한 BI 개요
가. BI(Business Intelligence)의 정의
- 기업 내외부의 데이터를 정보화하여 경영환경에 따른 관련자의 의사결정 지원시스템
나. BI의 유형
- 전략/전술 BI : 경영자, 관리자 수준의 분석지원
- 운영 BI : 실무자의 운영상의 판단, 의사결정 지원
2. BI의 구성요소 및 BI 2.0과의 비교
가. BI의 구성요소
- CDC/EAI/ETL : 원천데이터 실시간, 배치로 DW에 전달
- DW : 주제별 데이터 통합, 집계, RDW(실시간), ADW(분석)
- OLAP : 대화식, 통합 ERD, 스타스키마, 스노우플레이크
- CRM(고객세분화), SEM(경영평가,ABC,BSC등), DataMining
나. BI1.0과 BI2.0의 비교
구분 1.0 2.0
정보유형 정형데이터 정형,비정형데이터
정보전달 배치작업(ETL) 실시간(CDC), 배치작업
관련자 경영자 경영자,관리자,실무자
정보시스템 정보계(집계,통합) 계정계(OLTP),정보계
3. BI의 발전방향 및 기대효과
가. SOA연계 : 기존 DW에 의존하지 않고 데이터연계, 정보제공
나. In-Memory 활용 : OLTP성 데이터의 실시간 분석 지원
다. Big Data분석 : 내,외부 대용량데이터분석, R, Hadoop 솔루션 적용
라. RTE 구현 : Biz변화의 빠른 분석, 의사결정 통한 적시성 제공
끝.
답)
1. 실시간 의사결정 지원을 위한 BI 개요
가. BI(Business Intelligence)의 정의
- 기업 내외부의 데이터를 정보화하여 경영환경에 따른 관련자의 의사결정 지원시스템
나. BI의 유형
- 전략/전술 BI : 경영자, 관리자 수준의 분석지원
- 운영 BI : 실무자의 운영상의 판단, 의사결정 지원
2. BI의 구성요소 및 BI 2.0과의 비교
가. BI의 구성요소
- CDC/EAI/ETL : 원천데이터 실시간, 배치로 DW에 전달
- DW : 주제별 데이터 통합, 집계, RDW(실시간), ADW(분석)
- OLAP : 대화식, 통합 ERD, 스타스키마, 스노우플레이크
- CRM(고객세분화), SEM(경영평가,ABC,BSC등), DataMining
나. BI1.0과 BI2.0의 비교
구분 1.0 2.0
정보유형 정형데이터 정형,비정형데이터
정보전달 배치작업(ETL) 실시간(CDC), 배치작업
관련자 경영자 경영자,관리자,실무자
정보시스템 정보계(집계,통합) 계정계(OLTP),정보계
3. BI의 발전방향 및 기대효과
가. SOA연계 : 기존 DW에 의존하지 않고 데이터연계, 정보제공
나. In-Memory 활용 : OLTP성 데이터의 실시간 분석 지원
다. Big Data분석 : 내,외부 대용량데이터분석, R, Hadoop 솔루션 적용
라. RTE 구현 : Biz변화의 빠른 분석, 의사결정 통한 적시성 제공
끝.
SOA 서비스정의, Web Service 활용
문) SOA서비스 정의, Web Service 활용
답)
1. SOA(Service Oriented Architecture) 서비스 정의
가. 비즈니스 프로세스 측면
- 비즈니스 프로세스 세분화(Activity, Task)하여 자동화대상 App컴포넌트와 매핑
- 서비스 단위로 재사용할 수 있는 아키텍처
나. 요소 기술적 측면
1) Web Service : OS 및 HW와 독립적으로 실행할 수 있는 컴포넌트
2) BPEL : XML기반으로 Web Service를 실행할 수 있는 언어
3) ESB : Open Standard 기반으로 xml형태의 메시지를 전달하는 미들웨어(버스형)
4) BRE : 비즈니스 프로세스 Rule 가시화, 공통 Rule 재사용, 분기
다. 아키텍처 측면
1) SOMA : Goal기반 서비스 정의, 서비스 명세서
2) SODA : Data 표준, 데이터 구조, 데이터분석
3) SOUP : XP와 Rup기반의 방법론
4) SOAD : 서비스 분석, 설계를 위한 방법론
2. SOA에서 WebService활용
가. SOA구축 단계별 WebService 활용
단계 내용
서비스개발 서비스컴포넌트 단위 재사용 통한 구현, CBD
서비스표준화 이기종 시스템의 서비스표준화 위한 WSDL(XML)
서비스공개 서비스공유, 검색, 발견을 위한 UDDI, 레지스트리
서비스전송 서비스 간 메시지 전송 위한 SOAP(XML, TEXT)
서비스실행/관리 서비스연계, 실행, 모니터링 위한 EAI/ESB, BPEL,BAM
나. SOA에서 업종별 WebService 활용
통계청 : 리서치기관 통계청에 접속하여 WSDL 다운로드,소규모시 UDDI 미 존재
G4C : 전자정부 접속해서 주민등록(행자부)와 등기부등본(법무부)서비스제공
기상청 : YTN은 기상청웹서비스를호출 날씨 정보제공, 동네날씨 서비스
은행 : 대출 심사시 WebService 기반 대출 실행
본사와 지점감 대출심사/대출금 지급정보조회
보험 : 의료비 지급 신청을 위한 지점과 본사가 연계서비스 제공
웹상에서 회사의 퇴직급여 산출 서비스 제공
3. SOA에서 WebService 활용 도입 전후 비교 및 기대효과
가. SOA에서 WebServie 활용 도입 전후 비교
비교항목 도입전 도입후
상호운용성 기술 종속적인 단일 I/F 표준 I/F 기반의 통합
고객서비스 각부처별 개인 UI 제공 단일 접점으로 통합 수행
RealTime 1일지연데이터와실시간 Real Time 특성을 가짐
데이터
성능 Direct Connection통한 성능 성능보다 통합통한 유연성 향상
향상
나. SOA에서 WebService 활용 시 기대효과
- 표준화 : 이기종 시스템 간 표준 XML(WSDL)통한 연계, 상호운용성
- 비즈니스 적시성 : 고객 관점의 프로세스 지원, Time-to-Market
- 비즈니스 민첩성 : 서비스조립, 서비스오케스트레이션, 비즈니스와 IT정렬
- 정보시스템통합 : WebService 연계, Plug&Play로 신규 App추가
4. SOA에서 WebService활용 시 고려사항 및 기타 활용
- SOAP 복잡성 : REST 사용으로 메시지 호출 단순화, NW부하 감소
- 서비스도출 : BPM 수행 통해 Sub Process도출, 세분화 수행
- Open API 활용 : WSDL통한 서비스 공개 외 Web기반, Cloud서비스 고려
- BPM : 서비스 단위로 오케스트레이션을 하고 업무 프로세스 자동화
- MCI : 영업점 CallCenter, ATM등 멀티 채널을 Multi protocol 기반의 통합(Adapter)
끝.
답)
1. SOA(Service Oriented Architecture) 서비스 정의
가. 비즈니스 프로세스 측면
- 비즈니스 프로세스 세분화(Activity, Task)하여 자동화대상 App컴포넌트와 매핑
- 서비스 단위로 재사용할 수 있는 아키텍처
나. 요소 기술적 측면
1) Web Service : OS 및 HW와 독립적으로 실행할 수 있는 컴포넌트
2) BPEL : XML기반으로 Web Service를 실행할 수 있는 언어
3) ESB : Open Standard 기반으로 xml형태의 메시지를 전달하는 미들웨어(버스형)
4) BRE : 비즈니스 프로세스 Rule 가시화, 공통 Rule 재사용, 분기
다. 아키텍처 측면
1) SOMA : Goal기반 서비스 정의, 서비스 명세서
2) SODA : Data 표준, 데이터 구조, 데이터분석
3) SOUP : XP와 Rup기반의 방법론
4) SOAD : 서비스 분석, 설계를 위한 방법론
2. SOA에서 WebService활용
가. SOA구축 단계별 WebService 활용
단계 내용
서비스개발 서비스컴포넌트 단위 재사용 통한 구현, CBD
서비스표준화 이기종 시스템의 서비스표준화 위한 WSDL(XML)
서비스공개 서비스공유, 검색, 발견을 위한 UDDI, 레지스트리
서비스전송 서비스 간 메시지 전송 위한 SOAP(XML, TEXT)
서비스실행/관리 서비스연계, 실행, 모니터링 위한 EAI/ESB, BPEL,BAM
나. SOA에서 업종별 WebService 활용
통계청 : 리서치기관 통계청에 접속하여 WSDL 다운로드,소규모시 UDDI 미 존재
G4C : 전자정부 접속해서 주민등록(행자부)와 등기부등본(법무부)서비스제공
기상청 : YTN은 기상청웹서비스를호출 날씨 정보제공, 동네날씨 서비스
은행 : 대출 심사시 WebService 기반 대출 실행
본사와 지점감 대출심사/대출금 지급정보조회
보험 : 의료비 지급 신청을 위한 지점과 본사가 연계서비스 제공
웹상에서 회사의 퇴직급여 산출 서비스 제공
3. SOA에서 WebService 활용 도입 전후 비교 및 기대효과
가. SOA에서 WebServie 활용 도입 전후 비교
비교항목 도입전 도입후
상호운용성 기술 종속적인 단일 I/F 표준 I/F 기반의 통합
고객서비스 각부처별 개인 UI 제공 단일 접점으로 통합 수행
RealTime 1일지연데이터와실시간 Real Time 특성을 가짐
데이터
성능 Direct Connection통한 성능 성능보다 통합통한 유연성 향상
향상
나. SOA에서 WebService 활용 시 기대효과
- 표준화 : 이기종 시스템 간 표준 XML(WSDL)통한 연계, 상호운용성
- 비즈니스 적시성 : 고객 관점의 프로세스 지원, Time-to-Market
- 비즈니스 민첩성 : 서비스조립, 서비스오케스트레이션, 비즈니스와 IT정렬
- 정보시스템통합 : WebService 연계, Plug&Play로 신규 App추가
4. SOA에서 WebService활용 시 고려사항 및 기타 활용
- SOAP 복잡성 : REST 사용으로 메시지 호출 단순화, NW부하 감소
- 서비스도출 : BPM 수행 통해 Sub Process도출, 세분화 수행
- Open API 활용 : WSDL통한 서비스 공개 외 Web기반, Cloud서비스 고려
- BPM : 서비스 단위로 오케스트레이션을 하고 업무 프로세스 자동화
- MCI : 영업점 CallCenter, ATM등 멀티 채널을 Multi protocol 기반의 통합(Adapter)
끝.
SCRUM
문) SCRUM
답)
1. 팀의 유기적 결합, Tracking을 중시하는 SCRUM
가. SCRUM의 개요
- 작은 개발팀, 짧은 개발주기, 팀 집중력과 생산성 유지로 점진적, 반복적으로 SW를 개발하는 Agile Process
2. SCRUM의 특징과 프로세스
가. SCRUM의 특징
1) 독립적 : 개발언어나 개발 방법론에 종속되지 않음
2) 팀중심 : 팀 단위의 활동과 구현
3) 범용성 : SW개발, 유지보수, 프로젝트 적용 가능
나. SCRUM 프로세스
1) Product Backlog : 요구사항목록(기능,비기능)
2) Sprint : 스크럼의 팀의 반복 주기(2~4주)
3) Daily SCRUM : Daily회의 (15분, 진행상황,팀 진척확인)
4) Sprint Review Meeting : 산출물데모, Sprint Review
5) Sprint Restrospective : 지속적 개선 검토
3. SCRUM 이해관계자와 관리대상
1) Product Owner : User Story 작성 및 우선순위화, Product Backlog 작성
2) SCRUM Master : 장애물제거, 불안요소 중재, 계획주도, 코치역할
3) Scrum Team : Sprint 달성위한 주도적 작업수행, 자율성 강조
4) 관리대상 : Product Backlog, Story(요구사항), Estimate
===============================================================
추가적 파악사항
1. SCRUM의프로젝트 관리 영역별 방안
가. 프로젝트관리품질(개발일정) : 스프린트 백로그
나. 프로젝트관리품질 진척도 : 소멸챠트
다. 프로세스품질(생산성) : 소멸챠트, 수행속도, 스프린트주기
라. 프로세스품질(재작업율) : 스프린트 백로그
2. SCRUM과 XP
가. 개발(XP) : 지속적인 통합, 공동소유, Pair 프로그래밍
나. 설계(SCRUM) : 테스트부터 시작하고 설계 및 구현, 반복과 단순화로 설계
다. 테스트전략 : 코딩보다 단위테스트를 먼저하고, 테스트를 자동화
라. 계획세우기, 작은 시스템 릴리즈, Metaphor 등 XP의 12가지 실천사항 병행
마. 기존 방법론과의 결합은 SCRUM의 장점과 유연성이 감소
3. 방법론과 Agile 방법론을 결합하여 Enterprise Project 수행방안
가. 전통적 개발프로세스
- 프로젝트관리, 일정관리, PM 및 PMO 수행
나. SCRUM
- 세부 Task 관리, 세부일정 및 리소스 관리, PM 및 PL수행
다. SCRUM과 XP 결합
- Sprint 시 XP의 Pair Programming, TDD, Refactoring 등 실천법을 적용한 개발
끝.
답)
1. 팀의 유기적 결합, Tracking을 중시하는 SCRUM
가. SCRUM의 개요
- 작은 개발팀, 짧은 개발주기, 팀 집중력과 생산성 유지로 점진적, 반복적으로 SW를 개발하는 Agile Process
2. SCRUM의 특징과 프로세스
가. SCRUM의 특징
1) 독립적 : 개발언어나 개발 방법론에 종속되지 않음
2) 팀중심 : 팀 단위의 활동과 구현
3) 범용성 : SW개발, 유지보수, 프로젝트 적용 가능
나. SCRUM 프로세스
1) Product Backlog : 요구사항목록(기능,비기능)
2) Sprint : 스크럼의 팀의 반복 주기(2~4주)
3) Daily SCRUM : Daily회의 (15분, 진행상황,팀 진척확인)
4) Sprint Review Meeting : 산출물데모, Sprint Review
5) Sprint Restrospective : 지속적 개선 검토
3. SCRUM 이해관계자와 관리대상
1) Product Owner : User Story 작성 및 우선순위화, Product Backlog 작성
2) SCRUM Master : 장애물제거, 불안요소 중재, 계획주도, 코치역할
3) Scrum Team : Sprint 달성위한 주도적 작업수행, 자율성 강조
4) 관리대상 : Product Backlog, Story(요구사항), Estimate
===============================================================
추가적 파악사항
1. SCRUM의프로젝트 관리 영역별 방안
가. 프로젝트관리품질(개발일정) : 스프린트 백로그
나. 프로젝트관리품질 진척도 : 소멸챠트
다. 프로세스품질(생산성) : 소멸챠트, 수행속도, 스프린트주기
라. 프로세스품질(재작업율) : 스프린트 백로그
2. SCRUM과 XP
가. 개발(XP) : 지속적인 통합, 공동소유, Pair 프로그래밍
나. 설계(SCRUM) : 테스트부터 시작하고 설계 및 구현, 반복과 단순화로 설계
다. 테스트전략 : 코딩보다 단위테스트를 먼저하고, 테스트를 자동화
라. 계획세우기, 작은 시스템 릴리즈, Metaphor 등 XP의 12가지 실천사항 병행
마. 기존 방법론과의 결합은 SCRUM의 장점과 유연성이 감소
3. 방법론과 Agile 방법론을 결합하여 Enterprise Project 수행방안
가. 전통적 개발프로세스
- 프로젝트관리, 일정관리, PM 및 PMO 수행
나. SCRUM
- 세부 Task 관리, 세부일정 및 리소스 관리, PM 및 PL수행
다. SCRUM과 XP 결합
- Sprint 시 XP의 Pair Programming, TDD, Refactoring 등 실천법을 적용한 개발
끝.
COCOMO
문) COCOMO
답)
1. 소프트웨어 비용산정기법 COCOMO의 개요
가. COCOMO(Constructive Cost Model)의 정의
- 시스템의 구성모듈과 서브시스템의 비용합계를 계산하여 시스템의 비용을 산정하는 방식(이해하기 쉬운 실험적 모델)
나. CoCoMo의 특징
- 개발 소요 M/M를 과거 수행 프로젝트 경험에서 산출
- 다양한 SW개발프로젝트를 3가지 유형으로 구분(규모,소요인원 산출)
- CoCoMoII 모델로 발전 : SDLC별로 모델 반영
2. CoCoMo 모델의 유형
가. CoCoMo 모델의 유형
- Basic CoCoMo : 추정 라인수로 모델 정함, LOC 기반
- Intermediate CoCoMo : 제품 HW 특성, 개발구성원 고려하여 산정, LOC+가중치 기반
- Detailed CoCoMo : 개발단계별로 비용 산정방식 적용
나. CoCoMo 모델의 프로젝트 유형
프로젝트 유형 공식 내용(활용)
유기적모드 SM=2.4*(KDSI)^1.05 소규모,과학기술용 SW,잘알려진시스템
(Organic) (50KDSI 이하크기)
반결함모드 SM=3.0*(KDSI)^1.12 중간규모,개발지원도구(컴파일러,WP)개발용
(Semidetached) (300KDSI이하크기)
내장모드 SM=3.6*(KDSI)^1.20 HW포함,제약조건(RealTime),대형프로젝트
(Embeded) (300KDSI이상크기)
다. 프로젝트에 영향을 주는 비용승수
- 제품특성(신뢰성,복잡도,DB크기), 컴퓨터특성(수행시간,메모리제약)
- 개발요원 특성(응용/언어경험,능력),프로젝트 성격(도구,일정)
3. 수학적 산정방식간 비교
구분 FP COCOMO COCOMOII
특징 기능중심산정 크기중심산정(LOC) FP,LOC 산정
유형별기능분포도 SW유형별통계적방법 재사용, 컴포넌트 조립 고려
기여도계산 적용
장점 개발언어독립적 이해쉬운실험적모델 개발진행정도반영
단점 복잡도산정주관개입 코드재사용미고려 적용복잡
끝.
답)
1. 소프트웨어 비용산정기법 COCOMO의 개요
가. COCOMO(Constructive Cost Model)의 정의
- 시스템의 구성모듈과 서브시스템의 비용합계를 계산하여 시스템의 비용을 산정하는 방식(이해하기 쉬운 실험적 모델)
나. CoCoMo의 특징
- 개발 소요 M/M를 과거 수행 프로젝트 경험에서 산출
- 다양한 SW개발프로젝트를 3가지 유형으로 구분(규모,소요인원 산출)
- CoCoMoII 모델로 발전 : SDLC별로 모델 반영
2. CoCoMo 모델의 유형
가. CoCoMo 모델의 유형
- Basic CoCoMo : 추정 라인수로 모델 정함, LOC 기반
- Intermediate CoCoMo : 제품 HW 특성, 개발구성원 고려하여 산정, LOC+가중치 기반
- Detailed CoCoMo : 개발단계별로 비용 산정방식 적용
나. CoCoMo 모델의 프로젝트 유형
프로젝트 유형 공식 내용(활용)
유기적모드 SM=2.4*(KDSI)^1.05 소규모,과학기술용 SW,잘알려진시스템
(Organic) (50KDSI 이하크기)
반결함모드 SM=3.0*(KDSI)^1.12 중간규모,개발지원도구(컴파일러,WP)개발용
(Semidetached) (300KDSI이하크기)
내장모드 SM=3.6*(KDSI)^1.20 HW포함,제약조건(RealTime),대형프로젝트
(Embeded) (300KDSI이상크기)
다. 프로젝트에 영향을 주는 비용승수
- 제품특성(신뢰성,복잡도,DB크기), 컴퓨터특성(수행시간,메모리제약)
- 개발요원 특성(응용/언어경험,능력),프로젝트 성격(도구,일정)
3. 수학적 산정방식간 비교
구분 FP COCOMO COCOMOII
특징 기능중심산정 크기중심산정(LOC) FP,LOC 산정
유형별기능분포도 SW유형별통계적방법 재사용, 컴포넌트 조립 고려
기여도계산 적용
장점 개발언어독립적 이해쉬운실험적모델 개발진행정도반영
단점 복잡도산정주관개입 코드재사용미고려 적용복잡
끝.
ISO 9126
문) ISO 9126
답)
1. 사용자관점의 SW품질특성 표준 ISO9126의 개요
가. ISO9126의 정의
- SW품질 특성을 사용자관점으로 정의하고 품질평가 매트릭을 정량적으로 정의한 국제표준
나. ISO 9126의 기대효과
- 사용자, 평가자, 개발자 모두에게 품질평가 지침 제공
- 객관적, 정량적 SW품질평가 기본틀, 평가 매트릭 제공
2. ISO9126의 구성 및 SW 제품품질 특성
가. ISO9126의 구성
- ISO9126-1 : 품질특성(주특성,부특성)과 매트릭 정의
- ISO9126-2 : 외부매트릭스, 시험, 운영단계, 사용자/관리자
- ISO9126-3 : 내부매트릭스, 설계, 코딩단계, 개발자/설계자
- ISO9126-4 : 사용 중 품질, 운영환경의 결과로 측정, 운영자
나. SW제품 품질 특성
- 기능성 : 요구 기능의 충족 정도 (적합성, 정확성)
- 신뢰성 : 지정 수준의 기능유지 (회복성, 오류허용성)
- 사용성 : 사용자가 쉽게 이해 (이해성, 습득성)
- 효율성 : 투입자원 대비 성능 (실행효율, 자원효율성)
- 유지보수성 : 개선, 수정 시 변경가능 (해석성, 변경용이성)
- 이식성 : HW, SW환경 이전 능력 (적응성, 이식성)
3. ISO9126 표준 동향 및 활용 방안
가. ISO 25000 : ISO9126의 품질특성, 14598의 평가절차 통합추진
나. SW아키텍처 : SW품질 특성 도출을 위한 기본 틀 제공
다. 내부시스템 : 기업 자체 시스템 구축 시 품질 평가 기준 제공
라. 외부패키지 : SW패키지 도입 시 상대 비교 위한 평가 기준 제공.
끝.
답)
1. 사용자관점의 SW품질특성 표준 ISO9126의 개요
가. ISO9126의 정의
- SW품질 특성을 사용자관점으로 정의하고 품질평가 매트릭을 정량적으로 정의한 국제표준
나. ISO 9126의 기대효과
- 사용자, 평가자, 개발자 모두에게 품질평가 지침 제공
- 객관적, 정량적 SW품질평가 기본틀, 평가 매트릭 제공
2. ISO9126의 구성 및 SW 제품품질 특성
가. ISO9126의 구성
- ISO9126-1 : 품질특성(주특성,부특성)과 매트릭 정의
- ISO9126-2 : 외부매트릭스, 시험, 운영단계, 사용자/관리자
- ISO9126-3 : 내부매트릭스, 설계, 코딩단계, 개발자/설계자
- ISO9126-4 : 사용 중 품질, 운영환경의 결과로 측정, 운영자
나. SW제품 품질 특성
- 기능성 : 요구 기능의 충족 정도 (적합성, 정확성)
- 신뢰성 : 지정 수준의 기능유지 (회복성, 오류허용성)
- 사용성 : 사용자가 쉽게 이해 (이해성, 습득성)
- 효율성 : 투입자원 대비 성능 (실행효율, 자원효율성)
- 유지보수성 : 개선, 수정 시 변경가능 (해석성, 변경용이성)
- 이식성 : HW, SW환경 이전 능력 (적응성, 이식성)
3. ISO9126 표준 동향 및 활용 방안
가. ISO 25000 : ISO9126의 품질특성, 14598의 평가절차 통합추진
나. SW아키텍처 : SW품질 특성 도출을 위한 기본 틀 제공
다. 내부시스템 : 기업 자체 시스템 구축 시 품질 평가 기준 제공
라. 외부패키지 : SW패키지 도입 시 상대 비교 위한 평가 기준 제공.
끝.
ISO 12119
문) ISO 12119
답)
1. SW 패키지의 품질 평가, ISO 12119의 개요
가. ISO 12119의 정의
- 패키지, 소프트웨어에 대한 품질특성과 적용방법을 제시한 표준(실행프로그램, 제품설명서,사용자문서)
나. ISO 12119의 적용범위
- 시험대상 : 완성된 SW 패키지 프로그램 및 문서
- 제외대상 : 작업공정, 프로세스, 품질보증활동
2. ISO 12119의 요구사항 및 평가절차
가. ISO 12119의 요구사항
- 명세화 : 제품정보, 기능, 특성, 처리한계 명확한 제시
- 유사문서정의 : 설명서에 의해 시방서 등도 기준준수
- 변경용이성 : 버전별 기능 업그레이드 시 변경 용이
- 환경명세 : 운용에 필요한 SW, HW 환경 명시
- 보안, 백업절차, 설치가능여부, 저작권, 유지보수 등 분류
나. ISO 12119의 평가절차
- 제품설명서 시험 : 기본적 요구사항, 적절한 문서화체계 평가
- 사용자문서 시험 : 기능, 성능, 범위 정확, 이해 용이평가
- 실행프로그램 시험 : 프로그램의 안정적 동작 여부 평가
- 시험 기록, 보고서 작성 : 시험반복, 목적, 결과 요약 기록
3. ISO 12119의 활용 및 도입 효과
가. ISO 9126 : 제품 품질 평가 기준은 내,외부 매트릭스 활용
나. GS인증 : 국내 제품 품질 평가 위해 ISO 12119의 기준활용
다. 패키지도입 : 여러 패키지의 품질 상대비교, 적합한 제품선택
라. 패키지개발 : 제품의 품질 기준 제공, 인증 통한 신뢰성 제공
끝.
답)
1. SW 패키지의 품질 평가, ISO 12119의 개요
가. ISO 12119의 정의
- 패키지, 소프트웨어에 대한 품질특성과 적용방법을 제시한 표준(실행프로그램, 제품설명서,사용자문서)
나. ISO 12119의 적용범위
- 시험대상 : 완성된 SW 패키지 프로그램 및 문서
- 제외대상 : 작업공정, 프로세스, 품질보증활동
2. ISO 12119의 요구사항 및 평가절차
가. ISO 12119의 요구사항
- 명세화 : 제품정보, 기능, 특성, 처리한계 명확한 제시
- 유사문서정의 : 설명서에 의해 시방서 등도 기준준수
- 변경용이성 : 버전별 기능 업그레이드 시 변경 용이
- 환경명세 : 운용에 필요한 SW, HW 환경 명시
- 보안, 백업절차, 설치가능여부, 저작권, 유지보수 등 분류
나. ISO 12119의 평가절차
- 제품설명서 시험 : 기본적 요구사항, 적절한 문서화체계 평가
- 사용자문서 시험 : 기능, 성능, 범위 정확, 이해 용이평가
- 실행프로그램 시험 : 프로그램의 안정적 동작 여부 평가
- 시험 기록, 보고서 작성 : 시험반복, 목적, 결과 요약 기록
3. ISO 12119의 활용 및 도입 효과
가. ISO 9126 : 제품 품질 평가 기준은 내,외부 매트릭스 활용
나. GS인증 : 국내 제품 품질 평가 위해 ISO 12119의 기준활용
다. 패키지도입 : 여러 패키지의 품질 상대비교, 적합한 제품선택
라. 패키지개발 : 제품의 품질 기준 제공, 인증 통한 신뢰성 제공
끝.
2013년 2월 24일 일요일
ISO 25000
문) ISO 25000
답)
1. SW품질평가 통합규격 ISO 25000의 개요
가. ISO 25000의 정의
- SW품질의 측정, 평가의 복잡성 해소위해 ISO9126, ISO14598의 평가 기준, 절차 통합 정리한 표준
나. ISO 25000의 필요성
- 기존 SW품질, 평가 표준모델의 모호성, 불일치 해소 필요
- 품질요구명세부터 품질판정까지 일관된 표준지침 제공
2. ISO 25000의 구성요소 및 표준간 차이점
가. ISO 25000의 구성요소
- SW품질관리 : 25000, Quality Management Division
- SW품질모델 : 25010, Quality Model Division
- SW품질측정 : 25020, Quality Metrix Division
- SW품질요구사항 : 25030, Quality Requirement Division
- SW품질평가 : 25040, Quality Evaluation Division
나. ISO 표준간 차이점
구분 ISO9126 ISO14598 ISO25000
주요기능 SW품질특성에 ISO9126에따른품질측정 ISO9126과ISO14598
대한표준제시 평가절차 통합
구성 4Parts 6Parts 5Parts
표준화 국제표준 국제표준 Final Draft
3. ISO 25000의 고려사항 및 활용현황
가. Tailoring : 조직특성에 맞게 Division조정 적용, 우선순위지정
나. 표준주도 : SQM-UG에 적극참여, ISO표준의 초석확보 필요
다. GS인증 : 국내 SW제품 품질평가 위한 기준에 포함
라. SOA기반 SW, 임베디드 SW등의 품질평가 모델로 활용
끝.
답)
1. SW품질평가 통합규격 ISO 25000의 개요
가. ISO 25000의 정의
- SW품질의 측정, 평가의 복잡성 해소위해 ISO9126, ISO14598의 평가 기준, 절차 통합 정리한 표준
나. ISO 25000의 필요성
- 기존 SW품질, 평가 표준모델의 모호성, 불일치 해소 필요
- 품질요구명세부터 품질판정까지 일관된 표준지침 제공
2. ISO 25000의 구성요소 및 표준간 차이점
가. ISO 25000의 구성요소
- SW품질관리 : 25000, Quality Management Division
- SW품질모델 : 25010, Quality Model Division
- SW품질측정 : 25020, Quality Metrix Division
- SW품질요구사항 : 25030, Quality Requirement Division
- SW품질평가 : 25040, Quality Evaluation Division
나. ISO 표준간 차이점
구분 ISO9126 ISO14598 ISO25000
주요기능 SW품질특성에 ISO9126에따른품질측정 ISO9126과ISO14598
대한표준제시 평가절차 통합
구성 4Parts 6Parts 5Parts
표준화 국제표준 국제표준 Final Draft
3. ISO 25000의 고려사항 및 활용현황
가. Tailoring : 조직특성에 맞게 Division조정 적용, 우선순위지정
나. 표준주도 : SQM-UG에 적극참여, ISO표준의 초석확보 필요
다. GS인증 : 국내 SW제품 품질평가 위한 기준에 포함
라. SOA기반 SW, 임베디드 SW등의 품질평가 모델로 활용
끝.
SW Factory
문) SW Factory
답)
1. SW 재사용을 통한 품질확보, SW Factory개요
가. SW Factory의 정의
- SW SDLC를 통하여 사용되는 패턴, 프레임워크, 툴, 템플릿, 요구사항, 테스트, 기계화, 프로세스 가이드 등 많은 자산을 체계적으로 재사용하는 것
나. SW Factory 구성요소
1) 프로세스(방법론) : 프로덕트를 개발하기 위하여 수행하는 작업 및 흐름
2) 조직및역할 : 프로세스를 수행하는 주체인 역할의 정의 및 역할의 구성
3) 도구및개발 : 프로세스를 수행하는데 요구되는 툴, 툴이 통합된 개발 환경
2. SW Factory 구축방법 및 Factory Schema/Template
가. SW Factory 구축방법
1) 원칙및가이드라인 정의 : 프로젝트, 프로세스 수행함에 있어서 요구되는 방향
2) 조직및역할정의 : 프로젝트 수행을 위해 요구되는 조직 구성 및 역할정의
3) 툴 통합을 통한 프로덕트 라인구축 : 툴 간의 원활한 흐름을 위해 프로세스 및 기법 검증 수행
4) SW 팩토리 슬림 파일럿 수행 : SW팩토리를 검증하기 위한 사항 정의, 슬림화, 파일럿 수행
나. Factory Schema/Template
구분 내용
FactorySchema SW Factory를 기술한 모델
- 특정한 유형의 App을 위한 기술서
- 문제도메인기술,작업산출물기술,작업흐름기술,자산기술
FactoryTemplate 커스터마이징 할 수 있는 자산의 커넥션
- 지침,패턴,예제코드,위저드,클래스라이브러리,프레임워크
3. SW Factory 장점 및 활용방안
가. 일관성 : 제품패밀리에 속하는 여러 제품을 일관성있게 개발, 단순화
나. 생산성 : 개발과정 자동화, SW자산의 재사용,확장가능,모델에서 코드생성
다. Web Service SW Factory를 활용, App개발의 효과적 방법제공
다. Mobile Client SW Factory를 활용, 다양한 모바일 기기에 대한 SW생산성 향상
끝.
답)
1. SW 재사용을 통한 품질확보, SW Factory개요
가. SW Factory의 정의
- SW SDLC를 통하여 사용되는 패턴, 프레임워크, 툴, 템플릿, 요구사항, 테스트, 기계화, 프로세스 가이드 등 많은 자산을 체계적으로 재사용하는 것
나. SW Factory 구성요소
1) 프로세스(방법론) : 프로덕트를 개발하기 위하여 수행하는 작업 및 흐름
2) 조직및역할 : 프로세스를 수행하는 주체인 역할의 정의 및 역할의 구성
3) 도구및개발 : 프로세스를 수행하는데 요구되는 툴, 툴이 통합된 개발 환경
2. SW Factory 구축방법 및 Factory Schema/Template
가. SW Factory 구축방법
1) 원칙및가이드라인 정의 : 프로젝트, 프로세스 수행함에 있어서 요구되는 방향
2) 조직및역할정의 : 프로젝트 수행을 위해 요구되는 조직 구성 및 역할정의
3) 툴 통합을 통한 프로덕트 라인구축 : 툴 간의 원활한 흐름을 위해 프로세스 및 기법 검증 수행
4) SW 팩토리 슬림 파일럿 수행 : SW팩토리를 검증하기 위한 사항 정의, 슬림화, 파일럿 수행
나. Factory Schema/Template
구분 내용
FactorySchema SW Factory를 기술한 모델
- 특정한 유형의 App을 위한 기술서
- 문제도메인기술,작업산출물기술,작업흐름기술,자산기술
FactoryTemplate 커스터마이징 할 수 있는 자산의 커넥션
- 지침,패턴,예제코드,위저드,클래스라이브러리,프레임워크
3. SW Factory 장점 및 활용방안
가. 일관성 : 제품패밀리에 속하는 여러 제품을 일관성있게 개발, 단순화
나. 생산성 : 개발과정 자동화, SW자산의 재사용,확장가능,모델에서 코드생성
다. Web Service SW Factory를 활용, App개발의 효과적 방법제공
다. Mobile Client SW Factory를 활용, 다양한 모바일 기기에 대한 SW생산성 향상
끝.
SLA
문) SLA
답)
1. 서비스 품질의 정량화 SLA의 개요
가. SLA(Service Level Agreement)의 정의
- 서비스의 품질을 측정하고 수치화하여 서비스를 지속적으로 평가, 개선하기 위한 서비스 품질계약
나. SLA의 목적
- 서비스 품질 향상 : 서비스의 지속적 측정과 개선
- 고객 만족도 향상 : 제공 품질 향상 통한 신뢰성 확보
2. SLA의 구성요소 및 효과적 측정위한 관리 요소
가. SLA의 구성요소
1) Service Catalog : 서비스 항목 목록. 서비스 제공 내역
2) Service Metrix : 정량적 측정 위한 측정 항목
3) Service Measure : 측정 지표, 영역별 측정 요소
4) Service Report : 측정 결과 보고서, 일별/월별 보고서
5) Service Object : 서비스 목표 수준 정의
나. SLA의 절차
1) 서비스조사 : 프로젝트 착수, 정보자원조사, 정보서비스 조사
2) 서비스정의 : SLO도출, 측정방법정의,SLA작성
3) 서비스협약 : 초기 Baseline측정, 서비스 목표설정, 협약설정
4) 서비스관리 : 서비스결과측정/보고, 평가및조치,지속적인 서비스통제
다. 효과적 SLA측정위한 관리요소
1) Penalty & Incentive : 목표 성과에 따른 차등 비용지급
2) HelpDesk : 서비스 제공 1차접점, 고객지원센터
3) CMDB : 서비스향상, 요구사항,측정결과보완
4) ITIL : ITSM제공을 위한 SKMS, CSI 등 제공제
3. SLA 고려사항과 활용방안
가. 정량화 : 서비스 사용자/제공자가 동의할 수 있는 수치 기반이어야 함.
나. IT-BSC : 고객, 재무, 학습과성장,내부프로세스 개선에 활용
다. 6시그마 : DMAIC/DFF/DMADV문제해결도구 활용한 서비스 품질향상
라. ITSM : IT서비스공급에 대한 비용 효과 측정
끝.
답)
1. 서비스 품질의 정량화 SLA의 개요
가. SLA(Service Level Agreement)의 정의
- 서비스의 품질을 측정하고 수치화하여 서비스를 지속적으로 평가, 개선하기 위한 서비스 품질계약
나. SLA의 목적
- 서비스 품질 향상 : 서비스의 지속적 측정과 개선
- 고객 만족도 향상 : 제공 품질 향상 통한 신뢰성 확보
2. SLA의 구성요소 및 효과적 측정위한 관리 요소
가. SLA의 구성요소
1) Service Catalog : 서비스 항목 목록. 서비스 제공 내역
2) Service Metrix : 정량적 측정 위한 측정 항목
3) Service Measure : 측정 지표, 영역별 측정 요소
4) Service Report : 측정 결과 보고서, 일별/월별 보고서
5) Service Object : 서비스 목표 수준 정의
나. SLA의 절차
1) 서비스조사 : 프로젝트 착수, 정보자원조사, 정보서비스 조사
2) 서비스정의 : SLO도출, 측정방법정의,SLA작성
3) 서비스협약 : 초기 Baseline측정, 서비스 목표설정, 협약설정
4) 서비스관리 : 서비스결과측정/보고, 평가및조치,지속적인 서비스통제
다. 효과적 SLA측정위한 관리요소
1) Penalty & Incentive : 목표 성과에 따른 차등 비용지급
2) HelpDesk : 서비스 제공 1차접점, 고객지원센터
3) CMDB : 서비스향상, 요구사항,측정결과보완
4) ITIL : ITSM제공을 위한 SKMS, CSI 등 제공제
3. SLA 고려사항과 활용방안
가. 정량화 : 서비스 사용자/제공자가 동의할 수 있는 수치 기반이어야 함.
나. IT-BSC : 고객, 재무, 학습과성장,내부프로세스 개선에 활용
다. 6시그마 : DMAIC/DFF/DMADV문제해결도구 활용한 서비스 품질향상
라. ITSM : IT서비스공급에 대한 비용 효과 측정
끝.
데이터마이닝
문) 데이터마이닝
답)
1. 정보의 가치 발견 통한 기업 의사결정 지원 데이터 마이닝 개요
가. 데이터마이닝(Data Mining)의 정의
- 대용량의 데이터로부터 알려지지 않는 정보, 패턴을 찾아 기업 의사결정에 활용하려는 데이터분석 및 지식 발견 과정
나. 데이터 마이닝의 추진 배경
비즈니스 측면 : 비즈니스 모델 예측을 통한 고객 행동 예측 및 패턴분석
비즈니스 모델 분석을 통한 수익 극대화 및 고객만족도 증가
정보기술 측면 : OLAP으로 발견하지 못한 데이터간의 관계를 분석하여
효과적인 의사결정 지원
2. 데이터 마이닝의 주요기법 및 절차
가. 데이터 마이닝의 주요기법
기법 주요내용 활용사례
의사결정나무 기준값근거분류및예측모델생성 우수고객 분류모형
신경망 반복적학습을통한패턴도출 연체자 예측
연관성분석 데이터안의 항목간 종속관계도출 장바구니 분석
연속규칙 연관규칙에 시간관련 정보가포함 신차구입후 Navi구매
군집화 유사한특성을지닌데이터 그룹화 고객분류 마케팅
나. 데이터마이닝 절차
단계 세부내용 고려사항
현황분석 마이닝목적정의,주제영역도출,사전지식준비 전략연계
데이터센터 필요한데이터의위치,형태,완전성파악및통합
데이터정제 데이터의모호성과중복성제거,오류값보정 데이터무결성
데이터변환 불필요데이터삭제및신규파생데이터생성 파생,잔여Data
데이터마이닝 데이터마이닝기법을 선택하고 수행 설명력,효율성
해석및평가 결과해석및비즈니스에 활용하고평가함 지속적피드백
3. 데이터마이닝의 적용사례 및 고려사항
가. 은행의 대출심사, 보험의 보험금 지급심사, 증권의 주각예측
통신의 통화상세레코드분석, 유통의 물동량 예측 등에 활용
나. 수집된 고객 정보의 불확실성에 의해 분석이 왜곡되는 경우가 많음
때문에 분석의 정확성 보다는 기초 데이터의 내실을 기하는 방안 강구
끝.
답)
1. 정보의 가치 발견 통한 기업 의사결정 지원 데이터 마이닝 개요
가. 데이터마이닝(Data Mining)의 정의
- 대용량의 데이터로부터 알려지지 않는 정보, 패턴을 찾아 기업 의사결정에 활용하려는 데이터분석 및 지식 발견 과정
나. 데이터 마이닝의 추진 배경
비즈니스 측면 : 비즈니스 모델 예측을 통한 고객 행동 예측 및 패턴분석
비즈니스 모델 분석을 통한 수익 극대화 및 고객만족도 증가
정보기술 측면 : OLAP으로 발견하지 못한 데이터간의 관계를 분석하여
효과적인 의사결정 지원
2. 데이터 마이닝의 주요기법 및 절차
가. 데이터 마이닝의 주요기법
기법 주요내용 활용사례
의사결정나무 기준값근거분류및예측모델생성 우수고객 분류모형
신경망 반복적학습을통한패턴도출 연체자 예측
연관성분석 데이터안의 항목간 종속관계도출 장바구니 분석
연속규칙 연관규칙에 시간관련 정보가포함 신차구입후 Navi구매
군집화 유사한특성을지닌데이터 그룹화 고객분류 마케팅
나. 데이터마이닝 절차
단계 세부내용 고려사항
현황분석 마이닝목적정의,주제영역도출,사전지식준비 전략연계
데이터센터 필요한데이터의위치,형태,완전성파악및통합
데이터정제 데이터의모호성과중복성제거,오류값보정 데이터무결성
데이터변환 불필요데이터삭제및신규파생데이터생성 파생,잔여Data
데이터마이닝 데이터마이닝기법을 선택하고 수행 설명력,효율성
해석및평가 결과해석및비즈니스에 활용하고평가함 지속적피드백
3. 데이터마이닝의 적용사례 및 고려사항
가. 은행의 대출심사, 보험의 보험금 지급심사, 증권의 주각예측
통신의 통화상세레코드분석, 유통의 물동량 예측 등에 활용
나. 수집된 고객 정보의 불확실성에 의해 분석이 왜곡되는 경우가 많음
때문에 분석의 정확성 보다는 기초 데이터의 내실을 기하는 방안 강구
끝.
EAI
문) EAI
답)
1. 기업내 이기종 Application의 통합 EAI의 개요
가. EAI(Enterprise Architecture Integration)의 정의
- 기업내 연관된 Application과 Data를 관리, 통합할수 있는 벤더종속적 중앙집중형 미들웨어 솔루션
나. EAI 표준화 방안
- 인터페이스 패턴 표준화 : 송/수신 시스템 간 데이터 연계방식 정의
- Adapter 유형 표준화 : DB, File, Socket, Packet Adapter(송수신 I/F)
- 자원표준화 : 명명규칙 표준화, EAI디렉토리 구조 정의
- 보안체계 표준화 : 사용자 ID관리, 인터페이스 데이터 암호화
- 운영표준화 : EAI 솔루션 설치, 구성절차, 장애/백업절차, 모니터링
2. EAI의 주요기능 및 제품관점에서의 EAI활용
가. EAI의 주요기능
- Adapter : 이기종 패키지 연결, 데이터중계 및 인터페이스 담당
- Data Broker : 데이터 Mapping, 데이터 자동변환
- Workflow : 비즈니스 프로세스 자동화 수행
- EAI Platform : 데이터의 안전한 전달, 메시징/미들웨어 기능
나. 제품관점에서의 EAI 활용
- 사용자 및 자원접근 제한, 메타데이터 관리
- 데이터무결성 및 정합성 보장, 실시간 처리
- 장애처리 방안제공, 이중화 지원, 다양한 연계
- 시스템 및 프로세스 상태관리, Fail over 기능, 고가용성 제공
3. Open Standard 기반의 ESB와의 비교
구분 EAI ESB
통합대상 기업내이기종 application 기업내외 서비스
통합방법 중앙집중형(Hub&Spoke) 분산형(Message Bus)
통합도구 벤더종속 Adapter 개방표준 Driver
비용/기타 고비용/강결합 저비용/약결합
끝.
답)
1. 기업내 이기종 Application의 통합 EAI의 개요
가. EAI(Enterprise Architecture Integration)의 정의
- 기업내 연관된 Application과 Data를 관리, 통합할수 있는 벤더종속적 중앙집중형 미들웨어 솔루션
나. EAI 표준화 방안
- 인터페이스 패턴 표준화 : 송/수신 시스템 간 데이터 연계방식 정의
- Adapter 유형 표준화 : DB, File, Socket, Packet Adapter(송수신 I/F)
- 자원표준화 : 명명규칙 표준화, EAI디렉토리 구조 정의
- 보안체계 표준화 : 사용자 ID관리, 인터페이스 데이터 암호화
- 운영표준화 : EAI 솔루션 설치, 구성절차, 장애/백업절차, 모니터링
2. EAI의 주요기능 및 제품관점에서의 EAI활용
가. EAI의 주요기능
- Adapter : 이기종 패키지 연결, 데이터중계 및 인터페이스 담당
- Data Broker : 데이터 Mapping, 데이터 자동변환
- Workflow : 비즈니스 프로세스 자동화 수행
- EAI Platform : 데이터의 안전한 전달, 메시징/미들웨어 기능
나. 제품관점에서의 EAI 활용
- 사용자 및 자원접근 제한, 메타데이터 관리
- 데이터무결성 및 정합성 보장, 실시간 처리
- 장애처리 방안제공, 이중화 지원, 다양한 연계
- 시스템 및 프로세스 상태관리, Fail over 기능, 고가용성 제공
3. Open Standard 기반의 ESB와의 비교
구분 EAI ESB
통합대상 기업내이기종 application 기업내외 서비스
통합방법 중앙집중형(Hub&Spoke) 분산형(Message Bus)
통합도구 벤더종속 Adapter 개방표준 Driver
비용/기타 고비용/강결합 저비용/약결합
끝.
DRM
문) DRM
답)
1. 디지털 저작권보호를 위한 DRM 개요
가. DRM(Digital Rights Management)의 정의
- 허가받은 정당한 사용자가 허용된 권한 범위내에서 디지털 컨텐츠를 이용할 수 있도록 통제하는 기술
나. DRM과 M-DRM차이점
- DRM : De facto Standard, Rich Media, 컨텐츠 무료인식, DRM에 대한 강한 거부감
- M-DRM : OMA M-DRM표준 주도, Light Media, 컨텐츠 유료화에 대한 거부감 적음
2. DRM 구성요소 및 주요기능
가. DRM 구성요소
- 컨텐츠 제공자 : 컨텐츠 제공하는 저작권자
- 컨텐츠 분배자 : 암호화된 컨텐츠 제공
- 패키저 : 컨텐츠를 배포 가능한 단위로 묶음
- 보안 컨테이너 : 컨텐츠 안전유통 위한 전자적 보안장치
- DRM 컨트롤러 : 배포된 컨텐츠의 이용 권한 통제
- 클리어링 하우스 : 키 관리 및 라이센스 관리
나. DRM 주요기능
- 디지털 컨텐츠 식별체계 : 컨텐츠 식별 및 검색(DOI, MPEG21)
- 불법적인 접근, 복제방지 : 사용/접근제어(워터마킹, 핑거프린팅, SSO)
- 사용 규칙의 정의, 표현 : 저작권 관리 표현 언어(XrML2.0)
- 과금 및 거래 내역관리 : 라이센스 생성,발급(3DES, AES, ECC)
3. DRM 기대효과 및 고려사항
가. E-learning(강의/교재보호),KMS(정보자산의 외부누출방지),의료(처방전, x-ray보호), 모바일기기(m-DRM)적용, 다양한 비즈니스 수익모델(음악,영상)발굴
나. 표준규격부재, 제품간 상호호환성 결여, 디지털컨텐츠 유통시장 미성숙
유연성 및 확장성 결여
끝.
답)
1. 디지털 저작권보호를 위한 DRM 개요
가. DRM(Digital Rights Management)의 정의
- 허가받은 정당한 사용자가 허용된 권한 범위내에서 디지털 컨텐츠를 이용할 수 있도록 통제하는 기술
나. DRM과 M-DRM차이점
- DRM : De facto Standard, Rich Media, 컨텐츠 무료인식, DRM에 대한 강한 거부감
- M-DRM : OMA M-DRM표준 주도, Light Media, 컨텐츠 유료화에 대한 거부감 적음
2. DRM 구성요소 및 주요기능
가. DRM 구성요소
- 컨텐츠 제공자 : 컨텐츠 제공하는 저작권자
- 컨텐츠 분배자 : 암호화된 컨텐츠 제공
- 패키저 : 컨텐츠를 배포 가능한 단위로 묶음
- 보안 컨테이너 : 컨텐츠 안전유통 위한 전자적 보안장치
- DRM 컨트롤러 : 배포된 컨텐츠의 이용 권한 통제
- 클리어링 하우스 : 키 관리 및 라이센스 관리
나. DRM 주요기능
- 디지털 컨텐츠 식별체계 : 컨텐츠 식별 및 검색(DOI, MPEG21)
- 불법적인 접근, 복제방지 : 사용/접근제어(워터마킹, 핑거프린팅, SSO)
- 사용 규칙의 정의, 표현 : 저작권 관리 표현 언어(XrML2.0)
- 과금 및 거래 내역관리 : 라이센스 생성,발급(3DES, AES, ECC)
3. DRM 기대효과 및 고려사항
가. E-learning(강의/교재보호),KMS(정보자산의 외부누출방지),의료(처방전, x-ray보호), 모바일기기(m-DRM)적용, 다양한 비즈니스 수익모델(음악,영상)발굴
나. 표준규격부재, 제품간 상호호환성 결여, 디지털컨텐츠 유통시장 미성숙
유연성 및 확장성 결여
끝.
UML 2.0 추가 다이어그램
문) UML 2.0 추가 다이어그램
답)
1. 비주얼한 분석과 설계, UML 2.0개요
가. UML(Unified Modeling Lanaguage)정의
- 다양한 객체 모델링 기법을 통합하여 만든 모델링 언어로 도형과 기호를 이용하여 S/W를 가시화
나. UML 2.0의 변화
- SDL/MSC 수용 : 대규모 복잡한 시스템의 구조화를 목적
- MDA 수용 : 다양한 플랫폼에서 PIM/PSM 작성 지원 목적
2. UML 2.0의 추가 다이어그램
가. Composite Structure Diagram
- 다른 컴포넌트와 연동되는 컴포넌트의 내부 구조 표현
예) 사람, 학교, 학원으로 구성되는 학생
나. Timing Diagram
- 시간의 변화에 따른 상태나 값의 변화 표현
예) 시간의 변화에 따른 학년 진급
다. Interaction Overview Diagram
- diagram의 요소로서 다른 diagram을 포함하여 전체적인 조망
3. UML 2.0추가 다이어그램 활용방안
가. composite structure : Mediator, Observer 패턴이 내장된 컴포넌트(인터페이스 기반 상호연동) 구조화
나. Timing : Cron/Timer기반 주기적 작업
(예: 지정 시간의 DB백업, 메시지 전달)
다. Interaction Overview : 간단한 세부흐름으로 구성된 복잡한 하나의 프로세스의 표현
끝.
답)
1. 비주얼한 분석과 설계, UML 2.0개요
가. UML(Unified Modeling Lanaguage)정의
- 다양한 객체 모델링 기법을 통합하여 만든 모델링 언어로 도형과 기호를 이용하여 S/W를 가시화
나. UML 2.0의 변화
- SDL/MSC 수용 : 대규모 복잡한 시스템의 구조화를 목적
- MDA 수용 : 다양한 플랫폼에서 PIM/PSM 작성 지원 목적
2. UML 2.0의 추가 다이어그램
가. Composite Structure Diagram
- 다른 컴포넌트와 연동되는 컴포넌트의 내부 구조 표현
예) 사람, 학교, 학원으로 구성되는 학생
나. Timing Diagram
- 시간의 변화에 따른 상태나 값의 변화 표현
예) 시간의 변화에 따른 학년 진급
다. Interaction Overview Diagram
- diagram의 요소로서 다른 diagram을 포함하여 전체적인 조망
3. UML 2.0추가 다이어그램 활용방안
가. composite structure : Mediator, Observer 패턴이 내장된 컴포넌트(인터페이스 기반 상호연동) 구조화
나. Timing : Cron/Timer기반 주기적 작업
(예: 지정 시간의 DB백업, 메시지 전달)
다. Interaction Overview : 간단한 세부흐름으로 구성된 복잡한 하나의 프로세스의 표현
끝.
ISMP
문) ISMP
답)
1. 발주사 요구사항 명확화를 위한 ISMP의 개요
가. ISMP(Information System Master Plan)의 정의
- SW개발사업에 대한 상세분석과 RFP마련을 위하여 현황/요구사항을 분석하고 기능점수 도출이 가능한 수준까지 요건기술, 구축전략, 이행계획 수립
나. ISMP와 ISP 차이점
항목 ISMP ISP
목적 특정 정보시스템 기능적,기술적 경영전략과 정보화 전략 연계 및
비기능적 요구사항 상세화 새로운 정보기술 반영
범위 단위프로젝트 또는 단위프로젝트 전사,서비스 또는 부서대상 정보화
묶음 전략
주요 정보시스템구축범위및방향수립 경영환경분석,최근정보기술동향분
활동 요건도출,정보시스템 구조/요건 업무/정보시스템 구조 분석
상세기술,정보시스템구축 구축 정보전략,정보관리체계 수립
사업계획수립 미래업무프로세스,정보시스템구조설
예산산정,업체선정,평가지원 계
2. ISMP 추진방법론 및 사업대가 기준
가. ISMP 추진 방법론
> 프로젝트 착수 및 참여자결정 : 의사결정자,수행조직인력,역할정의
> 정보시스템방향성수립 : 사업이해,과제식별,정보시스템구축추진범위정의
> 업무및정보기술현황분석 : 업무프로세스,아키텍처분석및요건우선순위평가
> 정보시스템구조및요건정의 : To-Be아키텍처정의,재사용요소파악,요건기술서작성
> 정보시스템구축사업 이행방안수립 : 구축범위확정, 관련패키지 분석을 통한 분리발주 가능성조사, 예산수립, RFP작성, 구축업체평가선정
나. ISMP 사업대가 기준
ISMP사업대가=기술사1개월공수*(컨설팅지수)0.95*10,000,000
- 컨설팅지수는 "수행활동별가중치"*"난이도"로 계산
- "수행활동별가중치"는 ISMP사업에서 수행되는 업무의 가중치 합산
- "난이도"는 조직규모, 업무처리 복잡도 등9개 요소의 난이도 곱
3. ISMP기대효과 및 고려사항
가. SW사업 품질제고, SW기업 수익성 개선 및 경쟁력 강화
나. ISMP사업대가 산정식은 경험치 데이터에 근거하여 개선필요
다. 법정 강제성이 없어 실제 활용여부 미지수
답)
1. 발주사 요구사항 명확화를 위한 ISMP의 개요
가. ISMP(Information System Master Plan)의 정의
- SW개발사업에 대한 상세분석과 RFP마련을 위하여 현황/요구사항을 분석하고 기능점수 도출이 가능한 수준까지 요건기술, 구축전략, 이행계획 수립
나. ISMP와 ISP 차이점
항목 ISMP ISP
목적 특정 정보시스템 기능적,기술적 경영전략과 정보화 전략 연계 및
비기능적 요구사항 상세화 새로운 정보기술 반영
범위 단위프로젝트 또는 단위프로젝트 전사,서비스 또는 부서대상 정보화
묶음 전략
주요 정보시스템구축범위및방향수립 경영환경분석,최근정보기술동향분
활동 요건도출,정보시스템 구조/요건 업무/정보시스템 구조 분석
상세기술,정보시스템구축 구축 정보전략,정보관리체계 수립
사업계획수립 미래업무프로세스,정보시스템구조설
예산산정,업체선정,평가지원 계
2. ISMP 추진방법론 및 사업대가 기준
가. ISMP 추진 방법론
> 프로젝트 착수 및 참여자결정 : 의사결정자,수행조직인력,역할정의
> 정보시스템방향성수립 : 사업이해,과제식별,정보시스템구축추진범위정의
> 업무및정보기술현황분석 : 업무프로세스,아키텍처분석및요건우선순위평가
> 정보시스템구조및요건정의 : To-Be아키텍처정의,재사용요소파악,요건기술서작성
> 정보시스템구축사업 이행방안수립 : 구축범위확정, 관련패키지 분석을 통한 분리발주 가능성조사, 예산수립, RFP작성, 구축업체평가선정
나. ISMP 사업대가 기준
ISMP사업대가=기술사1개월공수*(컨설팅지수)0.95*10,000,000
- 컨설팅지수는 "수행활동별가중치"*"난이도"로 계산
- "수행활동별가중치"는 ISMP사업에서 수행되는 업무의 가중치 합산
- "난이도"는 조직규모, 업무처리 복잡도 등9개 요소의 난이도 곱
3. ISMP기대효과 및 고려사항
가. SW사업 품질제고, SW기업 수익성 개선 및 경쟁력 강화
나. ISMP사업대가 산정식은 경험치 데이터에 근거하여 개선필요
다. 법정 강제성이 없어 실제 활용여부 미지수
형상관리와 변경관리
문) 형상관리와 변경관리
답)
1.
가. 형상관리와 변경관리 개념
- 형상관리 : 개발소스 및 산출물에 대한 전반적인 관리체계
- 변경관리 : 동시수정 및 버전관리 위한 관리체계
나. 형상관리와 변경관리 체계
- 형상관리 구성>변경관리 : 소스코드 버전관리
배포관리 : 실행코드 버전 관리
2. 형상관리 및 변경관리의 기능
가. 형상관리의 기능
1) 형상식별 : IT Asset 식별, ID부여한 추적관리
2) 형상통제 : CCB(형상관리위원회) 통한 변경 및 배포관리
3) 형상감사 : History 추적하여 책임소재 명확화
4) 형상기록 : CMDB(Repository) 통한 Versionning
나. 변경관리의 기능
1) 소스의 동시수정 방지한 Check in/out
2) Tool : 특별한 개발도구 또는 eclips에서 지원되는 library제공
3) Comparity : 이전 버전과 수정사항 비교가능
4) 배포관리 기능 포함 (Deployment /Rollback)
3. 형상관리 및 변경관리 방안 및 기대효과
가. ITIL & ITSM : IT조직의 개발 및 운영 Roll&Responsibility 분리하여 관리
ITAM : 소스코드와 더불어 산출물관리(ITA)
나. 소스코드 일관성, 개발 효율성 통한 생산성 극대화
잘못 수정된 소스 반영으로 인한 Application 장애방지
끝.
답)
1.
가. 형상관리와 변경관리 개념
- 형상관리 : 개발소스 및 산출물에 대한 전반적인 관리체계
- 변경관리 : 동시수정 및 버전관리 위한 관리체계
나. 형상관리와 변경관리 체계
- 형상관리 구성>변경관리 : 소스코드 버전관리
배포관리 : 실행코드 버전 관리
2. 형상관리 및 변경관리의 기능
가. 형상관리의 기능
1) 형상식별 : IT Asset 식별, ID부여한 추적관리
2) 형상통제 : CCB(형상관리위원회) 통한 변경 및 배포관리
3) 형상감사 : History 추적하여 책임소재 명확화
4) 형상기록 : CMDB(Repository) 통한 Versionning
나. 변경관리의 기능
1) 소스의 동시수정 방지한 Check in/out
2) Tool : 특별한 개발도구 또는 eclips에서 지원되는 library제공
3) Comparity : 이전 버전과 수정사항 비교가능
4) 배포관리 기능 포함 (Deployment /Rollback)
3. 형상관리 및 변경관리 방안 및 기대효과
가. ITIL & ITSM : IT조직의 개발 및 운영 Roll&Responsibility 분리하여 관리
ITAM : 소스코드와 더불어 산출물관리(ITA)
나. 소스코드 일관성, 개발 효율성 통한 생산성 극대화
잘못 수정된 소스 반영으로 인한 Application 장애방지
끝.
2013년 2월 20일 수요일
Product Line
문) 프로덕트 라인
답)
1. 핵심자산의 전략적 재사용, product line 개요
가. 프로덕트 라인의 정의
- 제품, 서비스별 core asset을 개발하고, 이를 관리 재사용하여 경제적인 소프트웨어를 생산하는 개발방법론
나. product line category
- Domain Engineering : core asset(요구사항, 아키텍처, 컴포넌트, test case)개발
- Application Engineering : core asset을 활용한 제품 개발, 가변부 customizing, 사용 피드백 전달
- Management : Domain, Application 관리 연동
2. Product Line 도입전략과 core asset 가변성 부여
가. Product Line 도입전략
방향 개발범위
상향식ㅣ기존제품 다수의 많음 ㅣ *계층적도메인
ㅣ버전향상 제품개발 ㅣ 공학부서
ㅣ ㅣ *도메인공학부서
ㅣ대규모 전략적 ㅣ *업무부서
ㅣ제품개발 프로토타입 ㅣ *개발부서
ㅣ ㅣ
하향식 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ모델 적음 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
능동형 반응형 작음 큼
- 조직의 특성과 제품의 형태 -조직규모와 조직의 형태
- 조직의 규모가 클수록 core asset 개발 전담조직(도메인,공학부서),하향식(top-down), 능동형 적합
나. core asset의 가변성(variation)부여 방식
- 파라미터 : 조건적 컴파일, 설정값 수정 빌드
- 라이브러리 : 정적(컴파일, 빌드), 동적(실행시점) 라이브러리
- 가변점 지정 : realization(인터페이스),generalization
- overloading, overriding : 클래스의 필요부분 재정의
- reflection : 실행시간 상황에 따른 제어변경
3. product line의 기대효과와 고려사항
가. 개발측면 : core asset 조립기반 시간비용 절감
나. 비즈니스 측면 : 빠른 제품개발을 통한 적시성 확보
다. 관리측면 : 제품간 core asset도출, 지속적 관리 필요
라. 구축비용 : 초기 구축시 추가적 시간비용 발생
끝.
답)
1. 핵심자산의 전략적 재사용, product line 개요
가. 프로덕트 라인의 정의
- 제품, 서비스별 core asset을 개발하고, 이를 관리 재사용하여 경제적인 소프트웨어를 생산하는 개발방법론
나. product line category
- Domain Engineering : core asset(요구사항, 아키텍처, 컴포넌트, test case)개발
- Application Engineering : core asset을 활용한 제품 개발, 가변부 customizing, 사용 피드백 전달
- Management : Domain, Application 관리 연동
2. Product Line 도입전략과 core asset 가변성 부여
가. Product Line 도입전략
방향 개발범위
상향식ㅣ기존제품 다수의 많음 ㅣ *계층적도메인
ㅣ버전향상 제품개발 ㅣ 공학부서
ㅣ ㅣ *도메인공학부서
ㅣ대규모 전략적 ㅣ *업무부서
ㅣ제품개발 프로토타입 ㅣ *개발부서
ㅣ ㅣ
하향식 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ모델 적음 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
능동형 반응형 작음 큼
- 조직의 특성과 제품의 형태 -조직규모와 조직의 형태
- 조직의 규모가 클수록 core asset 개발 전담조직(도메인,공학부서),하향식(top-down), 능동형 적합
나. core asset의 가변성(variation)부여 방식
- 파라미터 : 조건적 컴파일, 설정값 수정 빌드
- 라이브러리 : 정적(컴파일, 빌드), 동적(실행시점) 라이브러리
- 가변점 지정 : realization(인터페이스),generalization
- overloading, overriding : 클래스의 필요부분 재정의
- reflection : 실행시간 상황에 따른 제어변경
3. product line의 기대효과와 고려사항
가. 개발측면 : core asset 조립기반 시간비용 절감
나. 비즈니스 측면 : 빠른 제품개발을 통한 적시성 확보
다. 관리측면 : 제품간 core asset도출, 지속적 관리 필요
라. 구축비용 : 초기 구축시 추가적 시간비용 발생
끝.
2013년 2월 19일 화요일
ITIL v3
문) ITIL v3
답)
1. IT서비스의 비즈니스 가치 제공을 위한 지침모델, ITIL v3의 개요
가. ITIL(IT Infrastructure Library)의 정의
- 고객의 비즈니스 목표달성을 위해 고품질의 IT서비스를 체계적으로 구축 및 지원하기 위한 IT서비스관리 분야의 Best Practice 모음집
나. ITIL version의 발전
운영관리(OM) > 서비스관리(SM) > 비즈니스가치(Value)
ITIL v2(SLA/SLM) ITIL v3(IT-BSC/Biz Alignment)
- ITIL v3는 기존 운영/관리를 넘어 비즈니스를 리딩하기 위한 모습을 제시
2. ITIL v3의 주요 특징 및 구성요소
가. 주요특징
주요특징 설명
비즈니스 연계 비즈니스와 연계된 지표 및 체계 구축(ROI/IT-BSC)
LifeCycle IT서비스전체를 지원하는 LifeCycle중심/지속적인 개선모델
IT Governance IT Governance의 체계 구축 및 실행 위한 지침 모델
- ITIL v2의 Service Support, Service Deliver의 프로세스 강화, ISO 20000요구 프로세스 포함
나. 구성요소
구성요소 설명
서비스전략 서비스전략 계획수립, 비즈니스와 IT전략방향 연계
서비스설계 설계목표와 구성요소, 비용모델, 위험분석
서비스전환 변경관리, 배포 및 배피관리, 테스트 및 지식관리
서비스운영 이벤트관리, 요청관리, 문제관리, 접근관리, 운영활동
지속적인개선 IT서비스 생명주기 기반의 개선활동, 측정 및 보고
3. ITIL v2와 비교 및 현황
가. ITIL v2와 v3의 비교3
항목 ITIL v2 ITIL v3
Library 8개영역(핵심:SS,SD) 5개영역(SS,SD,ST,SO,CSI)
Process 1개 Function + 10개프로세스 10개 프로세스
ROI ROI 측정방안 제시 안함(x) ROI 측정방안제시(ㅇ)
표준 ISO 9000, EFQM, CMM ISO20000, ISO27001,COBIT,CMMI,e-SCM
주요특성 SLM중심 서비스관리 비즈니스가치중심의 ITSM제시/거버넌스
나. 현황
- ITO 프레임워크제공, 프로세스표준화, ROI극대화, IT서비스의 체계화/품질보증/측정관리 효과
- IT의 ROI극대화/고객가치 극대화는 비즈니스 목표와 연계하여 IT서비스 분야의 지속적인 노력과 성과측정을 통해 달성 가능하며 최고경영층의 거버넌스관점과 전사적인 지원이 필요
끝.
답)
1. IT서비스의 비즈니스 가치 제공을 위한 지침모델, ITIL v3의 개요
가. ITIL(IT Infrastructure Library)의 정의
- 고객의 비즈니스 목표달성을 위해 고품질의 IT서비스를 체계적으로 구축 및 지원하기 위한 IT서비스관리 분야의 Best Practice 모음집
나. ITIL version의 발전
운영관리(OM) > 서비스관리(SM) > 비즈니스가치(Value)
ITIL v2(SLA/SLM) ITIL v3(IT-BSC/Biz Alignment)
- ITIL v3는 기존 운영/관리를 넘어 비즈니스를 리딩하기 위한 모습을 제시
2. ITIL v3의 주요 특징 및 구성요소
가. 주요특징
주요특징 설명
비즈니스 연계 비즈니스와 연계된 지표 및 체계 구축(ROI/IT-BSC)
LifeCycle IT서비스전체를 지원하는 LifeCycle중심/지속적인 개선모델
IT Governance IT Governance의 체계 구축 및 실행 위한 지침 모델
- ITIL v2의 Service Support, Service Deliver의 프로세스 강화, ISO 20000요구 프로세스 포함
나. 구성요소
구성요소 설명
서비스전략 서비스전략 계획수립, 비즈니스와 IT전략방향 연계
서비스설계 설계목표와 구성요소, 비용모델, 위험분석
서비스전환 변경관리, 배포 및 배피관리, 테스트 및 지식관리
서비스운영 이벤트관리, 요청관리, 문제관리, 접근관리, 운영활동
지속적인개선 IT서비스 생명주기 기반의 개선활동, 측정 및 보고
3. ITIL v2와 비교 및 현황
가. ITIL v2와 v3의 비교3
항목 ITIL v2 ITIL v3
Library 8개영역(핵심:SS,SD) 5개영역(SS,SD,ST,SO,CSI)
Process 1개 Function + 10개프로세스 10개 프로세스
ROI ROI 측정방안 제시 안함(x) ROI 측정방안제시(ㅇ)
표준 ISO 9000, EFQM, CMM ISO20000, ISO27001,COBIT,CMMI,e-SCM
주요특성 SLM중심 서비스관리 비즈니스가치중심의 ITSM제시/거버넌스
나. 현황
- ITO 프레임워크제공, 프로세스표준화, ROI극대화, IT서비스의 체계화/품질보증/측정관리 효과
- IT의 ROI극대화/고객가치 극대화는 비즈니스 목표와 연계하여 IT서비스 분야의 지속적인 노력과 성과측정을 통해 달성 가능하며 최고경영층의 거버넌스관점과 전사적인 지원이 필요
끝.
Ajax
문) Ajax
답)
1. Web 2.0을 구현 기술 Ajax의 개요
가. Ajax(Asynchronous javascript and XML)의 정의
- 웹페이지를 생성시 페이지 깜빡임(Refresh or Reload)을 최소화하는 비동기식 데이터 전송 방식의 프로그래밍 기법
나. 웹컨텐츠 생성시 Ajax의 주목원인
- 비동기 방식 : 대량의 데이터 송수신시 브라우저 처리의 오버헤드, 네트워크 부하
- View : 데이타변경 시마다 발생하는 페이지 깜빡임. iframe 해결시 코드의 복잡성
2. Ajax의 구현을 위한 주요 기술과 구현 코드 예제
가. Ajax의 구현을 위한 주요 기술
- json : java script 기반의 load data, 속성 변수명과 속성값으로 간략 구성
- 구현 Platform : Flex, 실버라이트, 트러스트폼, 마이플랫폼 등
- Web Service : XML, UDDI, WSDL, W3C 표준
- javascript : XMLHttpRequest, send, open, put Method 사용, css 등
나. javascript 를 이용한 Ajax 구현 코드
<script lanaguage = 'javascript'>
if (window.XMLHttpRequest) {
var xmlHttp = XMLHttpRequest.open ('GET','http:www.site.com/getDate.jsp'. true);
if (xmlHttp) {
xmlHttp.send(null) ;
var strText = xmlHttp.responseText ;
}
}
</script>
3. Ajax가 Web2.0에 미치는 영향과 기대효과
가. RIA : 멀티미디어 중심의 표현 가능, 의미 전달성 향상, 이동 경로의 단순화
나. eXtended : 대량처리 가능, SOA적용, Interface 향상
끝.
답)
1. Web 2.0을 구현 기술 Ajax의 개요
가. Ajax(Asynchronous javascript and XML)의 정의
- 웹페이지를 생성시 페이지 깜빡임(Refresh or Reload)을 최소화하는 비동기식 데이터 전송 방식의 프로그래밍 기법
나. 웹컨텐츠 생성시 Ajax의 주목원인
- 비동기 방식 : 대량의 데이터 송수신시 브라우저 처리의 오버헤드, 네트워크 부하
- View : 데이타변경 시마다 발생하는 페이지 깜빡임. iframe 해결시 코드의 복잡성
2. Ajax의 구현을 위한 주요 기술과 구현 코드 예제
가. Ajax의 구현을 위한 주요 기술
- json : java script 기반의 load data, 속성 변수명과 속성값으로 간략 구성
- 구현 Platform : Flex, 실버라이트, 트러스트폼, 마이플랫폼 등
- Web Service : XML, UDDI, WSDL, W3C 표준
- javascript : XMLHttpRequest, send, open, put Method 사용, css 등
나. javascript 를 이용한 Ajax 구현 코드
<script lanaguage = 'javascript'>
if (window.XMLHttpRequest) {
var xmlHttp = XMLHttpRequest.open ('GET','http:www.site.com/getDate.jsp'. true);
if (xmlHttp) {
xmlHttp.send(null) ;
var strText = xmlHttp.responseText ;
}
}
</script>
3. Ajax가 Web2.0에 미치는 영향과 기대효과
가. RIA : 멀티미디어 중심의 표현 가능, 의미 전달성 향상, 이동 경로의 단순화
나. eXtended : 대량처리 가능, SOA적용, Interface 향상
끝.
DWDM
문) DWDM
답)
1. 고밀도 파장 분할 DWDM의 개요
가. DWDM(Dense Wave Division Multiplexing)의 정의
- 광케이블의 효율성을 높이기 위하여 광케이블의 파장을 여러개로 분할/다증화하는 광통신 기술
나. DWDM의 부각이유
- 효율적 통신 : 광케이블 매설 불필요, 기존 광케이블 효과 극대화
- 다양한 서비스 : 파장에 따른 I/F, 파장별 서비스 가능
2. DWDM의 구성요소 및 DWDM종류간 비교
가. DWDM의 구성요소
종류 설명
MUX - 파장분할/다중화, 파장세분화, 1개의 파장에 10Ghz전송가능
증폭기 - 신호증폭, 리피터, 장거리 전송, 선로손실보장, 신호세기보장
분배반 - 파장별 Add/Drop, 파장관리, 파장에 선택, 서비스 차별화
나. DWDM 종류간 비교
구분 MetroDWDM 장거리DWDM
목적 Metropolitan 망 운용 600~800km 장거리 망 운용
특징 64채널, 160Gbps 32~40채널, Point to Point
활용 BCP, DR 원격지 백업
범위 도시, 특정지역 지역간, 도시간 연결
3. DWDM의 활용방안 및 고려사항
가. 해외 네트워크 : 글로벌 지사 연결, 가상기업, 다국적 기업
나. 지역 데이터 전송 : 지역정보, 중앙부터-지자체간 데이터 업데이트(지도 등)
다. 전송품질 : 증폭기 개선, 선로 유지보수, 신호 손실 최소화
라. ROI분석 : 광케이블 고가, 시스템 구축 고비용, 투자 분석수행 필요
끝.
답)
1. 고밀도 파장 분할 DWDM의 개요
가. DWDM(Dense Wave Division Multiplexing)의 정의
- 광케이블의 효율성을 높이기 위하여 광케이블의 파장을 여러개로 분할/다증화하는 광통신 기술
나. DWDM의 부각이유
- 효율적 통신 : 광케이블 매설 불필요, 기존 광케이블 효과 극대화
- 다양한 서비스 : 파장에 따른 I/F, 파장별 서비스 가능
2. DWDM의 구성요소 및 DWDM종류간 비교
가. DWDM의 구성요소
종류 설명
MUX - 파장분할/다중화, 파장세분화, 1개의 파장에 10Ghz전송가능
증폭기 - 신호증폭, 리피터, 장거리 전송, 선로손실보장, 신호세기보장
분배반 - 파장별 Add/Drop, 파장관리, 파장에 선택, 서비스 차별화
나. DWDM 종류간 비교
구분 MetroDWDM 장거리DWDM
목적 Metropolitan 망 운용 600~800km 장거리 망 운용
특징 64채널, 160Gbps 32~40채널, Point to Point
활용 BCP, DR 원격지 백업
범위 도시, 특정지역 지역간, 도시간 연결
3. DWDM의 활용방안 및 고려사항
가. 해외 네트워크 : 글로벌 지사 연결, 가상기업, 다국적 기업
나. 지역 데이터 전송 : 지역정보, 중앙부터-지자체간 데이터 업데이트(지도 등)
다. 전송품질 : 증폭기 개선, 선로 유지보수, 신호 손실 최소화
라. ROI분석 : 광케이블 고가, 시스템 구축 고비용, 투자 분석수행 필요
끝.
UseCase Modeling
문) Usecase Modeling
답)
1. 객체지향 요구사항 분석 UseCase Modeling의 개요
가. UseCase Modeling의 정의
- 사용자의 시각에서 SW의 범위와 기능을 쉽게 정의하고, 기능적 요구사항을 나타내는 모델링기법
나. UseCase Modeling의 구성요소
- Actor : 시스템 외부에 독립적으로 존재하면서 시스템과 교류, 상호작용을 하는 것
- Usecase : 시스템이 Actor를 위해서 수행하는 작업
- Relation : Actor와 UseCase, UseCase간, Actor간의 상호연관성
- 주요산출물 : Usecase Diagram, UseCase명세서, 부가기술서
2. Usecase 작성절차와 작성규칙
가. UseCase 작성절차
절차 내용
1. Actor 식별 사용자의 역할, 상호작용하는 타 시스템, 연동HW식별
2. UseCase식별 Actor가 요구하는 정보, 서비스를 식별
3. 관계설정 Actor, Usecase간 관계분석 및 정의
4. Usecase구조화 UseCase의 공통 서비스 추출
5. Usecase명세 업무흐름다양성 기록, 대안흐름작성 등 UseCase명세서 작성
나. Use Case 작성규칙
- Actor 와 UseCase 명칭을 직관적으로 이해가 쉽도록 정의
- 모든 UseCase는 하나이상의 Actor와 교류해야함
- UseCase의 추상화 레벨은 일정한 수준 유지
- UseCase의 크기 단위에 대한 일관성 정의
3. UseCase Model의 활용 시 고려사항
가. 현업사용자 : 업무를 UseCase화 하는 교육, 훈련 참여
나. 개발자 : 플랫폼 독립적 설계하여 재사용성을 높일 필요성 있음
다. 관리자 : 정확한 요구사항 파악을 위한 반복적 분석 필요
끝.
답)
1. 객체지향 요구사항 분석 UseCase Modeling의 개요
가. UseCase Modeling의 정의
- 사용자의 시각에서 SW의 범위와 기능을 쉽게 정의하고, 기능적 요구사항을 나타내는 모델링기법
나. UseCase Modeling의 구성요소
- Actor : 시스템 외부에 독립적으로 존재하면서 시스템과 교류, 상호작용을 하는 것
- Usecase : 시스템이 Actor를 위해서 수행하는 작업
- Relation : Actor와 UseCase, UseCase간, Actor간의 상호연관성
- 주요산출물 : Usecase Diagram, UseCase명세서, 부가기술서
2. Usecase 작성절차와 작성규칙
가. UseCase 작성절차
절차 내용
1. Actor 식별 사용자의 역할, 상호작용하는 타 시스템, 연동HW식별
2. UseCase식별 Actor가 요구하는 정보, 서비스를 식별
3. 관계설정 Actor, Usecase간 관계분석 및 정의
4. Usecase구조화 UseCase의 공통 서비스 추출
5. Usecase명세 업무흐름다양성 기록, 대안흐름작성 등 UseCase명세서 작성
나. Use Case 작성규칙
- Actor 와 UseCase 명칭을 직관적으로 이해가 쉽도록 정의
- 모든 UseCase는 하나이상의 Actor와 교류해야함
- UseCase의 추상화 레벨은 일정한 수준 유지
- UseCase의 크기 단위에 대한 일관성 정의
3. UseCase Model의 활용 시 고려사항
가. 현업사용자 : 업무를 UseCase화 하는 교육, 훈련 참여
나. 개발자 : 플랫폼 독립적 설계하여 재사용성을 높일 필요성 있음
다. 관리자 : 정확한 요구사항 파악을 위한 반복적 분석 필요
끝.
MDA
문) MDA
답)
1. 디자인 패턴 활용 극대화 모델 MDA
가. MDA(Model Driven Architecture)의 개요
- 메타모델을 기반, 구현환경독립적 시스템(PIM)개발, 자동화도구를 통해 구현환경종속모델(PSM) 변환 SW방법론
나. MDA 주요 특징
- 구현자동화 : 메타모델 통한 CORBA, EJB, .NET, COM 구현
- 상호운영성 : UML 표준 사용으로 이기종 플랫폼에 독립
2. MDA 핵심기술와 구축절차 및 변환도구
가. MDA 핵심기술
1) MOF(Meta-Object Facility) : 정보 모델의 저장소, 문법과 구조를 정의한 메타모델
2) UML 2.0 : MOF와의 호환성을 위한 메타모델
3) UML Profile : 사용자정의언어, UML확장, 구현모델 자동매핑
4) CWM : 메타데이터 상호교환을 위한 표준 저장소, DB모델 변환
5) XMI : MoF를 XML로 매핑하기 위한 표준 사양
나. MDA 구축절차(MDD개발)
1) CIM : 개념화 관점의 요구사항을 모델에 적용
2) PIM : 요구사항분석, 설계 내용을 가지는 플랫폼 독립적 모델
3) PSM : 구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
다. MDA의 변환도구
1) UMT : 중간모델기반, XML,XMI,XSLT를 이용한 모델변환 및 코드생성
2) MTL : 직접변환, 다중상속 지원, 메타모델 저장소를 통한 메타모델 재사용
3) ATL : 직접변환, ATL변환 규칙정의 언어를 사용해 UML>XMI>JAVA 변환
3. MDA의 주요 현황과 고려사항
가. 재사용 관점 진화 : 구현 모델 재사용에서 설계 재사용으로 변화
나. Round Trip Engineering : SDLC 전과정의 자동화 지원
다. UML 2.0 : UML 1.X의 MoF와의 호환 미흡 완벽지원
=================================================================
CIM : Computation Independent Model
PIM : Platform Independent Model
PSM : Platform Specification Model
CWM : Common Warehouse Model
끝.
답)
1. 디자인 패턴 활용 극대화 모델 MDA
가. MDA(Model Driven Architecture)의 개요
- 메타모델을 기반, 구현환경독립적 시스템(PIM)개발, 자동화도구를 통해 구현환경종속모델(PSM) 변환 SW방법론
나. MDA 주요 특징
- 구현자동화 : 메타모델 통한 CORBA, EJB, .NET, COM 구현
- 상호운영성 : UML 표준 사용으로 이기종 플랫폼에 독립
2. MDA 핵심기술와 구축절차 및 변환도구
가. MDA 핵심기술
1) MOF(Meta-Object Facility) : 정보 모델의 저장소, 문법과 구조를 정의한 메타모델
2) UML 2.0 : MOF와의 호환성을 위한 메타모델
3) UML Profile : 사용자정의언어, UML확장, 구현모델 자동매핑
4) CWM : 메타데이터 상호교환을 위한 표준 저장소, DB모델 변환
5) XMI : MoF를 XML로 매핑하기 위한 표준 사양
나. MDA 구축절차(MDD개발)
1) CIM : 개념화 관점의 요구사항을 모델에 적용
2) PIM : 요구사항분석, 설계 내용을 가지는 플랫폼 독립적 모델
3) PSM : 구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
다. MDA의 변환도구
1) UMT : 중간모델기반, XML,XMI,XSLT를 이용한 모델변환 및 코드생성
2) MTL : 직접변환, 다중상속 지원, 메타모델 저장소를 통한 메타모델 재사용
3) ATL : 직접변환, ATL변환 규칙정의 언어를 사용해 UML>XMI>JAVA 변환
3. MDA의 주요 현황과 고려사항
가. 재사용 관점 진화 : 구현 모델 재사용에서 설계 재사용으로 변화
나. Round Trip Engineering : SDLC 전과정의 자동화 지원
다. UML 2.0 : UML 1.X의 MoF와의 호환 미흡 완벽지원
=================================================================
CIM : Computation Independent Model
PIM : Platform Independent Model
PSM : Platform Specification Model
CWM : Common Warehouse Model
끝.
텔레메틱스
문) 텔레메틱스
답)
1. 유비쿼터스시대 컨버전스 산업 신성장동력 텔레메틱스의 개요
가. 텔레메틱스(Telematics)의 정의
- 자동차와 컴퓨터, 이동통신기술을 융합, 위치정보와 이동통신망을 이용하여 교통안내, 긴급구난, 인터넷 등 Mobile Office를 제공하는 차량용 멀티미디어 서비스
- 통신(Telecommunication)과 정보과학(Informatics)의 합성어로, 사용자에게 차량기반 Mobile Office를 제공하는 서비스
나. 텔레메틱스 서비스 구조도
차량정보(위치정보) 정보제공
GPS -> 자동차단말기 -> 서비스센터 <-교통정보,생활정보,위치추적,인터넷
<- 응용서비스 제공
2. 텔레메틱스의 주요기술 및 제공서비스
가. 텔레메틱스의 주요기술
구분 설명 상세요소기술
단말기술 차량내/외부 인터페이스 차량내 HW,SW,블랙박스,네비
서비스기술 주행안전,친환경,운전편의 항법맵,POI,교통정보,TPEG,센싱
통신기술 기지국연계,인프라간통신 무선랜,WCDMA,DMB,DSRC
위치정보 무선측위기술,지리정보 GPS,DGPS,CELL-ID,AOA,GIS
나. 텔레메틱스 제공서비스
유형 상세설명
원격고객관리 차향운행상태, 차량 정비이력,보험
엔터테인먼트 스트림서비스,동영상서비스,영화음악서비스
보안서비스 차량도난감시,위치추적,원격조정
교통정보 정체정보,경로안내,주차안내
생활정보 행사정보,지역정보,상가안내
안전서비스 노변정보,주행위험정보,운행제어
3. 텔레메틱스 활성화 방안
가. 정책측면 : 규제완화, 세제혜택, 표준화지원
나. 산업측면 : ITS와 LBS연계한 비즈니스모델 발굴, ISO26262 준수
다. 기술측면 : 인터페이스 표준개발, OPEN API개발
라. 사용자측면 : 사용자중심 서비스 개발, 주행안전, 운전편의
마. 인식및홍보 : 텔레메틱스 기반 ITS시험사업 홍보, 편의성/안전성 검증 통한 사용자 참여 유도
끝.
답)
1. 유비쿼터스시대 컨버전스 산업 신성장동력 텔레메틱스의 개요
가. 텔레메틱스(Telematics)의 정의
- 자동차와 컴퓨터, 이동통신기술을 융합, 위치정보와 이동통신망을 이용하여 교통안내, 긴급구난, 인터넷 등 Mobile Office를 제공하는 차량용 멀티미디어 서비스
- 통신(Telecommunication)과 정보과학(Informatics)의 합성어로, 사용자에게 차량기반 Mobile Office를 제공하는 서비스
나. 텔레메틱스 서비스 구조도
차량정보(위치정보) 정보제공
GPS -> 자동차단말기 -> 서비스센터 <-교통정보,생활정보,위치추적,인터넷
<- 응용서비스 제공
2. 텔레메틱스의 주요기술 및 제공서비스
가. 텔레메틱스의 주요기술
구분 설명 상세요소기술
단말기술 차량내/외부 인터페이스 차량내 HW,SW,블랙박스,네비
서비스기술 주행안전,친환경,운전편의 항법맵,POI,교통정보,TPEG,센싱
통신기술 기지국연계,인프라간통신 무선랜,WCDMA,DMB,DSRC
위치정보 무선측위기술,지리정보 GPS,DGPS,CELL-ID,AOA,GIS
나. 텔레메틱스 제공서비스
유형 상세설명
원격고객관리 차향운행상태, 차량 정비이력,보험
엔터테인먼트 스트림서비스,동영상서비스,영화음악서비스
보안서비스 차량도난감시,위치추적,원격조정
교통정보 정체정보,경로안내,주차안내
생활정보 행사정보,지역정보,상가안내
안전서비스 노변정보,주행위험정보,운행제어
3. 텔레메틱스 활성화 방안
가. 정책측면 : 규제완화, 세제혜택, 표준화지원
나. 산업측면 : ITS와 LBS연계한 비즈니스모델 발굴, ISO26262 준수
다. 기술측면 : 인터페이스 표준개발, OPEN API개발
라. 사용자측면 : 사용자중심 서비스 개발, 주행안전, 운전편의
마. 인식및홍보 : 텔레메틱스 기반 ITS시험사업 홍보, 편의성/안전성 검증 통한 사용자 참여 유도
끝.
컴퓨터 포렌직스
문) 컴퓨터 포렌직스
답)
1. 법적 증거확보를 위한 활동 컴퓨터 포렌직스의 개요
가. 컴퓨터 포렌직스(Computer Forensics)의 정의
- 디지털 증거(Digital Evidence) 확보를 위한 수집, 조사, 해석, 검증, 문서화, 제출 등의 과학적 증명기법
나. 컴퓨터 포렌직스의 법률적 과제
- 법의 효력 : 물리적 증거의 법률적 해석 상이, 법적근거 마련
- 신뢰성 검증 : 위/변조 확인, 원본증명 통한 증거요건 마련
2. 컴퓨터 포렌직스 절차 및 유형
가. 컴퓨터 포렌직스의 절차
절차 설명
준비단계 전문인력확보, 포렌직 방법 선택 및 Skill 확보
현장조사 접속확인, 피해규모 파악, 시스템 분석
증거수집 로그수집, 위변조 검사, Timeline, Signature 검사
증거제출 원본확인, 문서화, 법원제출, 백업/원본 검증
나. 컴퓨터 포렌직스의 유형
1) Disk Forensics : 디스크복제/복원/파일분석 통한 증거수집
2) Network Forensics : 네트워크 패킷/이벤트 분석 증거 수집
3) Mobile Forensics : 모바일기기 정보분석, 기기별 Architecture 상이
4) Database Forensics : 데이터분석, 자료연관성 분석, 마이닝 활용
5) Virtualization Forensics : 가상화 환경에서의 증거 수집
3. 컴퓨터 포렌직스 해결과제 및 동향
가. 법적 증거활용을 위한 법률 제정 및 전문인력 양성하고, 분석기법, 포렌직도구의 표준화를 통해 다양한 기기 검증 필요
나. 정보 복구분석 차단기법인 Anti-Forensics가 등장하고, 국가 차원 대응을 위한 NSCS, ECSC의 ESM연계 시스템 구축 필요
끝.
답)
1. 법적 증거확보를 위한 활동 컴퓨터 포렌직스의 개요
가. 컴퓨터 포렌직스(Computer Forensics)의 정의
- 디지털 증거(Digital Evidence) 확보를 위한 수집, 조사, 해석, 검증, 문서화, 제출 등의 과학적 증명기법
나. 컴퓨터 포렌직스의 법률적 과제
- 법의 효력 : 물리적 증거의 법률적 해석 상이, 법적근거 마련
- 신뢰성 검증 : 위/변조 확인, 원본증명 통한 증거요건 마련
2. 컴퓨터 포렌직스 절차 및 유형
가. 컴퓨터 포렌직스의 절차
절차 설명
준비단계 전문인력확보, 포렌직 방법 선택 및 Skill 확보
현장조사 접속확인, 피해규모 파악, 시스템 분석
증거수집 로그수집, 위변조 검사, Timeline, Signature 검사
증거제출 원본확인, 문서화, 법원제출, 백업/원본 검증
나. 컴퓨터 포렌직스의 유형
1) Disk Forensics : 디스크복제/복원/파일분석 통한 증거수집
2) Network Forensics : 네트워크 패킷/이벤트 분석 증거 수집
3) Mobile Forensics : 모바일기기 정보분석, 기기별 Architecture 상이
4) Database Forensics : 데이터분석, 자료연관성 분석, 마이닝 활용
5) Virtualization Forensics : 가상화 환경에서의 증거 수집
3. 컴퓨터 포렌직스 해결과제 및 동향
가. 법적 증거활용을 위한 법률 제정 및 전문인력 양성하고, 분석기법, 포렌직도구의 표준화를 통해 다양한 기기 검증 필요
나. 정보 복구분석 차단기법인 Anti-Forensics가 등장하고, 국가 차원 대응을 위한 NSCS, ECSC의 ESM연계 시스템 구축 필요
끝.
은행가 알고리즘
문)은행가 알고리즘
답)
1. 교착상태 해결을 위한 은행가 알고리즘
가. 은행가 알고리즘(Banker's Algorithm)의 정의
- 시스템의 프로세스와 자원을 은행원 프로세스로 관리하여 교착상태의 발생이 가능한 불안전상태가 되지 않도록 안전상태로 유지하는 교착생태 회피 기법
나. 은행가 알고리즘의 측정 요소
- Available : 가능한 모든 자원의 수
- Max : 최대 자원 요구 수
- Need : 필요로 하는 자원의 수
- Allocation : 할당된 자원의 수
2. 은행가 알고리즘의 개념도 및 상태 판단 방법
가. 은행가 알고리즘의 개념도
- [safe]
자원 프로세스
ㅁ -----> P1
ㅁ <------P1의 3개의 자원 추가 요청
ㅁ
ㅁ ------> P2
ㅁ ------> P2
<------P2가 2개의 자원 추가 요청
1) 전체 5개의 자원 중 초기 3개 자원 할당
2) P1 3개, P2 2개 추가 자원 요청
3) 미할당 자원 2개를 P2에 할당 P1은 할당 유보
4) P2 완료시 반납되는 자원 4개중 3개를 P1에 할당 가능하여 safe 상태유지
- [unsafe]
자원 프로세스
ㅁ -----------> P1
ㅁ -----------> P1
ㅁ <--- P1의 2개의 자원 추가 요청
ㅁ -----------> P2
ㅁ -----------> P2
<---P2가 2개의 자원 추가 요청
1) 전체 5개의 자원 중 초기 4개 자원 할당
2) P1 2개, P2 2개 추가 자원 요청
3) 미할당 프로세스가 자원의 상태를 모니터링
나. 은행가 알고리즘의 상태 판단 방법
- safe : 시스템의 모든 프로세스가 요구하는 자원을 모두 할당하여 모든 프로세스가 정상적으로 완료 될 수 있는 상태
- safety algorithm : 자원 요청의 관계를 판단하여 안전상태를 판단하는 알고리즘
3. 은행원 알고리즘의 고려사항
가. 은행원 프로세스에서 safety algorithm으로 자원 변동시마다 체크 오버헤드 존재
나. 프로세스 시작 시 전체 사용 자원에 대한정보를 제공하여야 하는 비현실성 존재
다. 항상 안전상태로 유지하기 위하여 자원의 활용이 비효율적
라. 분산환경의 정보유지 및 자원 공유를 위한 개념에 활용하는 사례 있음
끝.
답)
1. 교착상태 해결을 위한 은행가 알고리즘
가. 은행가 알고리즘(Banker's Algorithm)의 정의
- 시스템의 프로세스와 자원을 은행원 프로세스로 관리하여 교착상태의 발생이 가능한 불안전상태가 되지 않도록 안전상태로 유지하는 교착생태 회피 기법
나. 은행가 알고리즘의 측정 요소
- Available : 가능한 모든 자원의 수
- Max : 최대 자원 요구 수
- Need : 필요로 하는 자원의 수
- Allocation : 할당된 자원의 수
2. 은행가 알고리즘의 개념도 및 상태 판단 방법
가. 은행가 알고리즘의 개념도
- [safe]
자원 프로세스
ㅁ -----> P1
ㅁ <------P1의 3개의 자원 추가 요청
ㅁ
ㅁ ------> P2
ㅁ ------> P2
<------P2가 2개의 자원 추가 요청
1) 전체 5개의 자원 중 초기 3개 자원 할당
2) P1 3개, P2 2개 추가 자원 요청
3) 미할당 자원 2개를 P2에 할당 P1은 할당 유보
4) P2 완료시 반납되는 자원 4개중 3개를 P1에 할당 가능하여 safe 상태유지
- [unsafe]
자원 프로세스
ㅁ -----------> P1
ㅁ -----------> P1
ㅁ <--- P1의 2개의 자원 추가 요청
ㅁ -----------> P2
ㅁ -----------> P2
<---P2가 2개의 자원 추가 요청
1) 전체 5개의 자원 중 초기 4개 자원 할당
2) P1 2개, P2 2개 추가 자원 요청
3) 미할당 프로세스가 자원의 상태를 모니터링
나. 은행가 알고리즘의 상태 판단 방법
- safe : 시스템의 모든 프로세스가 요구하는 자원을 모두 할당하여 모든 프로세스가 정상적으로 완료 될 수 있는 상태
- safety algorithm : 자원 요청의 관계를 판단하여 안전상태를 판단하는 알고리즘
3. 은행원 알고리즘의 고려사항
가. 은행원 프로세스에서 safety algorithm으로 자원 변동시마다 체크 오버헤드 존재
나. 프로세스 시작 시 전체 사용 자원에 대한정보를 제공하여야 하는 비현실성 존재
다. 항상 안전상태로 유지하기 위하여 자원의 활용이 비효율적
라. 분산환경의 정보유지 및 자원 공유를 위한 개념에 활용하는 사례 있음
끝.
2013년 2월 18일 월요일
디지털컨텐츠 보호기술
문) 디지털컨텐츠 보호기술
답)
1. 디지털컨텐츠 보호기술의 개요
가. 디지털컨텐츠의 특징
- 복제 용이성 : 원본과 복제본의 품질차이가 없음
- 배포 용이성 : 상품자체가 인터넷을 통해 유통가능
나. 디지털컨텐츠 보호기술의 종류
1) 저작권 추적기술 : 소유권 입증(Watermarking, Fingerprint)
2) 저작권 관리기술 : 정당한 사용자에 권한부여(DRM)
2. 저작권 추적기술과 관리기술 설명
가. Watermarking의 개요
1) 정의 : 디지털 정보에 사람이 인지할 수 없는 마크를 삽입하여 디지털컨텐츠에 대한 소유권을 추적하는 기술
2) 특징 : 비인지성, 강인성, 연약성, 위조방지, 키제한
3) 활용분야 : 저작권보호/제어, 방송모니터링,불법복제 추적
나. Fingerprint의 개요
1) 정의 : 디지털컨텐츠 추적/보호를 위하여 저작권 정보와 함께 구매자정보를 같이 포함한 저작권보호기술
2) 특징 : 듀얼워터마킹, 견고성, 비대칭성, 익명성, 공모허용
3) 기대효과 : 멀티미디어 거래시 불법유통 억제 가능
다. DRM(Digital Right Management)의 개요
1) 정의 : 디지털컨텐츠를 암호화해서 불법복제를 방지하고, 정당한 사용자(Right User)에게만 서비스 허가하는 기술
2) 요소기술 : 암호화, 인증, Watermarking, Temper Proofing
3) 적용분야 : 온라인 컨텐츠, 소프트웨어, 교육 컨텐츠 등
3. 저작권 추적기술 Fingerprint와 Watermarking의 비교
비교항목 Watermarking Fingerprint
주목적 원저작자의 식별 구매자의 불법유통 추적
삽입정보 원저작자의 정보 원저작자및 구매자정보
문제점 인터넷 불법 유통 가능 공모위험 존재
요소기술 암호화,저작권정보삽입 dual watermarking,공모보안코드
끝.
답)
1. 디지털컨텐츠 보호기술의 개요
가. 디지털컨텐츠의 특징
- 복제 용이성 : 원본과 복제본의 품질차이가 없음
- 배포 용이성 : 상품자체가 인터넷을 통해 유통가능
나. 디지털컨텐츠 보호기술의 종류
1) 저작권 추적기술 : 소유권 입증(Watermarking, Fingerprint)
2) 저작권 관리기술 : 정당한 사용자에 권한부여(DRM)
2. 저작권 추적기술과 관리기술 설명
가. Watermarking의 개요
1) 정의 : 디지털 정보에 사람이 인지할 수 없는 마크를 삽입하여 디지털컨텐츠에 대한 소유권을 추적하는 기술
2) 특징 : 비인지성, 강인성, 연약성, 위조방지, 키제한
3) 활용분야 : 저작권보호/제어, 방송모니터링,불법복제 추적
나. Fingerprint의 개요
1) 정의 : 디지털컨텐츠 추적/보호를 위하여 저작권 정보와 함께 구매자정보를 같이 포함한 저작권보호기술
2) 특징 : 듀얼워터마킹, 견고성, 비대칭성, 익명성, 공모허용
3) 기대효과 : 멀티미디어 거래시 불법유통 억제 가능
다. DRM(Digital Right Management)의 개요
1) 정의 : 디지털컨텐츠를 암호화해서 불법복제를 방지하고, 정당한 사용자(Right User)에게만 서비스 허가하는 기술
2) 요소기술 : 암호화, 인증, Watermarking, Temper Proofing
3) 적용분야 : 온라인 컨텐츠, 소프트웨어, 교육 컨텐츠 등
3. 저작권 추적기술 Fingerprint와 Watermarking의 비교
비교항목 Watermarking Fingerprint
주목적 원저작자의 식별 구매자의 불법유통 추적
삽입정보 원저작자의 정보 원저작자및 구매자정보
문제점 인터넷 불법 유통 가능 공모위험 존재
요소기술 암호화,저작권정보삽입 dual watermarking,공모보안코드
끝.
Long Tail
문) Long Tail
답)
1. WEB환경에서 새로운 경제사상 Long Tail개요
가. 롱테일(Long Tail)법칙의 개념
- WEB2.0기업(아마존,이베이 등)에서 80% 상위매출이 전체 매출의 과반수를 차지하는 현상. 파레토법칙(20:80)의 파괴 의미
나. 롱테일법칙의 등장배경
- 사용자 시장규모 증대 : Prosumer(생산자+소비자)등장,사용자와 상호작용 강화
- 온라인 시장규모 증대 : WEB기업성장, Niche Market(블루오션)공략
- 유통구조 혁신 : B2C, C2C거래활성화, 가상재고, 매대공간 무한확장
2. 롱테일의 특징,요소기술, 파레토법칙과 비교
가. 롱테일의 특징(9가지)
- 비즈니스 측면 : 재고를 없애라(가상재고),셀프서비스(Crowd sourcing - 대중참여, 수익공유)
- 다양한 측면 : 유통방식 다양화, 상품형태 및 가격 다변화
- 공유측면 : 정보공유, AND 사고
- 시장측면 : 시장신뢰, 무료의 힘
나. 롱테일의 요소기술
- 인터넷의 발전 : 온라인기업(구글,아마존)활성화, 1인기업 성장
- WEB2.0 : RDF, 온톨로지, Agent기술, 추론기술
- 검색기술,지식조직화 SW, SNS(소비자간 다양한 정보공유)
다. 롱테일법칙과 파레토 법칙의 비교
구분 파레토법칙 롱테일법칙
개념 상위20%매출이전체매출의80% 하위80%매출이전체매출50
관심대상 베스트셀러에대한집중 상품의무한한확장
대상기업 오프라인기업 온라인기업
시사점 상품의선택과집중,부각전시 상품접근성,검색성
특징 다양한사례적용가능 사용자참여,개인화서비스
3. 롱테일의 활용사례 및 비즈니스 향상
가. 온라인도서(희귀도서판매), 검색사이트에서 소규모광고(구글에드워드,에드센서)
나. 이동통신사의 부가서비스(문자,메일,지상파DMB),방송사의 데이터서비스(IPTV)
다. 기업측면 : 온,오프라인연계, 유통구조혁신, 디지털컨텐츠중요
라. 소비자측면 : 1인기업 성장토대 마련, 지식,정보의 가치제고
끝.
답)
1. WEB환경에서 새로운 경제사상 Long Tail개요
가. 롱테일(Long Tail)법칙의 개념
- WEB2.0기업(아마존,이베이 등)에서 80% 상위매출이 전체 매출의 과반수를 차지하는 현상. 파레토법칙(20:80)의 파괴 의미
나. 롱테일법칙의 등장배경
- 사용자 시장규모 증대 : Prosumer(생산자+소비자)등장,사용자와 상호작용 강화
- 온라인 시장규모 증대 : WEB기업성장, Niche Market(블루오션)공략
- 유통구조 혁신 : B2C, C2C거래활성화, 가상재고, 매대공간 무한확장
2. 롱테일의 특징,요소기술, 파레토법칙과 비교
가. 롱테일의 특징(9가지)
- 비즈니스 측면 : 재고를 없애라(가상재고),셀프서비스(Crowd sourcing - 대중참여, 수익공유)
- 다양한 측면 : 유통방식 다양화, 상품형태 및 가격 다변화
- 공유측면 : 정보공유, AND 사고
- 시장측면 : 시장신뢰, 무료의 힘
나. 롱테일의 요소기술
- 인터넷의 발전 : 온라인기업(구글,아마존)활성화, 1인기업 성장
- WEB2.0 : RDF, 온톨로지, Agent기술, 추론기술
- 검색기술,지식조직화 SW, SNS(소비자간 다양한 정보공유)
다. 롱테일법칙과 파레토 법칙의 비교
구분 파레토법칙 롱테일법칙
개념 상위20%매출이전체매출의80% 하위80%매출이전체매출50
관심대상 베스트셀러에대한집중 상품의무한한확장
대상기업 오프라인기업 온라인기업
시사점 상품의선택과집중,부각전시 상품접근성,검색성
특징 다양한사례적용가능 사용자참여,개인화서비스
3. 롱테일의 활용사례 및 비즈니스 향상
가. 온라인도서(희귀도서판매), 검색사이트에서 소규모광고(구글에드워드,에드센서)
나. 이동통신사의 부가서비스(문자,메일,지상파DMB),방송사의 데이터서비스(IPTV)
다. 기업측면 : 온,오프라인연계, 유통구조혁신, 디지털컨텐츠중요
라. 소비자측면 : 1인기업 성장토대 마련, 지식,정보의 가치제고
끝.
Mobile OK
문)모바일 OK
답)
1. 모바일 웹의 비표준화를 해결하기 위한 W3C표준화활동 MobileOK개요
가. Mobile OK 정의
- WEB과 WAP으로 나뉜 무선 인터넷의 벽을 허물고 하나의 유무선간 컨텐츠가 원활히 유통되도록 유무선 인터넷 사이트의 기술표준을 만드는 작업
나. Mobile OK 표준화배경 및 특징
- 여러 단말지원 위한 중복개발 비효율성, Active X등 비표준 컨텐츠난립
- 웹2.0 확산에 따라 신규 모바일 비즈니스 창출을 위한 모바일 웹2.0 서비스에 대응 불가능
- 호환성(기존 웹ㅍ준수용), 유연성(단말정보규격 표준화), 보편화(시험,인증절차 표준화)
2. Mobile OK표준가이드 및 풒브라우징과의 비교
가. Mobile OK 표준 가이드
- DDC규약 : 문자인코딩(UTF-8,EUC-KR), 페이지/픽셀크기, 이미지포맷(JPEG, GIF), AJAX, DOM지원
- 웹페이지제작 : Active등 비표준 사용안함, 올바른 HTTP프로토콜, CSS, 이미지처리
- 단말정보 이용 : 표준화된 단말정보 규격 사용
- 웹페이지 이용 : MOK준수 페이지 표기방법
나. Mobile OK와 풀브라우징 비교
구분 기존문제 풀브라우징 MobileOK
접근방법 비표준컨텐츠처리불가 브라우저만으로해결 개방형
서비스방식 폐쇄형구조 폐쇄형 개방형
UI최적화 불가 불가(데스크탑UI) 가능(모바일)
모바일단말 특정단말중심 불가 가능
서비스속도 대용량속도저하 느림 빠름(모바일)
서비스확장 비표준,유무선연동불가 불가 가능
3. Mobile OK표준화 및 발전방향
가. Mobile OK 1.0 : 웹마크업 중심 표준화(HTML),컨텐츠 유무선 통합 목표 달성
나. Mobile OK 2.0 : 웹 응용 및 서비스중심 표준화(Mash-up,SNS),서비스 유무선통합 목표
다. 문화체육관광부 및 한국소프트웨어 진흥원의 지원하에 모바일OK시범서비스추진. MOK 3차년도 시범서비스로 모바일 OK표준기반의 응용서비스 개발확산
끝.
답)
1. 모바일 웹의 비표준화를 해결하기 위한 W3C표준화활동 MobileOK개요
가. Mobile OK 정의
- WEB과 WAP으로 나뉜 무선 인터넷의 벽을 허물고 하나의 유무선간 컨텐츠가 원활히 유통되도록 유무선 인터넷 사이트의 기술표준을 만드는 작업
나. Mobile OK 표준화배경 및 특징
- 여러 단말지원 위한 중복개발 비효율성, Active X등 비표준 컨텐츠난립
- 웹2.0 확산에 따라 신규 모바일 비즈니스 창출을 위한 모바일 웹2.0 서비스에 대응 불가능
- 호환성(기존 웹ㅍ준수용), 유연성(단말정보규격 표준화), 보편화(시험,인증절차 표준화)
2. Mobile OK표준가이드 및 풒브라우징과의 비교
가. Mobile OK 표준 가이드
- DDC규약 : 문자인코딩(UTF-8,EUC-KR), 페이지/픽셀크기, 이미지포맷(JPEG, GIF), AJAX, DOM지원
- 웹페이지제작 : Active등 비표준 사용안함, 올바른 HTTP프로토콜, CSS, 이미지처리
- 단말정보 이용 : 표준화된 단말정보 규격 사용
- 웹페이지 이용 : MOK준수 페이지 표기방법
나. Mobile OK와 풀브라우징 비교
구분 기존문제 풀브라우징 MobileOK
접근방법 비표준컨텐츠처리불가 브라우저만으로해결 개방형
서비스방식 폐쇄형구조 폐쇄형 개방형
UI최적화 불가 불가(데스크탑UI) 가능(모바일)
모바일단말 특정단말중심 불가 가능
서비스속도 대용량속도저하 느림 빠름(모바일)
서비스확장 비표준,유무선연동불가 불가 가능
3. Mobile OK표준화 및 발전방향
가. Mobile OK 1.0 : 웹마크업 중심 표준화(HTML),컨텐츠 유무선 통합 목표 달성
나. Mobile OK 2.0 : 웹 응용 및 서비스중심 표준화(Mash-up,SNS),서비스 유무선통합 목표
다. 문화체육관광부 및 한국소프트웨어 진흥원의 지원하에 모바일OK시범서비스추진. MOK 3차년도 시범서비스로 모바일 OK표준기반의 응용서비스 개발확산
끝.
위험관리
문)위험관리
답)
1. 위험관리 개요
가. 위험관리(Risk Management)의 정의
- 위험은 조직, 조직의 자산가치, 예산의 정도에 의존하며 수용가능한 수준으로 감소시키는 활동
나. 위험관리 프레임워크(CoBit)
- Risk Governance : ERM 통합 비즈니스 결정사항 및 위험식별.공통관점유지
- Risk Evaluation : 위험분석, 데이터분석, 위험 프로필 유지
- Risk Response : 위험관리, 위험명세화, 위험 발생시 대처
* ERM(Employee RelationShip Managemnet)
2. 위험관리 단계 및 기법
가. 위험관리 단계
단계 활동 기법
위험식별 문서검토(관리계획서,유사프로젝트기록) Delphi
WBS/RBS를 통한 체계적 식별 Check List
위험분석 위험요소분석, 연관위험도출,취약점분석 확률영향Matrix
정량적 정성적 위험분석 민감도분석
위험완화 Cost-Benefit Analysis 를 통한 대책/대응방안수립 회피,수용,완화,전가
나. 위험요소별 대응방안
1) 기술력 : 신기술부재, 품질저하 > 사전검증(Pilot)표준화교육
2) 범위변경 : 요구사항변경, 범위증가 > 형성관리강화, 변경영향 최소화
3) 의사결정 : 이해부족, 관점차이,다양한채널증가 > 공식검토회의,요구사항재반복
4) 시간,예산부족 : 예산초과, 일정지연 > 간트챠트, 마일스톤, Crashing
3. 위험관리의 고려사항
- 정량적 위험분석 접근법이 정성적 접근법보다 바람직
- 위험 최소화를 위한 Hot-Line, 구축방법론 정립, 위험조기경보, 품질활동 사례집 작성등 필요.
끝.
답)
1. 위험관리 개요
가. 위험관리(Risk Management)의 정의
- 위험은 조직, 조직의 자산가치, 예산의 정도에 의존하며 수용가능한 수준으로 감소시키는 활동
나. 위험관리 프레임워크(CoBit)
- Risk Governance : ERM 통합 비즈니스 결정사항 및 위험식별.공통관점유지
- Risk Evaluation : 위험분석, 데이터분석, 위험 프로필 유지
- Risk Response : 위험관리, 위험명세화, 위험 발생시 대처
* ERM(Employee RelationShip Managemnet)
2. 위험관리 단계 및 기법
가. 위험관리 단계
단계 활동 기법
위험식별 문서검토(관리계획서,유사프로젝트기록) Delphi
WBS/RBS를 통한 체계적 식별 Check List
위험분석 위험요소분석, 연관위험도출,취약점분석 확률영향Matrix
정량적 정성적 위험분석 민감도분석
위험완화 Cost-Benefit Analysis 를 통한 대책/대응방안수립 회피,수용,완화,전가
나. 위험요소별 대응방안
1) 기술력 : 신기술부재, 품질저하 > 사전검증(Pilot)표준화교육
2) 범위변경 : 요구사항변경, 범위증가 > 형성관리강화, 변경영향 최소화
3) 의사결정 : 이해부족, 관점차이,다양한채널증가 > 공식검토회의,요구사항재반복
4) 시간,예산부족 : 예산초과, 일정지연 > 간트챠트, 마일스톤, Crashing
3. 위험관리의 고려사항
- 정량적 위험분석 접근법이 정성적 접근법보다 바람직
- 위험 최소화를 위한 Hot-Line, 구축방법론 정립, 위험조기경보, 품질활동 사례집 작성등 필요.
끝.
2013년 2월 17일 일요일
CMMi
문) CMMi
답)
1. 소프트웨어 프로세스 개선의 내재화를 위한 CMMi 개요
가. CMMi(Capability Maturity Model Integration) 정의
- 카네기 멜론대학 SEI에서 여러 CMM 모델을 통합하여 만든 SW시스템 개발조직의 프로세스 성숙도 모델
나. CMMi 목적
- 프로세스 능력향상 : 프로세스 수행 기대 결과치 예측기준 명확(QCD향상)
- 개선성과 확보 : 프로세스 수행 기준에 맞는 데이터수집/정량적 분석(정량화)
- 조직성숙도제고 : 지속적 프로세스 개선 가능한 조직혁신 달성(내재화)
2. CMMi 구성요소, 성숙도 단계 및 표현방법비교
가. 구성요소 및 성숙도
- Maturity level : 초기, 반복, 정의, 관리, 최적의 5단계
- PA(Process Area) : 프로세스 관리, 프로젝트관리, 공학,자원 4개 영역
- Generic/Specific Goal 및 Practice : 프로세스 성숙도 레벨 식별
- 성숙도 단계 : 초기 : 프로세스미비, 예측불가, 반복: 이전문서프로젝트반복
정의 : 전사적차원 표준화된 프로세스, 관리: 정량적,예측가능, 최적:내재화
나. 표현방법 비교
구분 단계적(Staged) 연속적(Continuous)
PA단계 성숙도(Maturity)5단계 능력(Capability)6단계
수행방법 점진적 PA단계 수행 선택적PA단계 수행
조직성숙도중심프로세스개선 PA중심으로 프로세스 개선
표현구조 SW-CMMi 유사모델 SE-CMMi 유사모델,SPICE호환
Bottom up Top Down
3. 국내 소프트웨어 인증현황 및 활용방안
- K-Model : 3단계의 국내모델, GS인증, 중소소프트웨어 품질인증
- 프로세스 개선활동에 대한 참여를 진작하기위한 BSC에 따른 보상
- PSP, TSP, 6시그마와 연계한 통계적 프로세스 체계 강화
- SPI(Software Process Improvment) 조직기반 전략 추진
끝.
답)
1. 소프트웨어 프로세스 개선의 내재화를 위한 CMMi 개요
가. CMMi(Capability Maturity Model Integration) 정의
- 카네기 멜론대학 SEI에서 여러 CMM 모델을 통합하여 만든 SW시스템 개발조직의 프로세스 성숙도 모델
나. CMMi 목적
- 프로세스 능력향상 : 프로세스 수행 기대 결과치 예측기준 명확(QCD향상)
- 개선성과 확보 : 프로세스 수행 기준에 맞는 데이터수집/정량적 분석(정량화)
- 조직성숙도제고 : 지속적 프로세스 개선 가능한 조직혁신 달성(내재화)
2. CMMi 구성요소, 성숙도 단계 및 표현방법비교
가. 구성요소 및 성숙도
- Maturity level : 초기, 반복, 정의, 관리, 최적의 5단계
- PA(Process Area) : 프로세스 관리, 프로젝트관리, 공학,자원 4개 영역
- Generic/Specific Goal 및 Practice : 프로세스 성숙도 레벨 식별
- 성숙도 단계 : 초기 : 프로세스미비, 예측불가, 반복: 이전문서프로젝트반복
정의 : 전사적차원 표준화된 프로세스, 관리: 정량적,예측가능, 최적:내재화
나. 표현방법 비교
구분 단계적(Staged) 연속적(Continuous)
PA단계 성숙도(Maturity)5단계 능력(Capability)6단계
수행방법 점진적 PA단계 수행 선택적PA단계 수행
조직성숙도중심프로세스개선 PA중심으로 프로세스 개선
표현구조 SW-CMMi 유사모델 SE-CMMi 유사모델,SPICE호환
Bottom up Top Down
3. 국내 소프트웨어 인증현황 및 활용방안
- K-Model : 3단계의 국내모델, GS인증, 중소소프트웨어 품질인증
- 프로세스 개선활동에 대한 참여를 진작하기위한 BSC에 따른 보상
- PSP, TSP, 6시그마와 연계한 통계적 프로세스 체계 강화
- SPI(Software Process Improvment) 조직기반 전략 추진
끝.
BIA
문) BIA
답)
1. BCP 구축을 위한 사업영향도 분석 BIA의 개요
가. BIA(Business Impact Anaysis)의 정의
- BCP(비즈니스 연속성 계획) 수립을 위해 업무중단이 사업에 미치는 영향에 대한 정성적,정량적 분석 및 평가단계
나. BIA의 목적
- 핵심 우선순위 결정 : 핵심기능/시스템식별, 핵심기능 관련 요구자산 식별
- 자원 요건산정 : 연속성 보장 위해 필요자원 산정
- 중단가능 시간 산정(MTD) : 핵심프로세스 중단영향과 허용가능 정지시간 확ㅇ린
2. BIA 단계와 관려지표
가. BIA 단계
1) 평가자료취합 : 조직전체 업무프로세스, 주요업무프로세스, 업무프로세스사이의 연관성
2) 취약점 분석 : 손실영향분석수행, 정성적,정량적, 핵심자원 영역정의
3) 정보분석 : 프로세스 문서화, 상호의존성 확인, 수락가능한 중단시간(MTD)도출
4) 결과문서화/권고안 : 보고서/수집자료, 식별핵심자원영역 영향도,권고복권우선순위
* 권고안은 적절한 고위관리자에게 보고(Presentation) 필요
나. BIA 관련지표
1) RSO(Recovery Scope Objective) : 재해복구범위;기간계,정보계,Backup
2) RTO(Recovery Time Objective) : 재해복구시간;업무중단허용시간
3) RPO(Revovery Point Objective) : 재해복구시점;업무손실허용시간
4) RCO(Recovery Communication Objective) : NW복구시간, 주요영업점,지역
5) BCO(Backup Center Objective) : 백업센터 목표, 자체보조백업센터에재해복권시스템 구축
3. BIA 고려사항 및 활용방안
- 고위 경영진과 사용자의 참여 중요. 기회비용 예측을 위해 재무정보부의 회사 외부 정보까지 모두 수립필요
- 비재난 계획 정보보안 분야 : 취약성 평가, Application 평가
끝.
답)
1. BCP 구축을 위한 사업영향도 분석 BIA의 개요
가. BIA(Business Impact Anaysis)의 정의
- BCP(비즈니스 연속성 계획) 수립을 위해 업무중단이 사업에 미치는 영향에 대한 정성적,정량적 분석 및 평가단계
나. BIA의 목적
- 핵심 우선순위 결정 : 핵심기능/시스템식별, 핵심기능 관련 요구자산 식별
- 자원 요건산정 : 연속성 보장 위해 필요자원 산정
- 중단가능 시간 산정(MTD) : 핵심프로세스 중단영향과 허용가능 정지시간 확ㅇ린
2. BIA 단계와 관려지표
가. BIA 단계
1) 평가자료취합 : 조직전체 업무프로세스, 주요업무프로세스, 업무프로세스사이의 연관성
2) 취약점 분석 : 손실영향분석수행, 정성적,정량적, 핵심자원 영역정의
3) 정보분석 : 프로세스 문서화, 상호의존성 확인, 수락가능한 중단시간(MTD)도출
4) 결과문서화/권고안 : 보고서/수집자료, 식별핵심자원영역 영향도,권고복권우선순위
* 권고안은 적절한 고위관리자에게 보고(Presentation) 필요
나. BIA 관련지표
1) RSO(Recovery Scope Objective) : 재해복구범위;기간계,정보계,Backup
2) RTO(Recovery Time Objective) : 재해복구시간;업무중단허용시간
3) RPO(Revovery Point Objective) : 재해복구시점;업무손실허용시간
4) RCO(Recovery Communication Objective) : NW복구시간, 주요영업점,지역
5) BCO(Backup Center Objective) : 백업센터 목표, 자체보조백업센터에재해복권시스템 구축
3. BIA 고려사항 및 활용방안
- 고위 경영진과 사용자의 참여 중요. 기회비용 예측을 위해 재무정보부의 회사 외부 정보까지 모두 수립필요
- 비재난 계획 정보보안 분야 : 취약성 평가, Application 평가
끝.
일정관리
문) 일정관리
답)
1. 시간과 자원의 제약을 가지는 프로젝트 성공적 수행, 일정관리 개요
가. 프로젝트 일정관리(Project Time Management) 정의
- 정의된 시간안에 고객이 만족하는 품질을 확보하면서 시간을 준수하는 프로젝트 관리기법
나. 일정관리 절차
1) Activity 정의 : WBS에 근거하여 세부 Actitivity 분류및 체계화
2) 연관관계부여 : Activity간 논리적 연관성, 선후관계부여
3) 수행기관 추정 : 개별 액티비티의 작업기간 추정
4) 계획수립 및 통제 : 액티비티 별 일정수립 및 모니터링, 지연관리
2. 프로젝트 일정관리 기법, 일정추정법 및 단축기법
가. 일정관리 기법
- Milestone 기법 : 경영진, 고객에 보고용이, 주요이벤트만 표시
- 프로그램 개발 책자 : 문서관리를 통한 이정표 통제, 실용적
- Grantt챠트 : 계획대비 실적파악에 유리
- PERT/CPM : 프로젝트 수행팀, 의사결정, 일정협의 등 사용
- PND(Project Network Diagram) : AOA, AON을 이용한 관리
- EV(Earned Value) : 업무의 양을 화폐가치로 환산하여 관리
나. 일정추정 기법
- 전문가판단 : 과거 유사경험근거, 추정가 역량에 좌우됨
- 시뮬레이션 : 가상 통계적 실험, 가상 변수 적용이 어려움
- PERT : 비반복적 프로젝트 중심, Activity기간 불확실(확률모형)
- CPM : 과거의 경험이나 실적자료가 충분한 Project 적용
다. 단축기법
- Crashing : 추가적 자원투입, 빠른 프로젝트 수행, 일정단축
- Fase Tracking : 작업의 전후관계 파악, 병행처리
- Resource Leveling : 과부하 Activity를 다른 기간으로 이동
3. 일정관리 고려사항 및 기대효과
- 명확한 WBS 도출을 통한 일정산정 정확도 향상, 범위, 비용관리 용이
- CP(Critical Path)의 중점관리를 통한 일정지연 사전예방
- PMO 관점 : Activity 세분화, 명확화 통해 관리 및 사전위험 예방
- PM관점 : 진척도 파악용이, 투입자원 효율적 배분, 비용감소
끝.
답)
1. 시간과 자원의 제약을 가지는 프로젝트 성공적 수행, 일정관리 개요
가. 프로젝트 일정관리(Project Time Management) 정의
- 정의된 시간안에 고객이 만족하는 품질을 확보하면서 시간을 준수하는 프로젝트 관리기법
나. 일정관리 절차
1) Activity 정의 : WBS에 근거하여 세부 Actitivity 분류및 체계화
2) 연관관계부여 : Activity간 논리적 연관성, 선후관계부여
3) 수행기관 추정 : 개별 액티비티의 작업기간 추정
4) 계획수립 및 통제 : 액티비티 별 일정수립 및 모니터링, 지연관리
2. 프로젝트 일정관리 기법, 일정추정법 및 단축기법
가. 일정관리 기법
- Milestone 기법 : 경영진, 고객에 보고용이, 주요이벤트만 표시
- 프로그램 개발 책자 : 문서관리를 통한 이정표 통제, 실용적
- Grantt챠트 : 계획대비 실적파악에 유리
- PERT/CPM : 프로젝트 수행팀, 의사결정, 일정협의 등 사용
- PND(Project Network Diagram) : AOA, AON을 이용한 관리
- EV(Earned Value) : 업무의 양을 화폐가치로 환산하여 관리
나. 일정추정 기법
- 전문가판단 : 과거 유사경험근거, 추정가 역량에 좌우됨
- 시뮬레이션 : 가상 통계적 실험, 가상 변수 적용이 어려움
- PERT : 비반복적 프로젝트 중심, Activity기간 불확실(확률모형)
- CPM : 과거의 경험이나 실적자료가 충분한 Project 적용
다. 단축기법
- Crashing : 추가적 자원투입, 빠른 프로젝트 수행, 일정단축
- Fase Tracking : 작업의 전후관계 파악, 병행처리
- Resource Leveling : 과부하 Activity를 다른 기간으로 이동
3. 일정관리 고려사항 및 기대효과
- 명확한 WBS 도출을 통한 일정산정 정확도 향상, 범위, 비용관리 용이
- CP(Critical Path)의 중점관리를 통한 일정지연 사전예방
- PMO 관점 : Activity 세분화, 명확화 통해 관리 및 사전위험 예방
- PM관점 : 진척도 파악용이, 투입자원 효율적 배분, 비용감소
끝.
커버로스 인증시스템
문) 커버로스 인증시스템
답)
1. 중앙집중형 사용자 인증 프로토콜 커버로스 개념
가. 커버로스의 정의
- 대칭키 암호화 기법에 바탕을 둔 티켓기반 인증프로토콜(DES기반)
- 3A 지원 : Authentication, Accouting, Auditing > AAA서버
나. 커버로스의 장단점
장점 : 재생공격예방, KDC외 Principle만이 특정대칭키(DES)공유
단점 : 패스워드 추측 공격(사전공격)에 취약, SPOF
2. 커버로스의 구성요소 및 동작원리
가. 커버로스의 구성요소
KDC : 키분배센터(Key Distribution Server), 사용자와 비밀키 유지
AS : 인증서비스(Authentication Service), 실질적 인증수행
Principals : 인증을 위하여 커버로스 프로토콜을 사용하는 모든 실제
TGS : 티켓부여서비스, 티켓을만들고 세션키를 포함한 Principals 에 분배
Ticket : 인증토큰
나. 동작원리
- 사용자는 인즈어비스에 인증(접근권한)
- 사용자에게 티켓전송
- 사용자는 서비스 접근 요청
- TGS는 세션키가 포함된 새로운 티켓 생성
- 사용자는 세션키를 추출, 티켓을 파일서버로 전송
- 티켓을 받은 서버는 사용자에 대한 서비스 제공 여부결정
* AS : 접근권한인증, ERP서비스가 DB에 있는지 확인. TGS생성
3. 커버로스의 기대효과 및 고려사항
- KDC와 Principale 만이 특정 대칭키(DES)공유하여 도청으로부터 보호
- 시간 제한을 두어 티켓을 복사하여 정당 사용자로 위장하려는 것 방지
- SPOF(Single Point Of Failure) > 2Factor로 예방
끝.
답)
1. 중앙집중형 사용자 인증 프로토콜 커버로스 개념
가. 커버로스의 정의
- 대칭키 암호화 기법에 바탕을 둔 티켓기반 인증프로토콜(DES기반)
- 3A 지원 : Authentication, Accouting, Auditing > AAA서버
나. 커버로스의 장단점
장점 : 재생공격예방, KDC외 Principle만이 특정대칭키(DES)공유
단점 : 패스워드 추측 공격(사전공격)에 취약, SPOF
2. 커버로스의 구성요소 및 동작원리
가. 커버로스의 구성요소
KDC : 키분배센터(Key Distribution Server), 사용자와 비밀키 유지
AS : 인증서비스(Authentication Service), 실질적 인증수행
Principals : 인증을 위하여 커버로스 프로토콜을 사용하는 모든 실제
TGS : 티켓부여서비스, 티켓을만들고 세션키를 포함한 Principals 에 분배
Ticket : 인증토큰
나. 동작원리
- 사용자는 인즈어비스에 인증(접근권한)
- 사용자에게 티켓전송
- 사용자는 서비스 접근 요청
- TGS는 세션키가 포함된 새로운 티켓 생성
- 사용자는 세션키를 추출, 티켓을 파일서버로 전송
- 티켓을 받은 서버는 사용자에 대한 서비스 제공 여부결정
* AS : 접근권한인증, ERP서비스가 DB에 있는지 확인. TGS생성
3. 커버로스의 기대효과 및 고려사항
- KDC와 Principale 만이 특정 대칭키(DES)공유하여 도청으로부터 보호
- 시간 제한을 두어 티켓을 복사하여 정당 사용자로 위장하려는 것 방지
- SPOF(Single Point Of Failure) > 2Factor로 예방
끝.
SW 아키텍트의 역할
문)SW아키텍트의 역할
답)
1. SW아키텍처 구축의 핵심 역할 아키텍트의 이해
가. SW아키텍트(Architect)의 정의
- 프로젝트의 전체적인 설계/아키텍처 구성에 책임을 가지고 프로젝트와 관련된 여러 개발 활동 및 상호연계를 관리하는 사람 및 역할
나. SW 아키텍트의 요구 스킬
1) 조정능력 : 기술적 측면의 종속을 탈피, 조직의 이해과녜자간 의견 조정
2) 경험제시 : 실무 경력 기반, 시스템 및 도메인에 대한 숙지 필수
2. 아키텍트의 주요 역할
가. 관리적 측면에서의 주요 역할
역할 주요내용
Create Vision IT기술혁신 및 시장 동향 파악, 시스템 요구사항/제약이해
최종 시스템 용도/모습/전사 추진과제 및 비즈니스 목표와 연관
Make a Decision 요구사항 간 Trade-off파악, 요구사항 기준 설립
도메인 지식요구, 위험요소와 시간제약 고려한 의사결정
Coordinates 각 팀 멤버/이해당사자 간 대화, 설계내용 전파, 의견수립
설계 통합성 유지 및 아키텍처에 따른 설계 진행/통제
Advocates SW아키텍처 투자 당위성 제시, SW프로세스 통합
나. 기술적 측면에서의 주요 역할
1) Technical Consultant : 신기술/마케팅 포지션 파악, 제품 필수사항 및 한계설정
Cost 검토, PM에 대한 기술적 조언 및 협력
2) Coaches Implements : Design Time 리드, 초기 설계요소/Risk식별, 내용전파작업 조정,
무결성유지, 설계 결정/평가, 영향도 평가
3. SW아키텍트의 국내현황 및 양성방안
가. ITA/EA 구축, 비즈니스 모델링 이해, 비즈니스와 IT의 Alignment 관점제시
대규모 프로젝트 통제 가능, Master아키텍트 부족
나. PM에 종속된 형태로 사업 여건에 따른 제약적 활동 수행
다. 전사 아키텍처에 팀 운영 통한 전문인력 양성, 정부주도 아키텍트 양성활성화
ATAM, CBAM 등 댜양한 평가 모델 활용, 엔지니어의 비전으로서 목표수립
끝.
답)
1. SW아키텍처 구축의 핵심 역할 아키텍트의 이해
가. SW아키텍트(Architect)의 정의
- 프로젝트의 전체적인 설계/아키텍처 구성에 책임을 가지고 프로젝트와 관련된 여러 개발 활동 및 상호연계를 관리하는 사람 및 역할
나. SW 아키텍트의 요구 스킬
1) 조정능력 : 기술적 측면의 종속을 탈피, 조직의 이해과녜자간 의견 조정
2) 경험제시 : 실무 경력 기반, 시스템 및 도메인에 대한 숙지 필수
2. 아키텍트의 주요 역할
가. 관리적 측면에서의 주요 역할
역할 주요내용
Create Vision IT기술혁신 및 시장 동향 파악, 시스템 요구사항/제약이해
최종 시스템 용도/모습/전사 추진과제 및 비즈니스 목표와 연관
Make a Decision 요구사항 간 Trade-off파악, 요구사항 기준 설립
도메인 지식요구, 위험요소와 시간제약 고려한 의사결정
Coordinates 각 팀 멤버/이해당사자 간 대화, 설계내용 전파, 의견수립
설계 통합성 유지 및 아키텍처에 따른 설계 진행/통제
Advocates SW아키텍처 투자 당위성 제시, SW프로세스 통합
나. 기술적 측면에서의 주요 역할
1) Technical Consultant : 신기술/마케팅 포지션 파악, 제품 필수사항 및 한계설정
Cost 검토, PM에 대한 기술적 조언 및 협력
2) Coaches Implements : Design Time 리드, 초기 설계요소/Risk식별, 내용전파작업 조정,
무결성유지, 설계 결정/평가, 영향도 평가
3. SW아키텍트의 국내현황 및 양성방안
가. ITA/EA 구축, 비즈니스 모델링 이해, 비즈니스와 IT의 Alignment 관점제시
대규모 프로젝트 통제 가능, Master아키텍트 부족
나. PM에 종속된 형태로 사업 여건에 따른 제약적 활동 수행
다. 전사 아키텍처에 팀 운영 통한 전문인력 양성, 정부주도 아키텍트 양성활성화
ATAM, CBAM 등 댜양한 평가 모델 활용, 엔지니어의 비전으로서 목표수립
끝.
IPSec
문)IPSec
답)
1. IP계층의 보안프로토콜 IPSec의 개념
가. IPSec(IP Security)의 정의
- 안전한 통신을 위하여 IP계층을 기반으로 IP Packet에대한 인증이나 암호화, 접근제어 등의 다양한 보안서비스를 제공해주는 개방형프로토콜
나. IPSec의 특징
- Application과 독립적응로 동작, IPv6에 내장, 강력한 확장성
- VPN적용용이, 키관리 메커니즘 제공, 호환성 우수
2. IPSec의 구성요소화 작동방식모드
가. IPSec의 구성요소
1) Key Management : ISAKMP가 암호화 키 생성과 분배
2) SA(Secure Association) : 보안매개변수 집합 정의 및관리
3) AH(Authentication Header) : 연결무결성, 데이터원본승인
4) ESP(Encapsulation Security Protocol) : 연결무결성, 데이터원본승인, 기밀성제공,제안된트래픽흐름 기밀성제공
5) IKE(Internet Key Exchage) : IPSec의 통신 개체 사이에서 SA를 설정하기 위해 공유된 비밀키와 인증키를 설정
나. IPSec의 작동방식 모드
전송모드(transport Mode) 터널모드(Tunnel Mode)
-단말~단말간 - 라우터~라우터
- IP패킷의 페이로드부분보호 - inbound IP패킷전체에 대해서 IPSec AH, ESP적용
3. IPSec의 적용과 고려사항
- TCP나UDP등 Transport Protocol에 무관하게 적용가능
- VPN 구현에 주로 사용됨.
- IPv6에서 의무적으로 지원, 3세대 이동통신에서도 네트워크 보안용으로 고려.
끝.
답)
1. IP계층의 보안프로토콜 IPSec의 개념
가. IPSec(IP Security)의 정의
- 안전한 통신을 위하여 IP계층을 기반으로 IP Packet에대한 인증이나 암호화, 접근제어 등의 다양한 보안서비스를 제공해주는 개방형프로토콜
나. IPSec의 특징
- Application과 독립적응로 동작, IPv6에 내장, 강력한 확장성
- VPN적용용이, 키관리 메커니즘 제공, 호환성 우수
2. IPSec의 구성요소화 작동방식모드
가. IPSec의 구성요소
1) Key Management : ISAKMP가 암호화 키 생성과 분배
2) SA(Secure Association) : 보안매개변수 집합 정의 및관리
3) AH(Authentication Header) : 연결무결성, 데이터원본승인
4) ESP(Encapsulation Security Protocol) : 연결무결성, 데이터원본승인, 기밀성제공,제안된트래픽흐름 기밀성제공
5) IKE(Internet Key Exchage) : IPSec의 통신 개체 사이에서 SA를 설정하기 위해 공유된 비밀키와 인증키를 설정
나. IPSec의 작동방식 모드
전송모드(transport Mode) 터널모드(Tunnel Mode)
-단말~단말간 - 라우터~라우터
- IP패킷의 페이로드부분보호 - inbound IP패킷전체에 대해서 IPSec AH, ESP적용
3. IPSec의 적용과 고려사항
- TCP나UDP등 Transport Protocol에 무관하게 적용가능
- VPN 구현에 주로 사용됨.
- IPv6에서 의무적으로 지원, 3세대 이동통신에서도 네트워크 보안용으로 고려.
끝.
나선형 모델
문)나선형 모델
답)
1. 진화적 프로토타입 모델 나선형 모델의 개요
가. 나선형 모델(Spiral Model)의 정의
- 개발될 주요기능을 사전에 위험분석을 통해 반복적으로 수행하여 최종 소프트웨어 개발까지 순차/점진적으로 구현하는 모델
나. 나선형 모델의 특징
- 대규모, 위험의 높은 프로젝트에 적합(예, 신기술 및 신규 도메인 프로젝트)
- 위험 관리를 통한 위험최소화(위험식별, 발생가능성,영향도출PI metrix 활용)
2. 나선형 모델의 접근전략 및 비교
가. 나선형 모델의 접근전략
1) 계획 및 정의 : 요구사항 분석, 계획수립, 고객의 평가반영
2) 위험분석 : 초기위험분석, 정성적위험분석(전문가감정,델파이기법), 정량적위험분석
3) 개발 : 초기 프로토타입, Horizental, Vertical
4) 고객평가 : 사용자관점 Validation, 인스펙션, 체크리스트 활용
나. SDLC 모델간 비교
비교항목 폭포수 나선형 RAD
위험 낮은위험 높은위험 낮은위험
SW규모 소~중규모 대규모 소규모
접근 순차적 순차및반복형 반복형
주요특징 명세화강조 위험분석 사용자참여(JRP,JAD)
3. 나선형모델의 기대효과 및 고려사항
가. IT Compliance : Secure코딩 의무화에 따라 보안공통부분 나선형모델 적용
나. Framework : 핵심공통모듈, 품질확보를 위한 적용고려
다. 발주기관 : 프로토타입 통해 검증된 기능 품질
라. 사업자측면(PM) : 불명확한 요구사항으로 반복횟수 증가 등 일정지연 고려.
끝.
답)
1. 진화적 프로토타입 모델 나선형 모델의 개요
가. 나선형 모델(Spiral Model)의 정의
- 개발될 주요기능을 사전에 위험분석을 통해 반복적으로 수행하여 최종 소프트웨어 개발까지 순차/점진적으로 구현하는 모델
나. 나선형 모델의 특징
- 대규모, 위험의 높은 프로젝트에 적합(예, 신기술 및 신규 도메인 프로젝트)
- 위험 관리를 통한 위험최소화(위험식별, 발생가능성,영향도출PI metrix 활용)
2. 나선형 모델의 접근전략 및 비교
가. 나선형 모델의 접근전략
1) 계획 및 정의 : 요구사항 분석, 계획수립, 고객의 평가반영
2) 위험분석 : 초기위험분석, 정성적위험분석(전문가감정,델파이기법), 정량적위험분석
3) 개발 : 초기 프로토타입, Horizental, Vertical
4) 고객평가 : 사용자관점 Validation, 인스펙션, 체크리스트 활용
나. SDLC 모델간 비교
비교항목 폭포수 나선형 RAD
위험 낮은위험 높은위험 낮은위험
SW규모 소~중규모 대규모 소규모
접근 순차적 순차및반복형 반복형
주요특징 명세화강조 위험분석 사용자참여(JRP,JAD)
3. 나선형모델의 기대효과 및 고려사항
가. IT Compliance : Secure코딩 의무화에 따라 보안공통부분 나선형모델 적용
나. Framework : 핵심공통모듈, 품질확보를 위한 적용고려
다. 발주기관 : 프로토타입 통해 검증된 기능 품질
라. 사업자측면(PM) : 불명확한 요구사항으로 반복횟수 증가 등 일정지연 고려.
끝.
요구공학
문)요구공학
답)
1. 고객과 합의된 요구사항을 위한 요구공학의 개요
가. 요구사항의 문제점
1) 사업자 측면 : 요구사항변경, 추가요구, 불명확한요구사항,제도/조직의 변경 등관리적어려움
2) 발주기관 측면 : 요구사항 검증 및 추적 평가의 어려움, Biz변화에 따른 요구변경
나. 요구공학(Requirement Engineering) 정의
- 요구사항을 정의하고 문서화하는데 필요한 요구사항의 추출, 분석, 명세, 검증, 유지보수 및 관리에 대한 체계적 접근방법
2. 요구사항의 특징 및 요구공학 프로세스
가. 요구사항의 특성
1) 완전성 : 시스템 구현에 필요한 모든것이 표현되어야 한다.
2) 명확성 : 여러가지가 아니라 단한가지로 해석되어야 한다.
3) 수정용이성 : 구조와 스타일에 일관성을 유지하면서 요구사항 변경이 용이해야함.
4) 추적성 : 요구사항들간 End-to-End 유기적으로 연결되어야 함.(추적Metrix)
나. 요구공학 프로세스
1) 요구공학 추출 : 이해관계자 및 RFP,제안서 등으로부터 요구사항 추출
2) 요구사항 정의 : 범위설정, 기능적,비기능적(품질,성능,보안), 관리적 요구사항
3) 요구사항 명세 : 요구사항 상세화, 의사소통을 위한 가시화(ex.유스케이스명세서)
4) 요구사항 확인 : 고객과 요구사항을 합의 및 확인(Baseline & Validation)
5) 요구사항 관리 : 변경요청서접수>의사결정>변경처리 절차의 지속적 관리
3. 요구사항 명세서의 구성 예시
가. 객체지향 방법론 관점에서 요구사항 명세서
1) UseCase Diagram : usecase, class, Sequence, component, package
2) Usecase 명세서 : Actor, 선행조건, 후행조건, 시나리오정의
3) 부가기술서 : 비기능적 요구사항(성능,품질,보안,N/W), 관리적 요구사항.
끝.
답)
1. 고객과 합의된 요구사항을 위한 요구공학의 개요
가. 요구사항의 문제점
1) 사업자 측면 : 요구사항변경, 추가요구, 불명확한요구사항,제도/조직의 변경 등관리적어려움
2) 발주기관 측면 : 요구사항 검증 및 추적 평가의 어려움, Biz변화에 따른 요구변경
나. 요구공학(Requirement Engineering) 정의
- 요구사항을 정의하고 문서화하는데 필요한 요구사항의 추출, 분석, 명세, 검증, 유지보수 및 관리에 대한 체계적 접근방법
2. 요구사항의 특징 및 요구공학 프로세스
가. 요구사항의 특성
1) 완전성 : 시스템 구현에 필요한 모든것이 표현되어야 한다.
2) 명확성 : 여러가지가 아니라 단한가지로 해석되어야 한다.
3) 수정용이성 : 구조와 스타일에 일관성을 유지하면서 요구사항 변경이 용이해야함.
4) 추적성 : 요구사항들간 End-to-End 유기적으로 연결되어야 함.(추적Metrix)
나. 요구공학 프로세스
1) 요구공학 추출 : 이해관계자 및 RFP,제안서 등으로부터 요구사항 추출
2) 요구사항 정의 : 범위설정, 기능적,비기능적(품질,성능,보안), 관리적 요구사항
3) 요구사항 명세 : 요구사항 상세화, 의사소통을 위한 가시화(ex.유스케이스명세서)
4) 요구사항 확인 : 고객과 요구사항을 합의 및 확인(Baseline & Validation)
5) 요구사항 관리 : 변경요청서접수>의사결정>변경처리 절차의 지속적 관리
3. 요구사항 명세서의 구성 예시
가. 객체지향 방법론 관점에서 요구사항 명세서
1) UseCase Diagram : usecase, class, Sequence, component, package
2) Usecase 명세서 : Actor, 선행조건, 후행조건, 시나리오정의
3) 부가기술서 : 비기능적 요구사항(성능,품질,보안,N/W), 관리적 요구사항.
끝.
요구사항 명세
문) 요구사항 명세
답)
1. 정확한 의사소통을 위한 요구사항 명세방법 개요
가. 요구사항 명세 방법 정의
- 프로젝트 참여자들 사이에 의사소통의 수단을 제공하며, 자연어, 정형언어, 그래픽 형태
로 기술된 언어로 요구사항의 일치성과 상호참조를 위해 작성된 명세서
나. 요구사항 명세서의 목적
- 사용자 측면 : 추적성, 의사소통, 프로젝트 품질, 납기기준 등 베이스라인 제공
- 사업자 측면 : 프로젝트 관리 기준(일정,비용,품질), 검수기준, 정확한 설계/개발/테스트
2. 요구사항 명세서 기법의 종료 및 장단점
가. 요구사항 명세서 기법의 종류
구분 기법 기법의종류
정형명세 수학적 기반의 기술명세 기법 체계적시스템,검증프레임웍제공
모델링 언어기반 명세기법 Z, VDM, CSP, CSS
대수처리기반언어명세기법
비정형명세 상태중심명세기법 FSM(Finite State Machine)
기능중심명세기법 Decision Table, ER모델링
객체중심명세기법 State Chart(SADT)
3. 요구사항 명세시 고려사항
가. 명세화 이전자료 즉, RFP,제안서,상위요구사항에 기초하여 정확히 작성
나. 사용자와 개발자 모두 이해가 쉽고, 기술방법으로 모호하지 않아야함(UML활용)
다. 누락된 항목 즉, 비기능적, 관리적 요구사항도 모두 포함되어야함(완전성충족)
라. 요구사항은 End-to-End 양방향간 추적이 가능해야 함.
마. 사용자별 중요도 및 난이도를 고려하여 우선순위를 정의함(Critical 요구사항관리)
끝.
답)
1. 정확한 의사소통을 위한 요구사항 명세방법 개요
가. 요구사항 명세 방법 정의
- 프로젝트 참여자들 사이에 의사소통의 수단을 제공하며, 자연어, 정형언어, 그래픽 형태
로 기술된 언어로 요구사항의 일치성과 상호참조를 위해 작성된 명세서
나. 요구사항 명세서의 목적
- 사용자 측면 : 추적성, 의사소통, 프로젝트 품질, 납기기준 등 베이스라인 제공
- 사업자 측면 : 프로젝트 관리 기준(일정,비용,품질), 검수기준, 정확한 설계/개발/테스트
2. 요구사항 명세서 기법의 종료 및 장단점
가. 요구사항 명세서 기법의 종류
구분 기법 기법의종류
정형명세 수학적 기반의 기술명세 기법 체계적시스템,검증프레임웍제공
모델링 언어기반 명세기법 Z, VDM, CSP, CSS
대수처리기반언어명세기법
비정형명세 상태중심명세기법 FSM(Finite State Machine)
기능중심명세기법 Decision Table, ER모델링
객체중심명세기법 State Chart(SADT)
3. 요구사항 명세시 고려사항
가. 명세화 이전자료 즉, RFP,제안서,상위요구사항에 기초하여 정확히 작성
나. 사용자와 개발자 모두 이해가 쉽고, 기술방법으로 모호하지 않아야함(UML활용)
다. 누락된 항목 즉, 비기능적, 관리적 요구사항도 모두 포함되어야함(완전성충족)
라. 요구사항은 End-to-End 양방향간 추적이 가능해야 함.
마. 사용자별 중요도 및 난이도를 고려하여 우선순위를 정의함(Critical 요구사항관리)
끝.
피드 구독하기:
글 (Atom)