Upload
lyhanh
View
215
Download
0
Embed Size (px)
Citation preview
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 2
Objetivos
● Apresentar o processo de gerenciamento de qualidade e as atividades centrais da garantia de qualidade
● Explicar a importância dos padrões na qualidade de software
● Explicar o conceito de uma métrica de qualidade;● Explicar como a medição pode ser usada na
avaliação de qualidade de software e as limitaçõesda medição de software
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 3
Gerenciamento de qualidade de software
● Dedica-se a assegurar que o nível requeridode qualidade seja atingido em um produto de software.
● Envolve a definição de padrões e procedimentos apropriados de qualidade e a garantia de que sejam seguidos.
● Deve objetivar o desenvolvimento de uma‘cultura de qualidade’ onde a qualidade évista como uma responsabilidade de todos.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 4
O que é qualidade?
● Qualidade, de maneira simplista, significa que um produto deve atender às sua especificação.
● Isso é problemático para os sistemas de software• Existe uma tensão entre os requisitos de qualidade do
cliente (eficiência, confiabilidade, etc.) e os requisitos de qualidade do desenvolvedor (facilidade de manutenção, reusabilidade, etc.);
• Alguns requisitos de qualidade são difíceis de especificarde uma maneira não-ambígua;
• As especificações de software são, geralmente, incompletas e freqüentemente inconsistentes.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 5
O compromisso da qualidade
● Devemos implantar procedimentos de gerenciamento de qualidade para melhorar a qualidade, apesar da especificaçãoimperfeita.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 6
Escopo do gerenciamento de qualidade
● Gerenciamento de qualidade éparticularmente importante para sistemasgrandes e complexos. A documentação de qualidade é um registro do progresso e apóia a continuidade do desenvolvimentoquando a equipe de desenvolvimento muda.
● Para sistemas menores, o gerenciamento de qualidade precisa de menos documentaçãoe deve enfocar no estabelecimento de umacultura de qualidade.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 7
Atividade de gerenciamento de qualidade
● Garantia de qualidade• Estabelece procedimentos e padrões organizacionais
para qualidade.
● Planejamento de qualidade• Seleciona procedimentos e padrões aplicáveis para um
projeto específico e o modifica quando necessário.
● Controle de qualidade• Assegura que os procedimentos e os padrões sejam
seguidos pela equipe de desenvolvimento de software.
● O gerenciamento de qualidade deve ser separadado gerenciamento de projeto para assegurarindependência.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 8
● A qualidade de um produto desenvolvido éinfluenciado pela qualidade do processo de produção.
● Isso é importante no desenvolvimento de software, visto que os atributos de qualidadede produtos são difíceis de avaliar.
● Contudo, existe um relacionamento muitocomplexo e fracamente compreendido entre processos de software e qualidade de produto.
Qualidade de processo e de produto
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 9
Qualidade baseada em processo
● Existe uma ligação nítida entre processo e produtonos bens manufaturados.
● Para o software isso é mais complexo porque:• Fatores externos, tais como a novidade de uma aplicação
ou a necessidade de um cronograma de desenvolvimentoacelerado, podem piorar a qualidade do produto.
● Deve-se tomar cuidado para não impor padrões de processo inadequados – esses padrões poderiamreduzir, ao invés de melhorar a qualidade do produto.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 10
● Definir padrões de processo, tais como o modocomo as revisões devem ser conduzidas, o gerenciamento da configuração, etc.
● Monitorar o processo de desenvolvimento paraassegurar que os padrões estejam sendo seguidos.
● Relatar sobre o processo para a gerência de projetoe para o comprador do software.
● Não usar práticas inadequadas simplesmenteporque padrões foram estabelecidos.
Qualidade prática de processo
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 11
● Os padrões são a chave para o gerenciamentoefetivo de qualidade.
● Eles podem ser padrões internacionais, nacionais, organizacionais ou de projeto.
● Padrões de produto definem características quetodos os componentes devem exibir, por exemplo, um estilo de programação comum.
● Padrões de processo definem como o processo de software deve ser institucionalizados.
Garantia de qualidade e padrões
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 12
● Engloba as melhores práticas – evita a repetição de erros do passado.
● Eles são um framework para os processosde garantia de qualidade – eles envolvem a verificação de aderência aos padrões.
● Eles fornecem continuidade – um pessoalnovo pode compreender a organização pelacompreensão dos padrões que são usados.
Importância dos padrões
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 13
Problemas com padrões
● Podem não ser vistos como relevantes ouatualizados pelos engenheiros de software.
● Envolvem, freqüentemente, muitopreenchimento de formulários burocráticos.
● Se não são apoiados por ferramentas de software, o tedioso trabalho manual é, muitas vezes, envolvido para manter a documentação associada aos padrões.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 14
● Envolver os engenheiros no desenvolvimento. Elesdevem compreender as razões contidas em um padrão.
● Revisar padrões e seu uso regularmente. Os padrões podem se tornar rapidamentedesatualizados, e isso reduz sua credibilidade entre os engenheiros.
● Padrões detalhados devem ter ferramentas de apoioassociadas. Trabalho padronizado em excesso é a mais importante reclamação contra os padrões.
Desenvolvimento de padrões
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 15
Padrões de documentação
● Particularmente importantes – os documentos são a manifestação tangível do software.
● Padrões de processo de documentação• Relacionado ao modo como os documentos devem ser
desenvolvidos, validados e mantidos.
● Padrões de documentos• Relacionado ao conteúdo, à estrutura e à aparência de
documentos.
● Padrões de intercâmbio de documentos• Relacionado à compatibilidade de documentos
eletrônicos.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 16
Planejamento de qualidade
● Um plano de qualidade estabelece as qualidades do produto desejadas e comoelas são avaliadas, e define os atributos de qualidade mais significativos.
● O plano de qualidade deve definir o processo de avaliação de qualidade.
● Deve estabelecer quais padrõesorganizacionais devem ser aplicados e, ondenecessário, definir novos padrões a seremusados.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 17
Atributos de qualidade de software
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 18
Controle de qualidade
● Envolve a verificação do processo de desenvolvimento de software para assegurarque procedimentos e padrões estão sendoseguidos.
● Existem duas abordagens para controle de qualidade• Revisões de qualidade;• Avaliação automatizada e medições de
software.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 19
Revisões de qualidade
● É o principal método de validação da qualidade de um processo ou de um produto.
● Um grupo examina uma parte ou o todo de um processo ou de um sistema, bem comosua documentação para descobrirproblemas potenciais.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 20
● Um grupo de pessoas examina cuidadosamenteuma parte ou o todo de um sistema de software, bem como sua documentação associada.
● Código, projetos, especificações, planos de teste, padrões, etc. podem ser todos revisados.
● Os softwares ou documentos podem ser ‘assinados’em uma revisão que significa que o progresso parao próximo estágio de desenvolvimento foi aprovadopela gerência.
Revisões de qualidade
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 21
Medições e métricas de software
● A medição de software se dedica a derivar um valornumérico para algum atributo de um produto ou de processo de software.
● Permite comparações objetivas entre técnicas e processos.
● Embora algumas empresas tenham introduzidoprogramas de medição, a maioria das organizaçõesainda não fazem uso sistemático de medição de software.
● Existem poucos padrões estabelecidos nessa área.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 22
● É qualquer tipo de medição relacionada a um sistema de software, processo ou documentaçãoassociada
● Permite que o software e o processo de software sejam quantificados.
● Pode ser usado para prever atributos de produto e para controlar o processo de software.
● As métricas de produto podem se usadas paraprevisões gerais ou para identificar componentesanômalos.
Métrica de software
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 23
O processo de medição
● Um processo de medição de software podeser parte de um processo de controle de qualidade.
● Os dados coletados durante este processodevem ser mantidos como um recurso da organização.
● Uma vez que um banco de dados de medições foi estabelecido, comparaçõesentre projetos tornam-se possíveis.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 24
Precisão de dados
● Não colete dados desnecessários• As questões a serem respondidas devem ser
decididas previamente e os dados necessáriosdevem ser identificados.
● Conte às pessoas por que os dados estãosendo coletados
● Não dependa da memória• Colete dados quando são gerados, e não
depois que um projeto foi finalizado.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 25
● Uma métrica de qualidade deve ser um previsor de qualidade de produto.
● Classes de métrica de produto• Métricas dinâmicas que são coletadas por meio das
medições realizadas em um programa em execução;• Métricas estáticas que são coletadas pelas medições
realizadas em representações do sistema.• As métricas dinâmicas ajudam a avaliar a eficiência e a
confiabilidade; métricas estáticas ajudar a avaliar a confiabilidade, a facilidade de compreensão e a facilidadede manutenção.
Métricas de produto
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 26
Métricas estáticas e dinâmicas
● Métricas dinâmicas são bem relacionadas aosatribuitos de qualidade de software• É relativamente fácil medir o tempo de resposta de um
sistema (atributo de desempenho) ou o número de falhas(atributo de confiabilidade).
● Métricas estáticas têm um relacionamento indiretocom atributos de qualidade• Você necessita tentar e derivar um relacionamento entre
essas métricas e as propriedades, tais comocomplexidade, facilidade de compreensão e de manutenção.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 27
Análise de medições
● Nem sempre é óbvio o que os dados significam• A análise de dados coletados é muito difícil.
● Estatísticos profissionais devem ser consultados, se estiverem disponíveis.
● A análise de dados deve levar em conta as circunstâncias locais.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 28
Pontos-chave
● Gerenciamento de qualidade de software dedica-se a assegurar que o software atende aos padrões necessários.
● Os procedimentos de garantia de qualidadedevem ser documentados em um manual de qualidade da organização.
● Padrões de software são um encapsulamento de boas práticas.
● Revisões são a abordagem maisamplamente usada para avaliação de qualidade do software.
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 29
Pontos-chave
● A medição de software obtém informaçõessobre ambos, o processo e o produto de software.
● Métricas de qualidade de produto devem ser usadas para identificar componentespotencialmente problemáticos.
● Não existem métricas de software padronizadas e universalmente aplicáveis.