프로젝트의 단계 및 이정표
관리 관점에서 RUP의 소프트웨어 라이프사이클은 시간이 경과함에 따라 네 개의 순차적인 단계로 분해되며 각각은 주요 이정표로 종료됩니다. 각 단계는 본질적으로 두 기본 이정표 사이의 기간입니다. 각 단계의 끝에서
평가가 수행되어 단계의 목표가 달성되었는지 판별합니다. 만족스러운 평가 결과를 얻은 경우 프로젝트는 다음 단계로 이동합니다.
계획 단계
모든 단계는 스케줄 및 노력면에서 동일하지 않습니다. 이는 프로젝트에 따라 변동 폭이 크지만, 중형 프로젝트에 대한 일반적인 초기 개발 주기에서는 노력 및 스케줄 사이에 다음과 같은 비중을 두는 것을 고려해야
합니다.
그래픽으로 표시하면 다음과 같습니다.
이 분배 과정은 경우에 따라 일치하지 않을 수 있습니다. 예를 들어, 코드 및 테스트 케이스를 생성하는 도구는 구현/구축(Construction) 단계를 단축시킬 수 있습니다. 또한 전개 주기의 경우, 기본 비전과
아키텍처가 이미 설정되어 있어 도입/인식(Inception) 및 정제(Elaboration) 단계가 현저히 단축됩니다.
계획 전략
이 섹션에서 공통 프로젝트 프로파일에 해당하는 많은 라이프사이클 패턴을 소개합니다.
라이프사이클 패턴 점진적
"점진적 전략은 사용자 요구를 결정하고 시스템 요구사항을 정의한 후 일련의 빌드로 나머지 개발을 수행합니다. 시스템이 완료될 때까지 첫 번째 빌드는 계획된 기능의 일부를 통합하고 다음 빌드는 기능을 더
추가합니다." [DOD94]
다음 반복에는 해당 특성이 있습니다.
-
범위 및 비전을 설정하고 비즈니스 사례를 정의하는 간단한 도입/인식(Inception) 반복
-
요구사항을 정의하고 아키텍처를 구현하는 단일 정제(Elaboration) 반복
-
유스 케이스를 구현하고 아키텍처를 확장하는 여러 구현/구축(Construction) 반복
-
사용자 커뮤니티로 제품을 이주하는 여러 전이(Transition) 반복
이 전략은 다음과 같은 경우에 적절합니다.
-
문제점 도메인을 잘 알고 있습니다.
-
위험성을 잘 이해하고 있습니다.
-
숙련된 프로젝트 팀입니다.
"발전적 전략은 사용자 요구를 완전히 이해할 수 없고 모든 요구사항을 완전히 정의할 수 없으며 연속되는 각 빌드에서 정제되는 것을 인식한다는 점에서 점진적 전략과 다릅니다." [DOD94]
다음 반복에는 해당 특성이 있습니다.
-
범위 및 비전을 설정하고 비즈니스 사례를 정의하는 간단한 도입/인식(Inception) 반복
-
각 반복 시 요구사항이 정제되는 다양한 정제(Elaboration) 반복
-
유스 케이스가 실현되고 아키텍처가 확장되는 동안의 단일 구현/구축(Construction) 반복
-
사용자 커뮤니티로 제품을 이주하는 여러 전이(Transition) 반복
이 전략은 다음과 같은 경우에 적절합니다.
-
새로운 문제점 도메인이거나 잘 알지 못합니다.
-
서투른 팀입니다.
일부 작성자는 고객에게 점진적 기능성을 단계별로 전달합니다[GIL88]. 이는 시장 출시까지의 시간은
부족하지만 특정 중요 기능을 일찍 전달함으로써 중요한 비즈니스 수익을 얻을 수 있는 경우에 필요합니다.
단계 반복 방법에서 전이 단계가 일찍 시작되고 가장 많이 반복됩니다. 이 전략에는 매우 안정된 아키텍처가 필요하며 "새로 도입된" 시스템의 경우 초기 개발 단계에서 달성하기는 어렵습니다.
다음 반복에는 해당 특성이 있습니다.
-
범위 및 비전을 설정하고 비즈니스 사례를 정의하는 간단한 도입/인식(Inception) 반복
-
안정적인 아키텍처를 기반으로 하는 단일 정제(Elaboration) 반복
-
유스 케이스를 구현하고 아키텍처를 확장하는 단일 구현/구축(Construction) 반복
-
사용자 커뮤니티로 제품을 이주하는 여러 전이(Transition) 반복
이 전략은 다음과 같은 경우에 적절합니다.
라이프사이클 패턴: "전체
디자인"
종래의 폭포수형 방법은 구현/구축(Construction) 단계에서 한 번만 반복하는 퇴보 사례로 볼 수 있습니다. [DOD94]에서는 "전체 디자인"이라고
합니다. 실제로는 전이 단계에서 추가 반복을 피하기 어렵습니다.
다음 반복에는 해당 특성이 있습니다.
-
범위 및 비전을 설정하고 비즈니스 사례를 정의하는 간단한 도입/인식(Inception) 반복
-
유스 케이스를 구현하고 아키텍처를 확장하는 매우 긴 단일 구현/구축(Construction) 반복
-
사용자 커뮤니티로 제품을 이주하는 여러 전이(Transition) 반복
이 전략은 다음과 같은 경우에 적절합니다.
-
정의된 기능이 다소 증가하면 매우 안정적인 제품이 추가됩니다.
-
새 기능은 잘 정의되어 쉽게 이해할 수 있습니다.
-
문제점 도메인 및 기존 제품에 대해 숙련된 팀입니다.
라이프사이클 패턴: 혼성 전략
실제로는 하나의 전략을 준수하는 프로젝트는 거의 없습니다. 발전 초기, 점진적 빌드, 다중 전달의 몇몇 경우에 혼성을 사용하는 경우가 자주 있습니다. 단계 반복 모델의 장점 중 하나는 다음과 같이 특정
단계에서의 반복 길이 및 수를 늘리는 것만으로 혼성 접근 방식을 수용할 수 있다는 것입니다.
-
많은 탐색을 수행하는 복잡하거나 익숙하지 않은 문제점 도메인의 경우, 정제(Elaboration) 단계의 반복 횟수 및 해당 길이를 늘리십시오.
-
디자인을 코드로 변환하기가 어려운 모든 복잡한 개발 문제점의 경우, 구현/구축(Construction) 단계의 반복 횟수 및 해당 길이를 늘리십시오.
-
일련의 점진적 릴리스에서 소프트웨어를 전달하려면 전이 단계의 반복 횟수 및 해당 길이를 늘리십시오.
임의의 주기에서 다음 주기로 이동
네 단계를 한번 패스하는 것을 개발 주기라고 하며 네 단계의 각 패스에서 소프트웨어 세대가 생산됩니다. 제품이 "파기"되지 않는 이상 제품은 도입/인식(Inception),
정제(Elaboration), 구현/구축(Construction) 및 전이(Transition) 단계를 동일한 순서로 반복하여 다음 세대로 발전하지만, 이 때는 다양한 단계에서 다른 문제에 중점을 두게 됩니다.
이러한 후속 주기를 발전 주기라고 합니다. 제품이 여러 주기를 거치면서 새로운 세대가 생산됩니다.
발전 주기는 사용자가 제안한 개선사항, 사용자 컨텍스트의 변경사항, 기존 기술에서의 변경사항, 경쟁에 대한 반응 등에 의해 트리거될 수 있습니다. 기본 제품 정의 및 아키텍처는 이전 발전 주기에 의해 결정되므로
발전 주기는 일반적으로 훨씬 간단한 도입/인식(Inception) 및 정제(Elaboration) 단계를 갖습니다. 이 규칙에 대한 예외는 중요한 제품 또는 아키텍처 재정의가 발생하는 발전 주기입니다.
|