개념: 컴포넌트 솔루션 개발
컴포넌트 기반 개발은 일반 응용프로그램 개발의 변형입니다. 이 가이드라인에서, "컴포넌트"는 독립적으로 개발 및 배치 가능한 컴포넌트를 의미합니다.
기본 설명
라이프사이클 사이의 활동:
  1. 소개
  2. 도입/인식(Inception) 단계 활동
  3. 정제(Elaboration) 단계 활동
  4. 구현/구축(Construction) 단계 활동
  5. 전이(Transition) 단계 활동
추가 주제:

소개

컴포넌트 기반 개발은 다음과 같은 일반 응용프로그램 개발의 변형입니다.

  • 응용프로그램은 다른 팀에 의해 서로 비교적 독립적으로 개발 및 배치된 별도의 실행 가능 컴포넌트에서 어셈블됩니다.
  • 응용프로그램은 응용프로그램을 구성하는 컴포넌트 중 일부만 업그레이드하여 조금씩 점진적으로 업그레이드할 수 있습니다.
  • 컴포넌트를 응용프로그램 사이에 공유하여 재사용 기회를 만들 수 있지만 프로젝트 간 종속성도 발생합니다.
  • 컴포넌트 기반 응용프로그램은 분산되는 경향이 있습니다(반드시 컴포넌트 기반과 관련이 있지는 않음).

이 페이지에서, "컴포넌트"는 독립적으로 개발 및 배치 가능한 컴포넌트를 의미합니다. 그러나 RUP의 다른 부분에서는 개념: 컴포넌트에 설명되는 더 일반적인 의미의 "컴포넌트" 용어를 사용하고 필요에 따라 규정합니다.

컴포넌트 기반 개발 문제를 해결하기 위한 Rational Unified Process 적응에 대한 설명이 아래에 나와 있습니다.

도입/인식(Inception) 단계 활동

도입/인식 단계의 기본 워크플로우는 다음 확장 또는 변형과 함께 적용됩니다.

프로젝트 관리

  • 활동: 새 프로젝트 이해
  • 타스크: 비즈니스 사례 개발의 초점은 컴포넌트를 사용하여 개발의 비용 구조를 변경하는 것을 고려하도록 조정됩니다. 특히, 컴포넌트 개발 비용은 감소하지만 컴포넌트를 식별하고 선택된 컴포넌트가 요구사항을 충족하는지 검증하는 데 더 많은 노력이 소모됩니다.

  • 활동: 프로젝트 범위 및 위험성 평가
  • 컴포넌트 접근 방식을 택하면 특정 위험성 특성이 변경되고 새 위험성이 발생합니다. 특히, 다음에 유의하십시오.

    • 아웃소싱된 컴포넌트는 프로젝트 팀의 직접적인 제어를 받지 않는 중요한 요소를 도입하므로 위험성을 증가시킵니다.
    • 아웃소싱된 컴포넌트는 자원 위험성을 감소시켜 개발 시간을 줄여줄 수 있습니다.
    • 아웃소싱된 컴포넌트는 자체에 아키텍처 제한사항이 있을 경우 시스템의 아키텍처를 왜곡시킬 수 있습니다.
  • 활동: 프로젝트 계획
  • 타스크: 단계 및 반복 계획에서, 구현/구축(Construction) 단계 계획은 두 개의 다른 병렬 트랙으로 분할될 수도 있습니다. 하나는 아키텍처의 상위 계층에 조직되는 응용프로그램 특정 및 도메인 특정 컴포넌트와(개념: 계층화 참조)이고, 다른 하나는 하위 계층에 구성되는 비응용프로그램 및 비도메인 특정 컴포턴트입니다. 어떤 경우에는 재사용가능 컴포넌트가 관리 대상 개발 팀과 독립적으로 개발됩니다. 병렬 트랙 도입 결정의 대부분은 배치되는 응용프로그램과 독립적인 자산으로 재사용가능한 컴포넌트를 관리하려는 바램으로 발생하는 인력 구성 및 자원 문제입니다.

요구사항

  • 활동: 시스템 정의 정제
  • 시스템 요구사항을 정제할 때, 선택된 컴포넌트 프레임워크에 의해 부과되는 제한조건을 캡처해야 합니다. 컴포넌트 프레임워크는 소프트웨어 설계자와 디자이너의 자유 정도를 제한하여 부분적으로 개발 생산성을 개선합니다. 타스크: 소프트웨어 요구사항 세부화는 이와 같은 제한조건을 문서화하는 데 초점을 맞춰야 합니다.

테스트

  • 활동: 평가 미션 정의
  • 프로젝트에 대해 전체적으로 시행하려는 테스트를 식별하는 테스트 계획을 작성해야 합니다. 이 계획을 "마스터 테스트 계획"이라고 합니다.

환경

  • 활동: 프로젝트 환경 준비
  • 프로젝트의 가이드라인을 수집하고 준비할 때 타스크: 프로젝트의 가이드라인 준비의 세부사항을 참조하여 특정 컴포넌트 프레임워크와 이 프레임워크에 의해 부과되는 제한조건을 고려하십시오. 가이드라인에는 프레임워크를 사용하여 디자인하고 코딩하는 방법이 포함되어야 합니다. 컴포넌트 프레임워크 자체와 컴포넌트 사이에 정의된 인터페이스를 둘 다 준수하는지 확인하는 방법에 대한 테스트 안내도 제공해야 합니다.

정제(Elaboration) 단계 활동

정제(Elaboration) 단계의 기본 워크플로우는 다음 확장 또는 변형과 함께 적용됩니다.

요구사항

  • 활동: 시스템 정의 정제
  • 타스크: 소프트웨어 요구사항 세부화는 또한 기술적이며 비기능적인 요구사항 및 빌드하거나 구입한 컴포넌트에 부과되는 제한조건에 초점을 맞춥니다. 고려할 만한 특정의 비기능적 요구사항으로는 크기, 성능, 메모리 또는 디스크 풋프린트, 런타임 라이센스 부여 문제, 컴포넌트 선택 또는 구현에 영향을 주는 유사한 제한조건이 있습니다.

분석 및 디자인

  • 활동: 컴포넌트 디자인
  • 타스크: 서브시스템 디자인은 컴포넌트의 디자인을 더 정제하여 컴포넌트의 실제 동작을 제공하는 클래스를 컴포넌트 내에서 식별합니다. 정제(Elaboration) 단계의 초기에는 아키텍처 프로토타입 생성 목적으로 컴포넌트의 동작을 시뮬레이트하기 위한 스텁으로 동작하는 '서브시스템/컴포넌트 프록시' 유형의 단일 클래스가 있습니다. 이 클래스의 동작은 나중에 서브시스템에 포함된 클래스의 협업에 분배됩니다. 포함된 클래스는 타스크: 클래스 디자인에서 정제됩니다.

  • 활동: 데이터베이스 디자인
  • 정제(Elaboration) 시 초점은 지속성 전략이 확장 가능하고 데이터베이스 디자인 및 지속성 메커니즘이 시스템의 처리량 요구사항을 지원하도록 하는 데 있습니다. 지속적 클래스를 식별하여 지속성 메커니즘에 맵핑합니다. 메커니즘을 확장 가능하게 하기 위해 데이터 중심의 유스 케이스를 분석합니다. 테스트 활동과 관련하여 지속성 메커니즘 및 데이터베이스 디자인이 평가되고 유효성이 검증됩니다.

구현

  • 활동: 컴포넌트 구현

    타스크: 디자인 요소 구현중간 산출물: 프로젝트 가이드라인의 일부로 제공되는 프로그래밍 가이드라인에 설명된 대로 컴포넌트 프레임워크에서 부과하는 제한조건을 따라야 합니다. 정제(Elaboration) 단계에서는 대부분의 컴포넌트에 많은 '스텁' 코드가 포함됩니다. 여기에서의 구현은 프로덕션 품질 코드 생성이 아니라 아키텍처 유효성 검증에 초점을 맞추고 있기 때문입니다.

테스트

  • 활동: 평가 미션 정의, 테스트 접근 방식 확인, 테스트 및 평가, 허용 가능한 미션 달성, 테스트 자산 개선

    정제(Elaboration)에서의 테스트 활동 초점은 아키텍처의 유효성 검증에 있습니다. 컴포넌트 기반 시스템의 경우, 다음에 초점을 맞춥니다.

    • 컴포넌트 경계가 적절하도록 컴포넌트 사이의 인터페이스 연습 수행
    • 예상 트랜잭션 볼륨이 지속될 수 있도록 성능 테스트(특히 성능 비례 테스트)에 더욱 집중함

    컴포넌트 프레임워크에 있는 본래의 가정사항도 평가해야 합니다. 이 가정사항에는 공통적으로 지속성 및 트랜잭션 관리 메커니즘의 확장성 및 처리량이 포함됩니다. 메커니즘 디자이너가 작성한 숨겨진 가정사항은 응용프로그램 아키텍처가 이를 파악하지 못할 경우 해당 아키텍처를 상당히 손상시킵니다.

프로젝트 관리

  • 활동: 다음 반복 계획

    구현 서브시스템을 '책임의 논리 단위'로 사용할 경우, 구현/구축(Construction) 작업은 둘 이상의 병렬 "트랙"으로 파티션할 수 있습니다. 하나의 병렬 트랙은 응용프로그램 특정 기능성에 초점을 맞추고 다른 하나(또는 그 이상)은 재사용가능한 일반 컴포넌트에 초점을 맞춥니다. 물론 병렬 개발 노력에 인력을 배정할 만큼 충분한 자원을 가지고 있어야 합니다. 개발 팀과 작업을 병렬로 나눌 수 있는 능력은 전적으로 아키텍처의 안정성에 달려 있습니다. 특히, 컴포넌트 사이의 인터페이스 품질과 안정성에 의존합니다. 정제 단계에 많은 노력을 기울이면 이 분할이 가능하게 됩니다.

구현/구축(Construction) 단계 활동

구현/구축 단계의 기본 워크플로우는 다음 확장 또는 변형과 함께 적용됩니다.

프로젝트 관리

  • 활동: 다음 반복 계획

    첫 번째 구현/구축 반복 계획은 정제의 끝 무렵에 발생하며 위에서 설명했습니다. 후속 반복 계획과 개발 팀 및 작업을 병렬로 나눌 수 있는 능력은 여전히 아키텍처의 안정성과 컴포넌트 사이의 인터페이스 품질 및 안정성에 의존합니다.

분석 및 디자인

  • 활동: 아키텍처 정제활동: 컴포넌트 디자인

    구현/구축(Construction) 시 초점은 나머지 유스 케이스를 분석하고 유스 케이스를 실현하는 적절한 컴포넌트 및 컴포넌트 협업을 식별하는 데 있습니다. 기존 아키텍처가 확장 및 완료되고 컴포넌트의 '내부 동작'이 완전히 디자인되어 구현됩니다.

  • 활동: 데이터베이스 디자인

    구현/구축(Construction) 시 초점은 데이터베이스 디자인을 완료하고, 모든 지속적 클래스가 데이터베이스 및 지속성 메커니즘으로 지원되도록 하는 데 있습니다. 이 작업은 활동: 아키텍처 정제활동: 컴포넌트 디자인에서 수행되는 작업과 병렬 및 반복적으로 수행됩니다. 이상적인 조직은 좋은 데이터베이스 디자인을 위해 지속성 문제에 대해 팀 간의 조정이 이루어지는 통합 컴포넌트 팀을 갖는 것입니다.

구현

테스트

성능 테스트는 여전히 중요하지만 점점 기능 테스트에 초점을 맞추게 됩니다. 기능의 완전성, 기존 기능성의 회귀 테스트, 성능 기대 준수 등에 대해 다뤄야 합니다.

전이 단계 활동

  • 웹 환경에서의 제품 릴리스는 점진적이고 계속적이며 전형적인 매체 분배에 대해서는 덜 집중하는 추세입니다. 이에 따라 릴리스 계획을 조정해야 합니다.
  • 프로덕션 지원이 점차적으로 단계의 초점이 되고 있습니다.
  • 데이터 변환 활동이 수행됩니다.