O termo prova de conceito (POC) em arquiteturas de software e dados tem se tornado muito popular. Provas de conceito são instrumentos de mitigação de riscos técnicos, criação de arquiteturas executáveis e podem servir a vários propósitos gerenciais em um projeto. Apresentamos abaixo um modelo mental para guiar arquitetos na escolha e organização de uma prova de conceito. O nosso modelo é baseado em seis questões de análise

1. Que requisitos e cenários são candidatos a uma prova de conceito?

Observe a figura abaixo, que mostra os tipos de requisitos típicos de um sistema. Como exemplo, se considerarmos um site de comércio eletrônico veremos que os cenários de negócio ligados à venda de produtos e que fazem comunicações com sistemas de processamento de pagamento diversos são críticos para o negócio e ao mesmo tempo desafiantes tecnicamente em termos do tempo de reposta, disponibilidade, escalabilidade e vazão.

Os requisitos do quadrante 1 são aqueles que devem ser investigados pelo arquiteto e que normalmente derivam provas de conceito.

2. Quantas provas de conceito devo ter?

O número de provas de conceito é proporcional ao grau de risco de um projeto e portanto não é um número pré-determinado. Como regra geral, o número de provas de conceito deve tornar o risco técnico do projeto baixo e administrável ao longo do seu ciclo de vida.

3. O que uma prova de conceito irá explorar?

Provas de conceito normalmente exploram dois aspectos (estruturas ou comportamentos).

Provas de conceito que exploram estruturas normalmente são usadas para compararmos ou selecionarmos tecnologias, determinar viabilidade tecnológica de uma pilha tecnológica ou mesmo a descoberta de uma melhor prática técnica (ex. JEE ECB ou ASP.NET MVC). Provas de conceito que exploram comportamentos normalmente querem explorar algum caso de uso, história do usuário ou cenário de negócio potencialmente complexo em um sistema.

4. O que uma prova de conceito irá produzir?

A figura abaixo fornece tipos comuns de provas de conceito, que podem ir desde uma leitura de um artigo, passando por uma simulação simples de uma solução e até mesmo um protótipo evolutivo. Como regra geral, quanto maior o risco, mais densa tende a ser uma prova de conceito.

O conjunto dos produtos resultantes das provas de conceito de um produto é chamdo de arquitetura executável, composta por modelos, artigos, rascunhos, códigos descartávels ou mesmo códigos evolutivos.

5. Quando devo fazer as provas de conceito?

Use a regra do terço. No primeiro 1/3 de um projeto você deve ter todas as provas de conceito de um projeto finalizadas de forma a acomodar riscos e determinar a arquitetura executável do seu sistema.

6. Como encaixar as provas de conceito no processo de software da minha empresa?

• Se você usa métodos ágeis, mescle provas de conceito ao longo dos primeiros sprints de um projeto. Se possível, crie o conceito do Sprint 0 dedicada apenas ao tema prova de conceito.
• Se você usa o processo unificado (IBM RUP, Enterprise Unified Process, Open-UP, Essential UP ou similar), a fase de elaboração foi criada para lidar com provas de conceito.

Extraordinary claims require extraordinary evidence – Carl Sagan