Capítulo 24 Gerência de Qualidade Aula 1 Qualidade e Padrões de Qualidade 1
Roteiro ² Qualidade de software ² Padrões de software ² Revisões e inspeções ² Medidas e métricas de software 2
Gerência de Qualidade de Software ² Relaciona-se com garantir que o nível requerido de qualidade é alcançado em um produto de software. ² Três interesses principais: no nível organizacional, a gerência de qualidade relaciona-se com o estabelecimento de um framework de processos organizaionais e padrões que levarão ao software com alta qualidade; no nível de projeto, a gerência de qualidade envolve a aplicação de processos de qualidade específicos e a verificação que estes processos planejados foram seguidos; no nível de projeto, a gerência de qualidade também está relacionado com o estabelecimento de um plano de qualidade para um projeto. O plano de qualidade deve estabelecer os objetivos de qualidade para o projeto e definir quais processos e padrões são usados. 3
Atividades de Gerência de Qualidade ² A gerência de qualidade fornece uma verificação independente no processo de desenvolvimento de software. ² O processo de gerência de qualidade verifica o que deve ser entregue no projeto para garantir que são consistentes com os padrões e objetivos organizacionais. ² A equipe de qualidade deve ser independente da equipe de desenvolvimento de forma que ele possam tomar uma visão objetiva do software. Isso permite que eles relatem a qualidade do software sem ser influenciados por aspectos de desenvolvimento. 4
Gerência de Qualidade e Desenvolvimento de Software 5
Planejamento de Qualidade ² Um plano de qualidade estabelece as qualidades desejada do produto e como elas são avaliadas e define os atributos de qualidade mais significativos. ² O plano de qualidade deve definir o processo de avaliação de qualidade. ² Ele deve estabelecer quais padrões organizacionais devem ser aplicados e, quando necessário, definir novos padrões a serem usados. 6
Planos de Qualidade ² Estrutura do plano de qualidade introdução ao produto; planos de produto; descrições de processo; objetivos de qualidade; riscos e gerência de risco. ² Os planos de qualidade devem ser documentos curtos e sucintos Se forem muito longos, ninguém os lerá. 7
Escopo da Gerência de Qualidade ² A gerência de qualidade é particularmente importante para sistemas grandes e complexos. A documentação de qualidade é um registro do progresso e suporta a continuidade do desenvolvimento enquanto a equipe de desenvolvimento muda. ² Para sistemas menores, a gerência de qualidade precisa de menos documentação e deve concentrar-se em estabelecer uma cultura de qualidade. 8
Qualidade de Software ² Qualidade, de forma simples, significa que o produto deve atender às especificações. ² Isso é problemático para sistemas de software Existe uma tensão entre os requerimentos de qualidade do cliente (eficiência, confiabilidade, etc) e os requerimentos de qualidade do desenvolvedor (manutenibilidade, reusabilidade, etc); Alguns requerimentos de qualidade são difíceis de especificar de forma não ambígua; As especificações de software são geralmente incompletas e frequentemente inconsistentes.. ² O foco pode ser conveniência por propósito mais que conformidade com a especificação. 9
Conveniência por Propósito de Software ² Os padrões de programação e documentação foram seguidos no processo de desenvolvimento? ² O software foi testado adequadamente? ² O software é suficientemente seguro para ser colocado em uso? ² O desempenho do software é aceitável para uso normal? ² O software é utilizável? ² O software está bem estruturado e é compreensível? 10
Atributos de Qualidade de Software Segurança Compreensibilidade Portabilidade Proteção Testabilidade Usabilidade Confiabilidade Adaptabilidade Reusabilidade Resiliência Modularidade Eficiência Robustez Complexidade Capacidade de Aprendizado 11
Conflitos de Qualidade ² Não é possível para qualquer sistema ser otimizado para todos esses atributos por exemplo, melhorar a robustez pode levar a uma perda de desempenho. ² O plano de qualidade deve então definir os atributos de qualidade mais importantes para o software em desenvolvimento. ² O plano deve também incluir uma definição do processo de avaliação de qualidade, uma maneira acordada de avaliar se alguma qualidade, tal como manutenibilidade ou robustez, está presente no produto. 12
Qualidade de Processo e Produto ² A qualidade de um produto desenvolvido é influenciada pela qualidade do processo de produção. ² Isso é importante em um desenvolvimento de software já que alguns atributos de qualidade de produto são difíceis de avaliar. ² Contudo, há um relacionamento muito complexo e pouco entendido entre processos de software e qualidade de produto. A aplicação de habilidades individuais e experiência é particularmente importante no desenvolvimento de software; Fatores externos tais como a novidade de uma aplicação ou a anecessidade por um cronograma de desenvolvimento acelerado pode impactar na qualidade do produto. 13
Qualidade Baseada em Processo 14
Padrões de Software ² Os padrões definem os atributos necessários de um produto ou processo. Eles têm um papel importante na gerência de qualidade. ² Os padrões podem ser internacionais, nacionais, organizacionais ou de um projeto. ² Os padrões de produto definem características que todos os componentes de software devem exibir, como um estilo de programação comum. ² Os padrões de processo definem como o processo de software deve ser estabelecido. 15
A Importância de Padrões ² Encapsulamento de melhores práticas evita a repetição de erros passados. ² Eles são um framework para definir o que significa qualidade em uma configuração particular, isto é, a visão organizacional de qualidade. ² Eles fornecem continuidade novo pessoal pode entender a organização através do entendimento dos padrões usados. 16
Padrões de Produto e Processo Padrões de Produto Formulário de revisão de projeto Estrutura do documento de requerimentos Formato de cabeçalho de método Estilo de programação Java Formato de plano de projeto Formulário de pedido de mudança Padrões de Processo Conduta de revisão de projeto Submissão de código novo para dar um build no sistema Processo de entrega de versão Processo de aprovação de plano de projeto Processo de controle de mudança Processo de gravação de teste 17
Problemas com Padrões ² Eles podem não parecer tão relevantes e atualizados por engenheiros de software. ² Eles frequentemente envolvem muito preenchimento de formulários burocráticos. ² Se eles não são suportados por ferramentas de software, trabalho tedioso de preenchimento de formulário está frequentemente envolvido com manter a documentação associada com os padrões. 18
Desenvolvimento de Padrões ² Envolva praticantes em desenvolvimento. Os engenheiros devem entender a parte racional em um padrão. ² Revise os padrões e seus usos regularmente. Os padrões podem rapidamente se tornar desatualizados e isso reduz a credibilidade deles entre os praticantes.. ² Padrões detalhados devem ter suporte a ferramentas especializadas. ² Excesso de trabalho burocrático é a maior reclamação contra os padrões. Formulários baseados na web não são bons o suficiente. 19
Framework de Padrões ISO 9001 ² Um conjunto internacional de padrões que podem ser usados como uma base para desenvolver sistemas de ger6encia de qualidade. ² ISO 9001, o mais geral destes padrões, aplica-se a organizações que projetam, desenvolvem e mantém produtos, incluindo software. ² O padrão ISO 9001 é um framework para desenvolver padrões de software. Ele estabelece princípios de qualidade gerais, descreve processos de qualidade em geral e dispões os padrões e procedimentos organizacionais que devem ser definidos. Estes devem ser documentados em um manual de qualidade organizacional. 20
Processos Essenciais da ISO 9001 21
ISO 9001 e Gerência de Qualidade 22
Certificação ISO 9001 ² Os padrões e procedimentos de qualidade devem ser documentados em um manual de qualidade organizacional. ² Um corpo externo deve certificar que um manual de qualidade organizacional está em conformidade com os padrões ISO 9000. ² Alguns clientes requerem que os fornecedores sejam certificados ISO 9000, embora a necessidade para flexibilidade aqui é crescentemente reconhecida. 23
Pontos Principais ² A gerência de qualidade de software está relacionada com a garantia de que o software tem uma quantidade pequena de defeitos e que ele alcança os padrões requeridos de manutenibilidade, confiabilidade, portabilidade, etc. ² SQM inclui a definição de padrões para processos e produtos e estabelece processos para verificar que estes padrões foram seguidos. 24
Pontos Principais ² Os padrões de software são importantes para a garantia de qualidade já que representam uma identificação de melhores práticas. ² Os procedimentos de gerência de qualidade podem ser documentados em um manual de qualidade organizacional, baseado no modelo genérico para um manual de qualidade sugerido no padrão ISO 9001. 25
Capítulo 24 Gerência de Qualidade Aula 2 Revisões, Inspeções, Métricas e Medidas de SoFware 26
Revisões e Inspeções ² Um grupo examina parte ou todo de um processo ou sistema e sua documentação para encontrar problemas potenciais. ² Há tipos diferentes de revisões com objetivos diferentes: inspeções para remoção de defeitos (produto); revisões para avaliação de progresso (produto e processo); revisões de qualidade (produto e padrões). 27
Revisões de Qualidade ² Um grupo de pessoas cuidadosamente examina parte ou todo um sistema de software e sua documentação associada. ² Código, projetos, especificações, planos de teste, padrões, etc. Tudo pode ser revisado. ² Software ou documentos podem ser aprovados em uma revisão. Isso significa que o progresso para o próximo estágio de desenvolvimento foi aprovado pela gerência. 28
O Processo de Revisão de Software 29
Métodos Ágeis e Revisões ² O processo de revisão em desenvolvimento de software ágil é geralmente informal. Em Scrum, por exemplo, há uma reunião de revisão após cada iteração do software ser completada (uma revisão de sprint), na qual aspectos de qualidade e problemas podem ser discutidos. ² Em XP, a programação em pares garante que o código está sendo examinado e revisado constantemente por um outro membro da equipe. ² XP confia nos indivíduos tomando a iniciativa de melhorar e refatorar código. As abordagens ágeis não são geralmente dirigidas a padrões, então aspectos de conformidade com os padrões não são geralmente considerados. 30
Inspeções de Programa ² Há revisões em pares nas quais os engenheiros examinam o fonte de um sistema com o objetivo de descobrir anomalias e defeitos. ² As inspeções não necessitam da execução de um sistema, então podem ser realizadas antes da implementação. ² Elas podem ser aplicadas a qualquer representação do sistema (requerimentos, projeto, dados de configuração, dados de teste, etc.). ² Elas têm sido uma técnica efetiva para descobrir erros de programa. 31
Listas de Verificação de Inspeção ² A lista de verificação de erros comuns deve ser usada para dirigir a inspeção. ² Listas de verificação de erro são dependentes de linguagem de programação e refletem os erros característicos que podem aparecer na linguagem. ² Em geral, quanto mais fraca é a verificação de tipo, maior é a lista de verificação. ² Exemplos: iniciação, nomes de constantes, términos de laços, limites de matrizes, etc. 32
Uma Lista de Verificação de Inspeção (1 / 2) Classe da Falha Verificação de Inspeção Falhas de dados Todas as variáveis de programa são iniciadas antes dos valores serem usados? As constantes têm nomes? O limite superior de matrizes deve ser igual ao tamanho da matriz - 1? Se strings são usados, um delimitados está atribuído explicitamente? Há alguma possibilidade de estouro de buffer? Falhas de controle Para cada comando condicional, a condição está correta? Cada laço certamente termina? Os comandos compostos estão fechados corretamente? Nos comandos case, todos os casos são levados em conta? Se um break é necessário após cada case no comando case, ele foi incluído? Falhas de E/S Todas as variáveis de entrada são usadas? Todas as variáveis de saída têm um valor atribuído antes de serem exibidas? Entradas não esperadas podem causar corrupção? 33
Uma Lista de Verificação de Inspeção (2 / 2) Classe da Falha Verificação de Inspeção Falhas de interface Todas as chamadas a funções e métodos têm a quantidade correta de parâmetros? Os parâmetros formais e definidos no código são os mesmos? Os parâmetros estão na ordem correta? Se os componentes acessam memória compartilhada, eles têm o mesmo modelo da estrutura de memória compartilhada? Falhas de gerência de armazenamento Falhas de gerência de exceção Se uma estrutura de lista encadeada é modificada, todas as ligações são refeitas corretamente? Se é utilizado armazenamento dinâmico, o espaço está alocado corretamente? O espaço é explicitamente dealocado após não ser mais necessário? Todas as condições de erro foram levadas em consideração? 34
Métodos Ágeis e Inspeções ² Os processos ágeis raramente usam processos de inspeção formal ou revisão por pares. ² Ao invés disso, eles confiam na cooperação de membros da equipe para verificar os códigos uns dos outros, e diretrizes informais, tais como verifique antes de enviar, que sugere que os programadores devem verificar o próprio código. ² Os praticantes de XP discutem que a programação em pares é um substituto eficiente para a inspeção, já que é, de fato, um processo de inspeção contínuo. ² Duas pessoas olham toda linha de código e a verificam antes de ser aceita. 35
Métricas e Medições de Software ² A medição de software está relacionada com derivar um valor numérico para um atributo de um produto ou processo de software. ² Isso permite comparações obetivas entre técnicas e processos. ² Embora algumas empresas tenham introduzido programas de medidas, muitas organizações ainda não fazem um uso sistemático de medidas de software.. ² Há poucos padrões estabelecidos nesta área. 36
Métricas de Software ² Uma métrica de software é qualquer tipo de medida relacionada com um sistema de software, processo ou documentação relacionada. linhas de código em um programa, o índice Fog, quantidade de pessoas-dia necessárias para desenvolver um componente. ² Permite que o software e o processo de software sejam quantificados. ² Podem ser usadas para prever atributos de produto ou para controlar o processo de software. ² Métricas de produto podem ser usadas para previsões gerais ou para identificar componentes anômalos. 37
Medições de Previsão e Controle 38
Uso de Medidas ² Para atribuir um valor aos atributos de qualidade de sistema Medindo as características dos componentes de sistema, como a complexidade ciclomática, e então agregando estas medidas, você pode avaliar os atributos de qualidade de sistema, tal como manutenibilidade. ² Para identificar os componentes de sistema cujas qualidades são fora do padrão As medidas podem identificar componentes individuais com características que se desviam da norma. Por exemplo, você pode medir componentes para descobrir os que têm maior complexidade. Estes podem com maior chance conter bugs porque a complexidade faz com que sejam mais difíceis de entender. 39
Suposições de Métricas ² Uma propriedade de software pode ser medida. ² O relacionamente existe entre o que podemos medir e o que queremos saber. Nós só podemos medir atributos internos, mas estarmos frequentemente mais interessados em atributos externos de software. ² Este relacionamento foi formalizado e validado. ² Pode ser difícil relatar o que pode ser medido em atributos de qualidade externos desejáveis. 40
Relacionamentos Entre Software Interno e Externo 41
Problemas com Medidas na Indústria ² It is impossible to quantify the return on investment of introducing an organizational metrics program. ² There are no standards for software metrics or standardized processes for measurement and analysis. ² In many companies, software processes are not standardized and are poorly defined and controlled. ² Most work on software measurement has focused on codebased metrics and plan-driven development processes. However, more and more software is now developed by configuring ERP systems or COTS. ² Introducing measurement adds additional overhead to processes. 42
Métricas de Produto ² Uma métrica de qualidade deve ser uma previsão da qualidade de produto. ² Classes de métrica de produto: métricas dinâmicas que são coletadas por medidas feitas de um programa em execução; métricas estáticas que são coletadas por medidas feitas das representações do sistema; métricas dinâmicas ajudam a avaliar a eficiência e confiabilidade; métricas estáticas ajudam a a avaliar a complexidade, compreensibilidade e manutenibilidade. 43
Métricas Dinâmicas e Estáticas ² Métricas dinâmicas estão bem relacionadas com os atributos de qualidade de software É relativamente fácil medir o tempo de resposta de um sistema (atributo de desempenho) ou a quantidade de falhas (atributo de confiabilidade). ² Métricas estáticas têm um relacionamento indireto com atributos de qualidade Você precisa tentar e derivar um relacionamento entre essas métricas e propriedades tais como compreensibilidade e manutenibilidade. 44
Métricas de Produto de Software (1 / 2) Métrica de Software Descrição Fan-in/Fan-out Comprimento de Código Fan-in é uma medida da quantidade de funções ou métodos que chamam outra função ou método (digamos X). Fan-out é a quantidade de funções que são chamadas pela função X. Um valor alto de fan-in significa que X está fortemente acoplado ao resto do projeto e mudanças em X terão efeitos em cascata. Um valor alto de fan-out sugere que a complexidade de X como um todo pode ser alta por causa da complexidade que a lógica de controle precisa para coordenar os componentes chamados. Esta é uma medida de tamanho de um programa. Geralmente, quanto maior o tamanho de código de um componente, mais complexo e sujeito a erros ele estará. O comprimento do código tem se mostrado como uma das mais confiáveis métricas para prever sujeição a erros em componentes. 45
Métricas de Produto de Software (2 / 2) Métrica de Software Complexidade Ciclomática Comprimento de Identificadores Profundidade do Aninhamento Condicional Índice Fog Descrição Esta é uma medida da complexidade de controle de um programa. Esta complexidade de controle pode estar relacionada com a compreensibilidade de um programa. Complexidade ciclomática é discutida no capítulo 8. Esta é uma medida do comprimento médio dos identificadores (nomes para variáveis, classes, métodos, etc) em um programa. Quanto maiores são os nomes de i d e n t i f i c a d o r e s, m a i s s i g n i f i c a t i v o s e m a i s compreensíveis em um programa eles são. Esta é uma medida do comprimento do aninhamento de comandos if em um program. Comandos if profundamente aninhados são difíceis de serem entendidos e potencialmente sujeitos a erros. Esta é uma medida do comprimento médio de palavras e sentenças em documentos. Quanto maior o valor do índice de Fog em um documento, mais difícil de ser entendido é o documento. 46
O Conjunto de Métricas Orientadas a Objeto CK (1 / 2) Métrica Orientada a Objetos Métodos Ponderados por Classe - Weighted Methods per Class (WMC) Profundidade da Árvore de Herança - Depth of Inheritance Tree (DIT) Número de Filhos - Number of Children (NOC) Descrição Esta é a quantidade de métodos em cada classe, com o peso da complexidade de cada método. Assim sendo, um método simples pode ter a complexidade de 1, e um método grande e complexo um valor muito maior. Quanto maior o valor para esta métrica, mais complexa é a classe. Objetos complexos são mais difíceis de serem entendidos. Eles podem não estar logicamente coesos, então não podem ser usados eficientemente como superclasses em uma árvore de herança. A DIT representa a quantidade de níveis discretos na árvore de herança nos quais as subclasses herdam atributos e operações (métodos) das superclasess. Quanto mais profunda é a árvore de herança, mais complexo é o projeto. Muitas classes de objetos podem ter que ser entendidas para que as classes de objetos nas folhas sejam entendidas. O NOC é a medida de quantidade de subclassess imediatas de uma classe. Ele mede a largura de uma hierarquia de classe, enquanto DIT mede a profundidade. Um valor dlto de NOC pode indicar maior reuso. Pode significar que mais esforço deve ser dado na validação das classes base por causa da quantidade de classes que dela dependem. 47
O Conjunto de Métricas Orientadas a Objeto CK (1 / 2) Métrica Orientada a Objetos Acoplamento entre as classes de objeto - Coupling Between Object Classes (CBO) Resposta para uma classe - Response For a Class (RFC) Falta de coesão nos métodos - Lack of COhesion in Methods (LCOM) Descrição Classes são acopladas quando os métodos em uma classe usam métodos ou variáveis de instância definidas em uma classe distinta. CBO é uma medida de quanto acoplamento existe. Um valor alto de CBO significa que as classes são altamente dependentes, e desta forma, é mais provável que a mudança em uma classe afetará outras classes no programa. RFC é uma medida da quantidade de métodos que poderiam potencialmente ser executados em resposta a uma mensagem recebida por um objeto daquela classe. Novamente, RFC está relacionada com complexidade. Quanto maior é o valor de RFC, mais complexa é uma classe e, assim sendo, é mais provável que ela conterá erros. LCOM é calculada considerando pares de métodos em uma classe. LCOM é a diferença entre a quantidade de pares de métodos sem atributos compartilhados com a quantidade de pares de métodos com atributos compartilhados. O valor desta métrica foi muito debatido e existe em diversas variações. Não fica claro se ela adiciona realmente alguma informação útil além das fornecidas por outras métricas. 48
Análise de Componente de Software ² O componente de sistema pode ser analisado separadamente usando uma faixa de métricas. ² Os valores destas métricas podem então ser comparadas para diferentes componentes e, talvez, com dados de medições históricas coletados de projetos anteriores. ² Medidas anômalas, as quais desviam-se significativamente da norma, podem implicar que há problemas com a qualidade destes componentes. 49
O Processo de Medição de Produto 50
Surpresas de Medições ² Reduzir a quantidade de falhas em um programa leva a um número crescente de chamadas de suporte. O programa é agora imaginado mais confiável e então tem um mercado maior e mais diversificado. O percentual de usuários que ligam para o suporte pode ter diminuído, mas o total pode crescer. Um sistema confiável é usado em uma forma diferente de um sistema em que os usuários trabalham com as falhas. Isso leva a mais chamadas ao suporte. 51
Pontos Principais ² Revisões do que deve ser entregue no processo de software envolve uma equipe de pessoas que verificam que os padrões de qualidade estão sendo seguidos. ² Em uma inspeção de programa ou revisão de par, uma pequena equipe sistematicamente verifica o código. Eles leem o código detalhadamente e procuram por possíveis erros e omissões. ² A medição de software pode ser usada para conseguir dados sobre o software e o processo de software. ² As métricas de qualidade de produto são particularmente úteis para realçar componentes anômalos que podem ter problemas de qualidade. 52