개념: 컴포넌트 솔루션 개발

주제
라이프사이클에 따른 활동:
  1. 소개
  2. 초기화 단계 활동
  3. 구현화 단계 활동
  4. 구축 단계 활동
  5. 전이 단계 활동
추가 주제:

소개 페이지 맨 위

컴포넌트 기반 개발은 다음과 같은 점에서 일반 어플리케이션 개발의 변형입니다.

  • 어플리케이션은 잠재적으로 다른 팀에서 비교적 서로 독립적으로 개발되고 전개되는 분리된 실행 가능 컴포넌트에서 어셈블됩니다.
  • 어플리케이션은 어플리케이션을 구성하는 일부 컴포넌트만을 업그레이드하여 더 작은 증가량으로 업그레이드될 수 있습니다.
  • 컴포넌트는 재사용 기회를 생성하지만 내부 프로젝트 종속성도 작성하여 어플리케이션 간에 공유될 수 있습니다.
  • 정확히 말하면 컴포넌트 기반인 것에 관계가 없지만 컴포넌트 기반 어플리케이션은 분배하기 쉽습니다.

이 페이지 전체에서 "컴포넌트"는 독립적으로 개발되고 전개 가능한 컴포넌트를 나타내는 데 사용됩니다. 그러나 RUP 어디에서나 개념: 컴포넌트에서 설명된 보다 일반적인 의미로 "컴포넌트"를 사용하며 필요한 경우 한정됩니다.

아래에서는 컴포넌트 기반 개발 도전을 처리하기 위한 RUP 적응에 대해 설명됩니다.

초기화 단계 활동 페이지 맨 위

초기화 단계의 기본 워크플로우는 다음 확장 또는 변형과 더불어 적용됩니다.

프로젝트 관리

  • ../process/workflow/manageme/wfs_eval.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 프로젝트 영역 및 위험 평가
  • 컴포넌트 방법을 택하면 일정한 위험의 속성이 변경되고 새 위험이 나타납니다. 특히,

    • 결정적인 요소를 프로젝트 팀의 직접 제어하에 도입하지 않으므로 외부 소스의 컴포넌트가 위험을 증가시킬 수 있음
    • 외부 소스의 컴포넌트가 자원 위험을 줄여 개발 시간을 줄일 수 있음
    • 자체적인 구조적 제한사항을 부과하는 경우 외부 소스의 컴포넌트가 시스템의 구조를 변형시킬 수 있음
  • ../process/workflow/manageme/wfs_sdp.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 프로젝트 계획
  • 활동: 단계 및 반복 계획에서 구축 단계 계획은 잠재적으로 다르지만 병렬적인 두 개의 트랙으로 분리하여 프로젝트를 표시합니다. 하나는 어플리케이션 특정 및 도메인 특정 컴포넌트를 개발하는 트랙이고(구조의 상위 계층에 조직됨, 개념: 계층화 참조) 다른 하나는 하위 계층에 조직되는 비 어플리케이션 및 비 도메인 특정 컴포넌트를 개발하는 트랙입니다. 일부 경우에 재사용 컴포넌트는 독립적으로 관리되는 개발 팀에서 개발됩니다. 병렬 트랙을 도입하는 결정은 크게 재사용 컴포넌트를 개발된 어플리케이션에 독립적인 자산으로 관리하기 위한 요구로 도입된 인력 및 자원 문제입니다.

요구사항

테스트

환경

  • ../process/workflow/environm/wfs_env1.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 프로젝트에 대한 환경 준비
  • 프로젝트에 대한 가이드라인을 수집하고 준비할 때 특정 컴포넌트 프레임워크 및 이에서 부과된 제한조건을 고려하십시오. 가이드라인은 프레임워크를 사용하여 설계하고 코드화하는 방법을 포함해야 합니다. 가이드라인은 컴포넌트 프레임워크 자체 및 컴포넌트 간에 정의된 인터페이스 모두와의 일치를 확인하는 방법에 대한 테스트 가이드를 제공해야 합니다.

구현화 단계 활동 페이지 맨 위

구현화 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변화와 함께 적용됩니다.

요구사항

분석 및 설계

  • 워크플로우 세부사항: 컴포넌트 설계
  • 활동: 서브시스템 설계는 컴포넌트의 실제 작동을 제공하는 컴포넌트 내의 클래스를 식별하여 컴포넌트의 설계를 더 세부적으로 정제합니다. 구현화 단계의 초기 단계에서는 단일 클래스, 즉 구조적 프로토타입을 목적으로 컴포넌트 작동을 시뮬레이트하기 위한 스텁 역할을 하는 일종의 '서브시스템/컴포넌트 프록시'가 있을 수 있습니다. 이후에 이 클래스의 작동은 서브시스템 내에 포함된 클래스의 모음으로 분배됩니다. 서브시스템 내에 포함된 클래스는 활동: 클래스 설계에서 정제됩니다.

  • 워크플로우 세부사항: 데이터베이스 설계
  • 구현화에서는 지속성 전략이 확장 가능한지, 데이터베이스 설계 및 지속성 메커니즘이 시스템의 처리량 요구사항을 지원하는지 확인하는 데 중점을 둡니다. 지속성 클래스는 지속성 메커니즘으로 식별되고 맵핑됩니다. 메커니즘이 확장 가능한지 확인하기 위해 데이터 집약적 유스 케이스가 분석됩니다. 테스트 워크플로우 세부사항과 관련하여 지속성 메커니즘 및 데이터베이스 설계가 평가되고 검증됩니다.

구현

테스트

  • 워크플로우 세부사항: ../process/workflow/test/wfs_dfnevlmsn.htm -- This hyperlink in not present in this generated website평가 임무 정의, ../process/workflow/test/wfs_tstandevl.htm -- This hyperlink in not present in this generated website테스트 및 평가, ../process/workflow/test/wfs_achmsnacp.htm -- This hyperlink in not present in this generated website승인 가능 임무 달성,

    구현화에서 테스트 활동은 구조를 검증하는 데 중점을 둡니다. 컴포넌트 기반 시스템에서는 다음에 중점을 둡니다.

    • 컴포넌트 경계가 적절한지 확인하기 위해 컴포넌트 간의 인터페이스 시험
    • 예상되는 트랜잭션 볼륨이 유지될 수 있는지 확인하기 위해 성능 테스트, 특히 성능 크기 조정 테스트에 크게 중점을 둠

    컴포넌트 프레임워크의 어떤 고유 가정이라도 평가될 필요가 있습니다. 일반적으로 여기에는 가정을 이해하지 않는 경우 메커니즘 설계자가 작성한 숨겨진 가정이 자주 유효하게 어플리케이션 구조를 침해하는 지속성의 확장성 및 처리량, 트랜잭션 관리 메커니즘이 포함됩니다.

프로젝트 관리

  • ../process/workflow/manageme/wfs_plan.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 다음 반복 계획

    구축 작업은 구현 서브시스템을 '책임의 논리적 단위'로 사용하여 여러 "트랙"으로 분할될 수 있습니다. 한 트랙은 어플리케이션 특정 기능에 중점을 두고 하나 이상의 트랙은 일반 재사용 가능 컴포넌트에 집중합니다. 물론, 이것은 병렬 개발 작업에 담당 직원을 지정할 수 있을 만큼 충분한 자원을 가지고 있는지에 따라 달라집니다. 개발 팀을 나누고 병렬로 작업할 수 있는 능력은 전적으로 구조의 안정성에 의존하고 특히 컴포넌트 간 인터페이스의 품질 및 안정성에 의존합니다. 우수한 구현화 단계 노력은 이 분할을 가능하게 합니다.

구축 단계 활동 페이지 맨 위

구축 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변화와 함께 적용됩니다.

프로젝트 관리

  • ../process/workflow/manageme/wfs_plan.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 다음 반복 계획

    첫 번째 구축 단계 계획은 구현화의 끝에 발생하므로 이전에 설명되었습니다. 후속 반복 계획 및 개발 팀을 나누고 병렬로 작업할 수 있는 능력은 지속적으로 구조의 안정성과 컴포넌트 간 인터페이스의 품질 및 안정성에 의존합니다.

설계 및 분석

구현

테스트

    성능 테스트가 여전히 중요하지만 기능 테스트에 대해 더욱 집중하게 됩니다. 성능 기대치 준수뿐 아니라 기능의 완성도, 기존 기능의 회귀 테스트기 처리되어야 합니다.

전이 단계 활동 페이지 맨 위

  • 웹 환경에서의 제품 릴리즈는 점진적이고 지속적이며, 전통적인 매체 분배에는 덜 집중하기 쉽습니다. 릴리즈 계획은 적절히 조정되어야 합니다.
  • 제품 지원이 점점 이 단계의 초점이 됩니다.
  • 데이터 변환 활동이 수행됩니다.

Rational Unified Process   2003.06.15