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사의 제품으로 제한되며 제품의 가격이 고가

 

 

신고
by Hazard 2009.02.12 19:38