워크플로우 세부사항:
|
이 워크플로우 세부사항의 목적은 시스템의 설계를 정제하는 것입니다. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
주제 |
|
이 워크플로우 세부사항은 다음과 같은 목표를 가집니다.
이 섹션에서는 이 워크플로우 세부사항과 관련된 추가 정보의 링크를 제공합니다.
구현화 단계에서 시작합니다. 구축 및 전이 단계에서 반복됩니다.
필수사항.
일반적으로, 한 사람 또는 소규모 팀이 설계 요소 세트(보통 다른 설계 요소를 포함하는 하나 이상의 패키지 또는 서브시스템)에 대한 책임을 맡습니다. 이 사람/팀은 모든 조작 정의를 및 다른 설계 요소에 대한 관계의 정의를 완료하여 패키지 또는 서브시스템에 포함된 요소에 대한 설계 세부사항을 덧붙이는 책임을 맡습니다. 활동: 클래스 설계는 클래스 설계 요소의 설계를 정제하는 데 중점을 두는 반면, 활동: 서브시스템 설계는 서브시스템 자체가 포함된 설계 요소(포함된 클래스 또는 서브시스템)에 맵핑된 작동의 할당에 중점을 둡니다.
또한 수동 클래스 설계를 책임지는 클래스에서 사용되는 알고리즘 또는 기술에 대해서 만이 아니라 구현 언어에 대한 지식을 가지고 있어야 합니다. 서브시스템을 책임지는 개인 또는 팀은 보다 다방면에 지식을 가지고 있어야 하며 설계 요소 사이에 기능을 적절히 분배하는 것에 관련된 결정을 내릴 수 있고 다양한 설계 대안에 관련된 고유 상충을 이해할 수 있어야 합니다.
각 설계 요소가 정제되는 동안, 전개되는 설계 요소 책임을 반영하도록 유스 케이스 구현이 정제되어야 합니다. 일반적으로, 한 사람 또는 소규모 팀이 하나 이상의 관련된 유스 케이스 구현에 대한 책임을 맡습니다. 설계 요소가 추가되고 정제됨에 따라, 유스 케이스 구현이 오래되거나 설계 모델 개선시 유스 케이스 구현의 간소화를 고려하므로 유스 케이스 구현을 다시 고려하고 전개해야 합니다. 유스 케이스 구현을 책임지는 개인 또는 팀은 유스 케이스에 필요한 작동과 설계 요소 사이에 이 작동을 할당하는 여러 방법의 상충에 대해 광범위하게 이해하고 있어야 합니다. 또한 유스 케이스를 수행하는 요소를 선택하는 책임을 지므로 설계 요소 자체의 외부(공용) 작동에 대해 깊히 이해하고 있어야 합니다.
일반적으로, 여기에서 작업은 개인적으로 수행되거나 팀 사이에 변경사항을 전달할 필요가 있는 곳에서 비공식적인 그룹 내부 상호 작용을 통해 소규모 팀에서 수행됩니다. 설계 요소가 정제될수록, 많은 설계 요소 및 유스 케이스 구현에 대한 동시 변경이 필요하므로 종종 책임이 설계 요소와 유스 케이스 구현 사이에서 이동됩니다. 책임의 상호 작용으로 인해 설계 팀 구성원이 완전히 격리되어 작업하는 것은 거의 불가능합니다. 설계 노력이 시스템에 필요한 작동(유스 케이스 구현에 표시됨)에 집중되도록 하기 위해 전형적인 상호 작용 패턴이 나타납니다.
프로세스 자체가 반복적이므로, '반복에 필요한 모든 작동'에 대한 기준은 라이프사이클에서의 위치에 따라 다릅니다.
구현 및 테스트 활동이 시작되기 전에는 반복에 대한 설계가 완료될 필요가 없음에 주의하십시오. 부분적으로 설계가 전개될 때 설계를 구현하고 테스트하는 것이 설계를 검증하고 정제하는(반복 내에서도) 효율적인 수단이 될 수 있습니다.
Rational Unified Process
|