이 워크플로우 세부사항의 목적은 시스템의 설계를 정제하는 것입니다.

주제


      분석 클래스
분석 클래스
  분석 클래스
분석 클래스
  설계 클래스
설계 클래스
  인터페이스
인터페이스
설계 서브시스템
설계 서브시스템
  유스 케이스
유스 케이스
 
               
 
설계자
설계자
 

 
EJB 설계
EJB 설계

 
클래스 설계
클래스 설계

 
테스트 용이성 요소 설계
테스트 용이성
요소 설계

 
서브시스템 설계
서브시스템 설계

 
유스 케이스 설계
유스 케이스 설계

 
               
      설계 모델
설계 모델
EJB
EJB
  설계 모델
설계 모델
설계 클래스
설계 클래스
  설계 패키지
설계 패키지
테스트 용이성 클래스
테스트 용이성
클래스
  설계 서브시스템
설계 서브시스템
설계 클래스
설계 클래스
  설계 모델
설계 모델
유스 케이스 구현
유스 케이스 구현
 
                  인터페이스
인터페이스
설계 모델
설계 모델
     

      탐색 맵
탐색 맵
설계 모델
설계 모델
 
       
 
기술 검토자
기술 검토자
 

 
설계 검토
설계 검토

 
       
      검토 레코드
검토 레코드
 


설명 To top of page

이 워크플로우 세부사항은 다음과 같은 목표를 가집니다.

  • 설계 요소가 필요한 작동을 구현하는 방법에 대한 '세부사항'을 산출하여 정의 세분화
  • 식별된 새 설계 요소를 기반으로 유스 케이스 구현 정제 및 갱신(예: 유스 케이스 구현이 갱신되도록 함)
  • 설계가 전개될 때 설계 검토

관련 정보 To top of page

이 섹션에서는 이 워크플로우 세부사항과 관련된 추가 정보의 링크를 제공합니다.

시기 To top of page

구현화 단계에서 시작합니다. 구축 및 전이 단계에서 반복됩니다.

선택성 To top of page

필수사항.

인력 지정 방법 페이지 맨 위

일반적으로, 한 사람 또는 소규모 팀이 설계 요소 세트(보통 다른 설계 요소를 포함하는 하나 이상의 패키지 또는 서브시스템)에 대한 책임을 맡습니다. 이 사람/팀은 모든 조작 정의를 및 다른 설계 요소에 대한 관계의 정의를 완료하여 패키지 또는 서브시스템에 포함된 요소에 대한 설계 세부사항을 덧붙이는 책임을 맡습니다. 활동: 클래스 설계는 클래스 설계 요소의 설계를 정제하는 데 중점을 두는 반면, 활동: 서브시스템 설계는 서브시스템 자체가 포함된 설계 요소(포함된 클래스 또는 서브시스템)에 맵핑된 작동의 할당에 중점을 둡니다.

또한 수동 클래스 설계를 책임지는 클래스에서 사용되는 알고리즘 또는 기술에 대해서 만이 아니라 구현 언어에 대한 지식을 가지고 있어야 합니다. 서브시스템을 책임지는 개인 또는 팀은 보다 다방면에 지식을 가지고 있어야 하며 설계 요소 사이에 기능을 적절히 분배하는 것에 관련된 결정을 내릴 수 있고 다양한 설계 대안에 관련된 고유 상충을 이해할 수 있어야 합니다.

각 설계 요소가 정제되는 동안, 전개되는 설계 요소 책임을 반영하도록 유스 케이스 구현이 정제되어야 합니다. 일반적으로, 한 사람 또는 소규모 팀이 하나 이상의 관련된 유스 케이스 구현에 대한 책임을 맡습니다. 설계 요소가 추가되고 정제됨에 따라, 유스 케이스 구현이 오래되거나 설계 모델 개선시 유스 케이스 구현의 간소화를 고려하므로 유스 케이스 구현을 다시 고려하고 전개해야 합니다. 유스 케이스 구현을 책임지는 개인 또는 팀은 유스 케이스에 필요한 작동과 설계 요소 사이에 이 작동을 할당하는 여러 방법의 상충에 대해 광범위하게 이해하고 있어야 합니다. 또한 유스 케이스를 수행하는 요소를 선택하는 책임을 지므로 설계 요소 자체의 외부(공용) 작동에 대해 깊히 이해하고 있어야 합니다.

작업 가이드라인 페이지 맨 위

일반적으로, 여기에서 작업은 개인적으로 수행되거나 팀 사이에 변경사항을 전달할 필요가 있는 곳에서 비공식적인 그룹 내부 상호 작용을 통해 소규모 팀에서 수행됩니다. 설계 요소가 정제될수록, 많은 설계 요소 및 유스 케이스 구현에 대한 동시 변경이 필요하므로 종종 책임이 설계 요소와 유스 케이스 구현 사이에서 이동됩니다. 책임의 상호 작용으로 인해 설계 팀 구성원이 완전히 격리되어 작업하는 것은 거의 불가능합니다. 설계 노력이 시스템에 필요한 작동(유스 케이스 구현에 표시됨)에 집중되도록 하기 위해 전형적인 상호 작용 패턴이 나타납니다.

  • 설계 요소는 담당자 또는 담당 팀에 의해 정제됩니다.
  • 소규모 그룹(대략 2-5 구성원)이 기존 유스 케이스 구현 세트에 대한 새로운 설계 요소의 영향을 해결하기 위해 비공식적으로 모입니다.
  • 논의 중에, 유스 케이스 구현 및 관련 설계 요소에 대한 변경사항이 식별됩니다.
  • 반복에 필요한 모든 작동이 설계될 때까지 주기가 반복됩니다.

프로세스 자체가 반복적이므로, '반복에 필요한 모든 작동'에 대한 기준은 라이프사이클에서의 위치에 따라 다릅니다.

  • 구현화 단계에서 기타 모든 '세부사항'이 효율적으로 무시되고(또는 스텁으로 될 가능성이 더 높음) 초점은 구조적으로 중요한 작동에 있습니다.
  • 구축 단계에서는, 구축 단계 마지막에 해결되지 않은 설계 문제가 없도록 초점이 설계의 완전성 및 일관성으로 이동합니다.

구현 및 테스트 활동이 시작되기 전에는 반복에 대한 설계가 완료될 필요가 없음에 주의하십시오. 부분적으로 설계가 전개될 때 설계를 구현하고 테스트하는 것이 설계를 검증하고 정제하는(반복 내에서도) 효율적인 수단이 될 수 있습니다.


Rational Unified Process   2003.06.15