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

1. 경영환경분석의 개요

 1-1. 경영환경분석의 정의

    - 정보 전략 수립 시 내/외부의 경영 환경 분석을 통해 주요성공요인을 도출하는 등의 전략적 의사 결정에 유용한 정보를 제공하기 위한 기법

 1-2. 전략 수립 프로세스

2. 경영환경분석의 개념도, 경영환경 분석 및 전략수립 도구의 종류

 2-1. 경영환경분석의 개념도

 2-2. 경영환경 분석 및 전략수립 도구의 종류

3. 경영환경분석의 기대효과 및 고려사항

 1)  기대효과

   - 최대의 가치창출 및 독창적 경영활동을 위한 유용한 정보 제공

   - 고객관계 강화 및 경쟁업체 분석을 통한 수익성 제고

 2) 고려사항

   - 단기 수익률보다 가치 창출에 의한 미래의 성장 반영 고려

   - 새로운 시장의 등장에 대한 선도적 대응 필요함.

1. IT ROI (Return Of Investment)의 개요

 1-1. IT ROI (Return Of Investment)의 정의

   - IT ROI는 IT 투자비용 대비 IT 투자성과를 도출하여 IT투자의 경제적 타당성을 평가하는 기법

      -> IT 투자성과: IT가 비즈니스 성과향상에 기여하는 바를 재무적으로 환산하여 계산

      -> IT 투자비용: 컨설팅비용, 구축비용, 유지보수 비용 등 구축 및 운영 비용을 합산하여 산정

   - IT ROI 분석은 기업의 비즈니스에 대한 이해를분석은 기업의 비즈니스에 대한 이해를 바탕으로 시스템에 영향을 받는 중요한 프로세스를 규명하는 것부터 시작해야 함.

 1-2. IT ROI (Return Of Investment)의 필요성

2. IT ROI (Return Of Investment)의 분석 전략, 분석 방법

 2-1. IT ROI (Return Of Investment)의 분석전략

 2-2. IT ROI (Return Of Investment)의 분석 방법

  (1) 분석시기와 목적 기준 IT ROI 분석방법

    1) 사전 ROI 분석

      - 기업의 경제•사업•전략 관점에서 IT 투자 효과를 예측하고 IT 투자에 대한 의사결정 체계를 구현하는 평가 방법

      - 예상 프로젝트들에 대해 투자 타당성을 검증하고 그 결과에 따른 적합한 대안을 선택

   2) 중간 ROI 분석

      - 진행 중인 프로젝트에서 시간의 흐름에 따라 점점 구체화돼 가는 비용•효과•위험을 비교하는 평가 체계

      - 프로젝트별 진척 현황을 IT ROI 관점에서 관리하는 기법

   3) 사후 ROI 분석

      - 이미 구축된 정보시스템들의 IT 성과 측정 및 정보시스템 구축 목표 달성 여부를 검증

      - 정량적 평가와 정성적 원인 분석이 이루어지면 기업의 전략과 연계된 IT 성과 관리 체계를 구현, 지속적인 모니터링 체계를 구현 가능

 (2) 회수기간과 전략적 기여도 기준 IT ROI 분석방법

   1) Cost-benefit analysis (비용-효과 분석)

      - 재무적 평가 관점의 가장 많이 사용하는 방식

      - 비용-효과(Cost-benefit) 분석을 통해 투자수익률(ROI), 순현재가치 (NPV), 내부수익률(IRR), 회수 기간(PP) 등으로 결과 값을 도출해내는 방법

   2) Information economics (정보경제학)

     - 프로젝트의 포트폴리오를 평가하고 최대의 효과를 내는 장소에 자원을 할당하기 위한 중립적인 방법론

     - 상대적 중요성이나 위험을 평가하여 우선 순위를 매기며, 비즈니스 목표들과 연계하는데 용이

  3) Real options (실물옵션 가치)

     - 불확실한 경영 환경 아래서 전략적 투자를 평가하고 관리하는 방법

     - IT가 창출하는 유연성의 가치를 잡아내고 위험요소는 최소화하려는 접근방법

  4) Scenario planning (시나리오 계획)

     - 투자가 생겼을 때의 잠재적인 산출 결과를 완전히 이해하고 각각의 시나리오에서 효과 및 개연성을 염두하고 투자 결정 평가를 내리는 기법

  5) Information Orientation (정보 기반)

    - 3가지 영역인 정보행동 및 가치(Information Behaviors and Values), 정보관리 실행(Information Management Practices), 정보기술 실행(Information Technology Practices) 각 영역의 실행 수준과 가치 역량을 측정하여 정보화를 평가하는 기법

    - 정성적 효과 분석에서 누락될 수 있는 많은 부분을 고려

1. BSC(Balanced Score Card)의 개요

 1-1. BSC(Balanced Score Card)의 정의

- 재무적 관점과 고객, 내부프로세스, 학습과 성장측면의 3가지 비재무적인 관점을 측정 가능한 핵심성과지표(KPI)로 전환하여 관리함으로써, 균형적인 경영성과관리를 실행하도록 도와주는 성과관리기법

 1-2. 특징

 1) 지표간 균형 : 재무-비재무, 결과-과정, 단기-장기, 내부-외부, 과거-미래 지표간 균형

 2) 전략과 연계 : 조직의 전략으로부터 도출되어, 조직의 비전 및 전략을 이행하기 위한 목표를 기반으로 함

 3) 전략에 대한 의사소통 : 전략에 대한 조직 구성원간의 의사소통이 원활해짐으로써 공통의 목표를 지향하게 함

2. BSC(Balanced Score Card)의 구성도, 구성요소

 2-1. BSC(Balanced Score Card)의 구성도

 2-2. BSC(Balanced Score Card)의 구성요소

 1) 재무적 관점 (과거)

    - 전통적인 성과 측정 관점으로 매출액, 순이익, 원가절감 등 재무적인 평가

    - KPI(정량적수치) : 매출액, 현금흐름, 재고, 채권 효율화, 영업이익률

  2) 고객 관점 (현재)

    - 고객의 충성도 제고, 고객의 만족도 향상 등 고객 관계 관점 평가

    - KPI(정량적수치) : 고객만족도, 적시 공급율 수주출하 lead

  3) 내부프로세스 관점 (현재)

     - 조직내부 프로세스의 최적화 관점에서의 성과를 평가하고, 프로세스 향상에 대한 노력을 성과로 인정함      

     -  KPI(정량적수치) : Cycle Time, 신제품 개발건수 단위원가

  4) 학습과 성장 관점 (미래)

   - 조직에서 구성원의 중요성을 강조하여, 구성원의 학습노력과 역량증진에 대한 성과를 측정함

   - 종업원만족도, 제품개발기간 신제품비율

1. MDA(Model Driven Architecture)의 개요

 1-1. MDA(Model Driven Architecture)의 정의

- 모든 컴포넌트 기술 요소의 표준 메타모델을 정의하고 이를 기반으로 각 구성요소를 정의함으로써 호환성 및 시스템간 자동성을 보장하고자 하는 소프트웨어 개발 기술

 1-2. MDA(Model Driven Architecture)의 등장배경

  1) 다양한 미들웨어 플랫폼 등장 :CORBA, J2EE, .NET등 컴포넌트 기반으로 등장했지만 각각의 표준을 기반으로 구현되어 상호연동에 문제발생

  2) 다양한 컴포넌트 아키텍처의 등장 : 각각의 미들웨어 상에서 동작하는 여러 종류의 컴포넌트의 표준화 및 강호 운용성의 문제제기

  3) 개발 패러다임의 변화 : 빠른 시장대응(Time to market), 상호운용성, 개발생산성, 유지보수성

  4) CORBA의 복잡성 : OMG에서는 개방형 객체 표준인 CORBA를 표준으로 탄생시켰지만 무겁고 복잡한 표준규격으로 시장에서 외면됨

2. MDA(Model Driven Architecture의 모델 분류, 관련표준

 2-1.MDA(Model Driven Architecture의 모델 분류

 2-2. MDA(Model Driven Architecture)의 관련표준

  1) UML
   - Unified Modeling Language
   - OMG에 의해 표준화된 객체지향 분석 및 설계표준
   - 구현환경에 무관하게 표준화된 방법으로 시스템 모델링

  2) MOF
   - Meta Object Facility
   - 다른 메타모델을 정의하기 위한 메타-메타 모델
   - UML과 CWM은 MOF기반 메타모델, MOF는 모델 저장소 역할
   - MDA에서 사용되는 표준모델링과 변환 구조를 제공

 3) CWM
   - Common Warehouse Meta model
   - 데이터 웨어하우징 영역에서 DW 아키텍처를 정의한 메타모델
   - 데이터 소스, 타겟, 영역간 데이터 변환을 위한 표준 모델제시

 4) XMI
   - XML Metadata Interchange  
   - MOF기반 모델을 XML로 맵핑하기 위한 표준사양
   - XML 기반 데이터 관리를 위한 표준

1. SLA (Software Product Line)의 개요

 1-1. SLA (Software Product Line)의 정의

- S/W 공학의 전체관점에서 Domain Specific하게 재사용할 기본단위인 Core Assets을 미리 개발하고 실제 Product 개발 시 Core Assets을 이용하여 여러 Product를 만들어 내는 접근방법

 1-2. SLA (Software Product Line)의 특징

  1) 도메인 공학 활용: 제품간의 공통성(commonality)과 가변성(variability)을 추출하여 Core Asset 개발 (전략적 재사용으로 재사용상 향상)

  2) 아키텍처 기반 개발: 각각의 Product들을 개발 시 컴포넌트(Core Asset)가 조립 될 수 있는 프레임워크 제공

  3) 리엔지니어링: 기존의 Core Asset을 상황에 맞게 수정하여 재사용

2. SLA (Software Product Line)의 구성도, 핵심활동, 개발 프로세스

 2-1. SLA (Software Product Line)의 구성도

 2-2. SLA (Software Product Line)의 핵심활동

 2-3. SLA (Software Product Line)의 개발 프로세스

1. AOP(Aspect Oriented Programming)의 개요

 1-1. AOP(Aspect Oriented Programming)의 정의 

- 요구사항에 대해 핵심관심사항과 횡단관심사항으로 분할, 개발, 통합 함으로써 모듈화를 극대화하는 프로그래밍 기법

 1-2. AOP(Aspect Oriented Programming)의 특징

  1) 단순/집중

    - 개발절차 단순화 및 개발자에게는 비즈니스 기능에 대한 집중 가능

  2) 비캡슐화

    - 핵심 비즈니스 영역보다는 주변 업무 중심 공통 모듈에 해당

  3) Aspect 이용

    - 독립된 Aspect 단위변경을 통해 전체 응용시스템 변경 용이

   4) OOP 기반

    - OOP 사상을 기본으로 한 cross cut aspect 프로그래밍

2. AOP(Aspect Oriented Programming)의 동작원리, 구성요소, 설계절차

 2-1. AOP(Aspect Oriented Programming)의 동작원리

 2-2. AOP(Aspect Oriented Programming)의 구성요소

  1) 핵심관심

    - 시스템이 추구하는 핵심 기능 및 가치

  2) 횡단관심

    - 여러 개의 모듈에 공통적으로 적용되는 부가적인 요구사항

    - 예. 보안/인증, 로그작성, 트랜잭션, 에러 검사 등

  3) Joint Point

    - 횡단관심의 기능이 삽입되어 동작할 수 있는 실행 가능한 특정위치

    - 예) 메소드의 호출 부분 또는 리턴 시점

  4) Point-Cut

    - 어느 Joint Point 를 사용할 것인지 결정하는 선택 기능

  5) Advice

    - Joint Point에 삽입되어 동작할 수 있는 모듈

  6) Aspect

    - Point-cut(어디에서)과 Advice(무엇을 할지) 를 합쳐 놓은 코드

  7) Weaving

    - Point-cut에 의해서 결정된 Joint Point에 지정된 Advice 를 삽입하는 과정

 2-3. AOP(Aspect Oriented Programming)의 설계 절차

1. Planning Poker의 개요

 1-1. Planning Poker의 정의 

  - 플래닝 포커는 사용자 스토리의 규모를 추정하는 방식

  - 전통적인 방식과 달리 한 사람이 주도적으로 추정하는 것이 아니라 팀 전체가 같이 지혜를 모아 업무량을 추정하는 실천 기법

2. Planning Poker의 개념도, 구성요소, 주요절차

 2-1. Planning Poker의 개념도

 2-1. Planning Poker의 구성요소

 1) 역할자

    - 스크럼마스터: 플래닝 포커를 활용하여 업무량을 추정할 때, facilitator 역할 수행

    - 제품 책임자: 업무를 추정할 사용자 스토리에 대해 팀원들에게 설명하고, 팀원들이 추정하는 도움이 되는 질문을 할 때 답변하는 역할 수행

    -팀원: 업무에 대해 공유, 질문을 통해 사용자 스토리의 업무량을 추정

 2) 적용상황

    -계획 수립 시 각자의 의견이 대립되거나 이해관계자가 얽혀 있을 때

    - 함께 계획을 수립하며 각자의 의견이 골고루 반영되도록 하고 싶을 때

 3) 준비물

    - 인덱스 카드, 네임펜, 제품 백로그, 플래닝 포커

 2-3. Planning Poker의 주요 절차

  1) 기준점 스토리 포인트 결정 : 사용자 스토리 중에서 적당한 사용자 스토리의 크기를 3으로 정하고, 이를 스토리 포인트라는 단위로 정함

  2) 상대적 스토리 포인트 결정 : 스토리 포인트가 3인 사용자 스토리를 기준으로 상대적으로 포인트를 정함

  3) 대상 사용자 스토리 업무 이해 : 추정하고자 하는 인덱스카드를 고르고, 제품 책임자가 추정할 사용자 스토리를 설명하면, 팀원들은 이에 대해 질문하고, 제약사항,위험 등에 대해 간략히 토론을 하여 업무에 대해 이해

  4) 스토리 포인트 채점 : 설명이 끝나면 각자 생각하는 숫자가 적혀있는 카드를 위로 향하도록 제시

  5) 스토리 포인트 재조정을 위한 추가 설명 : 이번 라운드에서 만장일치가 아니고 차이가 발생하였다면 이제 의견조정을 위한 이야기를 다시 시작

  6) 최대, 최소 스토리 포인트 채점자 의견 청취 : 가장 낮게 나온 사람이 낮은 이유를 이야기하고 가장 높게 나온 사람이 높은 이유를 설명

 7) 게임 반복 : 이야기 나눈 것을 바탕으로 다시 게임을 반복

 8) 최종 스토리 포인트 결정 : 만장일치가 될 때까지 진행하는 것을 원칙으로 하지만, 3회가 되도록 만장일치가 나오지 않으면 중간 포인트를 선택하고 다음 게임으로 넘어감

 9) 분할된 사용자 스토리에 대한 플래닝 게임 수행 : 나눌 필요가 있다고 판단되는 일에 대해서는 세분화된 할 일을 인덱스 카드에 적고 이에 대해 플래닝 게임을 한 뒤, 이전의 인덱스 카드 폐기

 10) 마무리 : 모든 할일 목록에 대해 플래닝 게임을 진행하면 추정 종료

3. Planning Poker의 준비사항, 기대효과

 1) 준비사항

   - 제품 책임자와 스크럼 마스터는 도출된 사용자 스토리 목록인 제품 백로그를 준비

   - 플래닝 포커 카드를 이용하면 더욱 좋으며, 플래닝 포커 카드가 없을 경우 직접 만들거나 손을

 2) 기대효과

   - 다른 사람의 의견에 영향을 받지 않고 자신의 생각을 표현하고 공유할 수 있음

   - 업무에 대해 깊이 이해할 수 있음

1. SCRUM의 개요

 1-1. SCRUM의 정의 

- 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 산출하는 대표적인 Agile 개발 방법론

 1-2. SCRUM의 특성 및 가치

  1) 특성

    - 프로젝트관리 강조 : XP와 달리 진행 체계 수립, 역할, 정의에 중점

    - 포괄적 정의 및 포용 : 기존의 개발방법론, 표준, 공학적 접근법의 포괄적 수용

    - Role에 대한 강조 : 요구사항 관리주체 product owner, SCRUM team coaching을 위한 SCRUM master, 실질적인 업무 수행하는 SCRUM Team

    - 시간적 조건 설정 : 15분의 daily meeting, 30일 정도의 개발주기(time box)

    - 관리적 체계 : 전체 제품 요구사항 관리, 개발주기 내 요구사항, 업무 진행 가시화

    - 팀 중심 : 5~9명으로 구성, 팀 내에서 역할 분담, 모든 팀원 구성원간 업무교환

 2) 가치

   - 확약: 약속한 것은 확실히 실현되는 것

   - 전념: 확약한 것의 실현에 전념하는 것

   - 정직: 비록 자신에게 있어서 불리한 일에서도 숨지기 않는 것

   - 존중: 자신과 다른 사람에게 경의를 표하는 것

   - 용기: 위의 사항을 언제든지 지킬수 있는 용기

2. SCRUM의 개념도, 구성요소, 프로세스

 2-1. SCRUM의 개념도

 2-2. SCRUM의 구성요소

  1) Product Backlog

    - 시스템에서 해결해야 하거나, 시스템에 포함되어야 할 기능, 특성과 기술에 대한 모든 기술 나열

  2) Sprint Backlog

    - 해당 Sprint 기간에 수행되어야 하는 TASK 목록으로 Sprint 기간 동안 개발 가능한 기능의 목록을 Product Backlog에서 선택

  3) Sprint

    - 통산 4~8주(30)일 정도의 Time box 성격을 가진 잘 정의된 반복 개발주기

  4) Daily Scrum

    - 매일 약 15분 정도의 짧은 회의

    - SCRUM Master는 진척 사항 검토, 정상적 종료를 방해하는 위험 및 작업 계획을 확인

 2-3. SCRUM의 프로세스