Rational Unified Process

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