Métricas de Software como Ferramenta de Apoio ao Gerenciamento de Projetos

1. Métricas de Software como Ferramenta de Apoio ao Gerenciamento de Projetos Aluno: Felipe Barbalho felipebarbalho@gmail.com Professores: Alexandre Vasconcelos e Cristine Gusmão

2. Agenda •  O que são Métricas de Software • Visão Geral de Gerenciamento de Projetos •  Métricas no Gerenciamento de Projetos de Software •  Implantação de Programas de Medição

3. Objetivos • Entender as abordagens principais de métricas e como elas são utilizadas; • Entender as premissas básicas sobre Gerenciamento de Projetos; • Entender como as métricas de software podem contribuir para um melhor controle dos projetos; • Entender algumas boas práticas na implantação de Programas de Medição nas organizações.

4. Motivação • Aumentar a qualidade, performance e produtividade é o objetivo chave de qualquer organização que desenvolve software, e o uso de métricas está diretamente ligado ao controle desses processos; • Pesquisas realizadas em empresas de software indicam que mais da metade de grandes projetos de software se deparam com algum tipo de atraso, excesso de custo ou prazo ou algum fracasso na execução quando implantado ; • Falta de controle dos projetos de software. • Métricas de diferentes aspectos do desenvolvimento podem ajudar a determinar o progresso do projeto, e podem ser usadas no gerenciamento para prover base para tomada de decisão

5. O que são Métricas de Software

6. Por que medir software? • Entender e aperfeiçoar o processo de desenvolvimento • Melhorar a gerência de projetos e o relacionamento com clientes • Reduzir frustrações e pressões de cronograma • Gerenciar contratos de software • Indicar a qualidade de um produto de software • Avaliar a produtividade do processo • Avaliar os benefícios (em termos de produtividade e qualidade) de novos métodos e ferramentas de engenharia de software • Avaliar retorno de investimento

7. Por que medir software? • Identificar as melhores práticas de desenvolvimento de software • Embasar solicitações de novas ferramentas e treinamento • Avaliar o impacto da variação de um ou mais atributos do produto ou do processo na qualidade e/ou produtividade • Formar uma baseline para estimativas • Melhorar a exatidão das estimativas • Oferecer dados qualitativos e quantitativos ao gerenciamento de desenvolvimento de software, de forma a realizar melhorias em todo o processo de desenvolvimento de software

8. O que são métricas de software? • Uma métrica é a medição de um atributo (propriedades ou características ) de uma determinada entidade (produto, processo ou recursos). Exemplos: • Tamanho do produto de software (ex: Número de Linhas de código) • Número de pessoas necessárias para implementar um caso de uso • Número de defeitos encontrados por fase de desenvolvimento • Esforço para a realização de uma tarefa • Tempo para a realização de uma tarefa • Custo para a realização de uma tarefa • Grau de satisfação do cliente (ex: adequação do produto ao propósito, conformidade do produto com a especificação)

9. Conceitos • Medida: fornece uma indicação quantitativa da extenção, quantidade, dimenção, capacidade ou tamanho de algum atributo de um produto ou processo. • Medição: ato de determinação de uma medida. • Métrica: medida quantitativa do grau em que um sistema se encontra em relação a um determinado atributo. • Indicadores: métrica ou combinação de métricas que fornece uma compreensão de um processo, projeto, ou produto.

10. Categorização de Métricas • Métricas Básicas (Primitivas ou Diretas) • são aquelas que podem ser mensuradas a partir de observação direta dos atributos envolvidos. • Ex.: custo, esforço, no. linhas de código, capacidade de memória, no. páginas, no. diagramas, etc. • Métricas Derivadas (Indiretas) • Medidas obtidas a partir de outras métricas • Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção

11. Categorização de Métricas • Métricas orientadas a tamanho • consideram o tamanho do software produzido (linhas de código), e referem-se a todas as atividades da engenharia (análise, projeto, código, teste). • Ex.: Produtividade (KLOC/pesoa-mês ); Qualidade (defeitos/KLOC); Custo ($/KLOC) • Métricas orientadas por função • Consiste em um método para medição de software do ponto de vista do usuário, determinando de forma consistente o tamanho e a complexidade de um software.

12. Categorização de Métricas • Métricas de produtividade • Concentram-se na saída do processo de engenharia de software. • Ex.: no. de casos de uso/iteração. • Métricas de qualidade • Oferecem uma indicação de quanto o software se adeqüa às exigências implícitas e explícitas do cliente. • Ex.: erros/fase • Métricas técnicas • Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido. • Ex.: complexidade lógica e grau de manutenibilidade

13. Categorização de Métricas • Métricas privadas • Se refere ao escopo da equipe do projeto de software • Ex,: defeitos para funções importantes do software, erros encontrados durante revisões técnicas formais. • Métricas públicas • Geralmente assimilam informações que anteriormente eram privadas de uma equipe. São coletadas e avaliadas tentando descobrir indicadores. • Ex.: proporções de defeitos de projeto, esforço, tempo transcorrido e dados relacionados

14. Entender Avaliar Prever Controlar Os Quatros papéis de Medição • Segundo Humphrey, são quatro os principais papéis de Medições de Software: Processos, Produtos e Serviços de Software

15. Os Quatros papéis de Medição • Entender • Métricas ajudam a entender o comportamento e funcionamento de processos, produtos e serviços de software • Avaliar • Métricas podem ser utilizadas para tomar decisões e determinar o estabelecimento de padrões, metas e critérios de aceitação • Controlar • Métricas podem ser utilizadas para controlar processos, produtos e serviços de software • Prever • Métricas podem ser utilizadas para prever valores de atributos

16. Métodos para Definição de Medidas • O primeiro passo para o estabelecimento de uma política de mensuração é a identificação adequada das medidas a serem coletadas • Essa definição deve ser feita com base em critérios bem fundamentados, devido ao grande número de opções possíveis e ao custo envolvido na coleta de cada informação. • Com intuito de guiar o processo de definição das medidas, vários métodos foram propostos, como Balanced Scorecard (BSC), Goal-Question-Metric (GQM), Goal-Driven Software Measurement (GDSM) e Practical Software and System Measurement (PSM)

17. O Paradigma Goal Question Metrics (GQM) • Usado para definir o conjunto de métricas a ser coletado • Proposto por: • Basili and Rombach’s, Goal-Question-Metrics Paradigm, IEEE Transactions on Software Engineering, 1988. • Baseia-se no fato de que deve existir uma necessidade clara associada a cada métrica

18. O Paradigma GoalQuestionMetrics (GQM) O modelo é composto por três níveis: • Conceitual (Goal): são definidos os objetivos da organização, ou seja, as metas a serem atingidas pelo programa de medição. Ex: reduzir defeitos, aumentar produtividade, etc. • Operacional (Question): um conjunto de perguntas é elaborado com relação a cada objetivo identificado no nível anterior; Ex: Qual a taxa de defeito atual? Qual a taxa de defeito após a implantação do novo processo? • Quantitativo (Metrics): um conjunto de métricas (objetivas e subjetivas) é estabelecido, de maneira a atender a cada pergunta elaborada no nível anterior. Ex: Que dados serão necessários? Quais os formatos? Como coletar (fórmula e processo)? Onde armazenar e como utilizar?

19. Goal 2 Goal 1 Questão 3 Questão 1 Questão 4 Questão 2 Métrica 1 Métrica 3 Métrica 4 Métrica 5 Métrica 2 O Paradigma Goal Question Metrics (GQM)

20. Exemplo do uso do GQM • Objetivo: Assegurar que todos os defeitos são corrigidos antes do software ser liberado para uso. • Perguntas: • Quantos defeitos temos atualmente? • Qual o status de cada defeito? • Qual a cobertura dos testes? • Métricas: • Número de defeitos • Número de defeitos por status • Número de casos de testes planejados x executados • Número de requisitos testados

21. Visão Geral de Gerenciamento de Projetos

22. DEFINIÇÃO DE PROJETOS • Temporário (início e fim) • Para produzir produtos ou serviços únicos • Com elaboração progressiva • Limitado pelos critérios de tempo, custo, qualidade e recursos.

23. O QUE É GERENCIAMENTO DE PROJETOS É o conjunto de habilidades, ferramentas é técnicas para o planejamento, execução e controle de projetos.

24. GRUPOS DE PROCESSOS Para realizarmos um projeto é necessário executar uma série de processos divididos em áreas de conhecimento específicas. O foco do gerenciamento de projetos é a integração das áreas de conhecimento nos cinco grupos de processos definidos no PMBoK. Os cinco grupos de processo são: • Processos de Iniciação • Processos de Planejamento • Processos de Execução • Processos de Controle • Processos de Encerramento

25. ÁREAS DE CONHECIMENTO DE GERENCIAMENTO DE PROJETOS Segundo o PMBoK, podemos separar o conhecimento em gerenciamento de projetos em nove áreas distintas:

26. Tripla restrição de um projeto A visão de um projeto bem gerenciado consiste em ter seus objetivos alcançados, distribuindo o produto com alta qualidade, no tempo previsto e com o preço justo

27. Métricas no Gerenciamento de Projetos de Software

28. Definições • As métricas são ferramentas essenciais ao gerenciamento de projeto de software. A escolha das métricas está intimamente associada às estratégias e objetivos da organização, e vai depender do estágio de maturidade em que a mesma se encontra; • As métricas coletadas devem prover informações que ajudem o gerente de projeto na tomada de decisões de acordo com os objetivos e estratégias da organização. • Um gerente de projeto deve acompanhar o progresso do projeto, prover visibilidade do projeto para revisões e tomadas de decisões quando o projeto estiver sofrendo desvios do planejamento, e assegurar o sucesso do projeto e a satisfação do cliente. Dessa forma as métricas tornam-se ferramentas fundamentais para o gerenciamento de projetos de software.

29. Objetivos das Métricas no Gerenciamento de Projetos • Melhorar a qualidade do planejamento do projeto; • Reduzir os custos de retrabalho no processo; • Melhorar a qualidade do processo de desenvolvimento; • Melhorar a qualidade do produto resultante; • Reduzir os custos de falha; • Aumentar a produtividade do desenvolvimento; • Aperfeiçoar continuamente os métodos de gestão do projeto.

30. Características para Apoio ao Gerenciamento de Projetos • Métricas devem ser bem definidas. • Métricas devem ser intuitivas e rastreáveis • Métricas devem ser dimensionáveis ou expressas em alguma unidade. • Métricas devem ser robustas, ou seja, devem ser precisas e relativamente insensíveis a pequenas mudanças em ferramentas, métodos ou características do produto.

31. Características para Apoio ao Gerenciamento de Projetos • Métricas devem ser obtidas o mais cedo possível no ciclo de vida do sistema. • Métricas devem ser facilmente calculadas. • Métricas devem sugerir uma estratégia de melhoria. • Métricas devem ser simples.

32. Atividades Desempenhadas • Em se tratando de métricas de software, é necessário definir algumas regras comportamentais para evitar má interpretação e falta de clareza nas métricas coletadas. • Muitas das métricas de software coletadas são resultado das atividades desempenhadas pelos desenvolvedores de software e coletadas por eles próprios. Dessa forma, é preciso construir uma atmosfera confiável, que respeite as habilidades de cada pessoa para se medir e identificar as mudanças necessárias ao processo.

33. Atividades Desempenhadas • Organização: • Não permitir que métricas sejam utilizadas para medir individualmente as pessoas. • Definir objetivos claros para as métricas e envolver seu staff na definição das métricas. • Não enfatizar uma métrica, excluindo outras.

34. Atividades Desempenhadas • Gerente de Projeto: • Alcançar a concordância de toda equipe quanto as métricas a serem acompanhadas, e definir essas métricas em um plano de projeto. • Fornecer feedback regularmente à equipe sobre os dados que eles estão coletando. • Conhecer o foco estratégico da organização e, nos relatórios de métricos, enfatizar as métricas que suportam essa estratégia.

35. Atividades Desempenhadas • Equipe Técnica: • Procurar reportar os dados o mais apurado possível e nos períodos acordados. • Ajudar o gerente a focar nos dados do projeto que irão levar a melhoria do processo. • Não utilizar os dados levantados em benefício próprio.

36. Boas práticas na implantação de Programas de Medição nas organizações

37. Boas práticas na implantação de Programas de Medição nas organizações • Necessidade de foco desde os estados iniciais • Começar com um conjunto pequeno de métricas • Utilização de um conjunto de métricas coerentes • Utilização de um conjunto de medições rigorosamente definido • Não utilizar métricas para motivar comportamentos esperados

38. Boas práticas na implantação de Programas de Medição nas organizações • Automatizar a coleta e reportagem dos dados • Motivar a Gerência • Estabelecer expectativas • Envolvimento de todos desde os estágios iniciais • Educação e treinamento • Ganhar confiança

39. Boas práticas na implantação de Programas de Medição nas organizações • Adotar uma abordagem evolutiva • Descartar o que não é útil • Fornecer informações corretas para pessoas certas • Incentivar os desenvolvedores a fazer uso das métricas • Compreender que a adoção leva tempo • Má interpretação dos dados

40. Fatores críticos para implantação de programas de medição • Sobrecarga: envolve a coleta simultânea de muitos dados, o que resulta em esforço desperdiçado e perda da credibilidade do programa de medição. • Uso incorreto da medição: é a utilização dos resultados de medições para avaliação dos profissionais, resultando em perda da integridade dos dados, pois os profissionais tendem a mascarar os dados com medo de que estes sejam utilizados contra eles • Falhas de medição: são a obtenção de medidas erradas, ambíguas e inconsistentes, resultando em análises não conclusivas. • Falhas de processo: são a obtenção de medidas que motivaram as falhas de processo (exemplo: o objetivo de diminuir a taxa de resolução de problemas induz a ação indesejada de que as equipes tratem primeiramente os problemas mais simples).

41. Dúvidas?