Artefato: Prova de Conceito Arquitetural

Prova de Conceito Arquitetural	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.
Papel:	Arquiteto de Software
Possibilidade de Opção:	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.
Mais informações:
Finalidade Representação Ocorrência Responsabilidade Adaptação

Entrada para Atividades:

Avaliar Viabilidade de Prova de Conceito Arquitetural

Saída de Atividades:

Construir Prova de Conceito Arquitetural

Finalidade

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

Representação

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

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

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

Adaptação

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 não pode 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 novidade 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 possibilidade 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