Diretrizes:  Métricas

Tópicos

• Princípios
• Uma Taxonomia de Métricas
• Um Conjunto Mínimo de Métricas
• Um Conjunto Pequeno de Métricas
• Um Conjunto Completo de Métricas
  • O Que Deverá Ser Medido?
  • O Processo
  • O Produto
  • O Projeto
  • Os Recursos

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 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 alterações 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 do cronograma 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 Atribuído

O método mais usado ([PMI96]) para medir o andamento é a Análise do Valor Atribuído.

A forma mais simples de medir o valor atribuído é 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 atribuído dividido pelo total de esforço estimado original do projeto. A produtividade (ou Índice de Desempenho) é o valor atribuído 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 a maior ou a 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 Extreme Programming (XP)[JEF01]. Refira-se às estimativas originais como "pontos" e meça as novas tarefas em relação a esses mesmos "pontos", sem efetuar ajustes para o desempenho real. A vantagem de "pontos" é que aumentos (ou reduções) no desempenho podem ser controlados ("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 atribuído. É 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 atribuído é abordado com mais detalhes na seção Um Conjunto Completo de Métricas: Plano de Projeto mais adiante.

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.
  • É possível registrar mais informações, como uma "categoria de esforço" subjetiva de "menos de 1 dia", "1 dia", "menos de 5 dias" e "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 mais adiante.
    
• 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 abrangência é 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 informar o andamento é utilizar uma Tendência de Andamento 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.

O livro 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

Um Conjunto Completo de Métricas

O Que Deverá Ser Medido?

Os itens a serem medidos são:

• o Processo — a seqüência de atividades acionada para criar o software (e outros artefatos);
• o Produto — os artefatos do processo, como software, documentos e modelos;
• o Projeto — a totalidade de recursos, atividades e artefatos 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 das atividades planejadas formalmente. As atividades serão planejadas pelo Gerente de Projeto através de 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 Rational Unified Process (RUP) são os artefatos, que são documentos, modelos ou elementos do modelo. Os modelos são conjuntos 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 é fácil identificar se uma métrica se aplica ao modelo como um todo ou a um elemento. Quando isso não está claro, é fornecido um texto explicativo.

Características de Artefatos

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 artefato não se comporta conforme especificado, não obedece à especificação correspondente ou possui outras características indesejáveis
  • Complexidade — uma medida da dificuldade de uma estrutura ou de um 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 satisfaz o requisito de ter uma finalidade única e bem definida
  • 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
• Abrangência — uma medida do quanto um artefato satisfaz todos os requisitos (explícitos e implícitos — o Gerente 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 satisfeitos por artefatos em um nível inferior e, sob uma outra perspectiva, de que um artefato em qualquer nível tem um motivo para existir
• Volatilidade — o grau de mudança ou manipulações em um artefato em decorrência de defeitos ou requisitos variáveis
• Esforço — uma medida do trabalho (unidades de equipe-tempo) necessário para produzir um artefato

Nem todas essas características se aplicam a todos os artefatos: as mais relevantes são mencionadas com o artefato 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, quando você 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 Gerente 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 equipe-tempo (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e solicitações de mudança (abertos, fechados)
Qualidade	Defeitos — número de defeitos (abertos, fechados), por gravidade
Rastreabilidade	Rastreabilidade de Requisitos para UC = Rastreável para Modelo de Casos de Uso/Nu Rastreabilidade de Design = Rastreável para Modelo de Design/Nd Rastreabilidade de Implementação = Rastreável para Modelo de Implementação/(Nd+Ni) Rastreabilidade de Teste = Rastreável para modelo de teste/(Nd+Ni+Nt)

Modelo de Casos 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 artigo "The Estimation of Effort and Size based on Use Cases", disponível na Central de Recursos) 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 equipe-tempo (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e solicitações de mudança (abertos, fechados)
Qualidade	Complexidade relatada (0-5, por analogia com COCOMO (Construct Cost Model) [BOE81], no nível de classe. A faixa de complexidade é mais estreita em níveis mais altos de abstração; consulte o artigo "The Estimation of Effort and Size based on Use Cases", disponível na Central de Recursos) Defeitos — número de defeitos (abertos, fechados), por gravidade
Abrangência	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 (a partir de 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 equipe-tempo (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e solicitações de mudança (abertos, fechados)
Qualidade	Complexidade	Resposta para uma Classe (RFC): 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
Abrangência	Número de classes concluídas/número de classes estimadas (identificadas) Rastreabilidade de análise (no modelo de Casos de Uso)
Rastreabilidade	Não aplicável — o modelo de análise se transforma no 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 assim por diante. Consulte [HEND96] para obter detalhes sobre o significado e o 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", Transações IEEE sobre Engenharia de Software, 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 equipe-tempo (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e solicitações de mudança (abertos, fechados)
Qualidade	Complexidade	Resposta para uma Classe (RFC): 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
Abrangência	Número de classes concluídas/número de classes estimadas (identificadas) Rastreabilidade de design (no modelo de Casos de Uso) Rastreabilidade de design (nos 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 componentes 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 equipe-tempo (com produção, mudanças e correções separadas)
Volatilidade	Número de defeitos e solicitações de mudança (abertos, fechados) 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
Abrangência	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 (no modelo de Casos de Uso) Rastreabilidade de implementação (nos Atributos de Requisitos) Rastreabilidade do modelo de teste multiplicada pela Abrangência do 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 obter informações sobre os 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 obter informações sobre essa métrica.

*** Obtido 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 equipe-tempo (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 solicitações de mudança (abertos, fechados, em relação ao modelo de teste
Qualidade	Defeitos — número de defeitos (abertos, fechados) por gravidade (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)
Abrangência	Número de casos de teste registrados/número de casos de teste estimados Rastreabilidade de teste (no modelo de Casos de Uso) Rastreabilidade de teste (nos 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 usado para gerenciar Solicitações de Mudança.

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 equipe-tempo
Volatilidade	Quebra (estimada, real) para o subconjunto do modelo de implementação.
Abrangência	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)

e fatores derivados para variação de custos, variação de cronograma, e assim por diante. Consulte [ROY98] para obter informações sobre a aplicação de uma abordagem de valor atribuído ao gerenciamento do 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 em um gráfico que mostre 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 Gerente de Projeto, podem ser obtidas das métricas reunidas para o produto e o processo. São elas:

• Modularidade = quebra média (NCNB*) por mudança corretiva ou de aperfeiçoamento no modelo de implementação
• Adaptabilidade = esforço médio por mudança corretiva ou de aperfeiçoamento no modelo de implementação
• Maturidade = tempo de teste ativo/número de mudanças corretivas
• Manutenibilidade = Produtividade de Manutenção/Produtividade de Desenvolvimento = [correções cumulativas reais/esforço cumulativo de mudanças 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 cumulativa-correções cumulativas
• Quantidade de retrabalho = [quebra cumulativa-correções cumulativas]/unidade NCNB testada

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

O andamento deve ser relatado a partir do plano do projeto, cujo status é definido usando métricas de conclusão de artefato, com um peso específico (a partir da perspectiva de um valor atribuído) sendo atribuído à produção do software.

Se um modelo de estimativa como o COCOMO (consulte [BOE81] for usado, 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.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process