Pontos de Verificação: Documento de Arquitetura de Software
Tópicos
Em geral, o sistema é baseado integralmente na arquitetura porque:
- A arquitetura parece ser estável.
A necessidade de estabilidade é estabelecida pela natureza da fase de
Construção: em Construção, o projeto normalmente se expande, incluindo
desenvolvedores que trabalharão em paralelo e comunicando-se livremente com outros
desenvolvedores, conforme eles produzem o produto. O grau de independência e paralelismo necessário na Construção simplesmente não pode ser atingido se a arquitetura não é estável.
A importância de uma arquitetura estável não pode ser desconsiderada.
Não se engane pensando que 'o quase bom é o suficiente' - instável é instável e é melhor acertar a arquitetura e adiar o começo da Construção em vez de prosseguir.
Os problemas de coordenação relacionados à tentativa de corrigir a arquitetura enquanto os desenvolvedores tentam utilizá-la como base facilmente anularão quaisquer benefícios aparentes de um cronograma acelerado.
As mudanças na arquitetura durante a Construção têm um impacto amplo:
elas tendem a ser caras, destruidoras e desmoralizantes.
A dificuldade real em montar a estabilidade arquitetural é que
"você não tem idéia daquilo que não sabe"; a estabilidade é medida
com relação à alteração esperada. Como resultado, a estabilidade é essencialmente uma métrica subjetiva.
No entanto, podemos basear essa subjetividade em mais do que simples hipóteses.
A arquitetura em si é desenvolvida considerando-se 'cenários significativos do ponto de vista da arquitetura' - subconjuntos de casos de uso que representam o comportamento mais desafiador em termos tecnológicos que o sistema deve suportar.
Avaliar a estabilidade da arquitetura envolve assegurar que ela tenha ampla cobertura, que não haverá 'surpresas' na arquitetura mais adiante.
A experiência adquirida com a arquitetura também pode ser um bom indicador: se
a taxa de mudanças na arquitetura for baixa e permanecer baixa, conforme novos
cenários forem abordados, há um bom motivo para acreditar que a arquitetura está se
estabilizando. De modo contrário, se cada novo cenário gerar mudanças na arquitetura, é sinal que ela ainda está se desenvolvendo e a definição da baseline ainda não está garantida.
- A complexidade do sistema se ajusta à funcionalidade que ele oferece.
- A complexidade conceitual é apropriada devido à habilidade e experiência de seus:
- usuários
- operadores
- desenvolvedores
- O sistema tem uma única arquitetura, consistente e coerente.
- O número e os tipos de componentes são razoáveis.
- O sistema tem um recurso de segurança consistente em
todo o sistema. Todos os componentes de segurança trabalham juntos para
proteger o sistema.
- O sistema atingirá os objetivos de disponibilidade.
- Caso ocorra uma falha, a arquitetura permitirá que o sistema seja recuperado dentro do período necessário.
- Os produtos e as técnicas nos quais o sistema é baseado correspondem à duração esperada?
- Um sistema interino (tático) de pouca duração pode ser criado com segurança utilizando-se tecnologia antiga porque em breve será descartado.
- Um sistema com expectativa de longa duração (a maioria dos sistemas) deve ser criado com base em tecnologias e métodos atualizados para que possa ser mantido e expandido de forma a atender às necessidades futuras.
- A arquitetura fornecida define interfaces claras que permitem o particionamento para desenvolvimento da equipe paralela.
- O designer de um elemento de modelo pode ter conhecimento suficiente de arquitetura para projetá-lo e desenvolvê-lo corretamente.
- A abordagem de pacotes reduz a complexidade e melhora o entendimento.
- Os pacotes foram definidos para serem altamente coerentes dentro do pacote, embora eles mesmos tenham pouca relação entre si.
- Foram consideradas soluções similares dentro do domínio de aplicativo comum.
- A solução proposta pode ser facilmente compreendida por um profissional com conhecimento geral do domínio de problema.
- Todos os membros da equipe compartilham a mesma visão da arquitetura que a apresentada pelo arquiteto de software.
- O Documento de Arquitetura de Software é atual.
- O Guia de Design foi seguido.
- Todos os riscos técnicos foram reduzidos ou considerados em um plano de contingência.
Os novos riscos descobertos foram documentados e analisados quanto ao seu impacto em potencial.
- Os principais requisitos de desempenho (orçamentos estabelecidos) foram atendidos.
- Casos de teste, infra-estruturas de teste e configurações de teste foram identificados.
- A arquitetura não parece estar
"superprojetada".
- Os mecanismos existentes parecem ser simples o bastante para serem utilizados.
- O número de mecanismos é modesto e consistente com o escopo do sistema e as demandas do domínio de problema.
- Todas as realizações de casos de uso definidas para a iteração atual podem ser executadas pela arquitetura, conforme demonstrado por diagramas que descrevem:
- Interações entre objetos,
- Interações entre tarefas e processos,
- Interação entre nós físicos.
Gerais
- O particionamento e a divisão em camadas dos subsistemas e pacotes são consistentes em termos lógicos.
- Todos os mecanismos de análise foram identificados e descritos.
Subsistemas
- Os serviços (interfaces) de subsistemas das camadas superiores foram definidos.
- As dependências entre subsistemas e pacotes correspondem aos relacionamentos de dependência entre as classes contidas.
- As classes de um subsistema oferecem suporte aos serviços identificados para o subsistema.
Classes
- As principais classes de entidade e os respectivos relacionamentos foram identificados.
- Os relacionamentos entre as principais classes de entidade foram definidos.
- O nome e a descrição de cada classe reflete claramente o papel que ela desempenha.
- A descrição de cada classe captura com precisão as responsabilidades da classe.
- As classes de entidade foram mapeadas para mecanismos de análise quando apropriado.
- Os nomes de papéis de agregações e associações descrevem com precisão o relacionamento entre as classes relacionadas.
- As multiplicidades dos relacionamentos estão corretas.
- As principais classes de entidade e os respectivos relacionamentos são consistentes com o modelo de negócios (se aplicável), o domínio do negócio (se aplicável), os requisitos e as entradas de glossário.
- O modelo está em um nível de detalhes apropriado dados os objetivos do modelo.
- Para o modelo de negócios, o modelo de requisitos ou o modelo de design durante a fase de elaboração, não há uma ênfase exagerada nas questões de implementação.
- Para o modelo de design na fase de construção, há um bom equilíbrio de funcionalidade entre os elementos do modelo, utilizando composição de elementos relativamente simples para criar um design mais complexo.
- O modelo demonstra familiaridade e aptidão com a amplitude de conceitos de modelagem aplicáveis ao domínio de problema; as técnicas de modelagem são utilizadas adequadamente para o problema em questão.
- Os conceitos são modelados com o máximo de simplicidade.
- O modelo pode ser expandido com facilidade; as mudanças esperadas podem ser facilmente acomodadas.
- Ao mesmo tempo, o modelo ainda não foi estruturado em demasia para lidar com mudanças improváveis, à custa de simplicidade e entendimento.
- As principais suposições por trás do modelo estão documentadas e visíveis para os revisores do modelo.
Se as suposições forem aplicáveis a uma dada iteração, o modelo deve poder ser desenvolvido dentro dessas suposições, mas não necessariamente fora delas.
A documentação de
suposições é uma forma de recompensar os designers por não examinarem
"todos" os requisitos possíveis. Em um processo iterativo, é impossível analisar todos os requisitos possíveis e definir um modelo que considere todos os futuros requisitos.
- A finalidade do diagrama é claramente especificada e facilmente compreendida.
- O layout gráfico é simples e transmite com clareza as informações pretendidas.
- O diagrama contém informações suficientes para atingir seu objetivo, porém não mais do que isso.
- O encapsulamento é usado com eficiência para encobrir detalhes e melhorar a clareza.
- A abstração é usada com eficiência para encobrir detalhes e melhorar a clareza.
- A colocação de elementos do modelo transmite os relacionamentos de modo eficaz; elementos similares ou bastante relacionados são agrupados.
- Os relacionamentos entre os elementos do modelo são fáceis de entender.
- A identificação dos elementos do modelo colabora para o entendimento.
- Cada elemento do modelo tem uma finalidade distinta.
- Não existem elementos supérfluos do modelo; cada elemento desempenha um papel fundamental no sistema.
- Para cada erro ou exceção, uma política define como o sistema é
restaurado para um estado "normal".
- Para cada tipo possível de erro de entrada do usuário ou de dados
errados de sistemas externos, uma política define como o sistema é restaurado para
um estado "normal".
- Há uma política aplicada de forma consistente no tratamento de situações excepcionais.
- Há uma política aplicada de forma consistente no tratamento de dados danificados no banco de dados.
- Há uma política aplicada de forma consistente no tratamento da não-disponibilidade do banco de dados, que inclusive determina se ainda é possível inserir dados no sistema e armazená-los posteriormente.
- Se os dados são trocados entre os sistemas, há uma política que define como os sistemas sincronizam suas visões de dados.
- Se o sistema utilizar processadores ou nós redundantes para
fornecer tolerância a falhas ou alta disponibilidade, há uma estratégia para
assegurar que dois processadores ou nós não 'pensem' que eles são
principais ou que nenhum processador ou nó é o principal.
- Os modos de falha de um sistema distribuído foram identificados e estratégias foram definidas para tratar das falhas.
- O processo para atualizar um sistema existente sem perda de dados ou capacidade operacional foi definido e testado.
- O processo para converter os dados usados pelos releases anteriores foi definido e testado.
- O tempo e os recursos necessários para atualizar ou instalar o produto foram informados e documentados.
- A funcionalidade do sistema pode ser ativada em um caso de uso por vez.
- O espaço em disco pode ser reorganizado ou recuperado enquanto o sistema está em execução.
- As responsabilidades e os procedimentos de configuração do sistema foram identificados e documentados.
- O acesso ao sistema operacional ou às funções de administração é restrito.
- Os requisitos de licenciamento foram atendidos.
- As rotinas de diagnóstico podem ser executadas enquanto o sistema está em execução.
- O próprio sistema monitora o desempenho operacional (por exemplo, limite de capacidade, limite crítico de desempenho, exaustão de recursos).
- As ações executadas quando os limites são atingidos estão definidas.
- A política de tratamento de alarmes foi definida.
- O mecanismo de tratamento de alarmes foi definido e testado e seu protótipo foi construído.
- O mecanismo de manipulação de alarme pode ser 'ajustado' para
evitar alarmes falsos ou redundantes.
- As políticas e os procedimentos de monitoramento e administração da rede (LAN, WAN) foram definidos.
- As falhas ocorridas na rede podem ser isoladas.
- Há um recurso de rastreamento de eventos que pode ser ativado para auxiliar na detecção e resolução de problemas.
- As despesas gerais indiretas do recurso foram informadas.
- O pessoal de administração sabe usar o recurso com eficiência.
- Um usuário mal-intencionado não pode:
- acessar o sistema.
- destruir dados importantes.
- consumir todos os recursos.
- Os requisitos de sistema são razoáveis e refletem restrições reais no domínio de problema; a especificação desses requisitos não é arbitrária.
- Existem estimativas de desempenho do sistema (modeladas conforme necessário
através de um Modelo de Análise de Carga de Trabalho) e elas indicam que os requisitos
de desempenho não são riscos significativos.
- As estimativas de desempenho do sistema foram validadas utilizando-se protótipos arquiteturais, principalmente para requisitos cruciais de desempenho.
- A capacidade de memória do aplicativo foi definida.
- Foram executadas ações para detectar e impedir problemas de memória.
- Há uma política aplicada de forma consistente para definir como o sistema de memória virtual é usado, monitorado e ajustado.
- O número real de linhas de código desenvolvidas corresponde ao número estimado de linhas de código no marco atual.
- As hipóteses de cálculo foram revisadas e continuam válidas.
- As estimativas de custo e cronograma foram recalculadas utilizando-se a experiência do projeto e o desempenho de produtividade mais atuais.
- Os requisitos de portabilidade foram atendidos.
- O Guia de Programação oferece diretrizes específicas sobre como criar um código portátil.
- O Guia de Design oferece diretrizes específicas sobre como projetar aplicativos portáteis.
- Uma 'porta de teste' foi criada para verificar as reivindicações de portabilidade.
- As medidas de qualidade (MTBF, número de defeitos pendentes,
etc.) foram atendidas.
- A arquitetura permite a recuperação em caso de erro irreversível ou falha do sistema.
- Os requisitos de segurança foram atendidos.
- As equipes estão bem-estruturadas?
As responsabilidades foram bem divididas entre as equipes?
- Existem questões políticas, organizacionais ou administrativas que restringem a eficiência das equipes?
- Existem conflitos de personalidade?
A seção Visualização de Casos de Uso do Documento de Arquitetura de Software:
- cada caso de uso é de forma arquitetural significativo, identificado como
tal porque:
- é de vital importância para o cliente
- motiva elementos-chave nas outras visualizações
- é um condutor para atenuar um ou mais riscos importantes, incluindo
qualquer requisito desafiador não-funcional.
- não há nenhum caso de uso cujas preocupações arquiteturais já
estejam abordadas por outro caso de uso
- os aspectos de forma arquitetural significativos do caso de uso são claros e
não se perdem em detalhes
- o caso de uso é claro e provavelmente não é alterado de maneira
que afete a arquitetura ou há um plano no local para como atingir tal
clareza e estabilidade
- nenhum caso de uso de forma arquitetural significativo foi perdido (pode requerer alguma análise dos casos de uso
não selecionados para esta visualização).
A seção Visão Lógica do Documento de Arquitetura de Software:
- apresenta de forma precisa e completa uma visão geral dos elementos do design que são significativos do ponto de vista da arquitetura.
- apresenta o conjunto completo de mecanismos de arquitetura utilizados no design e os fundamentos usados para selecioná-los.
- apresenta a divisão em camadas do design, junto com os fundamentos usados para dividir as camadas.
- apresenta quaisquer frameworks ou padrões utilizados no design, junto com os fundamentos usados para selecioná-los.
- O número de elementos do modelo que são significativos do ponto de vista da arquitetura é proporcional ao tamanho e ao escopo do sistema e seu tamanho ainda torna compreensíveis os principais conceitos em atividade no sistema.
Tópicos
- As condições de disputa em potencial (concorrência de processos para recursos críticos) foram identificadas e foram definidas estratégias de prevenção e resolução.
- Há uma estratégia definida para manipular condições "fila de E/S
cheia" ou "buffer cheio".
- O próprio sistema monitora seu desempenho (limite de capacidade, limite de desempenho crítico, exaustão de recursos) e é capaz de executar ações corretivas quando um problema é detectado.
- Os requisitos de tempo de resposta de cada mensagem foram identificados.
- Há um modo de diagnóstico do sistema que permite medir os tempos de resposta das mensagens.
- Os requisitos de desempenho nominal e máximo para operações importantes foram especificados.
- Há um conjunto de testes de desempenho capaz de avaliar se os requisitos de desempenho foram atendidos.
- Os testes de desempenho abordam o comportamento "extra-normal"
do sistema (inicialização e encerramento, fluxos de eventos alternativos e
excepcionais dos casos de uso, modos de falha do sistema).
- Foram identificadas as deficiências de arquitetura que geram possibilidades de gargalos de desempenho.
Foi dada ênfase específica:
- Ao uso de alguns recursos compartilhados finitos, incluindo, entre outros, semáforos, handles de arquivo, bloqueios, travas, memória compartilhada etc.
- À comunicação entre os processos.
A comunicação entre as fronteiras dos processos sempre é mais dispendiosa do que a comunicação dentro do processo.
- À comunicação entre os processadores.
A comunicação entre as fronteiras dos processos sempre é mais dispendiosa do que a comunicação entre os processos.
- Ao uso de memória física e virtual; no momento em que o sistema fica sem memória física e começa a usar a memória virtual, o desempenho costuma cair abruptamente.
- Quando há processos principais e de backup, foi considerada a possibilidade de existir mais de um processo que acredite ser o principal (ou a possibilidade de não existir um processo que acredite ser o principal) e ações de design específicas foram executadas para resolver o conflito.
- Há processos externos que restaurarão o sistema para um estado consistente quando um evento, como uma falha de processo, colocar o sistema em um estado inconsistente.
- Quando o sistema tem recursos de tolerância a erros e exceções, como quando ocorre um erro ou exceção, ele pode voltar para um estado consistente.
- Os testes de diagnóstico podem ser executados enquanto o sistema está em execução.
- Se necessário, o sistema pode ser atualizado (hardware, software) enquanto está em execução.
- Há uma política consistente para lidar com alarmes do sistema e a política foi aplicada de forma consistente.
A política de alarmes leva em consideração:
- a "sensibilidade" do mecanismo de relatório
de alarme;
- a prevenção de alarmes falsos ou redundantes;
- os requisitos de treinamento e interface de usuário do pessoal que utilizará o mecanismo de registro de alarmes.
- O impacto no desempenho (ciclos do processo, memória, etc.) do
mecanismo de relatório de alarme foi avaliado e está dentro dos limites de
desempenho aceitáveis, conforme estabelecido nos requisitos de desempenho.
- Os requisitos de carga de trabalho/desempenho foram analisados e atendidos.
Nas situações em que os requisitos de desempenho são impraticáveis, eles foram renegociados.
- A capacidade de memória, se houver, foi identificada e o software foi verificado para atender a esses requisitos.
Foram tomadas medidas para detectar e impedir problemas de memória.
- Existe uma política para uso do sistema de memória virtual que define inclusive como monitorar e ajustar o uso.
- Os processos são suficientemente independentes uns dos outros e, quando necessário, podem ser distribuídos entre processadores ou nós.
- Foram identificados os processos que devem permanecer no mesmo local (devido aos requisitos de desempenho e taxa de transferência ou ao mecanismo de comunicação entre os processos - por exemplo, semáforos ou memória compartilhada) e o impacto de impossibilidade de distribuição desta carga de trabalho foi levado em consideração.
- As mensagens que podem se tornar assíncronas, para que possam ser processadas quando houver mais recursos disponíveis, foram identificadas.
- Os requisitos de taxa de transferência foram atendidos mediante a distribuição do processamento entre os nós e as possibilidades de gargalos de desempenho foram consideradas.
- A integridade das informações é assegurada nas situações em que elas são distribuídas e possivelmente replicadas entre diversos nós.
- Foram atendidos os requisitos para o transporte confiável de mensagens, como, por exemplo, verificar se elas existem.
- Foram atendidos os requisitos para o transporte seguro de mensagens, como, por exemplo, verificar se elas existem.
- O processamento foi distribuído entre os nós para minimizar o tráfego de rede e o tempo de resposta, estando sujeitos a restrições de consistência e recursos.
- Os requisitos de disponibilidade do sistema, se houver, foram atendidos.
- O tempo máximo de inatividade do sistema, caso ocorra uma falha no servidor ou na rede, foi determinado e está dentro dos limites aceitáveis, conforme definido pelos requisitos.
- Servidores redundantes e de espera foram definidos de tal
forma que não é possível para mais de um servidor ser designado como
o servidor "principal".
- Todos os possíveis modos de falha foram documentados.
- As falhas na rede podem ser isoladas, diagnosticadas e resolvidas.
- A quantidade de "espaço livre" na utilização da CPU foi
identificada e o método de medida foi definido
- Há uma política definida para as ações a serem tomadas quando a capacidade de utilização máxima da CPU for atingida.
| |
|