POC는 시작 초기에 식별되는 구조적으로 중요한 요구사항에 대한 솔루션으로 단지 개념적인 사항일 수 있습니다.  
역할:  소프트웨어 아키텍트 
선택 가능성/발생 시기:  POC는 문제 도메인이 제대로 이해되고 요구사항이 제대로 정의되며 시스템이 전례에 의해 제대로 지지되고 개발에 낮은 위험이 있는 것으로 평가되면 생략될 수도 있습니다.  
템플리트 및 보고서: 
     
예: 
     
UML 표시:  적용 가능하지 않습니다.
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

POC의 목적은 구조적으로 중요한 요구사항을 만족하는 솔루션이 있는지 또는 있을 가능성이 있는지 여부를 판별하기 위함입니다.  

표시 페이지 맨 위

POC는 여러 양식을 취할 수 있습니다. 예를 들어 다음과 같습니다. 

  • 솔루션에 적합해 보이는 알려진 기술 목록(프레임워크, 패턴, 실행 파일 구조)
  • UML과 같은 표기법을 사용한 솔루션의 개념적 모델 스케치
  • 솔루션 모의 실행
  • 실행 파일 프로토타입

시기 페이지 맨 위

POC는 초기 단계에 개발되어(선택사항) 프로젝트의 실행 가능성 판별, 개발에 수반되는 기술 위험 평가 및 구조적으로 중요한 요구사항을 형성하고 정제하는데 도움이 됩니다.

책임 페이지 맨 위

소프트웨어 아키텍트는 POC의 책임이 있습니다.  

사용자 정의 페이지 맨 위

POC가 필요한지 여부 및 취해야 하는 양식에 대한 결정은 다음에 따라 달라집니다.

  • 도메인 이해 정도 - 도메인을 잘 모르는 경우, POC가 가능한 솔루션을 탐색할 뿐 아니라 고객 및 개발 조직이 요구사항을 이해하고 명백히 하는데 도움을 줄 수도 있습니다.
  • 시스템의 진기함 - 개발 조직이 이러한 많은 시스템을 이전에 구성해 본 경우 개념 증명을 빌드할 필요가 없습니다. 기존 참조 구조 및 기술의 실행 가능성 판별을 기반으로할 수 있어야 합니다.
  • 도메인에 익숙하고 시스템이 전례로 지지되는 경우에도 임의의 요구사항이 특히 부담스러운지를 판단할지 여부(예: 과도하게 높은 트랜잭션 비율 또는 극도의 안정성이 필요한지 여부).

위험이 높을수록 초기의 이 구조적 통합 활동에 더 많은 노력을 기울여(작성되어 평가된 모델에서 보다 실제적인 결과를 기대하며) 모든 스테이크홀더가 자금 확약에 대한 기초와 구현화로의 진행이 확실함을 확신하도록 해야 합니다. 그러나 모든 위험이 이 단계에서 제거될 수 없다는 것을 인지해야 합니다. 초기 단계가 사실상 구현화 단계로 왜곡되어서는 안됩니다.



Rational Unified Process   2003.06.15