프로젝트가 확장되고 복잡도가 커질 경우 "프로젝트를 확장"할
수 있는 몇 가지 옵션이 있습니다. 새 요소를 단일 IBM® Rational® Rhapsody®
프로젝트에 계속 추가하는 것이 가장 적합한 경우도 있고,
새 프로젝트를 작성하는 것이 더 효율적일 때도 있습니다.
한 가지 솔루션으로 모든 상황을 해결할 수는 없습니다.
프로젝트 성장 및 확장을 계획하는 경우 다음과 같은 문제를 고려하십시오.
- 단일 프로젝트의 경우 특성 또는 특성 세트를 손쉽게 모든
모델 요소에 적용할 수 있습니다. 복수 프로젝트의 경우 프로젝트별로
프로세스를 수행해야 합니다.
- 프로젝트와 연관된 구성 관리 아카이브는 프로젝트 레벨
특성에 저장됩니다. 따라서 프로젝트가 여러 개의 아카이브에 저장될 경우
아카이브별로 별도의 프로젝트를 작성해야 합니다.
- 모든 팀 구성원이 자신과 직접적인 관련이 없는 파트를
포함한 모든 디자인 파트를 알고 있도록 하려면 단일 프로젝트를 사용하는 것이
좋습니다.
- 각 구성원이 자신의 작업과 관련된 요소만 볼 수 있도록
여러 팀 구성원의 작업을 구분하려면 여러 개의 프로젝트(팀 구성원당 하나씩)를
작성하십시오.
- 시스템의 서로 다른 컴포넌트에서 작업 중인 분산된 팀의 경우
전체 프로젝트를 몇 개의 작은 프로젝트로 분할하는 것이 도움이 될 수 있습니다.
- 프로젝트의 복잡도를 줄이려는 경우 전체 프로젝트의 각
기능을 정의하고 캡슐화하는 여러 개의 프로젝트를 작성할 수 있습니다. 이렇게
하면 모든 팀 구성원이 전체 프로젝트의 모든 요소에 액세스할 수 있습니다.
- 2진 재사용 패턴에서 프로젝트가 사용되고 있는 경우,
프로젝트를 몇 개의 프로젝트로 분할하십시오. 모델 재사용 패턴을 사용할 경우에는 분할하지 마십시오.
- 최종 제품(예: 하나 이상의 실행 파일에서 사용하는
라이브러리 세트)을 작성하기 위해 인터리브된 여러 2진 컴포넌트에
프로젝트가 맵핑된 경우, 이러한 컴포넌트를 단일 프로젝트에 배치하면
팀 구성원이 컴포넌트 내부를 디지안하고 컴포넌트 다이어그램을 사용하여
컴포넌트 간 관계를 디자인하는 데 도움이 됩니다(make 파일이 컴포넌트 간
관계를 고려함).
프로젝트를 여러 개의 프로젝트로
분할하도록 결정하는 데 영향을 주지 않는 문제는 다음과 같습니다.
- 프로젝트를 Rational Rhapsody로
로드하는 데 걸리는 시간. 부분 로드 기능을 사용하면 전체 프로젝트를
로드하지 않고 현재 태스크에 필요한 단위만 로드할 수 있습니다.
- 운영 체제. 몇 개의 대상 운영 체제에 한 개의
디자인을 재생성해야 하는 경우 여러 개의 프로젝트를 작성할 필요가 없습니다.
전체 프로젝트를 구성하는 방법을 결정한 후
이를 되돌릴 수 있습니다. 즉, 한 프로젝트를 손쉽게 두 개의 프로젝트로
분할할 수 있으며 두 개의 프로젝트를 한 프로젝트에 병합할 수 있습니다.