Skip to content Skip to navigation

Connexions

You are here: Home » Content » Atributos de Qualidade

Navigation

Recently Viewed

This feature requires Javascript to be enabled.
 

Atributos de Qualidade

Module by: Guilherme Germoglio. E-mail the author

Summary: Sobre a importância e influência dos atributos de qualidade no projeto da Arquitetura de Software.

Um software tem como objetivo atender aos seus requisitos funcionais e não-funcionais. Os requisitos funcionais descrevem as funções que o software deve ser capaz de realizar, ou seja, o que o sistema faz. Já os requisitos não-funcionais descrevem as qualidades e restrições de como o sistema realiza suas funções, ou seja, como o sistema funciona. Um software, portanto, deve exibir atributos de qualidade que atendam aos seus requisitos.

Por sua vez, a arquitetura de software contém a descrição de como esse alcança aos atributos de qualidade. Essa descrição de como o software atende aos requisitos não-funcionais é feita pelas diversas decisões presentes na arquitetura. Para conceber essas decisões arquiteturais – e, portanto, para projetar a arquitetura – é de fundamental importância que o arquiteto conheça tanto os objetivos a serem alcançados pelo software, quanto as ferramentas para alcançá-los. Em outra palavras, é essencial que ele conheça tanto os atributos de qualidade, quanto técnicas e padrões de design arquitetural que, ao serem implementados, possibilitam ao software que exiba os atributos de qualidade desejados.

Considerando a importância dos atributos de qualidade de software, dedicamos dois capítulos a eles. Neste capítulo, mostramos uma visão geral do assunto, abordando diversos atributos que devem ser alcançados. Este capítulo tem como objetivos:

  • Identificar o que são atributos de qualidade e qual é sua influência na arquitetura de software;
  • Relacionar atributos de qualidade a decisões arquiteturais que os proporcionam;
  • Entender que os atributos de qualidade se relacionam e como eles se relacionam.

No capítulo seguinte, apresentamos técnicas de design arquitetural e uma série de estudos de como alguns atributos foram alcançados na prática em diferentes sistemas de software. Esses estudos mostram que técnicas e padrões de design arquitetural foram aplicados para alcançar tais atributos e quais seus benefícios e limitações apresentados.

Requisitos Funcionais e Não-Funcionais

O único objetivo de um software é o de atender a seus requisitos. Esses requisitos são definidos ao longo de seu ciclo desenvolvimento e costumam ser classificados em requisitos funcionais e requisitos não-funcionais.

Os requisitos funcionais descrevem as funções que o sistema é capaz de realizar, ou seja, descrevem o que o sistema faz.

Definição 1: requisito funcional
É a declaração de uma função ou comportamento providos pelo sistema sob condições específicas.

Os requisitos do software são impostos pelos seus diversos stakeholders. No entanto, os requisitos funcionais costumam ser ditados pelos clientes do software, afinal são eles que esperam ter seus problemas resolvidos pelas funcionalidades do software.

Exemplo 1

Se estamos falando do SASF, entre suas funções, podemos citar:

  • (RF-01): O usuário deve ser capaz de inserir um filme da sua lista de aluguéis;
  • (RF-03): O usuário deve ser capaz de assistir a um filme via streaming;
  • (RF-06): O usuário deve ser capaz de adicionar um comentário sobre um filme.

Se o problema de desenvolver software fosse apenas o de atender aos requisitos funcionais, desenvolver software já poderia ser considerado uma tarefa difícil. Isso porque, para serem atendidos, muitos dos requisitos funcionais necessitam de conhecimento que ultrapassa os limites da Engenharia de Software, da Ciência da Computação ou mesmo da Matemática. Afinal, para se implementar sistemas para Computer-Aided Design (CAD) ou sistemas que analisam os dados extraídos do Large Hadron Collider (LHC) 1 é preciso grande conhecimento específico ao domínio do problema, ou seja, grande conhecimento de outras engenharias ( por ex., Engenharia Mecânica e Civil) ou de outras ciências ( por ex., Física e Química), respectivamente.

Além da necessidade de conhecimento específico ao domínio do problema, há outra dificuldade no desenvolvimento de software para atender apenas aos requisitos funcionais: o cliente pode não ter certeza sobre o que ele quer do software. Esta condição é bem conhecida pela Engenharia de Requisitos, que nos provê algumas técnicas para resolvê-la ou contorná-la. Mas isso não quer dizer que não possa se tornar um problema durante o ciclo desenvolvimento. Afinal, se o principal interessado não sabe bem quais funções se espera que o sistema realize, não podemos afirmar que será fácil desenvolver esse sistema.

Por outro lado, há também os requisitos não-funcionais. Esses estão relacionados à qualidade da realização dos requisitos funcionais, ou seja, como essas funções são realizadas.

Definição 2: requisito não-funcional
É a descrição de propriedades, características ou restrições que o software apresenta exibidas por suas funcionalidades.

Esses requisitos também são impostos pelos diversos stakeholders do software e estão normalmente relacionados a interfaces com o usuário, capacidades, consumo de recursos e escalas de tempo.

Exemplo 2

Podemos citar alguns exemplos de requisitos não-funcionais do SASF:

  • (RNF-01): O sistema deve permitir o uso por diversas interfaces diferentes: navegador de internet, celular, TV (usando um decodificador de TV por assinatura compatível) e aplicação-cliente compatível com as famílias de sistemas operacionais Windows, Mac OS e Linux;
  • (RNF-04): O sistema deve suportar até 3 milhões de inserções na fila de aluguéis por dia (34,7 operações por segundo);
  • (RNF-09): Uma transmissão de vídeo via streaming não pode ser iniciada em mais do que 30 segundos.

As restrições feitas pelos requisitos não-funcionais são várias e podem incluir restrições ao processo de desenvolvimento, restrições para atingir ou manter compatibilidade, e restrições legais, econômicas ou de interoperabilidade. As restrições ao processo de desenvolvimento podem ser feitas pela imposição de padrões de desenvolvimento ou mesmo de linguagens a serem utilizadas pelo sistema. Por exemplo, um requisito não-funcional de um sistema pode ser que ele deva ser implementado usando a linguagem Java™, uma vez que a equipe responsável pela operação e manutenção após seu desenvolvimento seja é experiente nessa linguagem. Por fim, podemos ainda citar requisitos não-funcionais conhecidos que foram impostos em prol de compatibilidade e interoperabilidade e – por que não dizer – de questões econômicas, que é um caso relacionado ao sistema operacional Windows NT. O Windows NT possui requisitos não-funcionais que ditam que ele deve ser capaz de executar aplicativos originalmente escritos para DOS, OS/2, versões anteriores do Windows e aplicativos de acordo com o padrão POSIX 2. Assim, satisfazendo aos requisitos de poder executar aplicativos originalmente escritos para sistemas operacionais anteriores, o Windows NT teria um custo de adoção mais baixo, uma vez as empresas não precisariam renovar seu ecossistema de aplicativos para poder usá-lo. Já o requisito de aderência ao padrão POSIX se mostra necessário para eventuais contratos com cláusulas do tipo: “o sistema operacional a ser utilizado deve estar de acordo com o padrão POSIX”.

Os requisitos não-funcionais podem ainda ser divididos em três tipos: de produto, de processo e externos. Os requisitos não-funcionais de produto podem, à primeira vista, nos parecer os únicos que deveríamos estudar. Isso se dá por eles estarem diretamente relacionados à qualidade do software e serem definidos como os requisitos que especificam as características que o software deve possuir. No entanto, devemos lembrar que a arquitetura de software não influencia apenas a qualidade final do software, mas também influencia (e é influenciada pela) a forma com que ele é desenvolvido e até mesmo a organização em que ela está inserida.

Definição 3: requisito não-funcional de produto
Requisito que especifica as características que um sistema ou subsistema deve possuir.

Os requisitos não-funcionais de produto, como já dito anteriormente, são relacionados à qualidade do software e são alcançados pelo que chamamos de atributos de qualidade. Portanto, quando existem requisitos em que o software deve ter algum grau de confiabilidade, certo nível de eficiência, ou ser portável para diversos sistemas operacionais, estamos descrevendo quais atributos de qualidade que o software deve exibir. Todos requisitos presentes no Exemplo 2 podem ser classificados como sendo de produto. Ainda retornaremos a esse assunto neste capítulo, mas antes devemos mostrar os outros tipos de requisitos não funcionais.

Os requisitos não-funcionais de processo são definidos como as restrições ao processo de desenvolvimento.

Definição 4: requisito não-funcional de processo
Requisito que restringe o processo de desenvolvimento do software.

Esse tipo de requisito é encontrado em muitas situações, principalmente em grandes empresas ou organizações. Por exemplo, é comum que o desenvolvimento de sistemas de software para o Exército Americano tenham como requisito ter o processo de desenvolvimento de acordo com a Joint Technical Architecture 3

Por fim, há os requisitos não-funcionais externos. Esses, muitas vezes, podem se classificar tanto como de produto quanto de processo e são extraídos do ambiente em que o sistema é desenvolvido. Esse ambiente pode ser tanto a organização, com políticas que devem ser seguidas ou seu atual ecossistema de software com o qual ele deve interoperar, quanto a legislação vigente do país em que o sistema está operando.

Definição 5: requisito não-funcional externo
Requisito derivado do ambiente em que o sistema é desenvolvido, que pode ser tanto do produto quanto do processo.

Por fim, como exemplo de requisitos externos, podemos citar:

Exemplo 3

O sistema de recomendação de livros deve ler as informações do sistema de aluguel de livros de uma biblioteca, onde cada registro de livro está de acordo com o padrão Dublin Core. Um requisito não-funcional externo desse sistema de recomendação é:

  • (RNF-01): O sistema deve guardar os dados dos livros recomendados em um modelo mapeável para o modelo de dados definido pelo padrão Dublin Core [16].

Note que o uso do Dublin Core só é realmente necessário porque a comunicação entre os dois sistemas é esperada e que um sistema já adota esse padrão.

Diferenças entre requisitos funcionais e não-funcionais

Apesar da classificação dos requisitos de software em requisitos funcionais e não-funcionais ser bem aceita, devemos observar que na prática essa divisão pode não ser tão clara. Isso ocorre devido ao nível de detalhes contido em sua descrição ou mesmo devido ao tipo de sistema desenvolvido.

Podemos ilustrar o caso em que o nível de detalhes faz a diferença com o seguinte exemplo:

Exemplo 4

Se considerarmos um requisito de segurança de confidencialidade (e normalmente considerado não-funcional):

  • (RNF-01): O sistema deve possibilitar o envio de mensagens de modo que não possam ser lidas a não ser pelos destinatários.

Uma vez que não especifica nenhuma funcionalidade, esse pode ser considerado um requisito não-funcional. Por outro lado, poderíamos deixar essa evidente característica de requisito não-funcional um pouco mais turva se adicionarmos um pouco mais de detalhes a ele:

  • (RF-01): O sistema deve permitir aos usuários que criptografem suas mensagens usando as chaves públicas dos destinatários.

Agora, esse requisito seria melhor classificado como funcional, uma vez que especifica uma função do sistema, apesar do atributo de qualidade exibido pelo software ao final do desenvolvimento será o mesmo: segurança, mais especificamente confidencialidade das mensagens enviadas.

Já quando mencionamos que o tipo do sistema pode influenciar em como classificamos um requisito, basta apenas lembrarmos dos sistemas de tempo-real. Neles, a corretude do comportamento do sistema não depende só do resultado lógico da função, mas também quando esse resultado é obtido. Portanto, uma resposta cedo ou tarde demais pode estar tão incorreta quanto uma resposta logicamente errada.

Exemplo 5

Em um sistema de informação, consideramos o requisito não-funcional:

  • (RNF-01): A busca por nome deve retornar os resultados em no máximo 100 milissegundos.

Já em um sistema de controle de voo fly-by-wire, devemos considerar o requisito a seguir como funcional, uma vez que respostas que não respeitam o intervalo de tempo especificado são tão inúteis quanto a falta de resposta dos sensores (podem causar a queda do avião):

  • (RF-01): Novas amostras de dados dos sensores da aeronave devem ser obtidas a cada 20 milissegundos.

Apesar disso, vale notar que ambos os requisitos presentes no Exemplo 5 ditam que tanto o sistema de informação quanto o sistema fly-by-wire devem exibir o atributo de qualidade desempenho, mesmo que em graus diferentes.

Conflitos entre requisitos

Como requisitos de software têm impacto em um ou mais atributos de qualidade, pode acontecer de impactarem em atributos relacionados a outros requisitos. Quando isso ocorre, o impacto pode resultar em reforço do atributo ou em conflito.

Podemos perceber que não surgem grandes problemas quando dois ou mais requisitos reforçam o mesmo atributo de qualidade. Afinal, caso isso ocorra, o design da solução que atenda a um dos requisitos afetará apenas positivamente o design da solução que atenda aos outros requisitos.

Apesar do caso de requisitos que se reforçam não ser muito comum, podemos ilustrá-lo com requisitos que afetam à segurança do software, mais precisamente autenticidade e confidencialidade:

Exemplo 6

Se temos um sistema de mensagens instantâneas com os seguintes requisitos:

  • (RNF-01): O sistema deve prover meios de autenticar os seus usuários.
  • (RNF-02): Uma mensagem enviada a um usuário não pode ser lida a não ser pelo destinatário.

Podemos observar que os requisitos RNF-01 e RNF-02 se relacionam, uma vez que afetam a alguns aspectos de segurança do sistema. Eles se reforçam visto que é possível encontrarmos uma solução para RNF-01 que facilite RNF-02 e vice-versa. A solução no caso é a utilização criptografia de chave pública: tanto ela pode ser usada para autenticação de usuários quanto pode ser usada para encriptação de mensagens.

Por outro lado, requisitos conflitantes são mais comuns e adicionam dificuldade durante o design das soluções. Isso ocorre porque a solução para um requisito conflitante afeta negativamente outro requisito. Assim, o design do software terá que considerar diversos trade-offs a fim satisfazer melhor aos requisitos mais importantes, já que atender a todos de forma ótima não é possível.

Se adicionamos alguns requisitos de usabilidade ao Exemplo 6, esses novos requisitos certamente afetarão negativamente à solução apresentada. Isso ocorre porque é comum que soluções de segurança afetem aos requisitos de usabilidade, visto que essas soluções adicionam conceitos não familiares aos usuários (por exemplo, chaves criptográficas) ou adicionam mais passos para que os usuários realizem suas tarefas (por exemplo, inserir login e senha).

Expressando requisitos não-funcionais

Grande parte do trabalho de um arquiteto consiste em projetar sistemas que devem satisfazer requisitos não-funcionais. No entanto, a Engenharia de Requisitos é limitada quanto a métodos de análise e derivação de requisitos não-funcionais. Essa limitação, muitas vezes, obriga ao arquiteto a trabalhar com requisitos que carecem de métricas e valores-alvo. Isso dificulta o processo de design, uma vez que desconhecer requisitos é o mesmo que desconhecer os objetivos do design. Por este motivo, recomenda-se aos arquitetos que sempre busquem por requisitos que possuam valores e métricas bem definidos e, desta maneira, conheçam e possam medir os objetivos e o sucesso de seu design.

Todavia, nem sempre é possível trabalhar com requisitos bem definidos, uma vez que encontramos alguns problemas ao expressá-los. Os principais motivos da dificuldade de expressar requisitos não-funcionais são os seguintes:

  • Alguns requisitos simplesmente não são conhecidos em etapas iniciais do ciclo de desenvolvimento. Por exemplo, a tolerância a faltas ou o tempo de recuperação pode ser muito dependente da solução de design.
  • Alguns requisitos, como alguns relacionados à usabilidade, são muito subjetivos, dificultando bastante a medição e o estabelecimento de valores-alvo.
  • E, por fim, há os conflitos entre requisitos. Como já foi apresentado, requisitos podem influenciar atributos de qualidade comuns ou relacionados, até fazendo com que requisitos sejam contraditórios.

Mesmo sendo difícil lidar com os requisitos não-funcionais, é obrigação do arquiteto projetar o software de modo que, ao fim do desenvolvimento, este exiba os atributos de qualidade esperados pelos stakeholders.

Atributos de qualidade

Apesar de afirmarmos que o software possui requisitos não-funcionais 4 a serem atendidos, é comum dizermos que o software exibe atributos de qualidade que atendem aos requisitos em questão. Portanto, atributos de qualidade estão mais relacionados aos objetivos já alcançados, enquanto requisitos são os objetivos propostos.

Podemos chamar de atributos de qualidade do software suas propriedades externamente visíveis. Essas propriedades podem se manifestar como:

  • capacidades ou restrições de suas funções. Por exemplo, tempo de resposta de uma determinada função ou capacidade de execução de certa quantidade de chamadas simultâneas;
  • características não diretamente relacionadas às suas funções. Por exemplo, usabilidade ou adoção de padrões para interoperabilidade; ou ainda
  • características relacionadas ao ciclo de desenvolvimento. Por exemplo, testabilidade ou mesmo a capacidade de facilitar o desenvolvimento por múltiplos times geograficamente distribuídos.

Definição 6: atributo de qualidade
É uma propriedade de qualidade do software ou de seu ciclo de desenvolvimento, podendo se manifestar como características, capacidades ou restrições de uma função específica ou de um conjunto de funções do software.

Podemos perceber a importância dos atributos de qualidade, em especial, quando comparamos dois produtos de software que têm as mesmas funcionalidades, como fazemos no exemplo a seguir:

Exemplo 7

Vamos considerar um projeto para construção de sistemas de buscas de sites web chamado Hounder 5. Para deixarmos nosso exemplo ainda mais significativo em termos de diferenças entre atributos de qualidade, vamos considerar um sistema construído usando o Hounder, mas em que todos os seus módulos executam em apenas um servidor. Vamos chamar esse serviço de busca de HSearch 6.

Uma vez que o Google Web Search 7 também é um serviço de busca de web sites, podemos afirmar que ambos os serviços têm o principal requisito funcional em comum:

  • (RF-01): O sistema deve retornar endereços de web sites que se relacionem às palavras-chave inseridas pelo usuário.

Já que ambos os serviços funcionam, percebemos que ambos atendem ao requisito (RF-01), o que poderia significar algum grau de equivalência entre os serviços. No entanto, se compararmos como ambos os sistemas atendem a esse requisito, perceberemos que eles são bem diferentes, justamente pela diferença entre os atributos de qualidade que exibem.

Para funcionar, um serviço de busca de web sites deve executar basicamente três atividades: (a) crawling, que é a coleta de páginas que servirão de resultados, (b) indexação, que é a organização da informação obtida na atividade de crawling de forma que facilite a busca (principalmente em termos de desempenho), e (c) busca, cujo resultado é a realização do requisito RF-01. Note que as três atividades são I/O bound, ou seja, as atividades têm uso intensivo de entrada e saída. Portanto, elas têm seu desempenho limitado pela capacidade de entrada e saída dos recursos computacionais em que executam.

Se compararmos as capacidades de ambos os sistemas, o HSearch está limitado à capacidade do único computador em que está executando. Isso significa que ele executa as três atividades usando o mesmo recurso. Por outro lado, é bem conhecido que a arquitetura do Google Web Search permite que o sistema utilize diversos data centers ao redor do mundo, usando muitos milhares de processadores simultâneos e, assim, podendo dividir a execução das três atividades entre esses recursos. Por essa diferença de utilização de recursos, algumas métricas de vários atributos de qualidade, como tempo de resposta, capacidade de atender a buscas simultâneas, tamanho do índice de busca ou tolerância a falhas de hardware serão bem diferentes entre os dois sistemas.

Quando comparamos as bilhões de consultas diárias que o Google Web Search é capaz de realizar com as apenas milhares ou poucos milhões do HSearch, dizemos que o desempenho do primeiro é melhor. Mas o desempenho não é diferente apenas em termos de operações por unidade de tempo, mas também quando comparamos os tempos de resposta para cada operação ou número de usuários simultâneos no sistema. Se considerarmos que o Google Web Search realiza um bilhão de buscas por dia e cada busca dura em torno de 300 milissegundos, pela Lei de Little [12], temos cerca de 3500 buscas simultâneas a qualquer momento ao longo da vida do sistema. Já o HSearch só consegue realizar 3,5 buscas simultâneas ao realizar 1 milhão de buscas por dia a 300 milissegundos cada.

Mas há outros atributos que podem ser mencionados. O HSearch é dependente do funcionamento de um único servidor. Portanto, se esse servidor falhar, todo o sistema ficará fora do ar. Já o Google Web Search é capaz de tolerar falhas de hardware, uma vez que não depende de apenas um servidor para funcionar. Assim, podemos dizer que o grau de confiabilidade ou tolerância a falhas do Google Web Search é maior que o do HSearch. As respostas do HSearch são formadas apenas pelo título e pequenos trechos dos web sites que contêm as palavras-chave. Já o Google Web Search ajuda ao usuário também mostrando imagens contidas no site ou mesmo trechos de vídeo, contribuindo assim para sua usabilidade. Por fim, citamos também que o Google Web Search apresenta o atributo de integrabilidade, dado que ele contém diversos serviços além da busca numa mesma interface: entre eles calculadora, previsão do tempo, conversão de medidas, definição de palavras, busca de sinônimos, entre outros.

É a arquitetura que permite que o software exiba os atributos de qualidade especificados. Já que a especificação dos atributos é feita pelos requisitos (normalmente não-funcionais), requisitos e atributos de qualidade partilham diversas características. Tanto que alguns autores usam ambas as expressões com o mesmo sentido.

As principais características dos atributos de qualidade são as seguintes:

  • Atributos de qualidade impõem limites às funcionalidades;
  • Atributos de qualidade se relacionam entre si; e
  • Atributos de qualidade podem tanto ser de interesse dos usuários quanto dos desenvolvedores.

Limites às funcionalidades

Os limites às funcionalidades acontecem da mesma forma que os requisitos podem restringir ou mesmo impedir funcionalidades, pois atributos de qualidade não se manifestam isolados no ciclo de vida do software, mas influenciam e são influenciados pelo meio. Por exemplo, para que o SASF tenha um time to market pequeno, ele deve ser lançado inicialmente sem possuir um cliente de streaming para dispositivos móveis, deixando para implementar essa funcionalidade em outras versões. Isso é uma limitação na funcionalidade de transmissão de filmes em benefício do atributo de qualidade custo e planejamento. É também bastante comum encontrarmos sistemas que têm funcionalidades podadas simplesmente porque, se estas existissem, o software não exibiria os atributos de segurança esperados.

Relações entre atributos de qualidade

Como já foi observado, os atributos não existem isoladamente e, por afetarem partes em comum da arquitetura, afetam também outros atributos de qualidade. Eis que surgem os trade-offs entre os atributos de qualidade. Por exemplo, um sistema mais portável terá seu desempenho afetado negativamente, pois necessita de mais camadas de software que abstraiam o ambiente que pode ser mudado. Já no caso do SASF, para se obter um nível de segurança capaz de realizar autorização e autenticação, a usabilidade do software é prejudicada, uma vez que o usuário deve ser obrigado de lembrar sua senha ou mesmo ter o fluxo de ações interrompido para que insira suas credenciais.

É papel do arquiteto conhecer e resolver os trade-offs entre os atributos de qualidade durante as fases de design e implementação. Por isso, ao apresentar algumas técnicas para alcance da qualidade, apresentaremos também quais atributos são influenciados positiva e negativamente.

A quem interessa os atributos de qualidade

Uma grande gama de atributos podem ser citados. Tanto que, a seguir, quando apresentamos uma lista deles, restringiremo-nos a apenas um modelo de qualidade. Esses atributos podem interessar a vários envolvidos no ciclo de vida do software, como usuários e desenvolvedores. Dos exemplos citados anteriormente, podemos dizer que desempenho e usabilidade são atributos importantes a usuários, enquanto custo e planejamento são mais importantes aos desenvolvedores.

Modelo de Qualidade

Para avaliar a qualidade de um software, o ideal seria usar todos os atributos de qualidade que conhecemos. No entanto, é inviável adotar esta abordagem em um processo de desenvolvimento que possua tempo e dinheiro finitos devido à grande quantidade de dimensões 8 do software que poderíamos avaliar. Para facilitar o processo de avaliação durante o desenvolvimento, foram desenvolvidos o que chamamos de modelos de qualidade. Modelos de qualidade têm como objetivo facilitar a avaliação do software, organizando e definindo quais atributos de qualidade são importantes para atestar a qualidade geral do software. Alguns exemplos significativos de modelos de qualidade são os de Boehm [1], o de McCall [14] e o contido no padrão ISO/IEC 9126-1:2001 [8]. Vamos descrever melhor este último, para assim termos uma melhor noção de quais atributos de qualidade procuramos que a arquitetura permita ao software.

Definição 7: modelo de qualidade
Modelo que define e organiza os atributos do software importantes para a avaliação de sua qualidade.

Padrão ISO/IEC 9126-1:2001

Ele é um padrão internacional para avaliação de software. O que nos interessa dele é o conteúdo de sua primeira parte, que é o que é chamado de qualidades internas e externas do software. Essas qualidades são apresentadas na forma de uma lista exaustiva de características ou atributos de qualidade. Os atributos que um software deve possuir para que possamos dizer que ele é de qualidade são os seguintes:

  • Funcionalidade
  • Confiabilidade
  • Usabilidade
  • Eficiência
  • Manutenibilidade
  • Portabilidade

É importante enfatizar que essa lista tem como objetivo ser exaustiva. Portanto, de acordo com a norma, todas as qualidades que venham a ser requisitadas ao software estão presentes nessa lista. No padrão, cada característica é ainda quebrada em subcaracterísticas, que são mais específicas, a fim de facilitar o entendimento e a avaliação. A seguir, definimos cada atributo de qualidade e mostramos algumas subcaracterísticas mais importantes ao atributo.

Funcionalidade

Funcionalidade é a capacidade do software de realizar as funções que foram especificadas. Esse primeiro atributo pode parecer óbvio, mas seu propósito é claro quando passamos a avaliar um sistema de software: se esse sistema faz menos que o mínimo que é esperado dele, ele não serve, mesmo que o (pouco) que ele faça, ele faça de forma usável e confiável ou eficientemente.

Para caracterizarmos melhor a funcionalidade do software, devemos ainda considerar as características de:

  • adequação, ou capacidade de prover as funções necessárias para os objetivos dos usuários. Podemos observar que a métrica deste atributo de qualidade é a satisfação ou não dos requisitos funcionais do sistema.
    Exemplo 8

    Para se adequar às necessidades de seus usuários, basta que o SASF atenda a seus requisitos funcionais. Se ele realizar a locação e a transmissão de filmes, ele está adequado às necessidades de seus usuários comuns. Por outro lado, para se adequar às necessidades dos usuários que distribuem os filmes, uma das funções que ele deve prover é a função de upload de filmes.

  • precisão, ou capacidade de prover os resultados com o grau de precisão adequado. Para que seja possível medir a precisão, é necessário que ela esteja especificada – possivelmente no documento de requisitos.
    Exemplo 9

    Podemos observar diferentes necessidades de precisão quando comparamos como os números são tratados em um sistema de software bancário e numa calculadora. No primeiro, os números são tratados apenas como racionais e truncados na quantidade de casas decimais relativa à moeda do país. No Brasil, por exemplo, o software bancário só reconhece até centavos de Real. Portanto, se é necessário dividir R$ 1,00 em três parcelas, cada parcela não será representada pela dízima R$ 0,33333..., mas sim por R$ 0,34. Essa mesma precisão não poderia ser adotada em um software de calculadora. Nesse, sendo uma calculadora comum, é esperado que os números seja representados da forma mais próxima aos números reais 9.

  • interoperabilidade, ou capacidade de interagir com outros sistemas. Para medir o grau de interoperabilidade, o ideal é que esteja especificado quais sistemas devem interagir. Já para facilitar a satisfação desse atributo, a solução mais utilizada é a adoção de padrões de facto. Alguns tipos de padrões são os de representação de dados, como o Dublin Core ou formatos de arquivos de vídeo, ou padrões de especificação de funcionalidades, como os padrões WS-*. 10
    Exemplo 10

    É uma qualidade do SASF ser capaz de interagir com diversos sistemas capazes de reproduzir o vídeo transmitido. Para isso, foi escolhido o padrão para transmissão de vídeo amplamente adotado entre sistemas.

  • segurança, ou capacidade de funcionar segundo os princípios de autenticação, autorização, integridade e não-repudiação. Autenticação é a capacidade de o sistema verificar a identidade de usuários ou de outros sistemas com que se comunica. Autorização é a capacidade de garantir ou negar direitos de uso a recursos a usuários autenticados. Integridade é a capacidade de garantir que os dados não foram alterados indevidamente, principalmente durante a comunicação. E não-repudiação é a capacidade de prover meios para a realização de auditoria no sistema. No entanto, é importante observar que nem todos os sistemas precisam estar de acordo com todos os princípios.
    Exemplo 11

    Uma vez que recebe o número do cartão do usuário para receber o pagamento, o SASF deve garantir que apenas o sistema de cobrança da operadora de cartão de crédito seja capaz de verificar as informações necessárias para a autorização. Outro aspecto de segurança do SASF é que ele precisa diferenciar os usuários que ainda não estão registrados (e, consequentemente, que não pagaram a assinatura), dos já registrados. Para isso, ele deve realizar a autenticação do usuário.

  • estar de acordo com padrões, ou a capacidade de aderir a normas, convenções ou leis relacionadas à funcionalidade.
    Exemplo 12

    Para ser executado no Brasil, o SASF é obrigado por lei a emitir o cupom fiscal do pagamento da assinatura do usuário.

Confiabilidade

Quando afirmamos que um sistema é confiável, estamos afirmando que esse sistema é capaz de manter algum nível de desempenho quando funcionando sob circustâncias determinadas. A confiabilidade é normalmente definida sob períodos de tempo. Ou seja, dizer apenas que o SASF deve ser confiável não é suficiente. Temos, por exemplo, que dizer que o SASF é capaz de transmitir vídeos para 6 mil usuários simultâneos sob condições normais durante 99% do ano e para mil usuários simultâneos durante o 1% do ano reservado para o período de manutenção dos servidores. Vale observar que, para uma loja online, faz mais sentido que a medida de confiabilidade seja a de servir aos seus usuários com o tempo de espera das operações de compra e busca de 50 milissegundos durante períodos normais do ano, mas, durante as semanas próximas ao Natal, ter o tempo de espera das mesmas operações em torno dos 150 milissegundos, uma vez que o número de usuários simultâneos nessa época do ano aumenta consideravelmente.

A confiabilidade pode ainda ser dividida nas seguintes características:

  • maturidade, ou capacidade de se prevenir de falhas resultantes de faltas de software. Isso é comum em sistemas distribuídos, onde um componente não confia completamente no resultado provido por outro. Isso pode ser verificado em sistemas com sensores de software, onde um módulo pode ser responsável por julgar os valores gerados pelos sensores. Caso os valores sejam julgados inválidos, o módulo pode simplesmente desligar o sensor defeituoso. A medição do grau de maturidade de um sistema é bem difícil, mas podemos ter uma noção ao analisarmos decisões que foram feitas com este objetivo.
    Exemplo 13

    No caso do SASF, o módulo de transmissão de vídeo pode verificar quantas conexões estão abertas para um mesmo destinatário. Uma grande quantidade de conexões para um mesmo destinatário pode significar um ataque ou mesmo um bug no reprodutor de vídeo no lado do cliente que, eventualmente, pode consumir todos os recursos disponíveis para streaming. Assim, ao detectar esse problema, o SASF pode recusar abrir novas conexões para esse cliente, prevenindo-se de um problema maior, como uma completa parada por DoS 11

  • tolerância a faltas, ou capacidade de manter alguma qualidade de serviço em caso de faltas de software ou comportamento imprevisto de usuários, software ou hardware. Em outras palavras, a medida de funcionamento do software, mesmo que de forma restrita, em caso de a parada de servidores, partições de rede, falhas de discos rígidos, inserção ou leitura de dados corrompidos, etc. Considerando a grande quantidade de eventos que o software deve tolerar, também são muitas as formas de medir o grau de satisfação a este atributo de qualidade. As formas mais comuns são: medir se o serviço continua funcionando em caso de falha de n servidores, medir qual a variação no tempo de resposta para as operações mais comuns ou quantos usuários simultâneos o sistema é capaz de servir em caso de falhas de servidores ou ainda verificar como o sistema se comporta se dados inválidos são inseridos no sistema.
    Exemplo 14

    A forma mais comum de melhorar o grau de tolerância a faltas em um serviço web é fazer com que não dependa de um único recurso. Seja esse recurso hardware, como um único processador, roteador ou disco rígido, seja esse recurso software, como depender de um único banco de dados, um único serviço de cadastro ou um único serviço de inventário. Assim, o SASF possui seus módulos replicados em diferentes servidores. Desta maneira, ele evita a dependência de um único recurso, ou o chamado ponto único de falhas e pode continuar a funcionar mesmo que um desses módulos pare por completo. Note que para a replicação funcionar, devem ser adicionados à arquitetura módulos responsáveis pela verificação de estado dos servidores e, assim que forem detectados problemas em algum servidor, o tráfego possa ser redirecionado para réplicas sadias. Para isso ser possível, há ainda outras complicações, como a manutenção da consistência de estado entre o servidor original e sua réplica. Falaremos mais sobre a eliminação do ponto único de falhas quanto estivermos tratando das diversas técnicas para a obtenção de atributos de qualidade.

  • recuperabilidade, também chamada de resiliência, é a capacidade de o sistema voltar ao nível de desempenho anterior a falhas ou comportamento imprevisto de usuários, software ou hardware e recuperar os dados afetados, caso existam. É comum medirmos o grau de recuperabilidade ao medirmos quanto tempo o sistema leva para voltar aos níveis normais de desempenho. Quanto menor esse tempo, melhor a qualidade do sistema neste sentido.
    Exemplo 15

    No SASF, podemos medir o tempo de substituição de um servidor de streaming pelo tempo da detecção da falha, somado ao tempo de inicialização do servidor e somado ao tempo de redirecionamento das requisições de transmissão. Uma forma de ter o tempo total de recuperação minimizado seria manter o servidor auxiliar ligado, apenas esperando a detecção da falha do servidor principal. No entanto, essa decisão significaria mais custos, uma vez que seriam dois servidores ligados ao mesmo tempo, gastando mais energia, diminuindo a vida útil do hardware e possivelmente consumindo licenças de software.

Usabilidade

Usabilidade é a medida da facilidade de o usuário executar alguma funcionalidade do sistema. Essa facilidade está ligada diretamente à compreensibilidade, à facilidade de aprendizado, à operabilidade, a quanto o usuário se sente atraído pelo sistema e à adesão de padrões de usabilidade, que são as subcaracterísticas desse atributo de qualidade. Apesar de muitos desses critérios serem subjetivos, há maneiras de medi-los para termos noção da usabilidade do software. A seguir, mostramos as subcaracterísticas da usabilidade:

  • compreensibilidade, ou a capacidade de o usuário entender o sistema. Esta característica está ligada à quantidade de conceitos que o usuário precisa saber previamente para lidar com o sistema ou à qualidade ou quantidade da documentação do sistema. A compreensibilidade serve para o usuário dicernir se o software serve para ele ou não.
  • facilidade de aprendizado está ligada diretamente à compreensibilidade. No entanto, neste caso, a qualidade é a de o usuário aprender a usar o software, caso ele saiba que o software serve para ele. As métricas dessa qualidade também estão relacionadas à quantidade de conceitos ou operações que o usuário precisa aprender para fazer com que o software funcione.
  • operabilidade é a capacidade de o usuário operar ou controlar o sistema. Esta qualidade é muito importante em grandes sistemas de software, onde há um tipo de usuário que é o administrador do sistema. O administrador deseja ser capaz de realizar operações sobre o sistema que, comumente, não estão entre as funções que interessam aos usuários mais comuns: ligar, desligar ou verificar estado de servidores, realizar backup dos dados, etc. Em sistemas de redes sociais, por exemplo, entre os serviços providos ao operador, ainda estão a possibilidade de expulsar usuários do sistema ou moderá-los, não permitindo que esses usuários realizem algumas funções, como enviar mensagens ou mesmo barrando conexões de acordo com o endereço de origem.

Eficiência

A eficiência ou desempenho é talvez a qualidade mais buscada durante o desenvolvimento de software, uma vez que ela é a mais percebida pelos usuários. Ela é a qualidade relacionada ao uso de recursos do sistema quando esse provê funcionalidade e é também a com que os desenvolvedores mais se preocupam. Quando queremos medir eficiência, medimos basicamente duas características:

  • comportamento no tempo ou desempenho, ou a capacidade do sistema de alcançar a resposta dentro do período de tempo especificado. Aqui, referimo-nos a tempos de resposta, latência, tempo de processamento, vazão ( throughput), etc. Vale observar que, ao medir essa característica, devemos também entender as condições em que o sistema está operando. Afinal, no Exemplo 7, mesmo que o HSearch tenha um tempo de resposta menor que o Google Web Search, o primeiro é capaz de servir a apenas um milésimo da quantidade de usuários servida pelo segundo.
  • uso de recursos, que é a capacidade de o software exigir mais ou menos recursos de acordo com suas condições de uso. Normalmente, essa característica também é chamada de escalabilidade e pode também ser vista de outra maneira: como a adição ou remoção de recursos no sistema vai melhorar ou piorar as condições de uso. Existem dois tipos mais comuns de escalabilidade, que também servem para facilitar o entendimento dessa característica: escalabilidade vertical e escalabilidade horizontal . Eles podem ser melhor explicados por meio de um exemplo:
    Exemplo 16

    Vamos considerar um sistema servidor de arquivos. Esse servidor de arquivos usa apenas um disco rígido e é capaz de servir a cinco usuários simultâneos, cada um usando 10 MB/seg de banda passante (fazendo upload ou download). Vamos desconsiderar os efeitos da rede que liga os clientes ao servidor ou qualquer outro gargalo. Podemos dizer que as condições de uso do software são: 5 usuários simultâneos a 10 MB/seg cada.

    No Exemplo 16, uma forma de melhorar as condições de uso, ou mais especificamente, aumentar a quantidade de usuários simultâneos, seria seria substituir um dos recursos do sistema por outro com maior capacidade. Ou seja, escalar verticalmente.
    Exemplo 17: (continuação do exemplo anterior)

    Vamos substituir o disco rígido do servidor por um que seja capaz de transferir arquivos no dobro da velocidade do anterior. Desta maneira, se o disco rígido fosse o único fator limitante, conseguiríamos não mais servir 5 usuários a 10 MB/seg, mas sim 10 usuários simultâneos a 10 MB/seg, como ilustrado na Figura 1. Além disso, poderíamos seguir melhorando verticalmente o sistema até encontrarmos um limite, que pode ser tanto o limite na velocidade possível para um disco rígido quanto o limite financeiro de comprarmos um disco mais rápido.

    Figura 1: Escalando verticalmente um sistema.
    Figura 1 (escalabilidade-vertical.png)
    Outra forma de escalar o sistema seria horizontalmente. Desta maneira, não substituímos um recurso por um melhor, mas adicionamos um novo recurso ao sistema de modo que ele faça uso tanto do recurso velho quanto do novo.
    Exemplo 18: (continuação do exemplo anterior)

    Ao invés de necessariamente comprar um disco rígido mais rápido, compramos um novo disco (que pode até ser igual ao anterior) e fazemos com que o software divida a carga de escrita e leitura entre os dois discos rígidos. Esta abordagem está ilustrada na Figura 2.

    Figura 2: Escalando horizontalmente um sistema.
    Figura 2 (escalabilidade-horizontal.png)
    Note que a solução do Exemplo 18 não vem de graça: além da camada de software ficar mais complicada, há o impacto na eficiência – possivelmente, o tempo de resposta será afetado, uma vez que uma operação do usuário terá que agora decidir qual disco rígido usar. No entanto, a vantagem desta solução reside no fato de que o teto de desempenho com a adição de novos discos será mais alto que o teto alcançável com discos mais rápidos. Além disso, há um limite de discos rígidos que podem ser utilizados por um mesmo sistema operacional. Para expandir ainda mais o limite de discos rigídos sendo usados simultaneamente, o próximo passo seria adicionar mais uma máquina servidora, o que deixaria o software ainda mais complexo, pois este agora teria que decidir entre discos presentes em máquinas diferentes e assim por diante. Esse é apenas um exemplo de técnica de se alcançar escalabilidade horizontal. No próximo capítulo, quando falarmos de técnicas de design, apresentaremos outras abordagens e padrões de design para a escalabilidade.

Manutenibilidade

A manutenibilidade é uma qualidade, às vezes, negligenciada pelos usuários, mas muito importante aos desenvolvedores. Ela é a capacidade de o software ser modificado em seu processo de evolução. Podemos citar as seguintes características do atributo de manutenibilidade: a analisabilidade, a modificabilidade e a testabilidade.

  • analisabilidade: é o grau de facilidade com que podemos procurar por deficiências no software ou por partes que devem ser modificadas para algum fim. Os níveis de modularidade, de separação de preocupações e de acomplamento do software se relacionam a essa característica.
  • modificabilidade: é a capacidade de realizar mudanças de implementação no sistema. Essa característica também está relacionada às métricas clássicas de software, como níveis de coesão e acoplamento e complexidade ciclomática. Quanto mais modificável o software, menor o impacto da mudança em áreas – teoricamente – não relacionadas às mudanças.
    Exemplo 19

    No SASF, por termos o módulo de transmissão de vídeos separado do gestor de usuários, qualquer mudança ou adição nos formatos suportados para transmissão não deve afetar ao módulo de usuários. Outra separação comum em sistemas web que também foi adotada no SASF é a aplicação do padrão Model-View-Controller (MVC) 12, que separa as interfaces de usuário de lógica de negócio. Isso permite modificações na lógica de negócio que não afetam as interfaces de usuário e vice-versa.

  • testabilidade: é a capacidade de o software ter suas mudanças validadas. Para um software ser testável, antes de tudo, devemos conhecer seus objetivos. Mas, além disso, precisamos que o sistema seja capaz de executar de forma controlada a fim de podermos medir os resultados obtidos a partir de entradas conhecidas. Sistemas pouco testáveis são aqueles os quais sua execução é muito cara, pode custar vidas ou, simplesmente, não podemos medir seu comportamento deterministicamente. Vale observar que muitos sistemas distribuídos, se mal projetados, podem se encaixar nesse último tipo.

Portabilidade

O último atributo de qualidade presente no padrão ISO/IEC 9126-1:2001 é o de portabilidade. Esse atributo é a medida de adaptações necessárias para que o sistema tenha seus requisitos ou ambientes de execução modificados, podendo ser o ambiente de software, de hardware ou organizacional. Esse atributo é importante, por exemplo, para jogos, uma vez que é desejável que eles sejam capazes de executar no maior número de plataformas, mas também é desejável que o custo para tornar isso possível seja baixo. Algo similar acontece com aplicativos para celulares. A necessidade de um aplicativo para celulares ser portável existe porque é comum que seus desenvolvedores queiram que ele esteja disponível em dezenas de modelos diferentes. Isso significa que um mesmo aplicativo deve estar disponível para dezenas de ambientes de hardware diferentes. Portanto, não faz sentido que o mesmo aplicativo seja reimplementado diversas vezes, mas sim que seja projetado de forma a minimizar o esforço para alterar o ambiente de hardware.

A portabilidade pode ainda ser dividida nas seguintes características:

  • adaptabilidade: é a capacidade de o software ser portado para outro ambiente sem precisar de modificações além das previstas.
    Exemplo 20

    O Vuze 13 é um aplicativo escrito na linguagem de programação Java e que, por isso, é capaz de executar em qualquer sistema operacional em que a máquina virtual Java (JVM) esteja disponível. No entanto, apesar da portabilidade provida pela linguagem de programação em que foi escrito, ele necessita de uma pequena modificação específica para cada novo sistema operacional suportado pela JVM. Essa modificação consiste na criação de um instalador específico para o S.O., uma vez que diferentes sistemas possuem diferentes formas de instalação de software. No entanto, essa modificação é prevista na arquitetura do Vuze e não afeta significativamente sua adaptabilidade a novos sistemas operacionais.

  • instalabilidade: é a capacidade de o software ser instalado em algum ambiente específico. A instalabilidade é medida junto com o ambiente-alvo. Portanto, por exemplo, antes do Apple Bootcamp, o sistema operacional Windows XP não era instalável em ambientes Apple. Já o sistema GNU/Linux, por sua vez, era instalável tanto em PCs quanto em Macs.
  • co-existência: é a capacidade de o software compartilhar recursos em um mesmo ambiente com outros sistemas.

Conflitos entre atributos de qualidade

Assim como os interesses de cada stakeholder não são isolados e podem afetar os de outro por meio dos requisitos não-funcionais, os atributos de qualidade não surgem isolados no software. Uma decisão arquitetural feita com o objetivo de alcançar um atributo de qualidade pode ter efeito em outros atributos. Por uma decisão arquitetural nunca ser isolada no design da arquitetura, o arquiteto deve sempre entender quais atributos a decisão afeta, seja positivamente ou negativamente, e fazer as devidas concessões caso ela afete atributos de qualidade conflitantes. No capítulo sobre técnicas de design, observaremos melhor as relações entre os atributos de qualidade ao apresentarmos algumas técnicas de design arquitetural para alcançá-los. Isso acontece porque é comum que essas técnicas não afetem cada atributo de software isoladamente.

Atributos de Negócio

Apesar de a lista de atributos de qualidade apresentada anteriormente ter sido criada a fim de ser exaustiva, há alguns atributos adicionais que merecem ser citados. São chamados os atributos de qualidade de negócio, que, apesar de não serem ligados diretamente ao software, têm grande influência sobre sua arquitetura. Eles são importantes porque influenciam principalmente as decisões de resolução de conflitos dos atributos apresentados anteriormente. Os atributos de negócio são:

  • mercado-alvo
  • time-to-market
  • custo e benefício
  • vida útil do sistema
  • agenda de lançamento

Mercado-alvo

O arquiteto só é capaz de priorizar os atributos de qualidade em seu design se conhecer o público e o mercado para o qual o software está sendo construído. Por exemplo, portabilidade e funcionalidade são buscados para o público geral de um pacote de aplicativos de escritório e, portanto, priorizados neste caso. Por outro lado, ao se construir um sistema de infraestrutura para uma empresa específica, o arquiteto pode priorizar a eficiência em detrimento da portabilidade e até mesmo da usabilidade, uma vez que os usuários comuns desse sistema são operadores qualificados.

Time-to-market

Time-to-market é o tempo entre a concepção do software e sua entrega no mercado. Esse atributo se torna importante, principalmente, quando a janela de oportunidade é pequena devido a produtos concorrentes. O time-to-market influencia e, quando curto, prioriza decisões de compra e reuso de módulos em detrimento do desenvolvimento in house ou de investimento em decisões que dizem respeito a atributos considerados secundários ao negócio.

Custo e benefício

Como os recursos financeiros para se desenvolver o software são limitados, cada decisão arquitetural deve ter seu custo e o benefício proporcionado analisados e, com base nessa análise, priorizados ou até mesmo descartados. Essa análise deve levar em conta o ambiente de desenvolvimento em questão: capacidades do time de desenvolvimento, ferramentas disponíveis para o reuso e os objetivos do software.

Vida útil

O design de sistemas de grande vida útil deve priorizar diferentes atributos de qualidade se os compararmos com o design de sistemas de vida mais curta, como protótipos. No primeiro tipo de sistemas, atributos de manutenibilidade e portabilidade são mais valorizados; no segundo, são priorizados atributos de eficiência e funcionalidade.

Agenda de lançamento

O design do software é muito dependente de como ele vai ser disponibilizado a público. Por exemplo, se o software será disponibilizado em fases distintas que englobarão diferentes conjuntos de funcionalidades, ele deve ser dividido de modo que funcione sem as partes que ainda não foram disponibilizadas, mas que também facilite tanto a modificabilidade, uma vez que é desejável que novas funcionalidades sejam adicionadas com menor esforço, quanto a interoperabilidade entre diferentes versões, que eventualmente ocorrerá. Já se o software será disponibilizado sem possibilidade de posterior atualização, como acontece em muitos sistemas embarcados, preocupações de modificabilidade e interoperabilidade entre versões podem ser descartadas.

Design Arquitetural para Qualidade de Software

A principal responsabilidade do arquiteto é a de conceber o design que possibilite ao software ser construído de modo que satisfaça os requisitos de qualidade impostos pelos stakeholders. Para que o processo de design arquitetural tenha sucesso, é essencial que o arquiteto conheça os objetivos do software, ou seja, conheça os requisitos funcionais e de qualidade para os quais ele está projetando. Além disso, ele deve conhecer tanto as técnicas e práticas de design arquitetural que podem ajudá-lo na concepção da arquitetura. Ele deve também conhecer como documentar a arquitetura projetada, uma vez que é preciso comunicá-la aos outros membros do time de desenvolvimento.

Neste capítulo, nós aprendemos sobre os objetivos que devem ser alcançados pelo design da arquitetura e esperamos que o leitor agora seja capaz de:

  • Identificar o que são atributos de qualidade e qual é sua influência na arquitetura de software;
  • Relacionar atributos de qualidade com algumas decisões arquiteturais que os proporcionam; e
  • Entender quais os atributos de qualidade se relacionam e como eles se relacionam.

A seguir, apresentaremos técnicas e práticas de design que o arquiteto deve conhecer para projetar sistemas com determinados atributos de qualidade. Por fim, no capítulo seguinte, apresentaremos como documentar o design arquitetural.

Referências

Requisitos funcionais e não-funcionais

Os livros Software Engineering [19], de Sommerville, Requirements Engineering: Processes and Techniques [11], de Sommerville e Kotonya, Software Engineering: A Practitioner's Approach [17], de Pressman, dedicam alguns capítulos a este assunto. No entanto, o foco desses livros é no papel dos requisitos de software no processo de desenvolvimento. Já o artigo Defining Non-Functional Requirements [15], de Malan e Bredemeyer, é mais voltado à influência dos requisitos na arquitetura.

Diferenças entre requisitos funcionais e não-funcionais

A discussão sobre a inexistência de diferenças práticas entre requisitos funcionais e não-funcionais pode ser encontrada tanto no livro Requirements Engineering: Processes and Techniques [11], de Sommerville e Kotonya, quanto no artigo Distinctions Between Requirements Specification and Design of Real-Time Systems [10], de Kalinsky e Ready, e no livro Real-Time Systems: Design Principles for Distributed Embedded Applications [9], de Kopetz. Essa discussão se mostra bastante presente em sistemas de tempo-real porque os requisitos de desempenho definem a funcionalidade desses sistemas – ao contrário do que encontramos, por exemplo, em sistemas de informação, onde os requisitos de desempenho são considerados requisitos não-funcionais.

Atributos de Qualidade

Bass et al, no livro Software Architecture in Practice [2], mostra o papel dos atributos de qualidade na arquitetura de software. Além dele, Gorton faz uma pequena introdução a este assunto ao tratar do estudo de caso presente em Essential Software Architecture [5]. Os livros Software Systems Architecture [18], de Rozanski e Woods, e Code Complete [13], de Steve McConnell, também dedicam seções aos atributos de qualidade de software, sendo o primeiro em nível de design arquitetural e o segundo em nível de design detalhado.

Atributos de Negócio

Por fim, podemos encontrar informações sobre atributos de qualidade de negócio nos livros Software Architecture in Practice [2], de Bass et al, e Beyond Software Architecture [6], de Hohmann.

Footnotes

  1. http://public.web.cern.ch/public/en/LHC/LHC-en.html
  2. Note que não tivemos acesso ao documento de requisitos do Windows NT. No entanto, a estrutura de seu kernel deixa bem clara esta necessidade de retrocompatibilidade e aderência ao padrão POSIX. Para mais informações sobre esse assunto, recomendamos a leitura do capítulo A Tale of Two Standards do livro Open Sources 2.0 [4].
  3. A Department of Defense Joint Technical Architecture (DoD JTA) [3] é um documento que descreve um conjunto de normas a que um sistema deve aderir para facilitar a interoperabilidade com outros sistemas do Exército Americano. A título de curiosidade, o DoD JTA contém algumas centenas de normas.
  4. Alguns autores preferem o termo requisitos de qualidade.
  5. http://hounder.org/
  6. Caso o leitor deseje criar um clone do HSearch, basta seguir o tutorial de cinco minutos presente em http://code.google.com/p/hounder/wiki/5minuteTutorial
  7. http://www.google.com
  8. Em Inglês, alguns autores se referem aos atributos de qualidade usando o sufixo -ilities, que é comum ao nome de vários atributos. Podemos perceber isso na lista de qualidades presente no endereço: http://en.wikipedia.org/wiki/Ilities. Em Português, poderíamos nos referir a -idades, mas preferimos usar dimensões, propriedades ou mesmo qualidades.
  9. Possivelmente, a calculadora implementará o padrão para aritmética de ponto-flutuante IEEE 754-2008 [7]
  10. A comunidade interessada em web services especificou uma série de padrões que facilitam a interoperabilidade entre os serviços. Podemos encontrar uma grande lista deles no seguinte endereço: http://bit.ly/kIEXs.
  11. O Denial of Service ou DoS ocorre quando o sistema não pode atender a novas requisições porque todos os seus recursos estão sendo consumidos, possivelmente devido a um ataque de um ou vários agentes maliciosos.
  12. Falamos mais do padrão arquitetural MVC quando apresentamos as ferramentas de design de software no capítulo sobre técnicas de design.
  13. http://www.vuze.com

References

  1. Boehm, B. W. and Brown, J. R. and Lipow, M. (1976). Quantitative Evaluation of Software Quality. In International Conference on Software Engineering. (p. 592–605). San Francisco: IEEE Computer Society Press.
  2. Bass, Len and Clements, Paul and Kazman, Rick. (2003, April). Software Architecture in Practice. (2). Addison-Wesley Professional.
  3. Defense Information Systems Agency,. (2003, October). Department of Defense Joint Technical Architecture, Version 6.0. Volume 2. U.S. Department of Defense.
  4. Dibona, Chris and Stone, Mark and Cooper, Danese. (2005, October). Open Sources 2.0 : The Continuing Evolution. O'Reilly Media, Inc.
  5. Gorton, Ian. (2006, June). Essential Software Architecture. Springer.
  6. Hohmann, Luke. (2003, January). Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional.
  7. IEEE Std 754-2008,. (2008). IEEE Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers.
  8. ISO 9126-1:2001,. Software engineering – Product quality – Part 1: Quality model. International Organization for Standardization, Geneva, Switzerland.
  9. Kopetz, Hermann. (1997, April). Real-Time Systems: Design Principles for Distributed Embedded Applications. Springer.
  10. Kalinsky, D. and Ready, J. (1989). Distinctions Between Requirements Specification and Design of Real-Time Systems. In Software Engineering for Real Time Systems, 1989., Second International Conference on. (p. 26–30).
  11. Kotonya, Gerald and Sommerville, Ian. (1998, September). Requirements Engineering: Processes and Techniques. John Wiley & Sons.
  12. Little, John D. C. (1961). A Proof for the Queuing Formula: L= W. Operations Research, 9(3), 383–387.
  13. McConnell, Steve ,. (2004, June). Code Complete. (2). Microsoft Press.
  14. McCall, J. ,. (1977, November). Factors in Software Quality: Preliminary Handbook on Software Quality for an Acquisiton Manager. (Vol. 1-3). General Electric.
  15. Malan, Ruth and Bredemeyer, Dana. (2001, August). Defining Non-Functional Requirements. Online at: http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF.
  16. Powell, Andy and Nilsson, Mikael and Naeve, Ambjörn and Johnston, Pete and Baker, Thomas. (2007, June). DCMI Abstract Model. DCMI Recommendation.
  17. Pressman, Roger. (2004, April). Software Engineering: A Practitioner's Approach. (6). McGraw-Hill Science/Engineering/Math.
  18. Rozanski, Nick and Woods, Eóin. (2005, April). Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional.
  19. Sommerville, Ian. (2006, June). Software Engineering. (8). Addison Wesley.

Content actions

Download module as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks