Princípios

• As métricas devem ser simples, objetivas, fáceis de coletar, fáceis de interpretar e difíceis de interpretar incorretamente.
• A coleta das métricas deve ser automatizada e não-intrusiva, ou seja, não deve interferir nas atividades dos desenvolvedores.
• As métricas devem contribuir para a avaliação da qualidade no início do ciclo de vida, quando os esforços para melhorar a qualidade do software são eficazes.
• Tendências e valores absolutos de métricas devem ser usados ativamente pelas equipes de gerenciamento e de engenharia para informar o andamento e a qualidade em um formato consistente.
• A seleção de um conjunto mínimo ou mais extenso de métricas dependerá das características e do contexto do projeto: se ele for grande ou tiver requisitos rigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e de avaliação tiverem um ótimo conhecimento sobre métricas, talvez seja útil coletar e analisar as métricas técnicas. O contrato pode exigir que determinadas métricas sejam coletadas ou a organização pode estar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma resposta simples que se adapte a todas as circunstâncias. O Gerente de Projeto deve selecionar o que é apropriado quando o Plano de Métricas for produzido. No entanto, quando você apresentar um plano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar e cometer erros.

Uma Taxonomia de Métricas

As métricas para determinados aspectos do projeto incluem:

• Andamento em termos de tamanho e complexidade.
• Estabilidade em termos de taxa de mudança nos requisitos ou implementação, tamanho ou complexidade.
• Modularidade em termos do escopo de mudança.
• Qualidade em termos da quantidade e do tipo de erros.
• Maturidade em termos da freqüência de erros.
• Recursos em termos de despesas do projeto versus despesas planejadas

As tendências são importantes e de alguma forma mais importantes de serem monitoradas do que qualquer valor absoluto no tempo.

Um Conjunto Mínimo de Métricas

Até mesmo os projetos menores devem controlar o andamento para verificar se estão dentro do cronograma e do orçamento e, caso não estejam, para refazer a estimativa e determinar se serão necessárias mudanças no escopo. O foco deste conjunto mínimo de métricas estará, portanto, nas métricas de progresso.

• Valor Atribuído. É usado para refazer a estimativa da programação e do orçamento para o restante do projeto e/ou para identificar a necessidade de mudanças no escopo.
• Tendências de Defeitos. São usadas para ajudar a projetar o esforço necessário para eliminar defeitos.
• Tendência de Andamento de Teste. É usada para determinar quanto da funcionalidade está realmente concluído.

Essas métricas são descritas a seguir mais detalhadamente.

Valor Agregado

O método normalmente mais utilizado ([PMI96]) para medir o progresso é a Análise de Valor Agregado.

A forma mais simples de medir o valor agregado é somar o esforço estimado original de todas as tarefas concluídas. Um "percentual de conclusão" do projeto pode ser calculado como o valor agregado, dividido pelo total de esforço estimado original do projeto. A produtividade (ou Índice de Desempenho) é o valor agregado dividido pelo esforço real empregado nas tarefas concluídas.

Por exemplo, suponha que o esforço de codificação tenha sido dividido em diversas tarefas, muitas das quais já estão concluídas. A estimativa original para as tarefas concluídas era 30 dias de esforço. O esforço estimado total para o projeto era 100 dias. Assim, podemos estimar que aproximadamente 30% do projeto estão concluídos.

Suponha que as tarefas tenham sido concluídas abaixo do orçamento - faltando apenas 25 dias para sua conclusão. O Índice de Desempenho é 30 / 25 = 1,2 ou 120%.
Podemos estimar que o projeto será concluído com uma insuficiência de 20% no orçamento e reduzir nossas estimativas de acordo.

Considerações

• O Índice de Desempenho deve ser usado apenas para ajustar estimativas de tarefas semelhantes. A conclusão antecipada de tarefas de obtenção de requisitos não sugere que a codificação será concluída com mais rapidez. Dessa forma, calcule o Índice de Desempenho apenas para tipos parecidos de tarefas e ajuste estimativas somente de tarefas semelhantes.
• Considere outros fatores. As tarefas futuras serão realizadas por equipes com a mesma qualificação e nas mesmas condições? Os dados foram contaminados por "desvios" - tarefas cuja estimativa foi calculada extremamente maior ou menor? O tempo está sendo relatado de forma consistente (por exemplo, as horas extras serão incluídas mesmo se não forem pagas)?
• As estimativas para tarefas mais novas já estão considerando o Índice de Desempenho? Se estiverem, é provável que as estimativas para novas tarefas se aproximem mais do objetivo, fazendo com que o índice de desempenho chegue a quase 100%. Você deverá refazer a estimativa de todas as tarefas incompletas de forma consistente ou adotar a prática de XP (Extreme Programming)[JEF01] - refira-se às estimativas originais como "pontos" e meça as novas tarefas em relação a esses mesmos "pontos", sem ajustar ao desempenho real. A vantagem de "pontos" é que aumentos (ou reduções) no desempenho podem ser ser monitorados ("velocidade do projeto" na terminologia XP).

Se as tarefas forem extensas (mais do que cinco dias) ou se existirem muitas tarefas parcialmente concluídas, convém incluí-las na análise. Aplique um "percentual de conclusão" subjetivo, multiplique-o pela estimativa de esforço da tarefa e inclua-o no valor agregado. É possível obter maior consistência nos resultados se existirem regras claras para atribuir o percentual de conclusão. Por exemplo, uma regra que poderia ser estabelecida é que uma tarefa de codificação não receba uma conclusão superior a 80% enquanto o código não passar por uma revisão.

O valor agregado é tratado com mais detalhes sob a seção Conjunto Completo de Métricas: Plano de Projeto a seguir.

Valor de Negócios

Um método de monitoramento do progresso baseado em valor utiliza indicadores que representam a realização de benefícios e o aproveitamento de oportunidades de negócios, além da comparação do valor realizado versus custo realizado feita na Análise de Valor Agregado.

A fonte para os indicadores voltados ao negócio é o Artifact: Caso de Negócio, que fornece diretrizes para indicadores relativos ao projeto de desenvolvimento em si. Também podem ser extraídos indicadores analidando a modelagem da Cadeia de Resultados. Alguns exemplos de indicadores:

• % entregue, relativo não aos custos, mas ao ROI e benefícios totais previstos
• Índices de satisfação dos usuários dos protótipos, testes alfa e testes beta
• Exposição total aos riscos do projeto X Orçamento e reservas gerenciais para resposta aos riscos
• Exposição aos riscos decorrentes de cada projeto externo associado pela Cadeia de Resultados
• Exposição aos riscos decorrentes de cada funcionalidade definida para o sistema
• Custo de desenvolver X Custo de adquirir funcionalidades restantes

Tendência de Defeitos

Em geral, é útil controlar a tendência de defeitos abertos e fechados. Esse controle fornece uma indicação aproximada da existência ou não de uma quantidade significativa de trabalho de correção de defeitos a ser concluído e da rapidez com que estão sendo fechados.

As tendências de defeitos são apenas uma das métricas fornecidas pelo Rational ProjectConsole.

Considerações

• As solicitações de mudança não devem ter o mesmo peso, mesmo que afetem uma linha de código ou causem um retrabalho significativo de design. Você pode lidar com isso seguindo algumas destas técnicas:
  • Cuidado com desvios. Solicitações de Mudança que exijam um trabalho considerável devem ser identificadas como tal e controladas como tarefas separadas, não incluídas em um grupo de correções de erros genéricos. Se um grande número de pequenas correções estiver dominando a tendência, convém agrupá-las de modo que cada Solicitação de Mudança represente uma unidade de trabalho mais consistente.
  • Você pode registrar informações adicionais, como "categoria de esforço" subjetivo de "menos de 1 dia" "1 dia" "menos de 5 dias" "mais de 5 dias".
  • É possível registrar SLOCs estimadas e SLOCs reais para cada Solicitação de Mudança. Consulte Um Conjunto Pequeno de Métricas a seguir.
    
• A ausência de defeitos registrados pode implicar na ausência de testes. Cuidado com o nível de esforço de teste que ocorre ao examinar tendências de defeitos.

Tendência de Andamento de Teste

A última medida de integralidade é quanto da funcionalidade foi integrado.
Se cada uma das tarefas de desenvolvimento representar um conjunto de funcionalidades integradas, um gráfico de tendências de valor atribuído poderá ser suficiente.

Uma forma bastante simples de comunicar o progresso é utilizar uma Tendência de Progresso de Teste.

Considerações

Um Conjunto Pequeno de Métricas

Em muitos projetos, o conjunto mínimo de métricas descrito anteriormente não é suficiente.

Software Project Management, a Unified Framework [ROY98], recomenda o conjunto de métricas a seguir para todos os projetos. Observe que essas métricas requerem dados reais e estimados de Linhas de Código-Fonte (SLOC) para cada solicitação de mudança, que podem ser obtidos através de esforço adicional.

Métricas e Métricas primitivas

Métricas de Qualidade para o Produto Final

Outras métricas interessantes podem resultar desse conjunto pequeno de métricas:

Indicadores de Andamento

Conjunto Completo de Métricas

O que Deve Ser Medido?

Os itens a serem medidos são:

• o Processo - a seqüência de tarefas chamadas para produzir o produto de software (e outros produtos de trabalho);
• o Produto - os produtos de trabalho do processo, incluindo software, documentos e modelos;
• o Projeto - a totalidade de recursos, tarefas e produtos de trabalho do projeto;
• os Recursos - pessoas, métodos, ferramentas, tempo, esforço e orçamento disponíveis para o projeto.

O Processo

Para caracterizar completamente o processo, as medições deverão ser efetuadas no nível mais inferior da tarefa planejada formalmente. As tarefas serão planejadas pelo Coordenador de Projeto utilizando um conjunto inicial de estimativas. Um registro dos valores reais ao longo do tempo e de quaisquer estimativas atualizadas deverá ser mantido.

O Produto

Os produtos no RUP (Rational Unified Process) são os Produtos de Trabalho, que consistem em documentos, modelos ou elementos de modelo. Os modelos são coleções de itens semelhantes (os elementos do modelo). Por isso, as métricas recomendadas são listadas aqui com os modelos aos quais elas se aplicam: geralmente fica claro se uma métrica aplica-se ao modelo como um todo ou a um elemento. Quando isso não está claro, é fornecido um texto explicativo.

Características do Produto de Trabalho

Em geral, estas são as características que estamos interessados em medir:

• Tamanho - uma medida do número de itens em um modelo, a duração, a extensão ou o volume de um item
• Qualidade
  • Defeitos - indicações de que um produto de trabalho não é desempenhado conforme especificado, não está em conformidade com sua especificação ou possui outras características indesejáveis
  • Complexidade - uma medida da complexidade de uma estrutura ou algoritmo: quanto maior a complexidade, mais difícil é compreender e modificar uma estrutura. Além disso, há indícios de que estruturas complexas tendam a apresentar falhas
  • Acoplamento - uma medida do quanto os elementos de um sistema estão interconectados
  • Coesão - uma medida do quanto um elemento ou componente atende ao requisito de ter um único propósito bem definido
  • Primitividade - o grau até onde as operações ou os métodos de uma classe podem ser compostos a partir de outras operações ou métodos oferecidos pela classe
• Integralidade - uma medida do quanto um produto de trabalho atende a todos os requisitos (explícitos e implícitos - o Coordenador de Projeto deve se esforçar para explicitá-los ao máximo a fim de limitar o risco de expectativas não cumpridas. Optamos por não fazer a distinção aqui entre suficiente e completo.
• Rastreabilidade - uma indicação de que os requisitos em um nível estão sendo atendidos por produtos de trabalho em um nível inferior e, sob uma outra perspectiva, de que um produto de trabalho em qualquer nível tem um motivo para existir
• Volatilidade - o grau de alteração ou incoerência em um produto de trabalho em decorrência de defeitos ou requisitos variáveis
• Esforço - uma medida do trabalho (unidades de tempo da equipe) necessária para produzir um produto de trabalho

Nem todas essas características aplicam-se a todos os produtos de trabalho: as mais relevantes são elaboradas com o produto de trabalho específico nas tabelas a seguir. Há casos em que diversas métricas são listadas em relação a uma característica. Isso quer dizer que possivelmente todas são interessantes, por fornecerem uma descrição completa da característica a partir de várias perspectivas. Por exemplo, ao considerar a rastreabilidade de Casos de Uso, em última instância, todos devem ser rastreáveis para um modelo de implementação (testado): nesse meio tempo, ainda será interessante para o Coordenador de Projeto saber quantos Casos de Uso podem ser rastreados para o Modelo de Análise, como uma medida de progresso.

Documentos

As métricas recomendadas se aplicam a todos os documentos do RUP.

Modelos

Requisitos

Atributos de Requisitos

Isto é, na verdade, um elemento do modelo.

Característica	Métricas
Tamanho	número do total de requisitos (= Nu+Nd+Ni+Nt) número a ser rastreado para casos de uso ( = Nu) número a ser rastreado apenas para design, implementação, teste ( = Nd) número a ser rastreado apenas para implementação, teste ( = Ni) número a ser rastreado apenas para teste ( = Nt) Observe que isso divide os requisitos em dois grupos: aqueles que serão modelados pelos Casos de Uso e naqueles que não o serão. Espera-se que a rastreabilidade de Casos de Uso seja responsável pelos requisitos atribuídos aos Casos de Uso, de modo a controlar o design, a implementação e o teste.
Esforço	Unidades de tempo da equipe (produção, alteração e reparo)
Volatilidade	Número de defeitos e controles de mudanças
Qualidade	Número de defeitos por gravidade
Rastreabilidade	Rastreabilidade de Requisitos-para-UC = Rastreável para Modelo de Caso de Uso/Nu Rastreabilidade de Design = Rastreável para Modelo de Design/Nd Rastreabilidade de Implementação = Rastreável para o Modelo de Implementação/(Nd+Ni) Rastreabilidade de Teste = Rastreável para Modelo de Teste/(Nd+Ni+Nt)

Modelo de Caso de Uso

Característica	Métricas
Tamanho	Número de Casos de Uso Número de Pacotes de Casos de Uso Nível Relatado de Caso de Uso (consulte o white paper, "A Estimativa de Esforço e Tamanho com Base em Casos de Uso" no Web site da IBM) Número de cenários (total e por caso de uso) Número de atores Tamanho do Caso de Uso (páginas de fluxo de eventos, por exemplo)
Esforço	Unidades de tempo da equipe com produção, alteração e reparo
Volatilidade	Número de defeitos e controles de mudanças
Qualidade	Complexidade relatada (0-5, por analogia com COCOMO [BOE81], no nível de classe; o intervalo de complexidade é mais estreito em níveis mais altos de abstração - consulte o white paper, "A Estimativa de Esforço e Tamanho com Base em Casos de Uso" no Web site da IBM) Defeitos - número de defeitos, por gravidade, abertos e fechados
Integralidade	Casos de Uso concluídos (revisados e sob gerenciamento de configuração sem defeitos pendentes)/casos de uso identificados (ou número estimado de casos de uso) Rastreabilidade de Requisitos-para-UC (em Atributos de Requisitos)
Rastreabilidade	Análise Cenários realizados no modelo de análise/total de cenários Design Cenários realizados no modelo de design/total de cenários Implementação Cenários realizados no modelo de implementação/total de cenários Teste Cenários realizados no modelo de teste (casos de teste)/total de cenários

Design

Modelo de Análise

Característica	Métricas
Tamanho	Número de classes Número de subsistemas Número de subsistemas de subsistemas... Número de pacotes Métodos (internos, externos) por classe Atributos (internos, externos) por classe Profundidade da árvore de herança Número de filhos
Esforço	Unidades de tempo da equipe para produção, mudanças e correções
Volatilidade	Número de defeitos e controles de mudanças
Qualidade	Complexidade	RFC (Resposta para uma Classe): talvez seja difícil calculá-la porque é necessário um conjunto completo de diagramas de interação.
	Acoplamento	Número de filhos Acoplamento entre objetos (desdobramento de classes)
	Coesão	Número de filhos
	Defeitos	Número de defeitos (abertos, fechados), por gravidade
Integralidade	Número de classes concluídas/número de classes estimadas (identificadas) Rastreabilidade de Análise (em Modelo de Caso de Uso)
Rastreabilidade	Não aplicável - o modelo de análise torna-se o modelo de design.

Podemos observar aqui algumas métricas técnicas específicas de OO que talvez não sejam familiares - profundidade da árvore de herança, número de filhos, resposta para uma classe, acoplamento entre objetos e outros. Consulte [HEND96] para obter detalhes do significado e do histórico dessas métricas. Várias dessas métricas foram sugeridas originalmente por Chidamber e Kemerer (consulte "A metrics suite for object oriented design", IEEE Transactions on Software Engineering, 20(6), 1994), mas nós as aplicamos aqui conforme sugerido em [HEND96] e preferimos a definição de falta de coesão em métodos LCOM (Lack of Cohesion in Methods) apresentada nesse trabalho.

Modelo de Design

Característica	Métricas
Tamanho	Número de classes Número de subsistemas de design Número de subsistemas de subsistemas... Número de pacotes Métodos (internos, externos) por classe Atributos (internos, externos) por classe Profundidade da árvore de herança Número de filhos
Esforço	Unidades de tempo da equipe (para produção, mudança e reparo)
Volatilidade	Número de defeitos e controles de mudanças
Qualidade	Complexidade	RFC (Resposta para uma Classe): talvez seja difícil calculá-la porque é necessário um conjunto completo de diagramas de interação.
	Acoplamento	Número de filhos Acoplamento entre objetos (desdobramento de classes)
	Coesão	Número de filhos
	Defeitos	Número de defeitos por gravidade
Integralidade	Número de classes concluídas/número de classes estimadas (identificadas) Rastreabilidade de Design (em Modelo de Caso de Uso) Rastreabilidade de Design (em Atributos de Requisitos)
Rastreabilidade	Número de classes no Modelo de Implementação/número de classes

Implementação

Modelo de Implementação

Característica	Métricas
Tamanho	Número de classes Número de arquivos Número de subsistemas de implementação Número de subsistemas de subsistemas... Número de pacotes Métodos (internos, externos) por classe Atributos (internos, externos) por classe Tamanho de métodos* Tamanho de atributos* Profundidade da árvore de herança Número de filhos Tamanho* estimado na conclusão
Esforço	Unidades de tempo da equipe (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e controles de mudanças Quebra* para cada mudança corretiva ou de aperfeiçoamento, estimada (antes da correção) e real (no fechamento)
Qualidade	Complexidade	Resposta para uma Classe (RFC) Complexidade ciclomática de métodos**
	Acoplamento	Número de filhos Acoplamento entre objetos (desdobramento de classes) Acoplamento para transmissão de mensagens (MPC)***
	Coesão	Número de filhos Falta de coesão em métodos (LCOM)
	Defeitos	Número de defeitos (abertos, fechados), por gravidade
Integralidade	Número de unidades de classe testadas/número de classes no modelo de design Número de classes integradas/número de classes no modelo de design Rastreabilidade de Implementação (em Modelo de Caso de Uso) Rastreabilidade de Implementação (em Atributos de Requisitos) Rastreabilidade de Modelo de Teste multiplicado por Integralidade de Teste Integração ativa e tempo de teste do sistema (acumulado a partir do processo de teste), ou seja, o tempo de operação do sistema (usado para calcular a maturidade)

* É necessário escolher algum método para medir o tamanho do código e depois aplicá-lo de forma consistente (por exemplo, sem comentários, sem espaços em branco). Consulte [ROY98] para uma discussão dos méritos e a aplicação de 'linhas de código' como uma métrica. Consulte essa mesma referência também para obter a definição de 'quebra'.

** O uso da complexidade ciclomática não é aceito mundialmente, principalmente quando aplicado aos métodos de uma classe. Consulte [HEND96] para uma descrição dessa métrica.

*** Originalmente de Li e Henry, "Object-oriented metrics that predict maintainability", J. Systems and Software, 23(2), 1993, e também descrito em [HEND96].

Teste

Modelo de Teste

Característica	Métricas
Tamanho	Número de Casos, Procedimentos e Scripts de Teste
Esforço	Unidades de tempo da equipe (com produção, mudanças e correções separadas) para a produção de casos de teste, e assim por diante
Volatilidade	Número de defeitos e controles de mudanças pedidos a partir do modelo de testes
Qualidade	Defeitos - número de defeitos, por gravidade, abertos e fechados (estes defeitos são aqueles apontados em relação ao próprio modelo de teste, e não aqueles apontados pela equipe de teste em relação a outro software)
Integralidade	Número de casos de teste registrados/número de casos de teste estimados Rastreabilidade de Teste (em Modelo de Caso de Uso) Rastreabilidade de Teste (em Atributos de Requisitos) Cobertura do código
Rastreabilidade	Número de Casos de Teste relatados como bem-sucedidos no Sumário de Avaliação de Testes/Número de casos de teste

Gerenciamento

Modelo de Mudança - é um modelo conceitual para apresentações consistentes - as métricas serão coletadas de qualquer sistema utilizado para gerenciar Controles de Mudanças.

Característica	Métricas
Tamanho	Número de defeitos, solicitações de mudança por gravidade e status; também categorizado como número de mudanças de aperfeiçoamento, número de mudanças de adaptação e número de mudanças corretivas.
Esforço	Esforço para correção de defeitos, esforço para implementação de mudanças em unidades de tempo da equipe
Volatilidade	Quebra (estimada, real) para o subconjunto do modelo de implementação.
Integralidade	Número de defeitos detectados/número de defeitos estimados (se um modelo de confiabilidade for usado)

Plano de Projeto (seção 4.2 do Plano de Desenvolvimento de Software)

Essas são medidas provenientes da aplicação de Técnicas de Valor Atribuído ao gerenciamento de projeto; são chamadas em conjunto de Critérios de Sistemas de Controle de Custos/Cronograma (C/SCSC). Uma técnica simples de valor atribuído que é descrita acima como parte de Um Conjunto Mínimo de Métricas. É possível realizar análises mais detalhadas usando métricas relacionadas, que incluem:

• BCWS, Custo Orçado para Trabalho Programado
• BCWP, Custo Orçado para Trabalho Realizado
• ACWP, Custo Real para Trabalho Realizado
• BAC, Orçamento na Conclusão
• EAC, Estimativa na Conclusão
• CBB, Base do Orçamento Contratual
• LRE, Estimativa Revisada Mais Recente (EAC)

fatores derivados para variação de custo e planejamento. Consulte [ROY98] para uma discussão da aplicação de uma abordagem de valor atribuído para gerenciamento de projeto de software.

O Projeto

O projeto precisa ser caracterizado em termos de tipo, tamanho, complexidade e formalidade (embora tipo, tamanho e complexidade geralmente determinem formalidade), pois esses aspectos condicionarão as expectativas sobre vários limites de medidas de nível inferior. Outras restrições deverão ser informadas no contrato (ou nas especificações). As métricas resultantes do processo, do produto e dos recursos captarão todas as outras métricas no nível do projeto. O tipo e o domínio do projeto podem ser registrados através de uma descrição de texto, certificando-se de que haja detalhes suficientes para caracterizar o projeto com precisão. Registre o tamanho do projeto por custo, esforço, duração, tamanho do código a ser desenvolvido e pontos de função a serem liberados. A complexidade do projeto pode ser descrita - um pouco subjetivamente - colocando o projeto em um gráfico que mostra a complexidade técnica e de gerenciamento em relação a outros projetos concluídos. [ROY98], a Figura 14-1 mostra esse diagrama.

As métricas derivadas descritas em [ROY98], que são os principais indicadores do Coordenador de Projeto, podem ser obtidas das métricas reunidas para o produto e o processo. São elas:

• Modularidade = = quebra média (NCNB*) por alteração corretiva ou de aperfeiçoamento no modelo de implementação
• Adaptabilidade = esforço médio por alteração corretiva ou de aperfeiçoamento no modelo de implementação
• Maturidade = tempo de teste ativo/número de alterações corretivas
• Manutenabilidade = Produtividade de Manutenção/Produtividade de Desenvolvimento = [correções acumulativas reais/esforço acumulativo de alterações corretivas e de aperfeiçoamento]/[número estimado de NCNB na conclusão/esforço de produção estimado na conclusão]
• Estabilidade de retrabalho = quebra acumulativa-correções acumulativas
• Quantidade de retrabalho = [quebra acumulativa-correções acumulativas]/unidade NCNB testada

* NCNB é um tamanho de código sem comentários, sem espaços vazios.

O progresso deve ser reportado a partir do plano do projeto, utilizando métricas de conclusão de produtos de trabalho, com uma importância específica (a partir de uma perspectiva de valor atribuído) sendo designada à produção do software de trabalho.

Se um modelo de estimativa como o COCOMO (consulte [BOE81] for utilizado, os vários fatores de escala e geradores de custos deverão ser registrados. Na verdade, esses elementos formam uma caracterização bastante detalhada do projeto.

Os Recursos

Os itens a serem medidos incluem pessoas (experiência, habilidades, custo, desempenho), métodos e ferramentas (em termos do efeito sobre a produtividade, a qualidade e o custo), tempo, esforço e orçamento (recursos utilizados, recursos restantes).

O perfil profissional deve ser registrado ao longo do tempo, mostrando o tipo (analista, designer, etc.), a categoria (que implica no custo) e a equipe para a qual foi alocado. Tanto os dados reais como os planejados devem ser registrados.

Vale ressaltar novamente que o modelo COCOMO requer a caracterização da experiência e da capacidade da equipe, bem como do ambiente de desenvolvimento de software. Ele é um excelente framework para manter essas métricas.

As informações sobre despesas, orçamento e cronograma serão obtidas do Plano de Projeto.