2011년 6월 3일 금요일

RUP(Rational Unified Process)

RUP 정의
- Booch. Rumbaugh, Jacoson 제안한 Rational 사가 개발한 소프트웨어 개발을 위한 가이드를 제공하는 프로세스 플랫폼
- 소프트웨어 시스템을 시각화하고 명세화하며 구축하고 문서화하기 위한 산업의 표준 메커니즘

RUP 특징
- 여러 번의 반복을 거치며 각각의 반복은 요구사항 분석, 설계, 구현 테스트, 평가 과정을 포함하고 있어 자체로서도 하나의 개발주기를 구성
- 반복마다 실행 가능한 릴리즈가 산출되고 이는 반복이 거듭될수록 향상되어 결국 최종시스템으로 발전

RUP 구조

- 수평축은 시간에 따른 변화, 동적인 생명주기 측면을 나타낸다. 시간의 흐름에 따라 단계(phase) 나누고 단계별 이정표(milestone) 제시한다.
- 수직축은 핵심적인 작업흐름(workflow) 보여주며 이는 활동(activity) 논리적으로 집단화시킨 것이다. 이것은 정적인 측면에서 공정 구성요소, 활동, 작업흐름, 산출물(artifact), 작업자(worker)들로 표현한다.

RUP 구성요소
구성요소내용
작업자
(Worker)
- 개인이나 그룹의 행위와 책임을 의미
- 작업자는 주어진 일을 수행해야 하는 역할을 의미
- 하나 이상의 역할을 수행하는 외에도 특정 산출물의 소유자가
활동
(Activity)
- 특정 작업자의 활동은 작업자의 역할에 따라 수행해야 하는 단위 업무를 말함
- 활동은 일반적으로 시간에서 며칠 정도가 소요되고, 보통 하나의 작업자에 의해 수행되며, 하나 혹은 적은 수의 산출물에 영향을 미침
산출물
(Artifact)
- 프로세스에 의해 생성되고 수정되고 사용되는 정보의 단위
- 프로젝트에서 최종 제품을 개발하는 과정에서 생성되고 사용되는 형태를 갖는 산물
- 작업자가 특정 활동을 수행할 입력으로 사용될 있으며 활동 수행의 결과로 생성될 있음
공정
(Discipline)
- 프로세스를 이루기 위해서는 가치 있는 결과를 생성할 있게 하는 활동의 순서와 작업자간의 상호작용을 기술할 있어야


RUP 개발 단계
1. 인식 단계
항목
내용
목표
- 제품의 운영 개념, 인수 조건 등을 포함한 프로젝트의 범위 설정
- 시스템의 사용사례 식별
- 전체 프로젝트에 대한 비용과 일정 견적, 구체 단계에 대한 상세한 견적
- 잠재적인 위험 요소 식별
활동
- 프로젝트의 범위를 공식화한다. 배경과 요구사항, 제한 조건 등을 파악하고 최종 제품에 대한 인수 조건을 끌어낸다.
- 업무 사례를 식별하고 비용과 일정, 수익성 등을 평가한다.
- 시스템의 아키텍처로 사용할 후보들을 식별하고 비용과 일정, 자원에 견주어 개발/구매/재사용 등의 정책을 결정한다.
산출물
- 비전 문서(vision document) à 시스템의 핵심적인 요구사항, 주요 특징, 제한 조건 등에 대한 일반적인 비전.
- 초기 사용사례 모델 à 초기에 식별한 모든 사용사례와 액터들의 목록
- 초기 용어집
- 업무 사례
- 업무 배경
- 성공 조건 (수익성, 시장성 )
- 재정 상황 예측
- 초기 위험 평가서
- 프로젝트 계획
- 단계와 반복 규정
이정표
- 프로젝트 범위와 비용, 일정 등에 대한 의견 일치
- 초기 사용사례 모델에 나타난 요구사항에 대한 이해도
- 비용과 일정, 우선 순위, 위험 요소, 개발 공정에 대한 신빙성
- 프로토타입의 깊이와 범위
- 예상 지출과 실제 지출
- 만일 프로젝트가 평가에 합격하지 못하면 취소하거나 고려할 있다.


2. 구체화 단계
항목
내용
목표
- 아키텍처의 정의, 검증, 기준선(baseline) 설정
- 구축 단계의 상세 계획 설정
- 기준선으로 설정된 아키텍처가 적절한 비용과 일정으로 시스템의 목표를 달성할 있는지 확인
활동
- 개발환경을 구축하고 공정, 개발 도구, 자동화 도구 등을 적절히 사용한다.
- 아키텍처를 정교화한다. 컴포넌트를 선택하여 주요 시나리오에 대하여 통합시키고 평가한다. 평가는 아키텍처의 재설계로 이어질 있다.
- 컴포넌트에 대한 개발/구매/재사용을 결정한다.
산출물
- 사용사례 모델 à 모든 사용사례와 액터의 목록과 사용사례 설명.
- 보조 요구사항 à 비기능적 요구사항이나 사용사례와 연관되어 있지 않은 요구사항들의 목록
- 소프트웨어 아키텍처 기술서
- 실행 가능한 아키텍처 프로토타입
- 개정된 위험 목록과 업무 사례
- 상세 개발 계획 à 반복에서의 평가 기준 등을 포함
- 사용설명서 (선택적)
이정표
- 제품의 비전은 안정적인가?
- 아키텍처는 비전을 성취할 있는가? 또한 안정적인가?
- 중요한 기술적 위험 요소들이 해결되었는가?
- 구축 단계의 계획이 충분히 상세하고 정확한가?
- 예상 지출과 실제 지출이 적절한가?
- 만일 프로젝트가 평가에 합격하지 못하면 파기하거나 고려할 있다.


3. 구축 단계
항목
내용
목표
- 자원의 최적화와 불필요한 재작업을 줄임으로써 개발 비용 최소화
- 적절한 품질 획득
- 시험판 획득
활동
- 자원을 관리하고 공정을 최적화한다.
- 컴포넌트 개발을 완료하고 평가 기준에 따라 시험한다.
- 시험판(알파판, 베타판 ) 발표하고 검수 기준에 따라 평가한다.
산출물
- 적합한 플랫폼에 통합된 소프트웨어 제품
- 사용설명서
- 제품 발표 설명서 (release description)
이정표
- 제품이 사용자에게 인도할 있을 만큼 안정적이고 기능이 모두 구현되었는가?
- 예상 지출과 실제 지출이 적절한가?
- 만일 프로젝트가 평가에 합격하지 못하면 다음 시험판 발표 때까지 인도 단계를 연기할 있다.


4. 인도 단계
항목
내용
목표
- 사용자 검수를 거친 최종 제품 획득
활동
- 제품을 포장하고 배포한다.
- 오류를 수정하고 성능과 활용성을 보강한다.
산출물
- 소프트웨어 제품
이정표
- 사용자가 만족하였는가?
- 예상 지출과 실제 지출이 적절한가?
- 프로젝트에 따라 개발 주기를 시작할 있다.


Waterfall Model Iterative & Incremental Model 비료
특징
Waterfall Model
Iterative & Incremental
장점
- 전체과정이 이해하기 용이
- 단계별로 정형화된 접근 방법
- 체계적인 문서화, 단계별 산출물 체크를 통한 프로젝트 진행의 명확화
- 예측 가능하며 변경에 민감
- 어려운 부분은 반복수행하여 위험감소
- 개발 생산성을 높이고 사용자의 참여 극대화
- 전반적으로 높은 품질을 얻을 있음
단점
- 문서 중심의 개발 접근 방식으로 인한 개발자의 문서화에 대한 부담 가중
- 처음 단계를 지나치게 강조하면 코딩, 테스트 지연
- 개발 초기에 사용자의 요구사항을 명확하게 찾아내기가 어려움
- 반복 수행시 비슷한 내용의 산출물 재생산 우려
- RUP 배우거나 다루기에 너무 광범위하고 어려움
- RUP 경우 프로세스를 지원하는 툴은 Rational사의 제품으로 제한되며 제품의 가격이 고가

댓글 없음:

댓글 쓰기

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...