8 de mar. de 2010

Capacidades da Arquitetura Ideal




Gostaria de abordar hoje sobre as capacidades que uma arquitetura bem planejada deve contemplar para proporcionar bons índices de qualidade. Este tema se torna extremamente importante se olharmos sob a ótica de que a qualidade afeta diretamente a satisfação do cliente e envolvidos com o sistema, sendo um ponto fundamental para o sucesso de um projeto de software.

Foram eleitas basicamente as seguintes 11 capacidades:

Disponibilidade

É a capacidade do sistema se manter no ar para uso devido. Diz-se que o sistema possui alta disponibilidade quando se mantém disponível a maior parte do tempo. Quando se contrata serviços de infra-estrutura, geralmente é acorda um percentual de disponibilidade que tal infra deve garantir, podendo pagar multas caso não cumpra o acordo, são as chamadas SLA's de disponibilidade.


 Robustez

É a característica pela qual se mede o nível de tolerância a falhas do sistema. O software deve ser capaz de prever situações inusitadas vindas de seus usuários e reagir com medidas que o mantenha estável, ou seja, sem apresentar falhas.


Gerenciabilidade

É a capacidade que mede o quão um sofware é configurável. A configuração dos níveis de logs gerados por um determinado software é um bom exemplo disso.


 Flexibilidade

Característica inerente à maneira em como um determinado software se comporta à mudanças, tanto arquiteturais quanto funcionais. Por exemplo, se um software hoje acessa uma base de dados Oracle, diz-se que ele é flexível caso seja possível mudá-lo para acessar uma base de dados SQL Server sem que para isso sejam necessárias grandes alterações em seu código-fonte.


 Desempenho

Esta característica está relacionada à utilização de recursos, como por exemplo, o tempo de processamento de uma grande quantidade de mensagens em uma fila JMS ou o tempo de processamento de uma consulta no banco de dados.


 Capacidade

Se refere às limitações impostas ao sistema, com o que o sistema deve suportar. Por exemplo: um sistema deve suportar 500 acessos simultâneos.


Resiliência

Este nome um tanto quanto "exótico" se refere ao grau de estabilidade do sistema mediante a picos de processamentos. Exemplo: um determinado sistema tem que suportar uma carga durante 3 horas e depois voltar ao seu estado normal sem sofrer quedas ou gerar defeitos.


Escalabilidade

É a capacidade de um determinado sistema ser flexível a ponto de prever o seu crescimento, ou seja, possbilita o seu incremento de funcionalidade e capacidades sem se tornar obsoleto, acompanhando sempre as necessidades do usuário.


Extensibilidade

É a capacidade que o sistema tem de crescer pela adição de novos componentes e que, muitas vezes, permita ao sistema fazer algo que ele já faz, mas de forma diferente. O polimorfismo em classes é um bom exemplo de extensibilidade em sistemas orientados a objetos, sendo possível através do uso de programação para interfaces e  nunca para classes com implementação concreta.


 Reusabilidade

Permite que um determinado sistema seja usado em contextos diferentes, ou então, que seus componentes sejam usados também em outras aplicações. Este tipo de reusabilidade de componentes facilita muito o desenvolvimento de aplicações corporativas, pois, proporciona uma maior facilidade de manutenção e ganho na produtividade do software.


Segurança

É a característica que permite avaliar o quanto um sistema é protegido, dadas as suas condições de exposição, contra ataques ou falhas internas ou externas que gerem inconsistências em suas informações ou outros tipos de defeitos, compromentendo a todas as outras capacidades aqui citadas. 
Um bom sistema deve prover condições de segurança nos quisitos autenticidade,  confidencialidade,  integridade e disponibilidade.

 

Fico por aqui pessoal. Para qualquer dúvida ou complemento das informações aqui postadas, não deixem de postar os seus comentários.   ;)

Um grande abraço e até o próximo post!

.

3 comentários:

  1. Negrão,
    Do ponto de vista de requisitos, esses são os requisitos não funcionais do sistema. É interessante que cada um deles seja mensurável
    para que se possa comprovar seu atendimento ao final do desenvolvimento. Agregando ao seu exemplo do quesito "desempenho", uma maneira interessante de descrever o requisito não funcional seria: "o sistema deve processar uma fila JMS de 3000 mensagens em no máximo 1 minuto". Desta forma você garante que o requisito é "verificável" ou "mensurável".

    Abs,

    Alfraino.

    ResponderExcluir
  2. Olá Alfraino!

    Obrigado pelo seu rico comentário, realmente é bem pertinente ao assunto.

    O ponto de vista que procurei abordar aqui, foi o aquitetural, no qual os requisitos não-funcionais também podem ser chamados de capacidades, já que se tratam de questões em que o arquiteto deve se atentar para fazer com que o sistema seja capaz de atendê-las.

    A questão de traduzir os requisitos em números, ou outra coisa que o represente de maneira concreta, é um fato muito importante, para que o requisito seja testável ou mensurável como você mesmo citou. Geralmente a elaboração descritiva do que a aplicação deve atender é feita na fase de elaboração do projeto, na qual já se define o escopo do sistema em termos de requisitos funcionais e também os não-funcionais. Após esta fase, temos a de projeto, na qual o arquiteto se baseia em tais definições para elaborar a arquitetura do sistema.

    :)

    Abraços!

    Eduardo Negrão.

    ResponderExcluir
  3. Cara parabens pelo seu blog esta me ajundando muito.

    ResponderExcluir