Métricas para Qualidade de Software

1. Métricas para Qualidade de Software Carlos Augusto Felipe Dias Hugo Cardoso Maylle Lo Feudo

2. O que será apresentado: • Qualidade de Software • Métricas de Software • Métricas de Qualidade de Software • Medidas de Qualidade de Software • Métricas para Manutenção de Software

3. 1. Qualidade de Software “O que é Qualidade de Software?” “Conformidade com requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente”. (Pressman)

4. Qualidade de Software Segundo Philip Crosby, o problema é o que elas pensam que sabem. Nesse sentido, a qualidade tem muito a ver com sexo: • Todo mundo é a favor (sob certas circunstâncias, certamente). • Todo mundo se considera um entendido no assunto (mesmo que não queiram explicá-lo). • Todo mundo pensa que a execução é apenas uma questão de seguir as inclinações naturais (apesar de tudo, seguimos de alguma forma). • E, certamente, a maioria das pessoas acha que problemas nessas áreas são causados pelos outros (se apenas pudessem usar o tempo para fazer as coisas direito).”

5. Qualidade de Software Importâncias durante um o processo: • Definir explicitamente o que quer dizer “qualidade de software”; • Criar um conjunto de atividades que ajudarão a garantir que todo produto de trabalho de engenharia de software exibe alta qualidade; • Realizar atividades de garantia de qualidade em todo o projeto de software; • Usar métricas para desenvolver estratégias para aperfeiçoar seu processo de software e, como conseqüência, a qualidade do produto final.

6. Qualidade de Software A qualidade é responsabilidade de todos os envolvidos no processo de engenharia de software. Se a qualidade de software for enfatizada, diminui-se a quantidade de trabalho que tem que ser refeito, resultando em menores custos e melhor definição de prazo para colocação no mercado.

7. Qualidade de Software Pesquisa de Capers Jones, onde foram estudados 6700 projetos e 500 empresas. Projetos de sucessos são eficazes em: • planejamento de projetos • estimativa de custo • acompanhamento de projetos • uso de métricas • controle de qualidade • gerência de alterações • metodologia de desenvolvimento • gerentes de projetos qualificados • pessoal técnico qualificado e especializado • reuso de material

8. Qualidade de Software Ao fazermos Análise de Risco em projetos de software, constatamos os seguintes critérios que influenciam no sucesso do projeto: • Prazo – O cronograma será mantido e o produto entregue no prazo? • Custo – O orçamento vai ser mantido? • Qualidade – O produto vai atender seu objetivo? • Suporte – O produto poderá ser facilmente modificado, adaptado e aprimorado?

9. Qualidade de Software Para haver uma avaliação contínua da qualidade do software durante todas as etapas de desenvolvimento, devemos estabelecer métricas.

10. 2. Métricas de Software A atividade de medir ajuda os gerentes e componentes da equipe a melhorar o processo de desenvolvimento de software.

11. Métricas de Software Medições de atributos específicos do processo, projeto e produto são utilizados para calcular as métricas. Medição ocorre como resultado da coleta de um ou mais pontos, fornecendo indicações quantitativas (como de extensão, quantidade, dimensão). Ex: quantidade de erros encontrados em um único módulo

12. Métricas de Software Métrica é definida como “medida quantitativa do grau em que um sistema, componente ou processo possui determinado atributo” [IEEE]. Uma métrica de software relaciona as medidas individuais de alguma forma. Ex: número médio de erros encontrados por revisão

13. Métricas de Software Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores, que são métricas ou combinação de métricas que fornecem compreensão de um processo, produto ou projeto de software, fornecendo a compreensão necessária ao gerente de projeto ou ao engenheiro de software para fazer os ajustes necessários de modo a aumentar a qualidade.

14. Métricas de Software A métrica fornecesse compreensão ao gerente, levando a uma tomada de decisão bem informada.

15. Métricas de Software Ex.: quatro equipes de um grande projeto irão realizar revisões de projeto, podendo cada equipe escolher o tipo de revisão que irá usar. Utilizando a métrica “erros encontrados por pessoa-hora empregada”, nota-se que duas equipes, que estão utilizando métodos mais formais de revisão, tiveram um valor para “erros encontrados por pessoa-hora empregada” 40% maior que o valor das demais equipes. Considerando as condições iguais entre as equipes, esse resultado para o gerente do projeto é um indicador de que utilizar métodos mais formais pode fornecer um retorno maior do investimento de pessoas em tempo do que outros métodos menos formais. Com essa métrica, o gerente pode então ter base para decidir qual método utilizar por todas as equipes.

16. 2.1. Métricas de Processo O desenvolvimento de medidas e métricas de processo requer o domínio e entendimento do processo de software.

17. Métricas de Processo As métricas são originas a partir das saídas que são derivadas do processo. Essas saídas diversas medidas, como erros descobertos antes da entrega do software, defeitos relatados pelos usuários, esforço humano despendido, cumprimento do cronograma.

18. Métricas de Processo Para a geração de métricas, Grady sugere uma etiqueta de métrica de software: • Use bom senso e sensibilidade ao interpretar resultados de métricas • Não deixe parar a coleta de resultados de métricas • Não avalie nem ameace indivíduos por métricas • Estabeleça objetivos e metas bem definidos para que as métricas possam ajudar a alcançar esses objetivos e essa metas • Não fique obcecado com uma métrica quando houver diversas outras em análise • Métricas são apenas criar indicadores, de forma a estudar melhorias para o processo.

19. 2.2. Métricas de Projeto São usadas pelo gerente de projeto e pela equipe de software com finalidade estratégica, para adaptar o fluxo do trabalho e as atividades técnicas do projeto.

20. Métricas de Projeto • Estimativa: métricas de projetos anteriores • Comparação com valores atuais e valores anteriores de métricas • Controle e monitoramento do progresso

21. Métricas de Projeto Objetivos: • minimizar o cronograma de desenvolvimento • avaliar a qualidade do produto durante sua evolução e modificar abordagem técnica para aperfeiçoar a qualidade

22. Métricas de Projeto Maior qualidade menos defeitos redução de retrabalho menor custo do projeto menor risco

23. 3. Métricas de Qualidade de Software Através de métricas bem definidas e calculadas, podemos ter a noção numérica sobre o desempenho da criação software, que ajuda a saber se está havendo melhora.

24. 4. Medidas de Qualidade de Software Dentre várias medidas de qualidade de software, temos algumas que fornecem indicadores úteis à equipe de software.

25. 4.1. Correção Um programa é correto se ele satisfaz sua especificação e satisfaz aos interesses do cliente. Correção é o grau em que um software desempenha sua função. • Ex.: “defeitos por KLOC”. Como defeito é um erro de software encontrado pelo usuário, então o programa apresenta falhas em relação aos requisitos funcionais, gerando então problemas de correção de software.

26. 4.2. Manutenibilidade Manutenção de software é a atividade que mais consome esforço em Engenharia de Software. A manutenibilidade pode ser definida como a facilidade de se corrigir um programa, após algum evento como erros encontrados, mudança de requisitos. • Ex.: a métrica “tempo médio para modificação” (mean-time-to-change, MTTC), que é o tempo gasto para analisar o pedido da modificação, projetá-la adequadamente, implementá-la, testá-la e distribuí-la. aos usuários.

27. 4.3. Integridade Ataques acidentais, ou não, podem ser feitos aos seguintes componentes de software: programas, dados e documentos. A integridade mede a capacidade de o sistema resistir a esses ataques. • Integridade = ∑ [ (1 – ameaça) x (1 – segurança)]

28. 4.4. Usabilidade Possui várias definições: • A capacidade do software ser entendido, aprendido, usado e atrativo ao usuário sobre certas condições especificas. (ISO/IEC 9126-1, 2000) • A extensão que um produto pode ser utilizado por usuários específicos para atingir objetivos especificados com eficácia, eficiência e satisfação num contexto de uso especificado. (ISO 9241-11, 1998) • A facilidade com que um usuário pode aprender a operar, preparar entradas para, e interpretar saídas de um sistemas ou componente. (IEEE Std.610.12-1990)

29. Usabilidade Os critérios usados para medí-la dependem da abordagem: • Uma mais orientada ao produto, mede usabilidade em termos de atributos ergonômicos do produto. • Um enfoque voltado ao usuário, realiza a medição através do esforço mental e atitudes do usuário. • Medições da interação do usuário com o produto com ênfase em facilidade de uso ou aceitabilidade, seguem uma visão voltada na performance do usuário. • Há uma orientado ao contexto, onde usabilidade é função do usuários em particular, suas atividades e do ambiente.

30. 5. Métricas para Manutenção de Software • O número de defeitos ou problemas que surgem são amplamente determinados pelo processo de desenvolvimento antes da fase de manutenção. Não se pode fazer muito para alterar a qualidade do produto durante essa fase. • O que poderia ser feito durante a fase de manutenção, seria reparar os defeitos com excelente qualidade e o mais rápido possível. Algumas ações, apesar de ainda não está disponível para melhorar a taxa de erro dos produtos, podem melhorar a satisfação do consumidor em grande parte.

31. Métricas para Manutenção de Software Métricas importantes • Evitar “backlog” • Consertar tempo de resposta • Percentual de reparos graves • Número de defeito reparados

32. 5.1 Evitar “backlog” • Coleção de trabalho inacabado – Definição do Dicionário • É uma forma de carga de trabalho para manutenção de software. • Está relacionado com taxa de chegada de defeito e a taxa em que reparos para problemas informados se tornem disponíveis

33. 6. Eficiência na Remoção de Defeitos(DRE) “A DRE é uma medida da capacidade de filtragem das atividades de controle e garantia de qualidade de software, à medida que são aplicadas às atividades de arcabouço de processo” [Pressman]

34. Eficiência na Remoção de Defeitos (DRE) Quando considerada para o projeto todo: DRE = E / ( E + D ) E é a quantidade de erros encontrados antes da entrega do software ao usuário final D é a quantidade de defeitos encontrados após a entrega.

35. Eficiência na Remoção de Defeitos (DRE) Quando usada no projeto para avaliar a capacidade de uma equipe encontrar erros antes que eles sejam repassados para a próxima tarefa de engenharia de software : DREi = Ei / ( Ei + Ei+1 ) Ei é o número de erros encontrados durante a atividade de engenharia de software Ei+1 é a quantidade de erros encontrados durante a atividade de engenharia de software i+1, que são atribuíveis a erros que não foram descobertos na atividade de engenharia de software i.

36. Eficiência na Remoção de Defeitos (DRE)

37. Eficiência na Remoção de Defeitos (DRE) Exemplo:

38. High-Level Design Inspection Effectiveness; IE (I0) IE(I0) = 730 / (122 + 859) = 74% __________________________________________________ Low-Level Design Inspection Effectiveness; IE (I1) IE(I1) = 729 / ( 251 + 939 ) = 61% _________________________________________________ Code Inspection Effectiveness; IE(I2) IE(I2) = 1095 / ( 461 + 1537 ) = 0,55 ou 55% _________________________________________________ Unit Test Effectiveness; TE(UT) TE(UT) = 332 / 903 + 2 = 0,37 ou 37%   _________________________________________________ Eficiência na Remoção de Defeitos no Processo (DRE): DRE = ( 1 – 81 / 3465 ) = 97.7%

39. “O quanto antes pudermos detectar erros, melhor”. isto é, quanto mais cedo o erro for descoberto menor será o esforço dispendido na sua remoção e no retrabalho