Quando criar uma prova de conceito arquitetural?

 

Em meu último post descrevi o método ACDM de Tony Lattanze que é fortemente centrado em provas de conceito (POCs). Em projetos de desenvolvimento de sistemas centrados em arquitetura esta prática é fundamental para mitigação de riscos arquiteturais. 

Quando devo criar uma prova de conceito arquitetural?

Para responder esta pergunta de forma simples e objetiva segue abaixo um checklist básico 'precioso' para nortear o planejamento das suas POCs. 

 
■ Existem requisitos funcionais parcialmente endereçados pela arquitetura que precisam ser provados?

 
 Existem métricas para atributos de qualidade que devem ser provadas? (Por exemplo o desempenho exigido parece ser de alto risco e você não possui métricas detalhadas provando que o sistema pode atingi-las.)

 
■ Existem componentes considerados de alto risco ou de vanguarda no que eles são obrigados a fazer que precisam ser provados?

 
 Existem integrações com interface com outros sistemas que precisam ser provadas?


 Existem interfaces com usuário que você precisa apresentar para os usuários finais para verificar se suas necessidades estão sendo satisfeitas?


 Existem pacotes complexos que estão sendo utilizados, que exigem personalizações
ou configurações? (Alguns produtos podem ser configurados de alguma maneira que pode afetar o desempenho ou a disponibilidade)

 

Você acrescentaria alguma outra questão neste checklist? 

 

Fonte: Software Architecting, Peter Eeles e Peter Cripps 

Exibições: 222

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Adriano Tavares em 4 março 2011 às 14:05
Baixei também e gostei.
Comentário de Giovani Salvador em 2 março 2011 às 21:17
BTW, fiz download do Architecture Studio do Lattanze. Alguém já usou?
Comentário de Giovani Salvador em 2 março 2011 às 21:13

Já fiz uma prova de conceito bem complexa onde justamente queria responder perguntas que não haviam sido respondidas, tais como:

- A integração da aplicação A com B vai funcionar?

- A quantidade de mensagens XML que serão processadas entre os sistemas irá requerer mais hardware/software?

 

Entre outras...

 

No fim, o design acabou mudando dado o que foi encontrado na PoC.

 

Bom post Adriano

Comentário de Denis Pinheiro em 1 março 2011 às 8:24

Olá Adriano,

Considero que Provas de Conceito são uma forma de mitigação de riscos tecnológicos do projeto (ou como o Corélio citou, "de redução do perfil dos riscos"). Porém, a maioria dos riscos arquiteturais, (senão todos) estão relacionados com atributos de qualidade. Se observarmos, poderíamos organizar o check-list apresentado em grupos de itens de verificação da necessidade de validação de um ou mais atributos de qualidade.

Um método de simples aplicação para validação de atributos de qualidade é o Método Estímulo-Resposta baseado em Cenários do SEI (apresentado por Len Bass em Software Architecture in Practice). 

Sendo assim, a partir da lista de riscos arquiteturais, pode-se levantar os atributos de qualidade associados aos riscos e desenvolver cenários para validação destes atributos por meio do método Estímulo-Resposta (SEI). Segue minha sugestão:






Comentário de Fábio Almeida em 1 março 2011 às 5:34

Oi Adriano,

Quando eu vi este checklist me lembrei das Perspectivas Arquiteturais(Woods2005) , usados para assegurar que um Sistema exiba um conjunto particular de propriedades.

Será que as provas de conceito  podem ser norteadas pelas Perspectivas Arquiteturais?

 

Comentário de Marco Mendes em 28 fevereiro 2011 às 22:38

Olá, Adriano. Gosto de pensar em provas de conceito em termos da redução do perfil de riscos tecnológicos do projeto.

Em termos ágeis, uma técnica como o Top-Ten Risks descrita no excelente livro Rapid Development, do mestre Steve McConnell, nos ajuda a identificar riscos arquiteturais e a exposição ao risco do projeto.  As provas de conceito nos ajudam a reduzir este perfil e podemos então reavaliar a exposição ao risco ao longo das iterações iniciais do projeto até obtermos uma arquitetura estável para o projeto, que é o marco onde o risco tecnológico é muito baixo.

My 2 cents...

Badge

Carregando...

© 2018   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço