A Prova de Conceito Arquitetural é uma solução, que pode simplesmente ser conceitual, para os requisitos significativos arquiteturalmente que são identificados primeiro na Iniciação.  
Função:  Arquiteto de Software  
Opcionalidade/Ocorrência:  A Prova de Conceito Arquitetural pode ser omitida quando o domínio do problema é bem entendido, os requisitos são bem definidos, o sistema tem bons precedentes e o seu desenvolvimento é avaliado como tendo baixo risco.  
Gabaritos e Relatórios: 
     
Exemplos: 
     
Representação em UML:  Não aplicável.
Informações Adicionais:   
Entrada de Atividades:    Saída das Atividades:   

Finalidade Para o início da página

A finalidade da Prova de Conceito Arquitetural é determinar onde existe, ou é provável que exista, uma solução que satisfaça os requisitos arquiteturalmente significativos.  

Representação Para o início da página

A Prova de Conceito Arquitetural pode ter muitas formas, por exemplo: 

  • uma lista de tecnologias (frameworks, padrões, arquiteturas executáveis) conhecidas que pareça adequada à solução
  • um esboço de modelo conceitual de uma solução que use uma notação como a UML
  • uma simulação de uma solução
  • um protótipo executável

Sincronização Para o início da página

A Prova de Conceito Arquitetural é (opcionalmente) desenvolvida na fase de Iniciação para ajudar a determinar a possibilidade do projeto, avaliar os riscos técnicos relacionados a esse desenvolvimento e formular e refinar os requisitos significativos arquiteturalmente.

Responsabilidade Para o início da página

O Arquiteto de Software é responsável pela Prova de Conceito Arquitetural. 

Adaptação Para o início da página

A decisão se uma Prova de Conceito Arquitetural é necessária e qual forma ela deve ter depende de:

  • o domínio ser bem entendido - se o domínio não é familiar, a Prova de Conceito Arquitetural pode não apenas explorar soluções possíveis, mas também pode ajudar o cliente e as organizações de desenvolvimento a entender e esclarecer os requisitos
  • a inovação do sistema - se a organização de desenvolvimento construiu muitos desses sistemas anteriormente, não será necessário criar uma prova de conceito - deve ser possível basear uma determinação de viabilidade nas arquiteturas e tecnologias de referência existentes
  • qualquer requisito ser considerado ou não como particularmente oneroso, mesmo que o domínio seja familiar e o sistema tenha precedentes; por exemplo, taxas de transação muito altas ou extrema confiabilidade são necessárias

Quanto maior o risco, mais esforço é necessário nessa atividade de síntese arquitetural na Iniciação (com a expectativa de resultados mais realistas dos modelos produzidos e avaliados). Portanto, todos esses envolvidos podem ser convencidos de que a base para confirmar os fundos e continuar na Elaboração é digna de crédito. Entretanto, é preciso reconhecer que nem todos os riscos podem ser eliminados nessa fase. A fase de Iniciação não deve ser distorcida em uma fase de Elaboração de fato.



Rational Unified Process   2003.06.15