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

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의 프로세스

1. ALM(Application Lifecycle Management)의 개요

 1-1. ALM(Application Lifecycle Management)의 정의

  - 비즈니스 요건 관리 부분과 실제 소프트웨어 개발 프로세스를 융합하고 자동화 툴을 이용하여 개발에 필요한 활동들을 관리하도록 하는 소프트웨어 관리 체계

  - 소프트웨어 개발의 요구사항 관리 및 아키텍처, 코딩, 테스트 그리고 이슈 추적과 릴리즈 관리 등 모든 과정에 전문화된 도구를 이용하여 소프트웨어 개발 프로세스를 개선하는 체계

 1-2. ALM(Application Lifecycle Management)의 특징

 1) 유기적인 통합 : 개발 전 과정 중에서도 코딩, 단위/통합테스트에 집중

 2) 이슈기반의 통제 : 위험의 조기제거 및 이슈추적을 통한 작업 관리 및 통제

 3) 개발방법론과 통합 : 개발 주기간의 유기적인 통합을 통한 생산성 및 품질 향상

 4) 프로세스 자동화 : 어플리케이션 생명주기 전 공정을 관리하는 자동화된 프로세스 구현

2. ALM(Application Lifecycle Management)의 구성도, 구성요소, 주요프로세스

 2-1. ALM(Application Lifecycle Management)의 구성도

 2-2. ALM(Application Lifecycle Management)의 구성요소

  1) Task Management

   - 프로젝트 Task에 대한 진행상황, 스케줄링, 리소스 관리 방법론 제공

   - 인력 별로 진행 중인 이슈와 완료된 이슈 추적을 통해 인력 별 작업 부하와 성과 측정

   - 작업 진척 사항 체크

  2) Build Environment

   - Implementation 단계에서 사용되는 개발환경 제공

   - 자동 빌드 시스템을 기반으로 점진적 방식의 통합 진행

  3) Test Automation

    - 단위테스트와 통합 테스트에 비중을 두고 테스트

    - 자동화와 회귀테스트를 중점적을 진행

    - 코드 오류 검사 수행, 테스트 커버리지 분석, 코드 복잡도 분석

  4) Collaboration

    - 프로젝트 진행 시 의사 소통과 공동 작업을 돕기 위한 기법과 시스템

    - 코드리뷰, 정보 공유 시스템, 양방향 커뮤니케이션 시스템

 2-3. ALM(Application Lifecycle Management)의 주요프로세스

1. Daily Build의 개요

 1-1. Daily Build의 정의

   - 지속적으로 변경되는 Source code에 대하여 지정된 시간에 테스트, 패키징, 태깅, 레포팅, 이슈관리 연결 등의 개발자가 사전 정의한 업무를 자동으로 수행하는 절차

 1-2. Daily Build의 필요성

  1) 지속적 통합 : 변경 및 수정되는 사항을 매일 반영함으로써 개발의 신속성 제공 (XP 실천 요소)

  2) 배포 효율화 : 별도의 배포 프로세스 없이 기 설정된 시나리오대로 자동 배포 가능

  3) 짧은 릴리즈 : 릴리즈 주기를 짧게 하여 시스템의 완성도 확보 및 통합시의 리스크를 감소

  4) 스모크 테스트 : End-to- End 테스트 결과물에 대한 검증 확인 배포

2. Daily Build의 개념도, 구성요소

 2-1. Daily Build의 개념도

 2-2. Daily Build의 구성요소

  1) IDE(통합개발환경)

    - 코딩, 디버깅, 컴파일, 배포 등 프로그램 개발에 관련된 모든 작업을 하나의 프로그램 내 처리하는 환경을 제공

   - 사례: 이클립스

   2) CVS(형상관리도구)

     - Check-In, Check-Out기능, 버전Control, Source의 무결성, 변경사항관리/기록

     - 사례: Subversion Clearcase

   3) Repository

     - Version, 형상정보, 오류정보, ISSUE를 기록하기 위한 저장소

     - 사례: 원본 Source및 Backup 저장소

    4) Build Server(서버)

      - Source Code의 최종본을 Build 및 Test하기 위한 서버

      - 사례: Windows계열 사용

    5) Scheduler(스케줄링)

      - Build, Test Scheduling, Batch Job Script활용하여 Job Time정의

      - 오류발생시 SM유지보수 담당자 E-mail Alert 적용 가능, Build Scheduling은 1일, 2일 또는 특정 요일

      - 사례: (Ex. 화, 목 00:00)로 적용할 수 있음 (Ant Script)

    6) Alerter, Reporter

      - ISSUE, 오류, 버그 발생 Alert 및 Report 도구, Bug Tracking System과 연계하여 구성가능

      - 사례: Luntbuild

1. CI(Continuous Integration)의 개요

 1-1. CI(Continuous Integration)의 정의

   - 여러 명으로 구성된 팀이 작업한 것을 자주 통합하는 것을 가리키는 소프트웨어 개발 프랙티스

   - 매번 이루어지는 통합은 자동화된 빌드와 테스트를 통하여 통합 에러가 없는지 가능한 빨리 검증되며 통합 시에 발생하는 문제도 조기 발견되어 단위코드의 품질을 향상시킴

 1-2. CI(Continuous Integration)의 특징

  1) 소스코드 일관성 유지: CI룰을 설정하기 위해서는 기본적으로 소스관리 시스템이 필요

  2) 소스코드 자동빌드: 소스 코드에 대한 빌드는 CI룰에 의해서 자동적으로 이루어짐

  3) 빌드 과정에서의 자동테스트(기능/비기능)

  4) 일일 체크아웃과 빌드를 통한 코드 무결성 유지

2. CI(Continuous Integration)의 구성도, 구성요소, 주요프로세스

 2-1. CI(Continuous Integration)의 구성도

 2-2. CI(Continuous Integration)의 구성요소

 1) 버전관리 저장소
    - 모든 프로젝트 파일의 중앙 저장소가 있어 팀원들의 작업을 전부 동기화 공간 제공

 2) 지속적인 통합서버 (CI시스템)
    - 컴파일, 테스트, 릴리즈, 디플로이, 결과보고 등의 작업을 통합적으로 자동화 해주는 SW

 3) 빌드 스크립트

   - 자동화된 절차를 위한 셀 스크립트(또는 배치파일)을 작성

  4) PM Tool

   - 빌드 결과를 모니터링 하거나 자동적으로 피드백을 받을 수 있는 관리도구로 의사소통도구 (이메일, 문자 메시지), 빌드 모니터등

  5) 자동화된 테스트

   - 결과를 스스로 확인하는 자동화된 테스트

 2-3. CI(Continuous Integration)의 주요프로세스