Please enable JavaScript.
Coggle requires JavaScript to display documents.
Métricas de Processo e Projeto - Coggle Diagram
Métricas de Processo e Projeto
Introdução
A medição permite obter o entendimento do processo e projeto dando um mecanismo para uma avaliação objetiva
Sem a possibilidade de medir e expressar em números, o conhecimento é escasso e insatisfatório.
As medições podem ser aplicadas ao processo de software com a intenção de melhoria contínua
As medições podem ser usadas durante um projeto para ajudar nas estimativas, controle de qualidade, produtividade e controle de projeto.
Medições podem ser usadas pelos eng. de SW para ajudar a avaliar a qualidade dos artefatos e auxiliar na tomada de decisões táticas na medida em que o projeto evolui.
Quando o projeto usa um processo, um time de software está preocupado principalmente com as métricas de produtividade e qualidade
Para fins de planejamento, o interesse está no histórico de medições
Qual foi a produtividade do desenvolvimento de software em projetos anteriores?
Qual foi a qualidade do software produzido?
Como a produtividade passada e os dados de qualidade podem ser extrapolados para o presente?
Como isso pode ajudá-lo a fazer planos e estimativas mais precisos?
Medidas do “resultado” do desenvolvimento de software em função do esforço e do tempo aplicados
Medidas da “adequação para uso“ dos artefatos que são produzidos
Razões para medir
(2) Avaliar
Para determinar o status com relação aos planos
(3) Prever
Entender as relações entre os processos e produtos e criando modelos dessas relações
(1) Caracterizar
Para estabelecer linhas de base para comparações com futuras avaliações
Esforço para obter conhecimento de processos, produtos, recursos e ambientes
(4) Melhorar
Identificar etapas, causas raiz de problemas, ineficiências e outras oportunidades de melhoria da qualidade do produto e desempenho do processo
A medição é uma ferramenta de gerenciamento, que, ao ser usada corretamente, promove discernimento ao gerente de projeto, e como consequência ajuda-o e a equipe a tomar decisões que podem levar a um projeto bem-sucedido.
(1) Métricas no Domínio de Processo e Projeto
Métricas de processo
Finalidade: proporcionar uma série de indicadores de processo que levam à melhoria do processo no longo prazo
São coletadas através de todos os projetos e sobre longos períodos de tempo
Métricas de projeto
Permitem ao gerente de projeto
(1) Avaliar o estado de um projeto em andamento
(2) Rastrear os riscos em potencial
(3) Descobrir áreas problemáticas antes que elas se tornem críticas
(4) Ajustar o fluxo de trabalho ou tarefas
(5) Avaliar a habilidade da equipe de projeto para controlar a qualidade dos produtos finais de software
Medidas coletadas por uma equipe podem ser convertidas em métricas
Para uso durante um projeto
E transmitidas para aqueles que têm responsabilidades pelo aperfeiçoamento do processo
Métricas de processo e aperfeiçoamento do processo de software
Uma maneira de melhorar qualquer processo é
desenvolver uma série de métricas significativas com base nesses atributos
e usar as métricas para fornecer indicadores que levarão a uma estratégia de aperfeiçoamento
Medir atributos específicos do processo,
O processo é apenas um item dentre os fatores controláveis na melhoria da qualidade do software e do desempenho organizacional
O processo está dentro do triângulo que conecta três fatoers que influenciam a qualidade do software e desempenho organizacional
Os vértices do triângulo são
Produto
A complexidade do produto pode ter um impacto substancial sobre a qualidade e desempenho da equipe
Tecnologia
A tecnologia (métodos, ferramentas da engenharia de software) que preenche o processo tem um impacto também
Pessoas
A habilidade e a motivação das pessoas representam o fator individual mais influente na qualidade e no desempenho
O triângulo do processo encontra-se dentro de um círculo de condições ambientais, que incluem
condições de negócio (por exemplo, prazos de entrega, regras de negócio)
Características do cliente (por exemplo, facilidade de comunicação e colaboração)
Ambiente de desenvolvimento (por exemplo, ferramentas de software integradas)
A eficácia de um processo de software pode ser medida indiretamente
Cria-se um série de métricas baseadas em resultados do processo
Resultados
Medidas de erros descobertos antes da entrega do software
defeitos relatados pelos usuários finais
produtos acabados fornecidos (produtividade)
Esforço humano gasto
Tempo despendido
Conformidade com o cronograma, etc.
Obtém-se métricas também medindo características de tarefas específicas de engenharia de software
Por exemplo, você pode medir o esforço e o tempo despendidos executando as atividades
genéricas de engenharia de software
Tipos de métricas
Métricas privadas
Exemplos: taxas de defeitos (por individuo), taxas de defeito (por componente) e erros encontrados durante o desenvolvimento
Métricas definidas a partir de dados coletados individualmente
Devem ser privados e servir apenas como um indicador individual
Os engenheiros de software individualmente podem ser sensíveis ao uso desse tipo de métrica
Dados privados do processo podem servir como um motivador importante quando se trabalha para melhorar a abordagem de engenharia de software.
O aperfeiçoamento do processo de software pode e deve começar em nível individual
Algumas métricas de processo são privadas para a equipe de projeto de SW mas são públicas para todos os membros da equipe
Defeitos relatados para funções principais do SW
Erros encontrados durante revisões técnicas
linhas de código ou pontos de função por componente ou função
A equipe examina esses dados para descobrir indicadores que podem melhorar o desempenho da equipe
Métricas públicas
Métricas públicas geralmente assimilam informações que originalmente eram privadas aos indivíduos e equipes
Avaliam-se dados coletados tentando descobrir indicadores que podem melhorar o desempenho do processo organizacional
Exemplos de dados
Esforço
Prazos agendados
Taxas de defeito em nível de projeto (absolutamente não atribuídas aos indivíduos)
E dados relacionaodos
Com base no uso dos tipos de dados de processo
Métricas de processo de software podem produzir benefícios significativos quando uma organização trabalha para melhorar seu nível geral de maturidade de processo
Quando mal utilizadas podem criar mais problemas do que elas podem resolver
Etiqueta de métricas de software apropriada para os gerentes e profissionais quando instituem um programa de métricas de processo
Trabalhe com profissionais e equipes para definir objetivos claros e métricas que serão usadas para alcançá-las.
Nunca use métricas para ameaçar indivíduos ou equipes.
Não use métricas para avaliar indivíduos.
Dados de métricas que indicam uma área com problema não deverão ser considerados “negativos”. Esses dados
são simplesmente um indicador para melhoria do processo.
Forneça regularmente feedback aos indivíduos e equipes que coletam medidas e métricas.
Não seja obsessivo sobre uma única métrica excluindo as outras métricas importantes.
Use bom senso e sensibilidade organizacional ao interpretar dados de métricas.
À medida em que uma organização se sente mais à vontade, coletando e usando métricas de processo, a derivação de indicadores simples dá margem a uma abordagem mais rigorosa chamada melhoria estatística de processo de software
(SSPI - statistical software process improvement)
A SSPI usa a análise de falhas de software para coletar informações sobre todos os erros e defeitos encontrados quando um aplicação, sistema, ou produto é desenvolvido e usado
Métricas de projeto
Medidas de projetos de software são táticas, (diferentemente das métricas de processo que são usadas para fins estratégicos)
Métricas de projeto são usadas por gerente e equipe de sw para adaptar o fluxo de trabalho do projeto e atividades técnicas
Aplicação das métricas
Métricas coletadas de projetos passados são usadas como base a partir da qual são feitas as estimativas de esforços e tempo para o trabalho atual de sw
À medida que o projeto progride, medidas de esforço e tempo despendidos são comparadas com as estimativas originais e com o cronograma do projeto
O gerente de projeto usa esses dados para monitorar e controlar o progresso
Quando o trabalho técnico começa, outras métricas começam a ter significado
As taxas de produção em termos de modelos criados, revisões, pontos de função e linhas de código-fonte são medidas
Os erros descobertos durante cada tarefa de Eng. SW são rastreados
Métricas técnicas são coletadas, à medida que o sw evolui dos requisitos de projeto, para avaliar a qualidade do projeto e fornecer indicadores que terão influência na abordagem adotada para geração de código e teste
Objetivos da métricas de projeto
Minimizar o cronograma de desenvolvimento fazendo os ajustes necessários para evitar atrasos e mitigar problemas e riscos em potencial
Usadas para avaliar a qualidade do produto de forma contínua, e, quando necessário, modificar a abordagem técnica para melhorar a qualidade
A melhoria da qualidade
proporciona a minimização de defeitos
que por sua vez reduz a quantidade de retrabalho durante o projeto
Redução no custo total do projeto
(2) Medidas de Software
Medidas diretas do processo
Incluem custos e trabalho aplicado
Exemplos: linhas de codigo produzidas, velocidade de execução. tamanho de memória e defeitos relatados durante um determinado período
São relativamente fácies de coletar desde que sejam estabelecidas convenções para medições antecipadamente
Medidas indiretas do processo
Incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade, e outras ades
São mais difiíceis de avaliar e podem ser medidas somente de forma indireta
O domínio de métricas de software podem ser dividos em processo, projeto e métricas de produto
As métricas de produto são privadas a um indivíduo
Muitas vezes as métricas de produto são combinadas para desenvolver métricas de projeto, que são públicas para a equipe de software
Métricas de projeto são então consolidadas para criar métricas de processo que são públicas à organização de sw como um todo
Combinação de métricas de diferentes fontes
Para combinar métricas de medidas individuais deve-se normalizar as medidas pelo tamanho ou complexidade dos projetos
Exemplo: a equipe A encontrou 342 erros antes da entrega durante o processo de software; a equipe B encontrou 184 erros.
Normalizando esses números, pode-se criar métricas de software que possibilitam a comparação com médias organizacionais mais amplas
(1) Métricas orientadas a tamanho
São criadas normalizando-se as medidas de qualidade e/ou produtividade considerando o tamanho do software que foi produzido
A organização que mantém registros simples pode criar uma tabela de medidas orientadas a tamanho que incluem medidas para projeto passados concluídos
Linhas de código
Esforço
Projeto
Custo
Páginas de documentação
Defeitos
Pessoas
Todo trabalho (esforço) e custo registrados representa todas as atividades de engenharia de software (análise, projeto, código e teste), não apenas codificação
Para produzir métricas que podem ser assimiladas com métricas similares de outros projetos, escolhe-se o número de linhas de código como um valor de normalização
Exemplos de métricas simples orientadas a tamanho
Defeitos por KLOC
$ por KLOC
Erros por KLOC (mil linhas de código)
Páginas de documentação por KLOC
Outras métricas interessantes
KLOC por pessoa-mês
$ por página de documentação
Erros por pessoa-mês
Métricas orientadas a tamanho não são aceitas universalmente como a melhor maneira de medir os processos de software
Os oponentes argumentam que
Elas não podem facilmente acomodar linguagens não procedurais
O seu uso nas estimativas requer um nível de detalhe que pode ser difícil de alcançar
As medidas LOC são dependentes da linguagem de programação, que quando considerada a produtividade, elas penalizam programas bem projetados mas menores
Os proponentes justificam o uso por
Modelos de estimativa de sw existentes usam LOC ou KLOC como dado principal de entrada
Já existe grande quantidade de literatura e dados baseados em LOC
Ser LOC ser um item de todos os projetos de desenvolvimento de software, facilmente contado
Maior parte da controvérsia: uso de linhas de código como medida principal
(2) Métricas orientadas a função
Usa uma medida da funcionalidade entregue pela aplicação como um valor de normalização
A métrica orientada a função mais usada é a de pontos de função (function point)
O cálculo de FP é baseado nas características de domínio de informação e complexidade do sw
Os proponentes argumentam que
a funçã é independente da linguagem de programação, tornando-a ideal para aplicações que usam linguagens convencionais e não procedurais
É baseada em dados que têm maior probabilidade de ser conhecidos na evolução, tornando a FP mais atraente como abordagem de estimativa
Oponentes argumentam que
O método requer um pouco de jeitinho, pois o cálculo é baseado em dados subjetivos
As contagens do domínio de informações podem ser difíceis de coletar após o fato
A FP não tem um significado físico direto (é apenas um número)
(3) Reconciliando métricas LOC e FP
A relação entre LOC e FP depende da linguagem de programação usada para implementar o software e da qualidade do projeto
Existem tabelas que fornecem estimativas da média do número de linhas de código necessárias para criar um ponto de função em várias linguagens de programação
LOC em C++ fornece aproximadamente 2,4 vezes a funcionalidade de uma LOC de C.
Medidas de LOC e FP são usadas para derivar métricas de produtividade
Na práticas, métricas como LOC/pessoa-mês e outras não devem ser usadas por gerentes para avaliar o desempenho ou fazer comparações entre equipes, uma vez que muitos fatores influenciam a produtividade
LOC e FP são indicadores relativamente preciso do trabalho e custo de desenv. de sw, mas para usá-los em estimativas deve ser estabelecida uma referência histórica de informações
Dentro do contexto de métricas de processo e projeto, deve preocupar-se primeiramente com a produtividade e qualidade
Medidas de resultado de desenvolvimento de sw em função do esforço e tempo aplicados
E as medidas da adequação para uso dos produtos criados
Para fins de melhoria e planejamento de projeto, o interesse está no histórico de medições
Qual foi a produtividade do desenvolvimento de software nos projetos passados?
Qual foi a qualidade do software produzido?
Como os dados de produtividade e qualidade do passado podem ser extrapolados para o presente?
Como isso pode nos ajudar a melhorar o processo e planejar novos projetos mais precisamente?
(4) Métricas orientadas a objeto
Métricas de projeto de software convencional (LOC ou FP) não fornecem granularidade suficiente para os ajustes necessários de cronograma e esforço na medida em que o projeto passa por iterações por meio de um processo evolucionário ou incremental
Conjunto de métricas para projetos orientados a objetos
Número de classes de apoio (Number of support classes).
Classes de apoio
Necessárias para implementar o sistema
Mas não estão imediatamente relacionadas com o domínio do problema
Exemplos: classes de interface de usuário (GUI), classes de acesso à base de dados e classes de cálculo
Pode-se desenvolver classes de apoio para cada uma das classes-chave
São definidas iterativamente durante um processo evolucionário
É uma indicação da quantidade de esforço necessário para desenvolver o software
É uma indicação do potencial de reutilização
Número médio de classes de apoio para cada classe-chave (Average number of support classes per key class).
Classes de apoio são definidas no início do projeto
Classes-chave são definidas durante o projeto
O conhecimento desse indicador para um dado domínio simplifica a estimativa (baseada no número total de classes)
Número de classes-chave (Number of key classes).
Classes-chave
São os "componentes altamente independentes"
Definidos no início em análise orientada a objeto
A quantidade dessas classes indica a quantidade de esforço para desenvolver o sw
Também indica o potencial de reutilização a ser aplicado no desenvolvimento do sistema
Número de subsistemas (Number of subsystems).
Subsistema
Agregação de classes que apoia uma função que é visível ao usuário final de um sistema
A identificação dos subsistemas facilita a elaboração de um cronograma razoável no qual o trabalho nos subsistemas é dividido entre o pessoal de projeto
Número de scripts de cenário (Number of scenario scripts).
Análogo aos casos de uso
É uma sequência detalhada de passos que descrevem a interação entre o usuário e a aplicação
Cada script é organizado em trios da forma {iniciador, ação, participante}
Iniciador
Objeto que solicita algum serviço (inicia uma mensagem)
Ação
Resultado da solicitação
Participante
Objeto servidor que satisfaz a solicitação
O número de scripts de cenário está correlacionado ao tamanho da aplicação e com o número de casos de testes que devem ser desenvolvidos para exercitar o sistema de pois de construído
Para uso eficaz em um ambiente de eng. de sw orientado a objetos, essas métricas devem ser coletadas juntamente com as medidas de projeto (esforço gasto, erros e defeitos, e modelos ou páginas de documentação)
À medida em que a base de dados cresce (conclusão de projetos), a relação entre medidas OO e as medidas de projeto fornecerão métricas que ajudam nas estimativas
(5) Métricas Orientadas a casos de uso
Casos de uso
Métodos usados para descrever requisitos no nível dos clientes ou domínio de negócio que implicam em recursos e funções de sw
Nos processos de sw, os casos de uso são definidos no início permitindo que ele seja usado para estimativas antes de iniciar atividades de modelagem e construção
Descrevem funções e características visíveis ao usuário que (requisitos básicos para um sistema)
É independente da linguagem de programação
A quantidade de casos de uso é diretamente proporcional
Ao tamanho do aplicativo em LOC
Ao número de casos de testes que terão de ser projetados para exercitar completamente o aplicativo
Podem ser criados em níveis diferentes de abstração, logo não há padrão de tamanho para um caso de uso
Sua aplicação como medida de normalização (ex. esforço gasto por caso de uso) é suspeita
Pontos de caso de uso (UCPs)
Mecanismo para estimar trabalho de projeto e outras caracterísitcas
Função do número de atores e transações deduzidas pelos modelos de casos de uso
(6) Métricas de projeto WebApp
Objetivo dos projets WebApp
Fornecer uma combinação de conteúdo e funcionalidade para o usuário final
Medidas e métricas de projetos originais são difícies de traduzir diretamente para WebApps
Apesar disso, é possível desenvolver uma base de dados que permite acesso a medidas internas de produtividade em uma série de projetos
Medidas coletadas
Número de páginas Web estáticas.
Páginas Web estáticas
usuário final não tem controle sobre o conteúdo mostrado na página
São as mais comuns de todas as características WebApp
Representam baixa complexidade relativa
Requer menos esforços para ser criadas do que páginas dinâmicas
Fornece uma indicação
Do tamanho global da aplicação
Do esforço necessário para desenvolver a aplicação
Número de páginas Web dinâmicas
Páginas Web com conteúdo dinâmico
Ações do usuário final ou outros fatores externos resultam em conteúdo personalizado apresentado na página
São essenciais em todos os aplicativos e-commerce, recursos de pesquisa, aplicações financeiras e muitas outras categorias WebApp
Representam uma complexidade relativa maior
Requerem mais esforço para ser construídas que as estáticas
Fornece uma indicação
Do tamanho global da aplicação
Do esforço necessário para desenvolver a aplicação
Número de links de páginas internos
Links de páginas internos
São ponteiros que fornecem um hyperlink para alguma outra página Web dentro do WebApp
Essa medida fornece uma indicação do grau de acoplamento arquitetônico dentro do WebApp
Quanto maior o número de links maior o esforço gasto no projeto navegacional e na construção
Número de objetos de dados persistentes
Objeto de dados persistentes
Base de dados ou arquivo de dados
Podem ser acessados por uma WebApp
A complexidade do WebApp e o esforço para implementá-la cresce com o aumento da quantidade de objetos
Número de sistemas externos interfaceados
É comum o interfaceaemento de WebApps com aplicações de negócio de "bastidores"
A complexidade do sistema e esforço de desenvolvimento aumentam com o crescimento do requisito para interfaceamento
Número de objetos de conteúdo estático
Objetos de conteúdo estático
Abrangem objetos estáticos baseados em texto, objetos gráficos, vídeo, animação e informações de áudio incorporados à WebApp
Objetos de conteúdo múltiplo podem aparecer numa única página Web
Número de objetos de conteúdo dinâmico.
Objetos de conteúdo dinâmico
Gerados baseados nas ações do usuário final
Abrangem informações de texto geradas internamente, informações gráficas, vídeo, animação, e áudio
Objetos de conteúdo múltiplos podem aparecer em uma única página Web
Número de funções executáveis
Função executável
Script ou applet
Proporciona algum serviço de cálculo ao usuário final
O aumento do número de funções aumentam os esforços de modelagem e construção
As medidas coletadas podem ser determinadas em um estágio antecipado
Exemplo: pode-se definir uma métrica que reflete o grau de personalização de usuário final requerida para a WebApp e correlacionar isso com o esforço gasto no projeto e/ou erros descobertos na medida em que são feitas as revisões e testes
Exemplo de métrica: O índice de personalização do WebApp:
C = Ndp/(Ndp+Nsp)
C varia de 0 a 1
O nível ed personalização se torna importante quando C aumenta
Métricas similares ao índice de personalização podem ser calculadas e correlacionadas com medidas de projeto (esforço gasto, erros e defeitos descobertos, etc.)
Á medida em que a base de dados cresce, relações entre as medidas WebApp e medidas de projeto proporcionarão indicadores que podem ajudar na estimativa do projeto
(3) Métricas para Qualidade de Software
Principal objetivo da Eng. de SW
Produzir um sistema, aplicação ou produto de alta qualidade, dentro de um prazo que satisfaça as necessidades do mercado
Para isso, deve-se aplicar métodos eficazes em conjunto com modernas ferramentas dentro do contexto de um processo de software bem desenvolvido
O engenheiro deve medir para saber se a alta qualidade será atingida.
Usa-se medidas para avaliar a qualidade dos requisitos e modelos de projeto, o código fonte, e os casos de testes criados no desenvolvimento do sw.
Para avaliação em tempo real, aplica-se métricas de produto para avaliar a qualidade dos artefatos de sw objetivamente
Para avaliar a qualidade enquanto o projeto avança, métricas privadas são coletadas por Eng. de SW individualmente e combinadas para obter resultados no nível do projeto
Embora muitas medidas possam ser coletadas, a principal tendência no nível de projeto é medir erros e defeitos
Métricas derivadas dessas medidas indicam a efetividade da garantia de qualidade de sw individual e de grupos, e das atividades de controle.
Exemplo de métricas: erros de produto por ponto de função, erros descobertos por horas de revisão e erros descobertos por horas de teste fornecem informação sobre a eficácia de cada uma das atividades sugeridas pela métrica
Dados sobre erros podem ser usados para calcular a eficiência de remoção de defeitos para cada atividade da estrutura de processo
(1) Medição da qualidade
Fortes indicadores úteis para equipe de projeto (definições e medidas para cada uma)
Manutenibilidade
É a facilidade com a qual um programa pode ser
Adaptado, se o ambiente mudar
Ou melhorado, se o cliente desejar uma alteração nos requisitos
Corrigido, se for encontrado um erro
Não pode ser medida diretamente (usa-se medidas indiretas)
Tempo médio de alteração (mean-time-to-change - MTTC)
Tempo necessário para
Projetar uma modificação apropriada
Implementar a alteração
Analisar a solicitação de alteração
Testá-la
Distribuir a alteração para todos os usuários
MTTC mais baixo significa que os programas são manuteníveis
Integridade
Esse atributo mede a habilidade de um sistema em resistir aos ataques à sua segurança
Os ataques podem ser feitos nos três componentes do software
Programas
Dados
Documentos
Atributos usados para medir a integridade
Ameaça
É a probabilidade de que um ataque de um tipo específico ocorrerá em um dado intervalo de tempo
Segurança
É a probabilidade de que um ataque de um tipo específico será repelido
Cálculo da integridade
Integridade = Somatório[1 - (ameaça*(1 - segurança))]
Uma baixa ameça e alta segurança resulta em alta integridade e vice-versa
Correção
Um programa deve operar corretamente, caso contrário terá pouca utilidade
Correção é o grau com o qual o software executa sua função
Medida mais comum da exatidão: número de defeitos por KLOC
Defeitos: ocorrência de falta de conformidade com os requisitos
Qualidade geral de um artefato
os defeitos são aqueles problemas relatados pelo usuário (programa já liberado para uso)
Os defeitos são contados durante um tempo padrão para fins de avaliação da qualidade (1 ano)
Usabilidade
É uma tentativa de quantificar a facilidade de uso
Pode ser medida em termos das características apresentadas no capítulo 11
Um programa de difícil uso está destinado ao fracasso
Os quatro fatores são apenas alguns exemplos de medidas para qualidade
(2) Eficiência na remoção de defeitos
É uma medida da habilidade de filtragem das ações de garantia e controle da qualidade quando aplicadas através de todas as atividades da estrutura de processo
Para um projeto como um todo, a DRE é definida por
DRE = E/(E + D)
E = número de erros encontrados antes que o software seja entregue ao usuário final
D = Número de defeitos depois que software é entregue
O valor ideal é 1;
Pode se aproximar de 1 à medida que E aumenta, ou seja,o os erros são filtrados antes de se tornarem defeitos e D diminui.
Se usada como métrica que fornece um indicador da habilidade de filtragem das atividades de controle de qualidade e segurança
A DRE estimula a equipe a instituir técnicas para encontrar o maior número possível de erros antes da entrega
A DRE pode ser usada para avaliar a habilidade de uma equipe para encontrar erros antes que eles passem para próxima atividade da estrutura do software (ou prócima ação de eng. de sw
Nesse caso, a DRE é definida como
DREi = Ei/(Ei + E(i+1))
E(i+1) = Número de erros encontrados durante a ação i+1 (erros não descobertos na ação i)
Ei = número de erros encontrados durante a ação de engenharia i antes que o software seja entregue ao usuário final
Objetivo de qualidade para uma equipe sw: conseguir uma DREi que se aproxime de 1 (filtrar erros antes que passem para próxima ação)
Exemplo: a análise de requisitos produz um modelo de requisitos que pode ser examinado para encontrar e corrigir erros
Erros que não são detectados na revisão do modelo de requisitos passam adiante para o projeto (onde pode ou não ser encontrados)
(4) Integrando Métricas Dentro do Processo de Software
Dificuldades
A maioria dos desenvolvedores de sw ainda não mede nada e muitos têm pouca vontade de começar
A resistência pela inexistência de medidas coletadas no passado.
Estabelecer um programa bem-sucedido de métricas de software para empresa inteira é um trabalho difícil, mas os benefícios das medidas são atraentes e compensa o trabalho duro
(1) Argumentos favoráveis a métricas de software
Sem medir, não há como determinar se o processo está melhorando. Sem melhoria, você está perdido
Solicitando e avaliando medidas
Uma equipe de software e seu gerente pode estabelecer objetivos claros para melhoria do processo de sw
Estabelecimento de metas de melhoria
Deve-se entender o status do desenvolvimento de software
Deve-se usar medidas para estabelecer uma linha de base do processo, a partir da qual as melhorias podem ser avaliadas
Principais preocupações dos gerentes de projeto
Desenvolver estimativas claras de projeto
Produzir sistemas de qualidade mais alta
Entrega do produto dentro do prazo
Aspectos melhores controlados realizando-se medições para definir uma linha de base de projeto
A linha de base serve como referência para estimativas
Pouco tempo para pensamento estratégico
A coleção de métricas de qualidade permite a sintonização do processo de software pela organização para remover as causas vitais de defeitos (com maior impacto sobre o desenv. de sw
(2) Estabelecendo uma linha de base
Benefícios nos níveis (técnicos) de processo, projeto e produto
Linhas de base das métricas
Dados coletados de projetos de desenvolvimento de sw do passado
Podem ser
Simples (uma simples tabela de dados)
Complexa (uma abrangente base de dados - dezenas de medidas de projeto e métricas derivadas delas)
Para ser eficazes na melhoria do processo e estimativas (custo e esforço), deve ter os seguintes atributos
Os dados devem ser razoavelmente precisos
Deve-se coletar dados de tantos projetos quantos for possível
As medidas devem ser consistentes através de todos os projetos dos quais são coletadas
As aplicações devem ser similares ao trabalho que deve ser estimado
(3) Coleta, cálculo e avaliação de métricas
A coleta de dados requer uma investigação histórica de projetos passados
a coleta dinâmica, para estabelecer a referência é uma situação ideal
Após a coleta de medidas, calcula-se as métricas
As métricas devem ser avaliadas e aplicadas durante:
Trabalho técnico
Controle de projeto
A estimativa
E melhoria de processo
A avaliação das métricas
focaliza as razões subjacentes para os resultados obtidos
produz um conjunto de indicadores que guiam o projeto ou o processo
(5) Métricas para Pequenas Organizações
A maioria das empresas de software são de pequeno porte (menos de 20 profissionais)
Na maioria dos casos não é viável que essas empresas desenvolvam programas abrangentes de métricas de sw
Apesar disso, todas organizações de sw devem medir e usar as métricas resultantes para melhorar
Seu processo local
A qualidade e prazo dos produtos produzidos
Abordagem de bom senso para implementação de qualquer atividade relacionada com processo de sw
Mantenha simples
Para derivar um conjunto de métricas simples e com valor que atendam às necessidades específicas da organização
Focalizar nos resultados em vez das medição
Ajuste para satisfazer as necessidades locais
Certifique-se de que tudo agregue valor
O grupo de software é consultado para definir um objetivo único que requer melhorias
Exemplo
“reduzir o tempo necessário para avaliar e implementar
solicitações de alterações”
Medidas de fácil obtenção que podem ser escolhidas por uma pequena organização
Esforço (homem-hora) necessário para fazer a alteração, Walteração.
Tempo (horas ou dias) para fazer a alteração, talteração.
Tempo (horas ou dias) decorridos desde o término da avaliação até a atribuição da ordem de alteração para o pessoal, avaliação.
Erros descobertos durante o trabalho para fazer a alteração, Ealteração.
Esforço (homem-hora) para executar a avaliação, Wavaliação.
Defeitos descobertos depois que a alteração é liberada para o cliente, Dalteração
Tempo (horas ou dias) decorridos desde o instante em que é feita uma solicitação até que a avaliação esteja completa, tfila.
Uma vez coletadas as medidas para um conjunto de solicitações de alteração, pode-se calcular as seguintes métricas
A porcentagem de tempo decorrido gasto na classificação inicial, avaliação e atribuição da mudança e implementação da alteração
o tempo total desde a solicitação de alteração até a implementação da alteração
Percentual do trabalho necessário para avaliação e implementação
As métricas obtidas podem ser analisadas no contexto de dados de qualidade: Ealteração e Dalteração
A análise permite visualizar onde o processo de solicitação de alteração se retarda e permite conduzir às etapas de processo para reduzir tfila, Wavaliação, tavaliação, Walteração e/ou Ealteração
A eficiência na remoção de defeitos pode ser calculada
DRE = Ealteração / (Ealteração + Dalteração)
A DRE pode ser comparada com o tempo decorrido e o trabalho total para determinar o impacto das atividades de garantia de qualidade sobre o tempo e trabalho necessários para fazer uma alteração
Os custos da coleta de medidas e cálculo as métricas podem apresentar substancial retorno sobre o investimento se as informações derivadas dos dados das métricas levarem a melhorias significantes.
(6) Estabelecendo um Programa de Métricas de Software
Guia abrangente (SEI - Software Engineering Institute) orientado a metas
Formalize as suas metas de medição.
Identifique questões quantificáveis e os indicadores relacionados que você usará para ajudá-lo a atingir as suas metas de medição.
Identifique as entidades e atributos relacionados com as suas submetas.
Identifique os elementos de dados que você coletará para construir os indicadores que ajudam a responder às suas questões.
Identifique as suas submetas.
Defina as medidas a ser usadas e torne essas definições operacionais.
Identifique o que você quer saber ou aprender.
Identifique as ações que você tomará para implementar as medidas.
Identifique as suas metas de negócio
Prepare um plano para implementar as medidas.
As métricas de software devem ser motivadas pelas metas de negócio e técnicas que você deseja atingir
Etapas 6-10
Metas de medição
refinamento
Questões
refinamento
entidades e atributos
refinamento
métricas