Conceitos: Métricas

Avaliamos principalmente para obter controle de um projeto e, portanto, poder gerenciá-lo. Avaliamos para estimar se estamos perto ou longe dos objetivos definidos no plano em termos de conclusão, qualidade, compatibilidade com os requisitos etc.

Avaliamos também para podermos estimar melhor o esforço de novos projetos, o custo e a qualidade, com base na experiência passada. Por fim, avaliamos para estimar como melhorar algum aspecto importante do desempenho do processo ao longo do tempo, para examinar os efeitos das mudanças.

A avaliação de alguns aspectos importantes de um projeto adiciona um custo significativo. Portanto, não fazemos uma avaliação só porque podemos. Devemos definir metas muito precisas para esse esforço, e só coletar as métricas que nos permitirão satisfazer a essas metas.

Essas metas gerais de gerenciamento não se transformam facilmente em métricas. É preciso transformá-las em algumas submetas menores (ou metas de ação) que identificam as ações que os participantes do projeto devem realizar para alcançar a meta. É preciso ter certeza de que as pessoas envolvidas entendem os benefícios.

Em seguida, algumas submetas (mas não todas) precisariam de alguma métrica para serem coletadas.

Uma maneira útil de categorizar essas metas é por organização, projeto e necessidade técnica. Esse procedimento fornece um framework para refinar o que foi discutido acima.

Necessidades Organizacionais das Métricas

Uma organização precisa conhecer, e talvez melhorar, o custo por 'item', diminuir os tempos de construção (tempo de mercado), e ao mesmo tempo liberar o produto de qualidade conhecida (objetiva e subjetiva) e as demandas de manutenção apropriadas. Uma organização pode precisar melhorar de vez em quando (ou até mesmo continuamente) o seu desempenho para permanecer competitiva. Para reduzir os riscos, uma organização precisa conhecer o nível de habilidade e experiência da sua equipe, e garantir que há outros recursos e capacidades para competir no setor escolhido. Uma organização deve poder introduzir uma nova tecnologia e determinar a relação custo-benefício dessa tecnologia. A tabela a seguir lista alguns exemplos dos tipos de métricas relevantes para as necessidades de uma organização de desenvolvimento de software.

Questão	Métrica
Custo do Item	Custo por linha de código, custo por ponto de função, custo por caso de uso. Esforço normalizado (através da parte definida do ciclo de vida, da linguagem de programação, do nível da equipe, etc.) por linha de código, ponto de função ou caso de uso. Observe que essas métricas não são normalmente números simples - elas dependem do tamanho do sistema para serem apresentadas e de a programação estar ou não compactada.
Tempo de Construção	Tempo decorrido por linha de código ou por ponto de função. Observe que isso também dependerá do tamanho do sistema. A programação também pode ser diminuída adicionando a equipe - mas apenas até um ponto. A capacidade de gerenciamento de uma organização determinará exatamente onde é o limite.
Densidade do Defeito no Produto Liberado	Defeitos (descobertos após a liberação) por linha de código ou por ponto de função.
Qualidade Subjetiva	Facilidade de uso, facilidade de operação, aceitação do cliente. Embora sejam confusas, as maneiras de tentar a quantificação foram planejadas.
Facilidade de Manutenção	Custo por linha de código ou ponto de função por ano.
Perfil das Habilidades, Perfil da Experiência	O grupo de Recursos Humanos manteria presumivelmente algum tipo de banco de dados de habilidade e experiência.
Capacidade Tecnológica	Ferramentas - uma organização deve saber quais são mais usadas e o nível de conhecimento dos funcionários sobre as que não são tão usadas. Maturidade do Processo - onde se encontra a taxa da organização na escala SEI CMM, por exemplo? Capacidade do Domínio - em que domínios do aplicativo a organização é capaz de atuar?
Medidas de Melhoria do Processo	Tempo e esforço da execução do processo. Taxas de defeito, estatística de análise causal, taxas fixas, retalhamento e retrabalho.

Necessidades Organizacionais das Métricas

O Gerente de Projeto deve poder verificar se está se dirigindo para essas metas, expandidas na tabela a seguir para fornecer alguma idéia do que será considerado no exame das medições do projeto:

Questão

Esforço e Orçamento do Projeto

Como acompanhar o esforço e o custo do projeto em relação ao plano?

Programação do Projeto

O projeto está alcançando os seus marcos?

Transição/Instalação

O esforço previsto, o custo e os requisitos de habilidade são aceitáveis?

Operação

O esforço previsto e os requisitos de habilidade são suportáveis pelo cliente?

Manutenção/Suportabilidade

O esforço previsto e os requisitos de habilidade são aceitáveis para o cliente?

Requisitos Funcionais

Os requisitos válidos estão completos?
Os requisitos estão alocados para uma iteração?
Os requisitos estão sendo atendidos de acordo com o plano?

Requisitos Não-Funcionais

Desempenho
- O sistema está atendendo aos requisitos de receptividade, taxa de transferência de dados, tempo de recuperação?
Capacidade
- O sistema comporta o número necessário de usuários simultâneos? O site da web comporta o número necessário de ocorrências por segundo? Há armazenamento suficiente para o número necessário de registros de cliente?
Fatores de Qualidade
- Confiabilidade: qual é a freqüência permitida de falhas do sistema, e o que constitui uma falha do sistema?
- Usabilidade: o sistema é fácil e agradável de usar? Quanto tempo é preciso para aprender a usá-lo e saber quais são as habilidades necessárias?
- Tolerância a falhas/robustez/flexibilidade/capacidade de sobrevivência: o sistema pode continuar a funcionar se ocorrerem falhas? O sistema pode lidar com uma entrada inválida? O sistema é capaz de se recuperar automaticamente após uma falha?
Requisitos de Especialidade da Engenharia
- Segurança: o sistema pode ser executado sem risco à vida ou à propriedade (tangível e intangível)?
- Segurança/privacidade: o sistema protege os dados confidenciais contra acesso não autorizado? O sistema é seguro contra acesso malicioso?
- Impacto ambiental: o sistema atende aos requisitos ambientais?
Outros Requisitos Reguladores ou Legais
Restrições
- Ambiente externo: o sistema é capaz de funcionar no ambiente recomendado?
- Recursos, host, destino: o sistema atende às restrições de CPU, memória, linguagem, ambiente de hardware/software?
- Uso do commercial-off-the-shelf (COTS) ou outro software existente: o sistema atende às restrições de reutilização?
- Disponibilidade e habilidades da equipe: o sistema pode ser criado com o número e o tipo da equipe disponíveis?
- Suporte de interface/compatibilidade: o sistema pode suportar o acesso necessário a outros sistemas e a partir deles?
- Reusabilidade: que provisões são criadas para que o sistema seja reutilizável?
- Padrões impostos: o sistema e o método de desenvolvimento são compatíveis?
- Outras restrições de design (arquitetural, algorítmica, por exemplo): o sistema está usando o estilo arquitetural necessário? Os algoritmos prescritos estão sendo usados?

Esta é uma lista grande, mas não exaustiva, das questões do Gerente de Projeto. Muitas exigirão a coleta e a análise das métricas, e algumas também exigirão o desenvolvimento de testes específicos (para gerar medições) a fim de responder às questões propostas.

Necessidades Técnicas das Métricas

Muitas necessidades do projeto não precisarão ter medidas diretas, e mesmo as que precisarem, talvez não seja óbvio o que deve ser feito ou alterado para aperfeiçoá-las. Os atributos de qualidade de nível inferior podem ser usados para criar a qualidade em relação a vários atributos de qualidade de nível superior, como, por exemplo, aqueles identificados no ISO Standard 9126 (Características e Métricas da Qualidade do Software) e aqueles mencionados acima nas Necessidades do Projeto. Essas medidas técnicas são características e efeitos (cobrindo o processo e o produto) da engenharia (estrutural e comportamental), que contribuem para as necessidades das métricas do nível do projeto. Os atributos na tabela a seguir foram usados para gerar um conjunto de exemplo das métricas dos artefatos e do processo do Rational Unified Process. Isso pode ser encontrado em Diretrizes: Métricas.

Qualidade	Atributos
Excelência dos Requisitos	Volatilidade: freqüência de mudança, taxa de introdução de novos requisitos Validade: estes são os requisitos certos? Abrangência: está faltando algum requisito? Correção da expressão: os requisitos estão adequadamente estabelecidos? Clareza: as descrições estão compreensíveis e não contêm ambigüidades?
Excelência de Design	Acoplamento: qual é a extensão das conexões entre os elementos do sistema? Coesão: cada componente tem uma finalidade única e bem definida? Originalidade: os métodos ou as operações de uma classe podem ser construídos de outros métodos ou operações da classe? Se puderem, não são originais (uma característica desejável). Abrangência: o design realiza completamente os requisitos? Volatilidade: freqüência da alteração arquitetural.
Excelência da Implementação	Tamanho: qual é a proximidade da implementação em relação ao tamanho mínimo (para resolver o problema)? A implementação atende às restrições? Complexidade: o código está difícil ou intricado do ponto de vista do algoritmo? É difícil de entender e modificar? Abrangência: a implementação executa com fidelidade todo o design?
Excelência de Teste	Cobertura: o teste experimenta bem o software? Todas as instruções são executadas por um conjunto de testes? O teste experimenta muitos caminhos por meio do código? Validade: os próprios testes refletem corretamente os requisitos?
Excelência do Processo (no nível mais baixo)	Taxa de defeito, causa do defeito: qual é a incidência de defeitos em uma atividade, e quais são as causas? Esforço e duração: qual é a duração e quanto esforço humano exige uma atividade? Produtividade: por unidade de esforço humano, qual é o rendimento de uma atividade? Excelência dos artefatos: qual é o nível dos defeitos nas saídas de uma atividade?
Eficiência do Processo/Mudança de Ferramenta	(no que diz respeito à Excelência do Processo, mas o percentual é alterado, assim como os valores totais): Taxa de defeito, causa do defeito Esforço e duração Produtividade Excelência dos artefatos

Para obter uma abordagem detalhada dos conceitos de métricas, consulte [WHIT97].

O que é Métrica?

Cada métrica é composta de uma ou mais métricas coletadas. Conseqüentemente, cada métrica original deve ser claramente identificada e seu procedimento de coleta definido.

As métricas destinadas a suportar as metas de mudança ou realização freqüentemente são "geradas primeiro" ao longo do tempo (ou iterações ou projeto). Estamos interessados em uma tendência, não em um valor absoluto. Para "melhorar a qualidade" é preciso verificar se o nível residual de defeitos conhecidos diminui ao longo do tempo.

Templates

Nome	Nome da métrica e qualquer sinônimo conhecido.
Definição	Os atributos das entidades que são avaliadas usando essa métrica, como a métrica é calculada, e de qual métrica original ela é calculada.
Metas	Lista de metas e perguntas referentes a essa métrica. Também alguma explicação sobre por que a métrica está sendo coletada.
Procedimento de análise	Como se pretende usar a métrica. Precondições para a interpretação da métrica (por exemplo, conjunto válido de outras métricas). Valores-alvo ou tendências. Modelos de técnicas e ferramentas de análise para serem usados. Suposições implícitas (por exemplo, do ambiente ou modelos). Procedimentos de Calibração. Armazenamento.
Responsabilidades	Quem coletará e agregará os dados da métrica, preparará os relatórios e analisará os dados.

Atividades das Métricas

A definição do plano de métricas é realizada uma vez por ciclo de desenvolvimento - na fase de iniciação, como parte da atividade de planejamento geral, ou às vezes, como parte da configuração do processo no caso de desenvolvimento. O plano de métricas pode ser revisto como qualquer outra seção do plano de desenvolvimento de software durante o curso do projeto.

A coleta das medidas é realizada repetidamente, pelo menos uma vez por iteração, e às vezes mais freqüentemente; por exemplo, semanalmente, em uma iteração que dure muitos meses.

As métricas coletadas fazem parte do documento Avaliação de Status, que deve ser explorado na avaliação do andamento e da integridade do projeto. Elas também podem ser acumuladas para uso futuro em estimativas do projeto e tendências sobre a organização.

Como as Métricas são Usadas?

Estimativa

O gerente do projeto especialmente se depara com a situação de ter de planejar - atribuir recursos a atividades com orçamentos e programações. Tanto o esforço quanto a programação são estimados com base em um julgamento do que deve ser produzido, ou o inverso - há recursos fixos e programação, e é necessária uma estimativa do que pode ser produzido. A estimativa normalmente está relacionada ao cálculo dos recursos necessários com base em outros fatores - normalmente tamanho e produtividade - para fins de planejamento.

Previsão

A previsão é um pouco diferente da estimativa e normalmente indica o cálculo do valor futuro de algum fator com base em seu valor atual, e outros fatores de influência. Por exemplo, com um exemplo dos dados do desempenho, é útil saber (prever) como o sistema funcionará com carga total, ou em uma configuração de recursos restritos ou degradados. Os modelos de previsão de confiabilidade usam os dados da taxa de defeito para prever quando o sistema alcançará certos níveis de confiabilidade. Com uma atividade planejada, o gerente de projeto precisará dos dados sobre os quais prever as datas de conclusão e o esforço na conclusão.

Avaliação

A avaliação é usada para estabelecer a posição atual para comparar com um limite ou identificação de tendências, ou para comparação entre alternativas, ou como base da estimativa ou previsão.

Para obter mais informações sobre métricas no gerenciamento de projeto, leia [ROY98].