개념:
|
라이프사이클에 따른 활동: |
추가 주제: |
컴포넌트 기반 개발은 다음과 같은 점에서 일반 어플리케이션 개발의 변형입니다.
- 어플리케이션은 잠재적으로 다른 팀에서 비교적 서로 독립적으로 개발되고 전개되는 분리된 실행 가능 컴포넌트에서 어셈블됩니다.
- 어플리케이션은 어플리케이션을 구성하는 일부 컴포넌트만을 업그레이드하여 더 작은 증가량으로 업그레이드될 수 있습니다.
- 컴포넌트는 재사용 기회를 생성하지만 내부 프로젝트 종속성도 작성하여 어플리케이션 간에 공유될 수 있습니다.
- 정확히 말하면 컴포넌트 기반인 것에 관계가 없지만 컴포넌트 기반 어플리케이션은 분배하기 쉽습니다.
이 페이지 전체에서 "컴포넌트"는 독립적으로 개발되고 전개 가능한 컴포넌트를 나타내는 데 사용됩니다. 그러나 RUP 어디에서나 개념: 컴포넌트에서 설명된 보다 일반적인 의미로 "컴포넌트"를 사용하며 필요한 경우 한정됩니다.
아래에서는 컴포넌트 기반 개발 도전을 처리하기 위한 RUP 적응에 대해 설명됩니다.
초기화 단계의 기본 워크플로우는 다음 확장 또는 변형과 더불어 적용됩니다.
활동: 비즈니스 케이스 개발의 초점은 컴포넌트 사용으로 개발의 비용 구조가 변경되는 것을 참작하도록 조정됩니다. 세부적으로, 컴포넌트 개발 비용이 줄어들지만 컴포넌트를 식별하고 선택된 컴포넌트가 요구사항을 충족하는지 확인하는 데 많은 노력이 필요합니다.
컴포넌트 방법을 택하면 일정한 위험의 속성이 변경되고 새 위험이 나타납니다. 특히,
활동: 단계 및 반복 계획에서 구축 단계 계획은 잠재적으로 다르지만 병렬적인 두 개의 트랙으로 분리하여 프로젝트를 표시합니다. 하나는 어플리케이션 특정 및 도메인 특정 컴포넌트를 개발하는 트랙이고(구조의 상위 계층에 조직됨, 개념: 계층화 참조) 다른 하나는 하위 계층에 조직되는 비 어플리케이션 및 비 도메인 특정 컴포넌트를 개발하는 트랙입니다. 일부 경우에 재사용 컴포넌트는 독립적으로 관리되는 개발 팀에서 개발됩니다. 병렬 트랙을 도입하는 결정은 크게 재사용 컴포넌트를 개발된 어플리케이션에 독립적인 자산으로 관리하기 위한 요구로 도입된 인력 및 자원 문제입니다.
시스템의 요구사항을 정제할 때 선택된 컴포넌트 프레임워크에서 부과된 제한조건이 캡처되어야 합니다. 컴포넌트 프레임워크는 소프트웨어 아키텍트 및 설계자에게 제공되는 자유도를 제한하여 개발 생산성을 일부 향상시킵니다. 활동: 소프트웨어 요구 세부사항 정의는 이러한 제한조건에 중점을 두어야 합니다.
프로젝트에 의도된 전체 테스트를 식별하는 "마스터 테스트 계획"이라는 테스트 계획이 작성되어야 합니다.
프로젝트에 대한 가이드라인을 수집하고 준비할 때 특정 컴포넌트 프레임워크 및 이에서 부과된 제한조건을 고려하십시오. 가이드라인은 프레임워크를 사용하여 설계하고 코드화하는 방법을 포함해야 합니다. 가이드라인은 컴포넌트 프레임워크 자체 및 컴포넌트 간에 정의된 인터페이스 모두와의 일치를 확인하는 방법에 대한 테스트 가이드를 제공해야 합니다.
구현화 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변화와 함께 적용됩니다.
활동: 소프트웨어 요구 세부사항 정의는 추가적으로 빌드되거나 구매된 컴포넌트에 부과된 기술적, 비기능적 요구사항 및 제한조건에 중점을 둡니다. 고려해야 할 특정 비기능적 요구사항은 크기, 성능, 메모리 및 디스크 풋프린트 그리고 컴포넌트 선택 및 구축에 영향을 미치는 유사한 제한조건입니다.
활동: 구조적 분석은 초기 계층 스키마와 기본 컴포넌트 및 서비스 세트(분석 및 설계 메커니즘으로 표시되는)를 포함하여 초기 구조를 정의하기 위해 컴포넌트 프레임워크 및 기술적, 비기능적 요구사항을 사용합니다. 활동: 유스 케이스 분석은 구조적으로 중요한 유스 케이스에서 구조적으로 중요한 컴포넌트를 식별하는 데 중점을 둡니다.
활동: 구현 모델 구축은 컴포넌트 프레임워크 구조와 호환 가능한 구현 모델과 개발 팀의 구조 및 책임을 확립합니다.
활동: 설계 메커니즘 식별은 특정 프레임워크 서비스 및 컴포넌트를 고려하기 위해 초기 설계 메커니즘을 정제합니다.
활동: 설계 요소 식별은 구조적으로 중요한 주요 시스템 컴포넌트를 식별합니다. 잠재적으로 재사용 가능한 책임은 재사용성을 높이기 위해 함께 그룹화되어야 하고 어플리케이션 특정 기능은 도메인 특정 기능과 어플리케이션 및 도메인 독립 기능에서 분리되어야 합니다. 설계 목적으로 컴포넌트는 결과물: 서브시스템 설계로 표시될 수 있습니다. 이러한 컴포넌트/서브시스템에 대해 결과물: 인터페이스가 식별되어야 합니다.
활동: 기존 설계 요소 통합은 식별된 컴포넌트가 이전 반복, 프레임워크 자체 또는 외부 소스에서 식별된 기존 컴포넌트와 일관되고 호환 가능한지 확인합니다.
활동: 런타임 구조 설명은 컴포넌트 프레임워크의 기본 프로세스 및 스레드 구조를 설명하고 활동: 분배 설명은 컴포넌트 어플리케이션이 실행될 분산 컴퓨팅 환경을 설명합니다.
활동: 서브시스템 설계는 컴포넌트의 실제 작동을 제공하는 컴포넌트 내의 클래스를 식별하여 컴포넌트의 설계를 더 세부적으로 정제합니다. 구현화 단계의 초기 단계에서는 단일 클래스, 즉 구조적 프로토타입을 목적으로 컴포넌트 작동을 시뮬레이트하기 위한 스텁 역할을 하는 일종의 '서브시스템/컴포넌트 프록시'가 있을 수 있습니다. 이후에 이 클래스의 작동은 서브시스템 내에 포함된 클래스의 모음으로 분배됩니다. 서브시스템 내에 포함된 클래스는 활동: 클래스 설계에서 정제됩니다.
구현화에서는 지속성 전략이 확장 가능한지, 데이터베이스 설계 및 지속성 메커니즘이 시스템의 처리량 요구사항을 지원하는지 확인하는 데 중점을 둡니다. 지속성 클래스는 지속성 메커니즘으로 식별되고 맵핑됩니다. 메커니즘이 확장 가능한지 확인하기 위해 데이터 집약적 유스 케이스가 분석됩니다. 테스트 워크플로우 세부사항과 관련하여 지속성 메커니즘 및 데이터베이스 설계가 평가되고 검증됩니다.
활동: 설계 요소 구현은 구현화 단계에서 구현은 생산 품질 코드를 생성하는 것이 아니라 구조를 검증하는 데 중점을 두기 때문에 여기에서 대부분의 컴포넌트는 많은 '스텁' 코드를 포함합니다.
구현화에서 테스트 활동은 구조를 검증하는 데 중점을 둡니다. 컴포넌트 기반 시스템에서는 다음에 중점을 둡니다.
컴포넌트 프레임워크의 어떤 고유 가정이라도 평가될 필요가 있습니다. 일반적으로 여기에는 가정을 이해하지 않는 경우 메커니즘 설계자가 작성한 숨겨진 가정이 자주 유효하게 어플리케이션 구조를 침해하는 지속성의 확장성 및 처리량, 트랜잭션 관리 메커니즘이 포함됩니다.
구축 작업은 구현 서브시스템을 '책임의 논리적 단위'로 사용하여 여러 "트랙"으로 분할될 수 있습니다. 한 트랙은 어플리케이션 특정 기능에 중점을 두고 하나 이상의 트랙은 일반 재사용 가능 컴포넌트에 집중합니다. 물론, 이것은 병렬 개발 작업에 담당 직원을 지정할 수 있을 만큼 충분한 자원을 가지고 있는지에 따라 달라집니다. 개발 팀을 나누고 병렬로 작업할 수 있는 능력은 전적으로 구조의 안정성에 의존하고 특히 컴포넌트 간 인터페이스의 품질 및 안정성에 의존합니다. 우수한 구현화 단계 노력은 이 분할을 가능하게 합니다.
구축 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변화와 함께 적용됩니다.
첫 번째 구축 단계 계획은 구현화의 끝에 발생하므로 이전에 설명되었습니다. 후속 반복 계획 및 개발 팀을 나누고 병렬로 작업할 수 있는 능력은 지속적으로 구조의 안정성과 컴포넌트 간 인터페이스의 품질 및 안정성에 의존합니다.
구축에서는 잔여 유스 케이스를 분석하고 유스 케이스를 구현하는 적절한 컴포넌트 및 컴포넌트 모음을 식별하는 데 중점을 둡니다. 기존 구조가 확장되고 완료되며 컴포넌트의 '초기 작동'이 완전히 설계되고 구현됩니다.
구축에서는 데이터베이스 설계를 완료하고 모든 지속적 클래스가 데이터베이스 및 지속성 메커니즘 모두에서 지원되는지 확인하는 데 중점을 둡니다. 이 작업은 워크플로우 세부사항: 구조 정제 및 워크플로우 세부사항: 컴포넌트 설계에서 수행되는 작업과 병렬로 반복 수행됩니다. 이상적인 조직은 우수한 데이터베이스 설계가 되도록 지속성 문제에 대한 팀 간의 중재로 통합된 컴포넌트 팀을 가지는 것입니다.
이 단계의 작업은 구현화의 작업과 유사하지만 단계가 진행됨에 따라 잔여 세부사항이 점점 완료됩니다.
단계가 계속됨에 따라 시스템이 점진적으로 빌드됩니다.
성능 테스트가 여전히 중요하지만 기능 테스트에 대해 더욱 집중하게 됩니다. 성능 기대치 준수뿐 아니라 기능의 완성도, 기존 기능의 회귀 테스트기 처리되어야 합니다.
Rational Unified Process
|