제품 디렉토리 구조는 버전 지정이 가능한 모든 제품 관련 중간 산출물에 대해 논리적으로 중첩된 플레이스홀더의 역할을 합니다. 중간 산출물은 다음과 같은 개발 프로세스 라이프사이클의 결과로 생성되며 전체 시스템의 각
구성 구현 요소 개발을 위해 생성됩니다.
다음 그림은 시스템 X는 "N"개의 서브시스템으로 구성되며, 각 서브시스템은 "N"개의 컴포넌트로 구성됨을 보여 줍니다. 제품 디렉토리 구조는 전체 시스템의 각 파트를 개발하는 데 필요한 다양한 중간 산출물에 공통
플레이스홀더를 제공합니다.
숙달된 소프트웨어 설계자는 처음부터 시스템 컴포지션에 대해 잘 알고 있지만, 후보 아키텍처를 정의하고 정제하기 위한 주요 개발 컴포넌트에 대한 보기가 분석 및 디자인 관련 활동의 결과로 새롭게 부상하고 있습니다.
다음 표는 프로젝트 개발의 초기 단계에서 "제품 디렉토리 구조"로 사용할 수 있는 제품 시스템 디렉토리 구조 패턴을 제공합니다. 하지만 컴포지트 서브시스템과 아키텍처 계층에 대한 정확한 세부사항은 앞으로 결정될
예정입니다.
분석 및 디자인 활동이 진행 중이고 전체 시스템에 필요한 서브시스템의 수와 특성에 대해 보다 잘 이해하게 되었으면(타스크: 서브시스템
디자인), 각 서브시스템을 포함하도록 제품 디렉토리 구조를 확장해야 합니다.
시스템 제품 디렉토리 구조의 정보는 프로젝트 전체의 모든 서브시스템에 표시되어야 합니다. 따라서 제품 관리와는 별도로 요구사항 및 테스트 정보 표준과 가이드라인이 시스템 제품 디렉토리 구조에 속하게 됩니다. 이
인스턴스에서는 도구가 시스템 제품 디렉토리 구조에 포함되지만 도구는 여러 시스템이 동일한 도구 세트를 사용할 수 있는 상위 레벨의 디렉토리에 있을 수 있습니다.
제품 서브시스템 디렉토리 구조의 정보는 특정 서브시스템의 개발과 직접적인 관련이 있습니다. 서브시스템 제품 디렉토리 구조의 '인스턴스화' 수는 분석 및 디자인 활동의 결과에 따라 결정되는 서브시스템 수와 명확하게
관련이 있습니다. 예를 들어, 시스템-y에는 세 개의 서브시스템(서브시스템-A, 서브시스템-B, 서브시스템-N)이 있을 수 있는데, 각 서브시스템은 디자인 및 궁극적으로 구현에 필요한 정보를 포함합니다.
서브시스템 제품 디렉토리
구조의 일반 작업분류는 다음과 같습니다.
컴포넌트 수는 서브시스템 디자인 결정의 결과입니다. 각 컴포넌트를 개발하기 위해서는 다음 디렉토리 구조를 인스턴스화해야 합니다.
규정된 방식으로 디렉토리를 중첩할 때 얻게 되는 한 가지 이점은 컴포넌트 개발에 대한 모든 관련 컨텍스트 정보를 동일한 레벨이나 상위 레벨에서 사용할 수 있다는 것입니다.
이 유형의 논리적 중첩을 사용하면 개발 및 통합 작업공간이 설정되어 전체 개발
팀 구조에 링크될 수 있습니다.
중간 산출물에 대한 이름 지정 규칙은 타스크: CM 정책 설정, 단계: 구성 식별 사례 정의에 설명되어 있습니다.
|