'소프트웨어공학'에 해당되는 글 5건

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. 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. 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. CBD(Component Based Development)방법론의 개요

 1-1. CBD(Component Based Development)방법론의 정의

    - 재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션의 개발생산성과 품질을 높이고 시스템 유지보수비용을 최소화하는 혁신적 방법

 1-2. CBD(Component Based Development)방법론의 등장배경

    - 객체지향 개발 방법론이 해결하지 못한 개발 생산성, 재사용성, 시스템 유지보수성 등을 해결하기 위한 대안으로 등장

    - 업무, 기술, e-Business 조직의 변화

2. CBD(Component Based Development)방법론의 개발 프로세스 구조, 프로세스 요소

 2-1. CBD(Component Based Development)방법론의 개발 프로세스 구조

 2-2. CBD(Component Based Development)방법론의 프로세스 요소

  1) CD
    - CD (Component Development)
    - SW 개발에 필요한 부품을 만드는 과정
    - 재사용 목적상 해당 도메인에 대한 분석이 핵심사항

  2) CBD
   - CBD (Component Based Development)
   - 컴포넌트들을 조립하여 새로운 응용 소프트웨어 제품개발
   - 반복적 개발 프로세스를 적용하여 혁신적인 생산성 향상

3. CBD(Component Based Development)방법론의 구축방안

  1) 아키텍처 중심적 : 아키텍처 중심 개발을 통한 가시성 확보, 위험 조기 식별 및 대응

  2) 엔지니어링 도구 : 자동화된 툴을 통해 생산성과 정확성 향상 가능

  3) 프레임워크 기반 : 프레임워크 기반 개발은 개발생산성 향상 및 품질향상의 기반 역할

  4) 수행조직 : 컴포넌트 개발팀, 솔루션 개발팀, 조직지원팀의 역할 분담

  5) 표준 및 방법론 :

    - 실행환경 표준: .NET, J2EE, CCM
    - 개발표준:UML기반 개발표준 및 RUP와 같은 방법론

  6) 개발 역량 강화 : 개발팀원의 기반 기술 습득 정도, 표준 이해 및 준수 정도

  7) 재사용관리체계 : 컴포넌트 재사용 자산 축적 및 품질관리 체계 구축 중요

  8) 경험 축적 : 프로젝트 관리나 아키텍처 정립에 대한 경험과 적용 능력 중요

  9) 정책 : 개발자들이 컴포넌트에 대해 긍정적인 마인드를 갖도록 고취

소프트웨어 가시화 (Software Visualization)

1. 소프트웨어 가시화 (Software Visualization)의 개요

 1-1. 정의

   - SW의 비가시성을 극복함으로써 SW 개발의 전체 과정을 파악할 수 있도록 하며 이를 통하여 효율적인 SW의 개발 관리를 실현하기 위한 방안

  1-2. 배경

   - SW 개발 비가시성 : SW의 구체적인 모습, 결과물의 확인이 개발 도중에는 어려움

   - 품질체계, 프로세스 측면 : 다양하게 변환하는 고객요구사항에 따른 정해진 프로세스만으로는 품질확보 불가

   - 정책적 측면: SW 공생발전정책추진에 따른 중소 SW 기업입장의 품질관리 대응책 필요

2. 소프트웨어 가시화 (Software Visualization)

 2-1. 소프트웨어 가시화 (Software Visualization)의 구성도   

 2-2. 소프트웨어 가시화 (Software Visualization)의 구성요소

  1) 요구사항 

     - 요구사항, 변경관리

     - 고객요구사항 및 변경관리, 변경에 따른 설계, 구현, 검증, 테스트 이슈 트레킹, 검증 지원

  2) 일정관리

     - 개발수명주기, 개발 진척도 관리

     - 개발공정의 기시성, 개발단계의 짧은 반복공정지원

     - 프로그램 코드량, 빌드 횟수, 결함율, 요구사항 매치율

  3) 품질관리

     - 품질제어기술, 품질관리기술

     - 결함율, 재사용율, 복잡도 등의 지표운영, 자동 측정

     - 요구수준의 품질척도 정의, 운영, 확보지원, 개선점 식별

  4) 유지보수성

      - 재사용성, Core Asset

      - SW 가변부, 고통부 식별체계 지원, 설계/아키텍쳐 지원

      - 요구사항 ~ 코드 ~ 테스트 등의 Asset화 지원

3. 소프트웨어 가시화 (Software Visualization)

 1) 개발상태 실시간 파악

 2) 객관적, 정량적 분석

 3) 개발의 투명성

 4) 자동화 편의성

 5) 문서 작업 간소화

 6) 품질기반 개발문화