Qualidade de Software
Métricas de Software
Prof. Daniele Chrusciak Szilagyi
Introdução
Não se consegue controlar o que não se consegue medir.
medir.
(Tom DeMarco)
Medida / Medição / Métricas
É preciso ter bem claro as sutis diferenças entre os termos métrica,
medição e medida.
• Medida – dentro dos termos da engenharia de software, a medida irá
fornecer uma indicação quantitativa da extensão, capacidade, quantidade,
dimensão ou tamanho de algum produto ou de processo de software. Uma
medida é estabelecida quando dados de um determinado ponto são
coletados.(Exemplo: quantidade de erros encontrados na revisão de um
único módulo).
• Medição é o ato de definir uma medida, e tem sua ocorrência quando são
coletados resultados em um ou mais pontos. (Exemplo: um determinado
número de revisões de módulos são feitas para coletar medidas da
quantidade de erros, para cada uma das revisões).
• Métrica é um atributo mensurável de uma entidade. Caso a entidade seja
um projeto, uma métrica seria, por exemplo, o seu tamanho.
Métricas de Software
Referem-se a um conjunto amplo de medidas para softwares
• Métricas de software são medições quantitativas
• são coletados dados de qualidade e produtividade
• os dados são analisados
• resultado é comparado a médias anteriores
• é avaliado se ocorreram melhorias de qualidade e produtividade
• Responsabilidade
• análise e avaliação - gerente do projeto
• coleta das medições - analistas, engenheiros, desenvolvedores
Utilidade das Métricas
Sem medir, qualquer julgamento é subjetivo
• Com métricas
• há direcionamento
• podem ser realizadas estimativas
• custo, prazos, performance, etc...
• melhorias verdadeiras podem ser implantadas
• os gerentes e os profissionais de software podem avaliar o que
funciona e o que não funciona
“Métricas de software permitem que você saiba quando rir e quando
chorar”
chorar”
Tom Gilb
Utilidade das Métricas
ou seja,
Os engenheiros de software realizam medidas e elaboram
métricas com a finalidade de obter indicadores, os quais
deverão fornecer um melhor entendimento de um processo, de
um projeto ou produto de software, e com isto, possibilitar aos
gerentes de projeto, ou mesmo aos próprios engenheiros de
software, que estes possam ajustar o processo, projeto ou
produto para um nível melhor.
4 Razões para Medir
• Caracterizar
• Para compreensão dos processos, produtos, recursos e ambientes
• Estabelecer uma base para comparação com avaliações futuras
• Avaliar
• Determinar a situação em relação aos planos
• As medidas são sensores que nos permitem dizer quando nossos
projetos e processos estão saindo dos trilhos
• poder retomar o controle
• Verificar a realização de nossas metas
• Verificar os impactos das melhorias de tecnologia e processos nos
produtos
4 Razões para Medir
• Predizer (Medições prognosticas)
• Para poder planejar
• Envolvem obter conhecimento dos relacionamentos entre os
processos
• Os valores já obtidos podem ser usados para predizer outros
• Base para estimativa de custos, planejamento (prazo) e qualidade
• Auxiliar na análise de riscos e na relação de custo-benefício
• Melhorar
• Com informações suficientes para auxiliar a identificar ineficiências e
oportunidades de melhoria de qualidade
Melhoria do Processo
Categoria das Métricas
Categoria das Métricas
• Métricas orientadas a tamanho usam número de linhas de código
fonte como fator de medida, bem como, número de instruções de
código objeto entregue, ou ainda, número de páginas de documentação
de sistemas.
• Métrica por ponto de função é originada a partir de medidas da
funcionalidade geral do sistema. A produtividade é expressa com base
na funcionalidade util produzid em um tempo determinado.
• Métricas de qualidade de software, assim como métricas de
produtividade, focalizam o processo, o projeto e o produto.
Desenvolvendo e analisando um referencial de métricas de qualidade,
uma organização pode corrigir as áreas do processo de software, que
são a causa dos defeitos de software.
Métrica Orientada ao Tamanho
Métricas orientadas ao tamanho são medidas do software
e do processo pelo qual ele é desenvolvido
• Registros simples da empresa de software como
• LOC (Lines of Code)
• Páginas de documentação
• Quantidade de erros após a entrega, ...
Métrica Orientada ao Tamanho
Métrica Orientada ao Tamanho
Métrica Orientada ao Tamanho
Vantagens
• Fáceis de serem obtidas
• Excelentes modelos utilizam LOC
• Existe ampla literatura sobre previsões de dados
Desvantagens
• LOC é dependente da linguagem de programação
• Penalizam programas bem planejados, mas
pequenos
• Não se adaptam a linguagens não procedimentais
• Difícil de ser obtida em fase de planejamento
Métrica de Pontos de Função
Foi lançada por A.J. Albrecht da IBM no início da década de 70, e tem
sido evoluída pelo IFPUG (International Function Point User Group), ou
Grupo Internacional de Usuários de Pontos de Função (www.ifpug.org).
É denominada também como Function Point Analisys ou Análise de
Ponto de Função e é uma forma efetiva de:
• estimar o tamanho de uma aplicação através da contagem de todas
as funções da mesma;
• estabelecer taxas de produtividade em pontos de função por hora;
• avaliar requisitos;
• estimar custos de mudanças em sistemas;
• normalizar a comparação entre módulos de software
Métrica de Pontos de Função
Métricas orientadas a Função são medidas indiretas de
software e do processo pelo qual ele é produzido
Em vez de contar LOC, esta métrica concentra-se na
funcionalidade
Ponto de Função:
Medida de complexidade. Os pontos de função são
calculados a partir da avaliação da complexidade do software
em domínio da informação
Os valores do domínio da informação são os componentes
da contagem e são definidos da seguinte maneira:
O Processo de Contagem
Funções Tipo Dados
ARQUIVO LÓGICO INTERNO (ALI): Representam os
requisitos de armazenamento de grupos de dados
logicamente relacionados, cuja manutenção é efetuada
pela própria aplicação.
ARQUIVO DE INTERFACE EXTERNA (AIE):
Representam os requisitos de grupos de dados
logicamente relacionadas, utilizados pela aplicação, mas
que sofrem manutenção a partir de outra aplicação.
Funções Tipo Transação
ENTRADAS EXTERNAS (EE): é um processo elementar que trata os
dados ou informações de controle vindas de fora da fronteira da aplicação
que está sendo contada, com o objetivo de inserir, alterar ou excluir dados
dos arquivos lógicos internos.
• Um processo elementar é a menor unidade de atividade significativa
para o(s) usuário(s).
Exemplo: O agendamento de um recebimento, com a indicação de
como será o parcelamento da receita e o rateio desta entre as unidades
organizacionais, é a menor unidade de atividade do usuário de contas a
receber
• O processo elementar deve ser auto-suficiente e deixar o negócio da
aplicação, objeto da contagem, em um estado consistente.
Exemplo: Ao final do agendamento de um recebimento, ele deixa o
sistema consistente, O agendamento da receita sem o devido registro do
parcelamento não é considerado como um processo completo pelo
usuário
Funções Tipo Transação
CONSULTAS EXTERNAS (CE): é um processo elementar que envia
dados ou informações de controle para fora da fronteira da aplicação que
está sendo contada. A intenção primária de uma CE é exibir informação
para o usuário através de uma recuperação de dados ou informação de
controle. O processamento lógico não pode conter fórmulas matemáticas
ou cálculos, e nem criar dados derivados.
• Exemplos: Telas de Help, Drop-downs (desde que recuperem dados
de arquivos), consultas e relatórios sem totalizadores e que não
atualizam arquivos
SAÍDAS EXTERNAS (SE): é um processo elementar que envia dados
ou informações de controle para fora da fronteira da aplicação. A intenção
primária de uma SE é exibir informação para o usuário através de um
processamento lógico ou outro que resulte numa recuperação de dados
ou informações de controle.
• Exemplos; Relatórios com totalização de dados, relatórios que
também atualizam arquivos, informações em formato gráfico.
Consideração sobre os
Componentes da Contagem
Associação com “ranking”
Uma vez que os dados foram coletados, um valor de complexidade é
associado a cada contagem
Organizações que utilizam pontos de função desenvolvem critérios para
determinar se um determinado componente é simples, médio ou
complexo
De qualquer forma, a determinação da complexidade é subjetiva
Para calcular os Pontos de Função, a seguinte relação é usada:
FP = total contagem x [0.65 + 0.01 x Σ (Fi)
Onde: total contagem é a soma de todas as entradas de FP e
Fi são os fatores de ajuste
Tabela de Complexidade do ALI e AIE
Tabela de Complexidade do SE e CE
Tabela de Complexidade da EE
Contagem de Pontos de Função
não Ajustados
Contagem de Pontos de Função
Fator de Ajuste
Contagem de Pontos de Função
Fator de Ajuste
Contagem de Pontos de Função
Fator de Ajuste
Análise
Análise
BIBLIOGRAFIA
• PRESSMAN, Roger S. Engenharia de Software. São
Paulo: Makron Books, 2006.
• VASQUEZ, Carlos Eduardo; SIMÕES Guilherme
Siqueira; ALBERT, Renato Machado. Análise de Pontos
de Função: Medição, Estimativas e Gerenciamento de
Projetos de Software: Editora Érica, 2004.
• material professores Gregório Perez e Marcos Roberto e
Silva, UNINOVE