[좐]군의 To-Be :: UP에 대한 정리

1. UP의 개요
-UML은 다양한 목적과 범위를 갖는 다양한 프로세스에서 사용할 수 있도록 설계되었다.
-프로세스는 무엇을, 언제, 어떻게, 왜 수행해야 하는지를 설명한다.
-소프트웨어 개발 프로세스는 그림 13-1과 같이 사용자의 요구사항을 소프트웨어 시스템으로 변환시키기 위한 일련의 활동이다.
-Unified Process의 목적은 최종 사용자의 요구를 충족시키는 고품질의 소프트웨어를 주어진 일정과 예산 범위 내에서 개발하는 것이다.

2. UP의 특징

(1) 소프트웨어를 반복적으로 개발한다.
(2) 사용자의 요구사항을 관리한다.
(3) 컴포넌트 기반의 아키텍처를 사용한다.
(4) 소프트웨어를 시각적으로 모델링한다.
(5) 소프트웨어 품질을 검증한다.
(6) 소프트웨어의 변경을 통제한다.

2.1. 유즈케이스 기반
- 유스 케이스 모델은 전형적인 시스템의 기능 명세서(functional specification)를 대체한다. 기능 명세서는 “시스템이 무엇을 수행하여야 하는가?”에 대한 응답을 할 수 있다.
- 유스 케이스는 요구사항을 지정하기 위한 도구만은 아니다.
- 유스 케이스는 시스템의 설계, 구현 및 테스트를 유도한다.
- 즉, 유스 케이스는 개발 프로세스를 유도한다.
- 개발자는 유스 케이스 모델에 근거하여 유스 케이스를 실현하는 일련의 설계 모델과 구현 모델을 작성한다.
- 개발자는 유스 케이스 모델에 대한 적합성을 위하여 각각의 모델을 검토한다.
- 테스터는 구현 모델의 컴포넌트가 유스 케이스를 정확히 구현했는지를 보장하기 위하여 구현을 테스트한다.

2.2. 아키텍쳐 중심
-소프트웨어 아키텍처의 역할은 건축물을 구축하는 과정에서의 아키텍처의 역할과 유사하다.
-소프트웨어 시스템의 아키텍처는 구축하고자 하는 시스템에 대한 다양한 뷰로 표현된다.
-소프트웨어 아키텍처 개념은 시스템의 가장 중요한 정적인 측면과 동적인 측면을 구체화한다.
-아키텍처는 구체적인 사항을 제거함으로써 보다 가시화되는 중요한 특성을 갖는 전체 설계에 대한 뷰이다.
-프로세스는 아키텍처 개발자가 올바른 목표에 집중할 수 있도록 도와준다.
-아키텍처와 유스 케이스는 어떠한 관계를 갖는가?
-모든 제품은 기능과 형태를 갖는다. 어느 것도 하나만으로는 충분하지 못하다.
-따라서 기능과 형태는 성공적인 제품을 얻기 위하여 균형을 이루어야 한다.
-이때 기능은 유스 케이스에 대응되며, 형태는 아키텍처에 대응된다.
-즉, 아키텍처와 유스 케이스는 병행하여 발전하여야 한다.
-아키텍처 개발자는 개발 대상 시스템의 핵심적인 기능을 표현하는 유스 케이스의 부분 집합을 가지고 작업을 수행한다.
-선택된 각각의 유스 케이스는 서브시스템, 클래스, 컴포넌트로 구체화되고 실현된다.
-유스 케이스가 완성됨에 따라 보다 많은 아키텍처가 식별된다.

2.3. 반복과 점진
-대부분의 상용 소프트웨어를 개발하기 위해서는 수개월에서 많게는 수년 혹은 그 이상이 소요된다.
-이러한 경우 개발 작업을 보다 작은 단위 혹은 미니 프로젝트로 나누어 수행하는 것이 실용적이다.
-각각의 미니 프로젝트는 증가분(increment)을 만들어 내는 반복(iteration)이다.
-반복은 작업 분야(discipline)의 단계를 의미하며, 증가분은 제품의 성장을 의미한다.
-이러한 이유로 반복을 미니 프로젝트라고 한다.
-개발자는 다음과 같은 두 가지의 요소에 근거하여 각각의 반복에서 구현할 대상을 선택한다.
-반복은 지금까지 개발된 산출물의 유용성을 함께 확장시키는 유스 케이스의 그룹을 다룬다.
-반복은 가장 중요한 위험을 다룬다

3. 프로세스
3.1. 프로세스 구조

-Unified Process는 시스템의 생명을 구성하는 일련의 주기(cycle)에서 반복된다.
-각각의 주기는 사용자에게 전달되는 산출물 릴리즈로 종료된다.
-각각의 주기는 [그림 14.2]와 같이 시작(inception) 단계, 상세(elaboration) 단계, 구축(construction) 단계 및 전환(transition) 단계의 네 가지 단계(phase)로 구성된다.
-각각의 단계는 반복(iteration)으로 추가적으로 나누어진다.
-Unified Process는 이차원적인 구조를 갖는다.
-수평축은 시간을 표현하며 프로세스의 생명주기 측면을 보여준다.
-수직축은 활동의 특성에 따라 활동을 논리적으로 그룹핑하는 핵심적인 프로세스 분야(process discipline)를 표현한다.
-첫 번째 차원은 프로세스의 동적인 측면을 표현하는 것으로 주기, 단계, 반복 및 이정표(milestone) 등의 항목으로 표현된다.
-두 번째 차원은 프로세스의 정적인 측면을 표현하는 것으로 프로세스 컴포넌트, 활동, 작업 분야, 산출물 및 작업자의 항목으로 표현된다.

3.2. 반복적인 프로세스 4단계

(1) 시작(inception) 단계 : 최종 산출물에 대한 비전과 비즈니스 케이스를 지정하고, 프로젝트의 범위를 정의한다. 시작 단계는 생명주기 목표(life cycle objective) 이정표에 의해 종료된다.

(2) 상세(elaboration) 단계 : 필요한 활동과 자원을 계획하고, 소프트웨어의 특징을 지정하며, 아키텍처를 설계한다. 상세 단계는 생명주기 아키텍처(life cycle architecture) 이정표에 의해 종료된다.

(3) 구축(construction) 단계 : 산출물을 개발하고, 산출물을 사용자에게 납품할 수 있을 때까지 산출물의 비전, 아키텍처 및 계획을 발전시킨다.

구축 단계는 초기 운용 능력(initial operational capability) 이정표에 의해 종료된다.

(4) 전환(transition) 단계 : 산출물을 사용자에게 전달하고, 사용자가 만족할 때까지 교육, 훈련, 기술 지원 및 유지보수를 제공한다.

3.3. 반복적인 UP 프로세스의 이정표

소프트웨어의 수명이 한 세대에서 종료되지 않는다면, 기존의 산출물은 시작, 상세, 구축 및 전환의 동일한 순서를 반복하면서 다음 세대로 진화하게 된다.
이러한 주기를 진화 주기(evolution cycle)라고 한다.

4. 개발 주기별 주요 활동

(1) 시작 단계 : 전체적인 요구사항을 이해하고 개발 노력의 범위를 결정하는데 중점을 둔다.

(2) 상세 단계 : 기본적으로는 요구사항에 중점을 두지만 아키텍처에 대한 프로토타입 개발, 기술적인 위험 요소의 완화, 도구 및 기법의 사용 방법에 대한 학습 등을 위하여 약간의 소프트웨어 설계와 구현이 추가된다.

상세 단계에서 사용자는 다음 단계를 위한 기준선(baseline)으로 역할을 하게 될 실행 가능한 아키텍처 프로토타입을 개발한다.

(3) 구축 단계 : 설계와 구현에 중점을 둔다.

구축 단계에서 사용자는 초기의 프로토타입을 첫 번째 운용 가능한 산출물로 발전시킨다.

(4) 전환 단계 : 시스템이 사용자의 목적을 충족시키는 품질 수준에 도달했음을 보장한다. 전환 단계에서 소프트웨어의 결점을 제거하고, 사용자를 교육하며, 누락된 요소들을 추가한다. 최종적인 산출물을 개발하여 납품한다.

4.1. 시작단계

4.1.1. 목적

(1) 운용 개념, 인수 기준, 산출물에 대한 설명 등을 포함하는 프로젝트의 소프트웨어 범위 및 경계 조건의 설정

(2) 시스템의 주요 유스 케이스 식별. 즉, 시스템의 기능을 유도하는 행위에 대한 기본적인 시나리오와 주요 설계 트레이드-오프(trade-off)의 구성

(3) 기본적인 시나리오에 대한 최소한 하나의 후보 아키텍처의 제시 및 증명

(4) 전체 프로젝트에 대한 비용 및 스케줄 산정과 상세 단계에 대한 세부적인 추정 제공

(5) 잠재적인 위험의 추정

4.1.2. 활동

(1) 프로젝트의 범위 결정. 즉, 가장 중요한 요구사항과 제약조건을 파악하여 최종 산출물에 대한 인수 기준을 유도한다.

(2) 비즈니스 케이스의 계획과 준비. 그리고 위험 관리, 인력 투입, 프로젝트 계획, 비용 및 스케줄간의 트레이드-오프 등을 위한 대안 평가

(3) 후보 아키텍처의 종합, 설계의 트레이드-오프 평가, 개발/구매/재사용 결정의 평가 및 비용, 스케줄, 자원에 대한 추정

4.1.3. 산출물

(1) 비전 문서(vision document). 즉, 코어 프로젝트의 요구사항, 주요 특징 및 주요 제약조건에 대한 일반적인 비전

(2) 초기 단계에 식별할 수 있는 모든 유스 케이스 및 액터를 나열하는 유스 케이스 모델 서베이(use-case model survey)

(3) 초기 프로젝트 용어집(project glossary)

(4) 다음을 포함하는 초기 비즈니스 케이스

- 비즈니스 컨텍스트

- 성공 기준

- 재무 예측

(5) 초기 위험 평가

(6) 단계와 반복을 보여주는 프로젝트 계획

(7) 추가적 산출물

∙ 초기 유스 케이스 모델(10%～20% 완료)

∙ 프로젝트 용어집보다 복잡한 도메인 모델

∙ 필요한 경우, 비즈니스 모델

∙ 사용하는 프로세스를 설명하기 위한 예비 개발 케이스(development case) 설명

∙ 하나 혹은 그 이상의 프로토타입

4.1.4. 평가기준

(1) 범위 정의 및 비용, 스케줄 추정에 대한 이해 당사자의 합의

(2) 기본 유스 케이스의 충실도에 근거한 요구사항에 대한 이해

(3) 비용 및 스케줄 추정, 우선순위, 위험 및 개발 프로세스의 신뢰성

(4) 개발된 아키텍처 프로토타입의 깊이와 폭

(5) 실제의 지출 대 계획된 지출

4.2. 상세단계

4.2.1. 목표

(1) 가능한 한 빠른 아키텍처의 정의, 검증 및 기준선 지정(baselining)

(2) 비전의 기준선 지정

(3) 구축 단계를 위한 신뢰할 수 있는 계획의 기준선 지정

(4) 아키텍처 기준선이 합리적인 비용과 시간 이내에 이러한 비전을 지원한다는 증명

4.2.2. 활동

(1) 비전을 구체화하며, 아키텍처 결정과 계획 수립 결정에 영향을 미치는 가장 중요한 유스 케이스를 확실히 이해한다.

(2) 프로세스, 기반구조 및 개발 환경을 구체화하고 프로세스, 도구 및 자동화 지원을 준비한다.

(3) 아키텍처를 구체화하고 컴포넌트를 선택한다.

잠재적인 컴포넌트를 평가하고, 구축 단계의 비용과 스케줄을 결정하기 위하여 개발/구매/재사용 결정을 충분히 고려한다.

선택한 아키텍처 컴포넌트를 통합하고 기본적인 시나리오에 대해 평가한다.

이러한 활동의 결과를 이용하여 요구사항을 다시 고려하거나 대안 설계를 고려하면서 아키텍처를 재설계할 수 있다.

4.2.3. 산출물

(1) 유스 케이스 모델 서베이에 모든 유스 케이스가 식별되고, 모든 액터가 식별되며, 대부분의 유스 케이스 설명이 개발된 유스 케이스 모델(최소한 80% 완료)

(2) 특정한 유스 케이스에 관련되지 않은 비기능적 요구사항과 기타의 요구사항을 확보하는 추가적인 요구사항

(3) 소프트웨어 아키텍처 설명

(4) 실행 가능한 아키텍처 프로토타입

(5) 수정된 위험 목록과 비즈니스 케이스

(6) 반복과 각각의 반복에 대한 평가 기준을 제시하는 전체 프로젝트에 대한 개발 계획

(7) 사용하려는 프로세스를 지정하는 수정된 개발 케이스

(8) 예비 사용 매뉴얼(선택적)

4.2.4. 평가기준

(1) 산출물 비전의 안정성

(2) 아키텍처의 안정성

(3) 주요 위험 요소의 파악 및 해결

(4) 구축 단계 계획의 상세함과 정확성

(5) 현재 아키텍처 환경에서 현재 비전의 달성 가능성에 대한 이해 당사자의 합의

(6) 실제의 지출 대 계획된 지출

만약 프로젝트가 생명주기 아키텍처 이정표를 통과하는데 실패하면, 프로젝트가 취소되거나 심층적인 재검토가 요구될 수 있다.

4.3. 구축단계

4.3.1. 목표

(1) 자원의 최적화 및 불필요한 작업의 제거를 통한 개발 비용의 최소화

(2) 적절한 품질 달성

(3)∙ 유용한 버전 확보(알파, 베타 및 기타의 테스트 릴리즈)

4.3.2. 활동

(1) 자원 관리, 자원 통제 및 프로세스 최적화

(2) 완전한 컴포넌트 개발 및 평가 기준에 대한 테스팅

(3) 비전을 위한 수락 기준에 대한 산출물 릴리즈의 평가

4.3.3. 산출물

(1) 적절한 플랫폼에 통합된 소프트웨어 산출물

(2) 사용자 매뉴얼

(3) 현재 릴리즈에 대한 설명

4.3.4. 평가기준

(1) 사용자에게 배치할 수 있는 정도의 산출물 릴리즈의 안정성과 성숙도

(2) 모든 이해 당사자가 사용자로 전환하기 위한 준비

(3) 실제의 지출 대 계획된 지출

4.4. 전환단계

전환 단계의 목적은 소프트웨어 산출물을 사용자에게 제공하는 것이다

(1) 사용자 기대를 충족시키는 새로운 시스템을 검증하기 위한 베타 테스팅

(2) 대체 대상인 레거시 시스템과의 병행 운영

(3) 운영 데이터베이스의 변환

(4) 사용자 및 유지보수 담당자에 대한 교육 훈련

(5) 마켓팅, 배포 등을 위한 산출물의 공개

전환 단계는 소프트웨어를 최종 사용자에게 제공하기 위한 활동에 중점을 둔다.

전환 단계는 베타 릴리즈(beta release), 일반 가용 릴리즈(general availability release), 결함 제거 및 개선 릴리즈(bug-fix and enhancement release) 등을 포함하는 다수의 반복으로 이루어진다.

4.4.1. 목표

(1) 사용자 지원 보장

(2) 배치 기준선의 완전성 및 평가 기준에 대한 적합성 여부의 이해 당사자 합의

(3) 최종 산출물 기준선의 확보

4.4.2. 활동

(1) 소프트웨어 배치에 관련된 엔지니어링 활동

(2) 성능과 유용성을 위한 결함 제거 및 개선 등의 튜닝 활동

(3) 산출물에 대한 인수 기준 및 비전에 대한 배치 기준선의 평가

전환 단계에서 반복 동안에 수행되는 활동은 목적에 따라 달라진다.

예를 들어, 결함 제거를 위한 경우에는 구현과 테스팅 만으로도 충분하다.

그러나 새로운 기능을 추가하는 경우에는 구축 단계의 활동과 유사한 반복이 이루어진다.

4.4.4. 평가기준

(1) 사용자의 만족도

(2) 실제의 지출 대 계획된 지출

UP의 주요 산출물 요약

분야	산출물	단계
분야	산출물	시작 I₁	상세 E₁...E_n	구축 C₁...C_n	전환 T₁...T_n
비즈니스 모델링	도메인 모델		시작
요구사항	유스 케이스 모델	시작	구체화
	비전	시작	구체화
	보충 명세서	시작	구체화
	용어집	시작	구체화
설계	설계 모델		시작	구체화
	소프트웨어 아키텍처 문서		시작
	데이터 모델		시작	구체화
구현	구현 모델		시작	구체화	구체화
프로젝트 관리	소프트웨어 개발 계획	시작	구체화	구체화	구체화
테스팅	테스트 모델		시작	구체화
환경	개발 케이스	시작	구체화