Design da Solução · Etapa 03 · Como Trabalhamos
Estratégia e Arquitetura definem como um sistema deve ser estruturado. O Design da Solução determina exatamente o que será construído — os fluxos de trabalho, interfaces, contratos de dados e comportamentos em falha que transformam uma direção de engenharia em algo que a equipe realmente consiga implementar.
Esta etapa não começa pela implementação. Começa por uma especificação testada com base em evidências antes que qualquer linha de código de produção seja escrita.
Não esta questão
"O que devemos construir?"
Em vez disso, esta pergunta
"Esse design específico realmente se comporta como esperamos, nas condições reais que enfrentará — e podemos provar isso antes de comprometer recursos de engenharia para construí‑lo?"
Design · Protótipo · Teste · Medição · Especificação
Por que o Design segue a Arquitetura
A arquitetura de referência da etapa anterior define camadas, escolhas tecnológicas e preocupações transversais. Ainda não especifica como um fluxo de trabalho deve se comportar quando uma requisição é ambígua, nem o que acontece quando uma integração retorna dados malformados. O Design da Solução fecha essa lacuna — sem ele, "arquitetura" continua sendo um diagrama, não um sistema.
Arquitetura de Referência → Especificação da Solução
Por que o rigor no design importa
A pesquisa de Barry Boehm sobre a economia da engenharia de software — publicada pela primeira vez em 1976 e ampliada em seu livro de 1981, Software Engineering Economics — concluiu que o custo para corrigir um defeito aumenta substancialmente quanto mais tarde ele for detectado.
~1×
Custo para corrigir um defeito detectado durante o design.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Custo para corrigir o mesmo defeito após o lançamento em produção, dependendo da escala do projeto.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Essa conclusão foi revisitada desde então. A própria revisão de Boehm e Basili em 2001 constatou que a curva fica consideravelmente mais plana para equipes pequenas, que iteram rápido e têm forte cobertura de testes e entrega contínua. O multiplicador não é universal, e nós não o tratamos como tal.
Mas a tendência observada não foi revertida: detectar uma falha de projeto antes de ela ser implementada é mais barato do que detectá‑la depois. Por isso a OpenQCore trata prototipação e testes como parte integrante do design — não como uma fase que acontece depois que a construção já começou.
Da Arquitetura à Especificação
Cada decisão arquitetural da etapa anterior é detalhada em especificações concretas.
A sequência exata de passos, pontos de decisão, exceções e transferências que a solução deve suportar — fundamentada no Modelo de Fluxo de Trabalho do Estado Atual gerado durante a fase de descoberta, e não em um processo ideal reimaginado.
O que cada usuário, sistema ou agente vê, envia e recebe — telas, fluxos conversacionais, contratos de API e os campos relevantes em cada etapa.
A estrutura exata, regras de validação, abordagem de versionamento e propriedade dos dados que circulam entre os componentes.
O que o sistema faz — e o que explicitamente não faz — em condições normais, em casos-limite e em cenários de falha.
Resultado
Especificação da Solução (Rascunho)
Design de Fluxo de Trabalho e Interação
Uma interface conversacional sobreposta a um fluxo de trabalho falho não corrige o fluxo — apenas o esconde, até que a limitação subjacente volte a surgir em outro ponto.
O Design de Solução parte das evidências de fluxo levantadas durante a descoberta e coloca uma questão estrutural antes da questão de interface: quais etapas desse processo devem ser automatizadas, quais devem permanecer com intervenção humana e onde, exatamente, ocorre a transferência de responsabilidade entre elas? Mapeamos isso de forma explícita, para que os pontos com intervenção humana sejam decisões de design deliberadas — e não um acaso das capacidades tecnológicas.
Pontos de verificação explícitos em que revisão, julgamento ou autorização humana são exigidos por projeto — não por omissão.
Limites claramente definidos sobre o que o sistema pode decidir ou executar sem aprovação humana.
Caminhos planejados para casos que fogem ao tratamento normal — e não falhas silenciosas ou soluções padrão de contingência.
Prototipagem e Experimentação
A OpenQCore trata o design em estágio inicial do mesmo modo que a Design Science trata um artefato de sistemas de informação: como algo construído especificamente para ser avaliado frente a um problema real, e não simplesmente admirado pela sua elegância. Essa abordagem — formalizada no influente trabalho de Hevner et al., "Design Science in Information Systems Research" (MIS Quarterly, 2004) — considera o artefato e sua avaliação como inseparáveis. Aplicamos o mesmo raciocínio orientado por hipóteses usado na fase de descoberta também ao nível do design.
Uma decisão de design específica e falsificável — não uma orientação vaga.
Uma representação funcional suficiente para testar a decisão — não necessariamente pronta para produção.
Entradas reais ou realisticamente representativas — não exemplos idealizados escolhidos para dar certo.
Comparação com a linha de base e os critérios de sucesso definidos na fase de descoberta — não uma impressão subjetiva de qualidade.
O design é mantido, modificado ou abandonado com base no que o teste demonstrou — não pelo esforço já investido.
O objetivo de um protótipo não é provar que um design pode funcionar. É verificar se ele funciona de forma confiável nas condições reais às quais o sistema final estará sujeito.
Especificação de Dados e Interface
Falhas de integração raramente surgem de uma única decisão obviamente errada. Costumam decorrer da ambiguidade — um campo assumido como sempre presente, um caso de erro que ninguém documentou, uma incompatibilidade de versão que não foi prevista.
Trata-se de um trabalho deliberadamente pouco glamouroso. É também o trabalho que determina se um sistema que teve bom desempenho numa demonstração continua a ter bom desempenho em produção, após seis integrações e dezoito meses.
Projetar para falhas, não apenas para o sucesso
A maioria das falhas de projeto não acontece no caminho feliz. São falhas do que ocorre quando algo dá errado — um sistema a montante atinge o tempo limite, um documento não é extraído corretamente, um modelo está incerto, um usuário faz algo inesperado. O OpenQCore antecipa e projeta essas condições deliberadamente, em vez de descobri-las em produção.
O que o sistema faz quando a confiança em um resultado é baixa — inclusive se e como comunica isso.
Quais funcionalidades permanecem disponíveis quando uma dependência falha, em vez de haver uma queda total do sistema.
As condições específicas em que um caso é encaminhado a um humano e qual o contexto que acompanha essa transferência.
Como o sistema se comporta diante de entradas malformadas, sequências inesperadas ou tentativas de uso indevido — não apenas frente a requisições bem-formadas.
Um sistema que nunca foi questionado 'o que acontece quando isto falha?' não foi realmente projetado. Apenas foi demonstrado.
Critérios de validação definidos antes da implementação
Em conformidade com o princípio definido durante a fase de discovery — de que o sucesso deve ser estabelecido antes da implementação — o Design da Solução produz critérios de aceitação explícitos e documentados e um plano de testes antes do início do desenvolvimento em produção.
O que a solução deve fazer corretamente, descrito em termos testáveis.
Alinhados às características reconhecidas de qualidade de software — incluindo eficiência de desempenho, confiabilidade, usabilidade, segurança e manutenibilidade, conforme o modelo de qualidade de produto de software ISO/IEC 25010 — especificados como metas mensuráveis em vez de aspirações gerais.
Os cenários, conjuntos de dados e condições específicos contra os quais a solução será avaliada antes de ser considerada pronta para implementação em produção.
Portão de Revisão de Design
Essa prática tem precedentes: o método formal de inspeção de design e código de Michael Fagan, introduzido na IBM em 1976, demonstrou que revisões estruturadas e baseadas em critérios detectam defeitos mais cedo e com mais confiabilidade do que aprovações informais. A OpenQCore aplica o mesmo princípio ao design da solução.
A especificação está suficientemente precisa, o protótipo cumpriu os critérios de avaliação e o desenvolvimento pode começar.
A direção principal está correta, mas elementos específicos precisam ser revistos com base no que os testes revelaram.
O trabalho de design revelou uma restrição que a arquitetura não havia previsto — a resposta adequada é revisar a estrutura, não projetar contornando-a.
O trabalho de design identificou um risco — técnico, operacional, de segurança ou ético — que exige uma decisão além da autoridade da equipe de design antes de prosseguir.
Um portão de design que sempre diz “sim” não é um portão.
O que o Design da Solução produz
Conforme o escopo do engajamento, esta etapa produz:
Fluxos de trabalho, interfaces, contratos de dados e comportamentos, com detalhes suficientes para construir sem precisar reinterpretar a intenção.
Representações visuais do fluxo de processos, incluindo pontos explícitos de intervenção humana.
Esquemas, regras de validação e estratégia de versionamento para cada interface entre componentes.
O que foi testado, qual foi a linha de base utilizada e o que os resultados comprovam ou descartam.
Condições de falha documentadas e a resposta projetada do sistema para cada uma delas.
Condições específicas e mensuráveis que a solução implementada deve cumprir antes da implantação.
Do Design ao Desenvolvimento e Integração
O Design da Solução gera uma especificação testada e validada — não um sistema finalizado. A etapa seguinte transforma essa especificação em software funcional, integrado aos sistemas com os quais deve operar.
Especificação da Solução → Avaliação de Protótipo → Critérios de Aceitação → Desenvolvimento e Integração
Etapa 04
Implemente a solução especificada com base nos critérios de aceitação definidos — não em suposições.
Referências de investigação e metodologia
Boehm, B. — Software Engineering Economics (1981); Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
Fonte das conclusões sobre o custo da mudança mencionadas acima, incluindo a revisão posterior que mostra uma curva menos acentuada para equipas pequenas que iteram rapidamente.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in Information Systems Research," MIS Quarterly (2004)
Quadro teórico fundamental que trata o artefato de sistemas de informação e a sua avaliação como inseparáveis — a base para o ciclo de prototipagem, teste e refinamento descrito acima.
Fagan, M. — "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal (1976)
Origem da revisão de design estruturada e baseada em critérios como prática formal de engenharia, referida no Design Review Gate acima.
ISO/IEC 25010:2011 — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models
Fonte das características de qualidade não funcionais mencionadas nos critérios de aceitação acima.
