[소프트웨어공학] 5. RUP (Rational Unified Process)

RUP(Rational Unified Process)

RUP는 Rational 라는 회사에서 만든 소프트웨어 개발 프로세스를 말한다.

보통 3번째 글에서 정리한 소프트웨어 모델들을 조합하여 소프트웨어를 개발하는데, 각자 자신들만의 개발 방법론을 쓴다고 해도 그 3가지를 조합해서 사용하는 것은 비슷하기 때문에 RUP 만 살펴봐도 다른 개발 방법론을 이해하는데는 충분하다.

 

RUP에서는 크게 3가지 perspective를 가지고 process 를 설명한다.

 

dynamic perspective

dynamic perspective는 시간에 따라서 어떻게 단계가 변하는지 보여준다.

 

 

dynamic perspective 에서는 소프트웨어 개발의 4개 단계를 각각을 반복할 수 있으며, 전체 프로세스도 계속해서 반복되는 것을 나타낸다. 그리고 각각의 Phase는 기술적인 부분보다 비즈니스에 더 밀접하게 연관이 되어있다. (그래서 기존의 specification ~ maintenance 와 다른 용어로 표현한 것 같다.)

 

- Inception

'착수하다' 라는 뜻을 가지고 있는 단어로, 시스템을 위한 business case 를 만들고 각 business case 가 시스템에 얼마나 중요한지 평가한다.

 

예를 들어 새로운 핸드폰 기종을 개발하면서 핸드폰에 홀로그램을 넣겠다고 해보자.

기존에는 홀로그램을 넣는 것이 실현가능한지 고민하고 실제 사용자들을 인터뷰하면서 파악했다면, RUP에서는 비즈니스적으로 도움이 되는지, 홀로그램 가격은 어떤지 등을 따져서 평가한다.

 

요구사항을 파악할 때 철저하게 비즈니스 관점에서 생각하고, 평가가 좋지 않다면 다시 다른 아이디어를 고민하기를 반복한다.

사실 이 단계가 선행되어야만 이후 단계가 진행되는 것이 의미있기 때문에 Inception 단계가 제일 중요하고 많이 반복된다.

 

 

- Elaboration

비즈니스 케이스를 정교하게 다듬는다는 뜻으로, 이 비즈니스 케이스를 넣기로 했으니 프로그램 도메인에 대한 이해를 높이고, 구조적인 프레임워크를 만들고, 프로젝트 플랜을 세우고, 중요한 프로젝트 리스크 요소를 파악한다.

 

- Construction

이 단계에서 시스템을 설계하고 개발한 뒤 테스트하는 단계를 수행한다.

 

- Transition

개발한 시스템을 배포한다. (마켓으로 트랜지션한다.)

 

 

static perspective

어떤 process activity 를 사용하는지를 나타낸다.

 

 

RUP 에서는 activity 를 workflow 라고 표현하기도 한다.

예를 들어 buisness modeling 은 business case 를 만드는 것을 의미한다.

이런 각각의 workflow 는 특정 phase 에 묶이지 않고, 어떤 phase 에서도 이 workflow 를 모두 활용할 수 있다.

inception 할 때는 business modeling 도 필요하고, 비즈니스 케이스를 평가하기 위해 프로토타입을 만든다면 requirement, implementation, testing 이 모두 필요할 수 있다.

 

 

각각의 static workflows 와 RUP phases 를 함께 고려해보면 위와 같이 그림을 그릴 수 있다.

곡선이 위쪽에 있으면 자주 사용한다는 것이고, 아래쪽으로 꺽어지면 자주 사용되지 않음을 나타낸다.

 

예를 들어 비즈니스 모델링(BM)은 Inception 단계와 Elaboration 단계에서 자주 사용되고 Construction, Transition 단계에서는 비교적 자주 사용되지 않는다. (사용할 수 없다는 것은 아니다.)

Rrequirement(R) 역시 I, E 단계에서 활용할 것이다.

 

AD, I, T 는 다른 단계에서도 사용하겠지만 C 단계에서 제일 많이 활용할 것이고,

Deployment(D)는 아무래도 T 단계에서 제일 많이 활용할 것이다.

 

Project management (P) 는 모든 단계에서 꾸준히 필요하다. (각 단계에서 나오는 문서를 관리하는 것도 프로젝트 관리의 일환이므로)

 

이 그림을 통해 특정 workflow 가 특정 단계에서 자주 사용될 수는 있어도 그 단계에만 묶여서 사용되지 않음을 알 수 있다.

 

Pratice Perspective

마지막으로 practice perspective (good practice) 는 어떻게 개발해야 소프트웨어를 잘 개발할 수 있는지에 대한 이야기를 다룬다.

 

- 반복을 활용해서 소프트웨어 개발하기 (소프트웨어를 개발할 때 프로세스가 반복되는 것은 당연하다)

- requirement 관리하기 (requirement 의 변경사항을 모두 문서화해두기)

- 컴포넌트 기반의 아키텍처를 사용하기 (기존 컴포넌트를 최대한 재사용하기)

- 소프트웨어를 최대한 시각적으로 모델링하기 (뒤에서 정리할 다이어그램 등을 활용하여 모델링해야 한다.)

- 소프트웨어의 퀄리티를 검증하기

- 소프트웨어의 변화를 제어하기 (형상관리 도구를 활용하여 변경사항을 트래킹하고 버저닝하기)