Métricas de Software como Ferramenta
de Apoio ao Gerenciamento de Projetos
Aluno: Felipe Barbalho
[email protected]
Professores: Alexandre Vasconcelos e Cristine
Gusmão
1
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
2
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.

3
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
4
O que são Métricas de Software
5
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
6
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
7
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)
8
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.

9
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
10
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.
11
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
12
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
13
Os Quatros papéis de Medição

Segundo Humphrey, são quatro os principais papéis de Medições de
Software:
Entender
Controlar
Processos,
Produtos e
Serviços de
Software
Avaliar
Prever
14
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
15
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)
16
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
17
O Paradigma Goal Question
Metrics (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?
18
O Paradigma Goal Question
Metrics (GQM)
Goal 1
Goal 2
Questão 1
Questão 2
Questão 3
Questão 4
Métrica 1
Métrica 2
Métrica 3 Métrica 4
Métrica 5
19
Exemplo do uso do GQM

Objetivo: Assegurar que todos os defeitos
são corrigidos antes do software ser
liberado para uso.
Perguntas:

Métricas:

◦ Quantos defeitos temos atualmente?
◦ Qual o status de cada defeito?
◦ Qual a cobertura dos testes?
◦ Número de defeitos
◦ Número de defeitos por status
◦ Número de casos de testes planejados x
executados
◦ Número de requisitos testados
20
Visão Geral de
Gerenciamento de Projetos
21
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.
22
O QUE É GERENCIAMENTO DE
PROJETOS
É o conjunto de habilidades, ferramentas
é técnicas para o planejamento, execução
e controle de projetos.
23
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

24
ÁREAS DE CONHECIMENTO DE
GERENCIAMENTO DE PROJETOS
Segundo o PMBoK, podemos separar o conhecimento em
gerenciamento de projetos em nove áreas distintas:
Escopo
Tempo
Custos
Qualidade
Integração
Recursos
Humanos
Comunicação
Riscos
Aquisições
25
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
Métricas no Gerenciamento
de Projetos de Software
27
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.
28
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.
29
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.

30
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.

31
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.

32
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.
33
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.
34
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.
35
Boas práticas na implantação
de Programas de Medição
nas organizações
36
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
37
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
38
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
39
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).
40
Dúvidas?
41