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

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

1. ATDD(Acceptance Test Driven Development)의 개요

 1-1. ATDD(Acceptance Test Driven Development)의 정의

   - 테스트로부터 시작해서 구현을 마무리 짓는 TDD의 범위를 소스 코드 수준에서 기능 테스트 수준까지 확장하여 고품질의 소프트웨어를 생산하는 개발 방법론

 1-2. ATDD(Acceptance Test Driven Development)의 필요성

   - 테스트 케이스 명확: 개발 착수 전 사용자, 개발자, QA등 제품 관련자들이 인수 테스트 케이스를 작성

   - 커뮤니케이션 도구: 토론하는 과정을 통해 요구사항에 대한 오해가 없고 충분한 의사소통가능

2. ATDD(Acceptance Test Driven Development )의 프로세스, 단계별 활동, 관련 기법간 비교

 2-1. ATDD(Acceptance Test Driven Development)의 프로세스

 2-2. ATDD(Acceptance Test Driven Development)의 단계별 활동

  1) 요구사항 토론
   활동 : 명확한 인수 기준 항목, 기능별 질문 사항 요구
   연관요소: 이해관계자와 협업, 자연어 기반 기록

 2) 프레임워크 포맷 기반의 케이스 작성
   활동: 테스트 자동화 F/W, 다양한 유형 테스트
   연관요소: FIT, Selenium

 3) TDD 수행
   활동: 테스트 픽스처 작성, setUp, tearDown
   연관요소: Regression Test, SUT

 4) 탐색적 테스팅
   활동: Test Code를 수행하면서 테스트 시나리오 작성
   연관요소: 테스트 차터

 2-3. ATDD(Acceptance Test Driven Development)와 관련 기법간 비교

- ATDD 시스템 품질(상위 레벨), TDD 소스 품질(하위 레벨)

1. SEM(Strategic Enterprise Management)의 개요

 1-1. SEM(Strategic Enterprise Management)의 정의

   - 기업의 경영 정보를 보다 정확히 판단하여 최고 경영진 및 임원으로 하여금 가치 중심의 경영을 전사적으로 구현할 수 있게 해주는 일련의 통합 경영 관리 체계.

 1-2. SEM(Strategic Enterprise Management)의 특징

   - 경영진이 가치 창출에 경영 활동을 집중하도록 회사의 비전, 목표, 전략을 정렬

   - 전략과 운영을 연계하며, 수익성을 제고하는 전략 경영을 위한 통합된 시스템

2. SEM(Strategic Enterprise Management)의 개념도, 구성요소

 2-1. SEM(Strategic Enterprise Management)의 개념도

 2-2. SEM(Strategic Enterprise Management)의 구성요소

 1) 가치중심 경영, VBM (Value Based Management)

   - 정의: 경영의사결정의 판단 기준을 손익위주에서 기업의 가치 중심으로 전환하여, 장기적으로 회사의 미래 성장이 유지되도록 계획, 실행, 통제함으로써 회사의 기업가치를 최대화 해나가는 동태적인 경영 사고

 2) 활동중심 원가관리, ABM (Activity Based Management) ABC(Costing)

   - 정의: 의사결정과정에서 경영자를 지원하는 강력한 도구이며, ABC 원가정보를 이용하여 기업에 나타나는 다양한 전략적이고 운영적인 의사결정이 이루어지게 하는 경영활동

 3) 기업성과 관리, BSC (Balanced Scorecard)

   - 정의: 기업의 성과를 재무, 고객, 내부 프로세스, 학습과 성장의 네 가지 관점에서 종합적이고 균형적으로 측정하는 성과 관리 시스템

 4) 실시간 분석 도구 OLAP (OnLine Analytical Processing)

   - 정의 : DW에 저장되어있는 대용량 데이터를 사용자의 의도대로 쉽게 사용(질의, 가공, 보고서작성, 분석)할 수 있도록 하는 데이터 처리 기법

3. SEM(Strategic Enterprise Management) 향후 전망

  - 부가가치 우선의 가치경영 도입의 필수적인 환경으로 발전

  - ERPⅡ, SCM, CRM 등의 업무성과 평가 측정을 위한 시스템의 연계

  - 경영 전략과의 연동 및 보상 체계와 연계

  - VBM, BSC, ABM 등의 신 경영지식과 신 정보기술로의 결합

1. TDD (Test Driven Development)의 개요

 1-1. TDD (Test Driven Development)의 정의

  - 프로그램에 대한 Test Case를 먼저 개발하고 이 Test Case를 통과하는 실제코드를 나중에 개발하는 Agile 개발방법

  - 테스트 작성으로 요구사항 검증 및 설계의 고도화, 짧은 주기에 Lifecycle을 반복하는 테스트-설계-피드백 중심의 개발 사고방식/방법론

 1-2. TDD (Test Driven Development)의 특징

  - Design for Testability : 소스코드의 의존성이 감소하고 독립적인 테스트가능

  - 테스트 커버리지 확보 : 단위테스트를 통한 테스트 커버리지 유지, 디버깅감소

  - Clean code that works : 작동하는 깔끔한 코드지향

2. TDD (Test Driven Development)의 개념도, 구성요소, 패턴

 2-1. TDD (Test Driven Development)의 개념도

  - Needs --> 해결방안모색 TODO List 작성 --> TODO List 세분화 --> Test 로 시작하는 method를 만듦 --> 테스트가 실패할 경우 실제코드를 작성 --> 가장빨리 테스트를 통과 --> 중복을 제거한 리팩토링--> 테스트코드로 밝히는 진실 --> 테스트 통과

 2-2. TDD (Test Driven Development)의 구성요소

  1) 사용자 요구사항 : 사용자, BA, 제품 개발자 등이 요구사항 Story작성, 유저스토리

  2) Test Case : 사용자, Tester등 관련자들이 Test Case 작성, Test Case

  3) Code 작성 : 테스트에 대해 실행 가능한 코드 작성. 임시코드

  4) Refactoring : Bad Small을 제거하여 Refactoring 수행, 리펙토링

 2-3. TDD (Test Driven Development)의 패턴

  1) 빨강막대 패턴 : 테스트를 언제, 어디에 작성할 것인지, 언제 멈출 것인지 결정

  2) 초록막대 패턴 : 코드가 테스트를 통과하도록 신속하게 작동하는 코드작성

  3) 테스트 패턴 : 상세한 테스트를 작성, 자식/모의객체/Self-Shunt/메시지 호출

  4) xUnit패턴 : 자동화된 단위테스트 지원 프레임 워크, jUnit, CppUnit, PyUnit

  5) 디자인 패턴 : 검증된 해결책 설계, Template/Best Practice

1. XP (extreme Programming)의 개요

 1-1. XP (extreme Programming)의 정의

   - 짧은 개발주기 반복(Iteration)을 통해 고객이 원하는 핵심적인 기능을 우선 구현 함으로서 프로젝트의 위험을 줄이는 프로그래밍 중심의 소프트웨어 개발방법론

 1-2. XP (extreme Programming)의 특징

  1) 신속한 피드백 : 개발자가 짧은 단위로 고객의 피드백을 받아서 고객의 요구 반영 확인 

  2) 단순함을 전제 : 현재의 문제에 집중해서 작업하고 미래의 일에 대해 걱정하지 않음

  3) 점진적인 수정 : 문제를 풀 때의 과정은 작은 교정의 연속

  4) 변화의 인정 : 변경 및 변화는 당연히 발생하는 것이라 인정함

  5) 고품질의 작업 : 선 테스트 후 프로그래밍 방법(TDD)으로 테스트의 중요성 강조

2. XP (extreme Programming)의 핵심 가치와 실천항목

 2-1. XP (extreme Programming)의 핵심 가치

  1) 용기 : 고객의 요구사항 변화에 능동적인 대처

  2) 단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제

  3) 커뮤니케이션 : 개발자, 관리자, 고객 간의 원활한 의사소통

  4) 피드백 : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백

 2-2. XP (extreme Programming)의 실천항목

3. XP (extreme Programming)의 개발 프로세스

 1) 사용자 스토리
    - 사용자 요구사항/UML의 유즈케이스와 같은 목적

 2) 스파이크
   - 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램

 3) 배포계획
   - 전체 프로젝트에 대한 배포 계획 생성

 4) 반복
   - 하나의 반복을 1~3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지

 5) 인수테스트
- 고객은 제대로 작동하는 시스템을 보면서 진척사항을 확인하고 이 시스템이 자신이 직접 명세한 테스트를 통과했는지 파악

 6) 작업배포
- 소규모로 빈번하게 배포하여 고객에게 이득 조기 제공

1. Agile 개발방법론의 개요

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

- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 고객과 상호작용하며 반복적으로 SW개발하는 방법론

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

  1) S/W개발 환경 변화 

    - 정보시스템의 time-to-market과 적시배포가 중요해짐

    - 사용자의 요구가 다양해지고 수명주기가 짧아짐

  2) 기존 개발방법론의 한계

   - 문서 및 절차위주의 방법론은 변화에 신속 대응 어려움

   - 변화에 빠르게 적응하고 효율적으로 개발할 수 있는 방법론 필요

  1-3. Agile 개발방법론의 4가지 핵심가치

   1) 프로세스나 도구에 앞서, 개인의 상호 협력을 중시

   2) 포괄적인 문서에 앞서, 작동하는 소프트웨어를 중심

   3) 계약 협상에 앞서, 고객과의 협력을 중시

   4) 계획 준수에 앞서, 변화에 대응을 중시

2. Agile 개발방법론의 개념도, 특징, 종류

 2-1. Agile 개발방법론의 개념도

  2-2. Agile 개발방법론의 특징

   1) 가변적 요구 대응

      - Predictive 하기 보다는 Adaptive한 방식임

   2) 고객만족

     - 개발 후반부라도 요구사항의 변화 적극 수용

     - 고객의 요구 사항 신속 대응: S/W 배포 일정이 짧음

   3) 개발자 동기부여

    - 개발자에게 적합한 개발환경 구성

    - 개발자가 책임을 완수할 것으로 신뢰

   4) PM의 역할변화

    - 프로젝트 관리자에서 촉진자로 변경

    - 프로젝트 계획수립 및 통제의 책임이 팀원에게 이양

   5) Sweet Spots

    - 한 작업실에 5~8명의 작업자

    - Key User 상주: 개발자와 사용자간 중계역할, 신속한 피드백 가능

   6) 적용 범위

    - 중소형, 아키텍처 설계, 프로토타이핑에 적합

  2-3.  Agile 개발방법론의 종류

   1) XP
    - extreme programming
    - 의사소통 개선, 즉각적인 피드백에 의해 단순하게 코딩하여 S/W 품질 향상
    - 테스트 강조, 4가지 가치와 12개 실천항목
    - 1~3주 단위의 반복
    - 가장 주목 받음
    - 개발 관점

  2) SCRUM
    - 프로젝트를 스프린트(30일 단위 반복)로 분리, 팀은 매일 스크럼(15분정도) 미팅으로 계획수립
    - 팀 구성원이 어떻게 활동해야 하는가에 초점
    - 통합 및 인수 테스트가 상세하지 않음
    - Iteration 계획과 Tracking에 중점

  3) UP
    - 완전한 S/W 개발 모델 제시
    - 비주얼 모델링 도구 지원
    - Agility 성격 강조

  4) Crystal
    - 프로젝트 상황에 따라 알맞은 방법론을 적용할 수 있도록 다양한 방법론 제시
    - Tailoring 하는 원칙 제공
    - 프로젝트 중요도와 크기에 따른 메소드 방법 제시

  5) FDD
    - Feature Driven Development
    - 기능 모델, 설계와 구현, 수행의 3단계 사이클
    - 짧은 Iteration(2주)과 5단계 프로세스
    - 설계와 구축 프로세스의 반복