qualidade de software - bachfatec.files.wordpress.com · atribuitos de qualidade de software • É...

29
©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 QUALIDADE DE SOFTWARE

Upload: lyhanh

Post on 09-Nov-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

QUALIDADE DE SOFTWARE

©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.