결과물:
|
![]() |
POC는 시작 초기에 식별되는 구조적으로 중요한 요구사항에 대한 솔루션으로 단지 개념적인 사항일 수 있습니다. | |
역할: | 소프트웨어 아키텍트 | |
---|---|---|
선택 가능성/발생 시기: | POC는 문제 도메인이 제대로 이해되고 요구사항이 제대로 정의되며 시스템이 전례에 의해 제대로 지지되고 개발에 낮은 위험이 있는 것으로 평가되면 생략될 수도 있습니다. | |
템플리트 및 보고서: |
|
|
예: | ||
UML 표시: | 적용 가능하지 않습니다. | |
자세한 정보: | ||
|
활동 정보: | 활동 결과: |
POC의 목적은 구조적으로 중요한 요구사항을 만족하는 솔루션이 있는지 또는 있을 가능성이 있는지 여부를 판별하기 위함입니다.
POC는 여러 양식을 취할 수 있습니다. 예를 들어 다음과 같습니다.
POC는 초기 단계에 개발되어(선택사항) 프로젝트의 실행 가능성 판별, 개발에 수반되는 기술 위험 평가 및 구조적으로 중요한 요구사항을 형성하고 정제하는데 도움이 됩니다.
소프트웨어 아키텍트는 POC의 책임이 있습니다.
POC가 필요한지 여부 및 취해야 하는 양식에 대한 결정은 다음에 따라 달라집니다.
위험이 높을수록 초기의 이 구조적 통합 활동에 더 많은 노력을 기울여(작성되어 평가된 모델에서 보다 실제적인 결과를 기대하며) 모든 스테이크홀더가 자금 확약에 대한 기초와 구현화로의 진행이 확실함을 확신하도록 해야 합니다. 그러나 모든 위험이 이 단계에서 제거될 수 없다는 것을 인지해야 합니다. 초기 단계가 사실상 구현화 단계로 왜곡되어서는 안됩니다.
Rational Unified Process
|