개념: 제품 디렉토리 구조
제품 디렉토리 구조에는 제품 관련 중간 산출물을 저장하는 데 사용되는 폴더와 파일의 계층 구조 디렉토리와 서브디렉토리가 포함되어 있습니다.
관계
관련 요소
기본 설명

제품 디렉토리 구조는 버전 지정이 가능한 모든 제품 관련 중간 산출물에 대해 논리적으로 중첩된 플레이스홀더의 역할을 합니다. 중간 산출물은 다음과 같은 개발 프로세스 라이프사이클의 결과로 생성되며 전체 시스템의 각 구성 구현 요소 개발을 위해 생성됩니다.

다음 그림은 시스템 X는 "N"개의 서브시스템으로 구성되며, 각 서브시스템은 "N"개의 컴포넌트로 구성됨을 보여 줍니다. 제품 디렉토리 구조는 전체 시스템의 각 파트를 개발하는 데 필요한 다양한 중간 산출물에 공통 플레이스홀더를 제공합니다.

컴포넌트 레벨 디렉토리 구조 서브시스템 레벨 제품 디렉토리 구조 시스템 제품 디렉토리 구조 함께 표시된 텍스트에서 설명되는 다이어그램

시스템 제품 디렉토리 구조

숙달된 소프트웨어 설계자는 처음부터 시스템 컴포지션에 대해 잘 알고 있지만, 후보 아키텍처를 정의하고 정제하기 위한 주요 개발 컴포넌트에 대한 보기가 분석 및 디자인 관련 활동의 결과로 새롭게 부상하고 있습니다.

다음 표는 프로젝트 개발의 초기 단계에서 "제품 디렉토리 구조"로 사용할 수 있는 제품 시스템 디렉토리 구조 패턴을 제공합니다. 하지만 컴포지트 서브시스템과 아키텍처 계층에 대한 정확한 세부사항은 앞으로 결정될 예정입니다.

시스템 레벨 제품 디렉토리 구조

시스템 요구사항

모델

유스 케이스 모델 유스 케이스 패키지
데이터베이스 요구사항 속성
문서 비전
용어집
이해 당사자(stakeholder) 요청
보충 스펙
소프트웨어 요구사항
스토리보드

보고서

보고서: 유스 케이스 모델 조사
보고서: 유스 케이스 명세
시스템 디자인 및 구현 모델 분석 모델 유스 케이스 실현(realization)
디자인 모델 디자인 서브시스템
인터페이스
디자인 패키지
데이터 모델
워크로드 분석 문서
사용자 인터페이스 프로토타입
문서 소프트웨어 아키텍처 문서
보고서: 디자인 모델 조사
탐색 맵
서브시스템-1 서브시스템 디렉토리 구조
서브시스템-N 서브시스템 디렉토리 구조
시스템 통합 계획 통합 빌드 계획
라이브러리  
시스템 테스트 테스트 계획 테스트 스위트
테스트 케이스 테스트 스크립트
테스트 데이터  
테스트 결과  
시스템 배치 배치 계획  
문서 릴리스 정보
매뉴얼 사용자 지원 자료
훈련 자료
설치 아티팩트  
시스템 관리 계획 소프트웨어 개발 계획
반복 계획 요구사항 관리 계획
위험성 목록 위험성 관리 계획
개발 사례 하부 구조 계획
제품 적합성 계획 형상 관리 계획
문서화 계획 QA 계획
문제점 해결 계획 하청업체 관리 계획
프로세스 향상 계획 측정 계획
평가 반복 평가
개발 조직 평가
상태 평가
도구 개발 환경 도구 편집기
컴파일러
형상 관리 도구 Rational ClearCase
요구사항 관리 도구 Rational RequisitePro
비주얼 모델링 도구 Rational Rose
테스트 도구 Rational Test Factory
결함 추적 Rational ClearQuest
표준 및 가이드라인 요구사항 요구사항 속성
프로젝트 가이드라인
디자인 프로젝트 가이드라인
구현 프로젝트 가이드라인
문서 매뉴얼 스타일 안내서

분석 및 디자인 활동이 진행 중이고 전체 시스템에 필요한 서브시스템의 수와 특성에 대해 보다 잘 이해하게 되었으면(타스크: 서브시스템 디자인), 각 서브시스템을 포함하도록 제품 디렉토리 구조를 확장해야 합니다.

시스템 제품 디렉토리 구조의 정보는 프로젝트 전체의 모든 서브시스템에 표시되어야 합니다. 따라서 제품 관리와는 별도로 요구사항 및 테스트 정보 표준과 가이드라인이 시스템 제품 디렉토리 구조에 속하게 됩니다. 이 인스턴스에서는 도구가 시스템 제품 디렉토리 구조에 포함되지만 도구는 여러 시스템이 동일한 도구 세트를 사용할 수 있는 상위 레벨의 디렉토리에 있을 수 있습니다.

서브시스템 디렉토리 구조

제품 서브시스템 디렉토리 구조의 정보는 특정 서브시스템의 개발과 직접적인 관련이 있습니다. 서브시스템 제품 디렉토리 구조의 '인스턴스화' 수는 분석 및 디자인 활동의 결과에 따라 결정되는 서브시스템 수와 명확하게 관련이 있습니다. 예를 들어, 시스템-y에는 세 개의 서브시스템(서브시스템-A, 서브시스템-B, 서브시스템-N)이 있을 수 있는데, 각 서브시스템은 디자인 및 궁극적으로 구현에 필요한 정보를 포함합니다.

서브시스템 제품 디렉토리 구조의 일반 작업분류는 다음과 같습니다.

서브시스템 레벨 제품 디렉토리 구조

서브시스템-N 요구사항

모델 유스 케이스 모델 유스 케이스 패키지
스토리보드
유스 케이스(텍스트)
사용자 인터페이스 프로토타입
데이터베이스 요구사항 속성
문서 비전
용어집
이해 당사자(stakeholder) 요청
보충 스펙
소프트웨어 요구사항
스토리보드

보고서

보고서: 유스 케이스 모델 조사
보고서: 유스 케이스 명세
서브시스템-N 디자인 및 구현 모델 분석 모델 유스 케이스 실현(realization)
디자인 모델 디자인 패키지
인터페이스 패키지
테스트 패키지
구현 모델
데이터 모델
워크로드 모델
문서 소프트웨어 아키텍처 문서
보고서: 디자인 모델 조사
탐색 맵

보고서

보고서: 유스 케이스 실현(realization)

컴포넌트-1

컴포넌트-1 디렉토리

컴포넌트-N

컴포넌트-N 디렉토리
서브시스템-N 통합 계획 통합 빌드 계획
라이브러리  
서브시스템-N 테스트 테스트 계획 테스트 스위트
테스트 케이스 테스트 스크립트
테스트 결과  
테스트 데이터  

컴포넌트 디렉토리 구조

컴포넌트 수는 서브시스템 디자인 결정의 결과입니다. 각 컴포넌트를 개발하기 위해서는 다음 디렉토리 구조를 인스턴스화해야 합니다.

규정된 방식으로 디렉토리를 중첩할 때 얻게 되는 한 가지 이점은 컴포넌트 개발에 대한 모든 관련 컨텍스트 정보를 동일한 레벨이나 상위 레벨에서 사용할 수 있다는 것입니다.

이 유형의 논리적 중첩을 사용하면 개발 및 통합 작업공간이 설정되어 전체 개발 팀 구조에 링크될 수 있습니다.

중간 산출물에 대한 이름 지정 규칙은 타스크: CM 정책 설정, 단계: 구성 식별 사례 정의에 설명되어 있습니다.