QUALIDADE DE SOFTWARE

Transcrição

1 Engenharia de Software Unidade B Introdução A engenharia de software é responsável pela produção de software de qualidade. Mas, o que é qualidade de um produto de software? Qualidade, de maneira simplista, significa que um produto deve atender à sua especificação. Isso não é simples quando o produto é um sistema de software, visto que devem ser considerados tanto os requisitos de qualidade definidos pelo cliente (eficiência, confiabilidade, usabilidade, etc.) quanto os requisitos de qualidade do desenvolvedor (facilidade de manutenção, reusabilidade, etc.). É preciso, portanto, conhecer quais são os atributos que devem ser considerados para que possamos fazer a avaliação de qualidade de um software. UNIDADEB QUALIDADE DE SOFTWARE A avaliação da qualidade de software pode ser realizada com diferentes objetivos, entre eles, para aprimorar o processo de desenvolvimento e para então melhorar a qualidade do produto resultante. Neste caso, ela é feita pelas empresas que desenvolvem o software; para avaliar a qualidade do produto visando emitir documento oficial sobre a qualidade de um software e sua conformidade em relação a uma norma ou padrão. Essas avaliações utilizam como referência normas internacionais e são feitas por organismos de certificação; para aquisição de software com a intenção de escolher o produto mais adequado dentre um conjunto de softwares selecionados. Este processo é feito por pessoas ou organizações que adquirem software. A avaliação da qualidade de um produto de software é muito importante, visto que atualmente vários sistemas são gerenciados e controlados via software e cada vez mais os clientes estão mais exigentes quanto à qualidade dos sistemas. No entanto, a qualidade do processo adotado para o desenvolvimento também influencia na qualidade do produto que é produzido. Nesta unidade, será dado maior enfoque à qualidade de produto sem, no entanto, ignorar a qualidade do processo. Qualidade de Software: Uma visão geral O que determina se um software tem qualidade ou não? Ou como definimos qualidade de software? Para ajudar a responder essas questões a ISO (International Organization for Standardization) e a IEC (International Electrotechnical Comission), que são organismos normalizadores com importância internacionalmente reconhecida no setor de software, uniram-se para editar normas internacionais. A norma internacional ISO/IEC 9126, publicada em 1991 e que, na versão brasileira de agosto de 1996, recebeu o número NBR 13596, define qualidade de software como A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas. No entanto, o que são necessidades explícitas de um software? Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. São, portanto, fatores relativos à qualidade do processo de desenvolvimento do produto e são percebidos somente pelas pessoas que trabalharam no seu desenvolvimento. Já as necessidades implícitas são necessidades subjetivas dos usuários (inclusive operadores, destinatá- 11

2 rios dos resultados do software e os mantenedores do produto), são também chamadas de fatores externos e podem ser percebidas tanto pelos desenvolvedores quanto pelos usuários. As necessidades implícitas, também chamadas de qualidade em uso, devem permitir usuários atingir metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado. Mesmo sendo possível afirmar que se as qualidades internas foram observadas muito provavelmente as qualidades externas também foram atendidas, o usuário procura resposta para questões como: As funções requeridas estão disponíveis e são executadas eficientemente? Funciona adequadamente em imprevistos, como, por exemplo, efetuar débito em uma conta com saldo insuficiente? O software é seguro, ou seja, evita que pessoas ou sistemas não autorizados tenham acesso aos dados para leitura ou modificação? Permite que pessoas ou sistemas autorizados para acessar os dados não tenham acesso negado a eles? É fácil de integrar com outros sistemas existentes? Aceita trabalhar com arquivos de outros sistemas ou enviar dados para outros sistemas? É capaz de restabelecer seu nível de desempenho e recuperar dados afetados em casos de falha? É fácil de usar ou requer muito treinamento? É fácil transferir o software para outro ambiente previsto na descrição do produto? O suporte técnico é confiável e atende com a rapidez necessária? Ainda nesta unidade, você verá como a norma define estas características desejadas a um software de qualidade e como podemos medir a qualidade de um software. Qualidade de Produto de Software O principal problema com que se defronta a engenharia de software é a dificuldade de se medir a qualidade de software. A qualidade de um dispositivo mecânico é frequentemente medida em termos de tempo médio entre suas falhas, que é uma medida da capacidade de o dispositivo suportar o desgaste. O software não se desgasta, portanto tal método de medição de qualidade não pode ser aproveitado. A ISO/IEC 9126, que serviu de base à norma brasileira NBR 13596, fornece um modelo de propósito geral que tem por objetivo servir de referência básica na avaliação de produto de software. Além de ter força de norma internacional, ela cobre os aspectos mais importantes para qualquer produto de software. No modelo proposto, são definidas seis amplas categorias de características de qualidade de software que são, por sua vez, subdivididas em subcaracterísticas, conforme apresentado na Tabela 1. Neste modelo, funcionalidade, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade são características que devem ser avaliadas para todo o software. CARACTERÍSTICAS SUBCARACTERÍSTICAS SIGNIFICADO Funcionalidade O conjunto de funções satisfazem as necessidades explícitas e implícitas para a finalidade a que se destina o produto? Adequação Acurácia Interoperabilidade Segurança de acesso Conformidade Propõe-se a fazer o que é apropriado? Gera resultados corretos ou conforme acordados? É capaz de interagir com os sistemas especificados? Evita acesso não autorizado, acidental ou deliberado a programa e dados? Está de acordo com normas e convenções previstas em leis e descrições similares? 12

3 Confiabilidade O desempenho se mantém ao longo do tempo e em condições estabelecidas? Usabilidade É fácil utilizar o software? Eficiência Os recursos e os tempos utilizados são compatíveis com o nível de desempenho requerido para o produto? Manutenibilidade Há facilidade para correções, atualizações e alterações? Maturidade Tolerância a falhas Recuperabilidade Inteligibilidade Apreensibilidade Operacionalidade Comportamento em relação ao tempo Comportamento em relação aos recursos Analisabilidade Modificabilidade Estabilidade Com que frequência apresenta falhas? Ocorrendo falhas, como ele reage? É capaz de recuperar dados após uma falha? É fácil entender os conceitos utilizados? É fácil aprender a usar? É fácil de operar e controlar a operação? Qual é o tempo de resposta e de processamento? Quanto recurso utiliza? É fácil encontrar uma falha quando ocorre? É fácil modificar e remover defeitos? Há grandes riscos de bugs quando se faz alterações? Testabilidade É fácil testar quando se faz alterações? Portabilidade É possível utilizar o produto em diversas plataformas com pequeno esforço de adaptação? Adaptabilidade É fácil adaptar a outros ambientes sem aplicar outras ações ou meios além dos fornecidos para esta finalidade no software considerado? Capacidade para ser instalado É fácil instalar em outros ambientes? Capacidade para substituir É fácil substituir por outro software? Conformidade Está de acordo com padrões ou convenções de portabilidade? Tabela 1: Atributos de qualidade de produto de Software Métricas de Software Além de conhecer quais as características a serem avaliadas também é preciso saber como avaliá-las. Sempre que possível, é interessante usar processos de medição, que nos permitem derivar um valor numérico para algum atributo, através do uso de métricas. Uma métrica de software é qualquer tipo de medição relacionada a um sistema de software, processo ou documentação associada. Neste sentido, número de linhas de código em um programa, o número de pessoas-dia necessárias para desenvolver um componente e número de defeitos são exemplos de métricas de software. As métricas permitem que o software e o processo de software sejam quantificados e podem ser usadas para prever atributos de produto e para controlar o processo de software. As métricas de produto podem se usadas para previsões gerais sobre a qualidade do produto ou para identificar componentes anômalos. São exemplos de métricas de produto: complexidade de um módulo, número de linhas de código, número de classes, etc. A Tabela 2 apresenta exemplos de métricas de produto de software, dentre elas, podemos destacar a complexidade ciclomática, medida da complexidade do fluxo de controle de um programa ou subrotina. Esta métrica também é usada no Teste de Software e será abordada em mais detalhes na Unidade C. Outra métrica bastante usada é a extensão de um programa, que por vezes é medida em linhas de código (LoC: Lines of code) e ajuda a avaliar a propensão de um componente a erros, considerando que quanto mais extenso ele é, mais propenso a erros este será. Além destas, há métricas específicas para a avaliação de 13

4 programas orientados a objetos, tais como a profundidade da árvore de herança, número de operações sobrescritas, bem como métricas simples como número de classes, número de métodos, número de atributos de uma classe, entre outras. Fan-in/Fan-out Extensão de código Complexidade ciclomática Extensão de identificadores Métrica de software Profundidade de aninhamento de declarações condicionais Índice de Fog Descrição Fan-in é uma medida do número de funções ou métodos que chamam alguma outra função ou método (digamos X). Fan-out é o número de funções chamadas pela função X. Um valor alto para fan-in significa que X está firmemente acoplado com o resto do projeto, e mudanças em X terão grande impacto. Um alto valor para fan-out sugere que a complexidade geral de X pode ser alta devido à complexidade da lógica de controle necessária para coordenar os componentes chamados. É uma medida do tamanho de um programa. Geralmente, quanto maior for o tamanho do código de um componente, mais complexo e propenso a erros esse componente será. A extensão de código foi mostrada como uma das métricas mais confiáveis de previsão de propensão a erros em componentes. É uma medida da complexidade de controle de um programa. Essa complaxidade de controle pode estar relacionada à facilidade de compreensão do programa. Explico como calcular a complexidade ciclomática na Unidade C. É uma medida da extensão média de identificadores distintos em um programa. Quanto maiores forem os identificadores, mais eles serão significativos e, por isso, mais compreensível será o programa. É uma medida da profundidade de aninhamento de declarações IF em um programa. As declarações IF profundamente aninhadas são difíceis de compreender e são potencialmente propensas a erros. É uma medida da extensão média das palavras e das sentenças em documentos. Quanto maior for o valor para o índice de Fog, mais difícil será a compreensão de documentos. Tabela 2: Exemplo de métricas de produto de Software. Fonte: Sommerville, Podemos classificar as métricas de produto como estáticas e dinâmicas. As métricas dinâmicas são coletadas por meio das medições realizadas em um programa em execução, enquanto as métricas estáticas são coletadas pelas medições realizadas em representações do sistema (código, modelo, etc). As métricas dinâmicas podem ser relacionadas diretamente aos atributos de qualidade de software e ajudam a avaliar a eficiência e a confiabilidade de um produto. É relativamente fácil medir o tempo de resposta de um sistema (atributo de desempenho) ou o número de falhas (atributo de confiabilidade). Já as métricas estáticas têm um relacionamento indireto com atributos de qualidade e para que possam ser usadas para prever propriedades como facilidade de manutenção, usabilidade, entre outras propriedades, você necessita tentar derivar um relacionamento entre essas métricas e as propriedades citadas. Medidas como coesão e acoplamento de módulos, assim como a profundidade do aninhamento de condicionais podem estar relacionadas à manutenção, porém 14

5 não de forma tão direta. O tema métricas de software é um assunto muito extenso e estudamos aqui apenas uma introdução ao assunto com foco maior nas métricas de produto. Para saber mais sobre este tema, consulte as referências indicada no final da Unidade. Normas e Modelos de Qualidade de Software Como vimos anteriormente, a qualidade de software pode ser dividida em qualidade de produto e qualidade de processo de software. As principais normas e modelos aplicadas à qualidade de software são citadas nesta unidade. Já citamos nesta unidade a Norma ISO/IEC 9126 (NBR 13596), que define as características de qualidade de software que devem estar presentes em todos os produtos, e que é a principal norma para avaliação da qualidade de produto de software. Além desta norma, ISO/IEC também definiram outras normas que são citadas abaixo e que têm diferentes focos. Norma ISO/IEC 12119: estabelece os requisitos de qualidade para pacotes de software e instruções para teste, considerando-se esses requisitos; Norma ISO/IEC : foco em um processo de avaliação da qualidade de produto de software; Norma ISO/IEC 12207: define um processo de ciclo de vida de software; Norma ISO/IEC : apresenta diretrizes para a aplicação da ISO 9001, a mais utilizada por organizações que desenvolvem software, ao desenvolvimento, fornecimento e manutenção de software. Além dessas normas da ISO, há também modelos que podem ser usados para avaliar a qualidade de um processo de desenvolvimento e que foram definidos por institutos de pesquisa. O principal modelo é conhecido como CMM (Capability Maturity Model) e foi desenvolvido nos EUA pelo Software Engineering Institute (SEI). Não é uma norma ISO, mas é muito bem aceito no mercado para avaliar a maturidade das Organizações de Software, pois este modelo descreve os estágios de maturidade através dos quais Organizações evoluem o seu ciclo de desenvolvimento de software, buscando a melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade: inicial, repetitivo, definido, gerenciado e otimizado. Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a organização atingir o nível de maturidade em qualidade de software. Além do CMM, o projeto SPICE (Software Process Improvement & Capability determination) é outro esforço reconhecido para gerar normas ISO/IEC para a avaliação de processos de software. Conclusões Ainda é elevado o número de empresas brasileiras de software que não adotam técnicas para melhoria da qualidade de seus produtos, mas não há como negar que as empresas que desenvolvem software de qualidade são mais competitivas, o que é muito importante para sua sobrevivência em um mercado cada vez mais globalizado. A abertura de mercados externos para os softwares brasileiros exigirá uma nova postura frente à qualidade, beneficiando o mercado interno que acabará por exigir softwares melhores a menor preço. Podemos avaliar a qualidade de um software, observando aspectos relacionados à qualidade do produto que é 15

6 entregue ou ainda à qualidade do processo de desenvolvimento adotado. Portanto, para uma completa garantia de qualidade, é preciso que os esforços em melhoria da qualidade de software não tenham seu foco apenas no produto, mas principalmente no processo, mas além disso, também considerar a satisfação do cliente. A qualidade de software é um tema bastante amplo e de grande importância para a área da engenharia de software. Este tema também está relacionado com o tema Teste de Software, que será estudado na próxima unidade. Referências PRESSMAN, R. Engenharia de Software. 6ª Ed. São Paulo: Mcgraw-hill, SOMMERVILLE, I. Engenharia de Software. 8ª Ed. São Paulo: Pearson Addison-Wesley, ISO (International Organization for Standardization) Disponível em: < tc/catalogue_detail.htm?csnumber=22750> Acesso em: 20 maio CMMI (Capability Maturity Model Integration). Disponível em: < Acesso em: 20 maio SPICE (Software Process Improvement and Capability determination) Disponível em: < Acesso em: 20 maio