opid's document

1. RUP ?

미국의 UML을 처음으로 제창하고, 표준화에 커다란 역할을 한 Rational사(社)가 개발에서 판매하고 있는 상용 개발 프로세스이다. (Rational사는 2003년에 IBM사에 합병되었지만, 제품의 브랜드는 아직도 그대로 사용되고 있다.)

2. 특징

2-1. 반복형 개발을 전제로 프로젝트 계획 전체를 4가지 단계로 분할하는 지침을 제공한다.

1) 개념화(Inception) 단계

시스템의 전체적인 모습을 정의한다.

2) 구체화(Elaboration) 단계

적용 기술을 평가하고, 어플리케이션 기본 구조를 만들기 위해 일부 중요한 기능을 한정하여 실제로 어플리케이션을 만든다.

3) 구축(Construction) 단계

어플리케이션 기능의 전체를 개발한다. 어플리케이션 기능의 우선 순위가 높은 순으로 단계적으로 개발하는 것을 장려한다.

4) 전이(Transition) 단계

실제 운용을 위해 필요한 작업(종합 테스트, 성능 개선, 운용 교육 등)을 실행한다.

사진 출처(링크)

2-2. 커스터마이징을 전제로 하고 있다.

RUP가 정의하는 작업 항목과 산출물은 의무가 아닌 선택 사항이며, 프로젝트의 설징과 상황에 따라 필요한 것을 선택해서 이용하는 것을 전제로 한다.

개발 프로세스(Development Process)

폭포수형 개발 프로세스(waterfall development process)

1. 폭포수형?

작업의 순환을 회피하고, 물의 흐름처럼 유유하게 진행하는 것을 목표로 하는 방법.

기본적으로 '소프트웨어의 변경에는 많은 비용이 든다.'라는 것과 '소프트웨어보다도 문서를 만드는 비용이 훨씬 적게 든다.'라는 것을 전제로 함

2. 한계

2-1. 요구의 문제

요구 사양을 정하는 사람이 업무 전체를 정확히 이해하고 있다고 할 수 없으며, 의견이 다른 경우와 편견이 원인이 되어 모순된 사양을 결정하는 경우가 있다. 

더욱이 외부 요인에 의해 시스템의 전제 조건과 목표가 바뀌는 경우도 있어, 처음 단계에서 아무리 심사 숙고해서 정의했다 하더라도 나중에 여기저기서 변경 요소가 발생하는 것이 일반적이다.

2-2. 기술의 문제

신기술과 신제품의 적절한 이용 방법과 성능 면의 문제는 실제 프로그램을 작성해서 움직이는 단계에서 알되게는데 폭포수형 개발 프로세스의 경우 이러한 문제는 늦게 인식하게 된다. 그리고 그 단계에서 커다란 문제가 발생하면 프로젝트의 계획 전체가 막대한 영향을 받게 된다.

사진 출처 (링크)