Aula 05 - ES - Métricas de Software

Transcrição

1 Aula 05 - ES - Métricas de Software Conceito METRICAS inferências sobre os processos de trabalho que traduzem: a priori ESTIMATIVAS expectativas METRICAS Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com DESEMPENHO a posteriori eficiência eficácia O que são? Uma métrica é a medição de um atributo (características) de uma determinada entidade (produto ou processo). 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); Porque 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 retorno de investimento. 2 3

2 Categorização das Métricas Métricas orientadas a tamanho São medidas diretas do tamanho dos artefatos de software associados ao processo por meio do qual o software é desenvolvido. Ex.: esforço, custo, no. KLOC, no. páginas de documentação, no. erros 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. Categorização das 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 adéqua à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 4 5 Painel Comparativo prototipagem vs métricas Possíveis Problemas com Métricas Ex: Comparar a produtividade de engenheiros em termos de linha de código Está sendo utilizado a mesma unidade de medida? O que é uma linha de código válida? O contexto considerado é o mesmo? Todos os engenheiros são familiarizados com a linguagem de programação? O que se quer realmente é o tamanho do código? E a qualidade do código? Como o resultado será interpretado? Produtividade média de um engenheiro? O que se quer com o resultado? Comparar a produtividade do processo de software? 6 7

3 Exemplo: Exemplos de Métricas Interessados: grupo de desenvolvimento, clientes, gerência do projeto Objetivo: Assegurar que apenas uma quantidade aceitável de defeitos persistam antes da versão betha do software ser liberado para uso. Perguntas: Quantos defeitos temos atualmente? Qual o status de cada defeito? Qual a cobertura dos testes? Quantos defeitos são aceitáveis para uma versão betha? 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 Número aceitável de defeitos na fase betha 8 9 Motivação Não se pode gerenciar o que não se pode medir. Tom De Marco Se você não sabe para onde você quer ir, qualquer caminho você pode seguir. Se você não sabe onde você está, um mapa não vai ajudar!. Roger Pressman Prof. Luiz 10/57 Alberto - Propriedades desejáveis de uma métrica Facilmente calculada, entendida e testada Passível de estudos estatísticos Expressa em alguma unidade Obtida o mais cedo possível no ciclo de vida do software Passível de automação Repetível e independente do observador Sugere uma estratégia de melhoria Prof. Luiz 11/57 Alberto -

4 Em resumo... Uma métrica deve ser: Válida: quantifica o que queremos medir Confiável: produz os mesmos resultados dadas as mesmas condições Prática: barata, fácil de computar e fácil de interpretar Dois contextos para medição de software Processo: ex. produtividade Produto: ex. qualidade Categorização de Métricas Métricas diretas (fundamentais ou básicas) Medida realizada em termos de atributos observados (usualmente determinada pela contagem) Ex.: custo, esforço, no. linhas de código, capacidade de memória, no. páginas, no. diagramas, etc. Métricas indiretas (derivadas) Medidas obtidas a partir de outras métricas Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção Prof. Luiz 12/57 Alberto - Prof. Luiz 13/57 Alberto - Possíveis problemas com métricas Ex: Comparar a produtividade de engenheiros em termos de linha de código Está sendo utilizado a mesma unidade de medida? O que é uma linha de código válida? O contexto considerado é o mesmo? Todos os engenheiros são familiarizados com a linguagem de programação? O que se quer realmente é o tamanho do código? E a qualidade do código? Como o resultado será interpretado? Produtividade média de um engenheiro? O que se quer com o resultado? Comparar a produtividade do processo de software? Os Quatros papéis de Medição Segundo Humphrey, são quatro os principais papéis de Medições de Software: Entender Processos, Produtos e Serviços de Software Controlar Avaliar Prever Prof. Luiz 14/57 Alberto - Prof. Luiz 15/57 Alberto -

5 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 Selecionando Objetivos Devem estar associados a um período de tempo Aumentar a produtividade em 20% no prazo de 12 meses Facilita o acompanhamento e a tomada de ações para viabilizar objetivo pois existe um prazo!!! Estudos indicam que objetivos muito complexos e de longo prazo podem causar impacto na motivação Objetivos menores, a curto prazo, permitem que as pessoas visualizem o progresso e alcancem sucessos Com o tempo e com a maturidade da organização, os objetivos devem se tornar mais complexos e mais desafiadores Prof. Luiz 16/57 Alberto - Prof. Luiz 17/57 Alberto - Selecionando Métricas Seja realista e prático Considere o processo e o ambiente de desenvolvimento atual Não selecione métricas em que os dados sejam difíceis de serem coletados na sua realidade Comece com o que for possível Selecionando Métricas Objetivo: Aumentar satisfação do cliente Que atributos dos nossos produtos e serviços são mais importantes para os nossos clientes? Aspectos Relevantes de Produto e Serviço para Clientes A equipe não deve ser muito impactada Utilize a abordagem incremental Com o tempo, com os benefícios, mais dados estarão disponíveis... Clientes que Consideram o Aspecto Qualidade Custo Prazo Visibilidade do Progresso Flexbilidade p/ mudanças # Clientes Aspectos Relevantes Para os Clientes Prof. Luiz 18/57 Alberto - Prof. Luiz 19/57 Alberto -

6 Princípios de um Processo de Medição Um processo de medição deve: Fornecer uma base para melhoria contínua do processo Quantificar a qualidade e produtividade Estar integrado com o ciclo de vida de desenvolvimento Medir o impacto de vários métodos, ferramentas, e técnicas de melhorias Princípios de um Processo de Medição Medições devem ser usadas para medir processos, não pessoas O processo de medição deve ter objetivos claros e bem-definidos O processo de medição deve ser fortemente acoplado com o processo de gerência da qualidade e integrado dentro de planos e orçamentos Prof. Luiz 20/57 Alberto - Prof. Luiz 21/57 Alberto - Princípios de um Processo de Medição O processo de coleta de dados deve ser simples, e ferramentas automáticas para extração de dados devem ser usadas O processo de medição é contínuo e sujeito a melhoria Plano de Métricas Para cada objetivo técnico o plano contém informação sobre: POR QUE as métricas satisfazem o objetivo QUE métricas serão coletadas, como elas serão definidas, e como serão analisadas QUEM fará a coleta, quem fará a análise, e quem verá os resultados COMO será feito: que ferramentas, técnicas e práticas serão usadas para apoiar a coleta e análise das métricas QUANDO no processo e com que freqüência as métricas serão coletadas e analisadas ONDE os dados serão armazenados Prof. Luiz 22/57 Alberto - Prof. Luiz 23/57 Alberto -

7 Por que é tão difícil estimar? É difícil conhecer se é possível desenvolver o produto desejado pelo cliente antes de conhecer os detalhes do projeto. Estimativas de Software 24/57 Prof. Luiz 25/57 Alberto - Por que é tão difícil estimar? Desenvolvimento é um processo gradual de refinamento Incerteza da natureza do produto contribui para a incerteza da estimativa Requisitos e escopo mudam Defeitos são encontrados e demandam retrabalho Produtividade varia O Processo de Estimativas 1. Estimar o tamanho do produto 2. Estimar o esforço 3. Estimar o prazo 4. Fornecer estimativas dentro de uma faixa permitida e refinar essa faixa à medida que o projeto progride Prof. Luiz 26/57 Alberto - Prof. Luiz 27/57 Alberto -

8 Principais Barreiras Mas podemos contornar... Falta de comprometimento da alta gerência Medir custa caro Os maiores benefícios vêm a longo prazo Má utilização das métricas Grande mudança cultural necessária Dificuldade de estabelecer medições apropriadas e úteis Interpretações dos dados realizadas de forma incorreta Obter o comprometimento de todos os envolvidos e impactados Estabelecer um programa de medições é fácil, o difícil é manter!! Foco desde os estágios iniciais da melhoria de processo Medição faz parte do TODO Começar Pequeno Selecionar um conjunto coerente É importante definir cada detalhe da métrica Descartar o que não estiver sendo útil Fornecer as informações corretas, para as pessoas certas Agregar valor, ao invés de gerar apenas dados Prof. Luiz 28/57 Alberto - Prof. Luiz 29/57 Alberto - Mas podemos contornar... Métricas Orientadas a Função Incentivar a equipe de desenvolvimento a fazer uso das métricas Envolvimento de todos os impactados Estabelecer as expectativas Métricas de software orientadas a função usam uma medida de funcionalidade entregue pela aplicação como valor de normalização. A métrica orientada a função mais amplamente usada é a pontos por função (function point FP). Educação e Treinamento Ganhar Confiança Adotar uma Abordagem Evolucionária Compreender que a Adoção leva Tempo Prof. Luiz 30/57 Alberto -

9 Pontos por Função Fatores de Ajuste -Fi 1. O sistema requer salvamento (backup) e recuperação (recovery)? 2. Comunicações de dados são necessárias? 3. Há funções de processamento distribuídas? 4. O desempenho é crítico? 5.O sistema vai serexecutado em um ambiente operacional existente, intensamente utilizado? 6. O sistema requer entrada de dados on-line? 7.A entrada de dados on-line exige que a transação de entrada seja construída através de várias telas ou operações? 8. Os arquivos mestre são atualizados on-line? 9. As entradas, saídas, arquivos ou consultas são complexas? 10. O processamento interno é complexo? 11. O código é projetado para serreusado? 12. A conversão e a instalação estão incluídas no projeto? 13. O sistema está projetado para instalações múltiplas em diferentes organizações? 14. A aplicação estáprojetada para facilitar modificações e para facilidade de uso pelo usuário? Classificação das Fi Métricas Orientadas a Função Cada resposta deve obedecer a uma escala de 0 a 5., em que 0 significa não-importante ou não-aplicável e 5 absolutamente essencial. Vantagens Desvantagens PF = total de contagem x [0,65 + 0,01 x Σ(Fi)] Artigo para consulta Albrecht, A. J. "Measuring Application Development Productivity". Proc. IBM Application Development Sysmposium, Monterey, CA, out. de 1979, p

10 Métricas Orientadas a Função Vantagens Independentes da linguagem; Ideal para aplicações que usam linguagem não procedimental; Se baseiam em dados mais fáceis de serem conhecidos durante a evolução do projeto. Desvantagens Cálculo baseado em dados subjetivos; Resultado é apenas um número. Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com Qualidade de Software Estimativa de Esforço É difícil fazer uma estimativa precisa de esforço de desenvolvimento Os requisitos podem ser de alto nível, incompletos ou imprecisos Não se conhece bem o ambiente no qual o software irá operar (hardware, usuários, etc.) Apesar das dificuldades, as empresas precisam estimar esforço e custos Razões para se medir o software: Indicar a qualidade do produto Avaliar a produtividade dos que desenvolvem o produto Determinar os benefícios derivados de novos métodos e ferramentas de engenharia de software Formar uma base para as estimativas Ajudar na justificativa de aquisição de novas ferramentas ou de treinamentos adicionais 38 39

11 Medidas de Software Custo: real R$ Prazo: inteiro semanas Tamanho ou porte : inteiro unidade Esforço: inteiro pessoas/mês Linhas de Código: inteiro unidade Velocidade de Execução: inteiro segundos Tamanho de Memória Utilizada: inteiro KB Funcionalidade: inteiro unidade Complexidade: Eficiência: Qualidade: Objetivos Métricas para Planejamento e Gerenciamento Dimensão dos produtos Modelos, protótipos, documentos e software Esforço de produção Pessoas necessárias num período de tempo Produtividade Quantidade produzida por esforço Defeitos Número de erros encontrados Custo de produção Valor do esforço de produção e correção de erros 41 Modelo COCOMO Nos anos 1980, Barry Boehm propôs uma hierarquia de modelos de estimativa de software denominada COCOMO (Constructive Cost Model). O modelo COCOMO tornou-se um dos modelos de estimativa de custo de software mais amplamente usados. Mais tarde, o modelo COCOMO evoluiu para um modelo mais abrangente, chamado COCOMO II. Modelo COCOMO II É uma hierarquia de modelos que tratam das seguintes áreas: Modelo de composição da aplicação Usado nos primeiros estágios da engenharia de software Modelo do primeiro estágio de projeto Usado depois que os requisitos foram estabilizados e a arquitetura foi estabelecida. Modelo para o estágio após a arquitetura Usado durante a construção do software

12 Modelo COCOMO II Como todos os modelos de estimativa de software, requer informação de tamanho. Três opções: Pontos por objeto Pontos por função Linhas de código-fonte Métrica pontos por objeto É calculada usando-se a contagem da quantidade de: Telas (na interface com o usuário) Relatórios Componentes que serão necessários pra construir a aplicação. Cada objeto é classificado em três níveis de complexidade. Modelo COCOMO II A porcentagem de re-uso é estimada e a contagem de pontos por objeto é ajustada. A produtividade é estimada usando-se: A experiência/capacidade do desenvolvedor. A maturidade/capacidade do ambiente de desenvolvimento. O esforço é estimado usando-se os pontos por objeto e a produtividade. E = NOP/PROD ponto de objeto Cada instância de objeto (por exemplo, uma tela ou um relatório) é classificada em um dentre três níveis de complexidade (simples, médio ou difícil) usando critérios sugeridos por Boehm [Boe96]. Uma vez determinada a complexidade, os números de telas, relatórios e componentes são ponderados de acordo com a tabela abaixo: Produtividade Tabela de produtividade de ponto de aplicação por desenvolvedor (PROD) 46 47