|
As medidas são efetuadas principalmente para ter o controle de um projeto e, portanto, ser capaz de gerenciá-lo. Elas
também são utilizadas para avaliar o grau de proximidade dos objetivos estabelecidos no plano em termos de conclusão,
qualidade, conformidade com os requisitos, etc.
Com as medidas, também é possível estimar melhor o esforço, custo e qualidade de novos projetos, com base em
experiência anterior. Por último, utiliza-se a medida para avaliar o aprimoramento em alguns aspectos-chave de
desempenho do processo ao longo do tempo, para observa os efeitos das alterações.
A medição de alguns aspectos-chave de um projeto envolve um custo significativo. Por essa razão, não medimos qualquer
coisa simplesmente porque podemos fazer isso. É necessário estabelecer com bastante exatidão as metas desse esforço e
coletar apenas as métricas que permitirão cumprir essas metas.
Há dois tipos de metas:
-
Metas de conhecimento: são expressas pelo uso de verbos, como avaliar, prever, monitorar. Você deseja
compreender melhor o processo de desenvolvimento. Por exemplo, talvez você deseja avaliar a qualidade do produto,
obter dados para prever o esforço de teste, monitorar a cobertura de teste ou rastrear alterações de requisitos.
-
Metas de alteração ou realização: são expressas pelo uso de verbos, como aumentar, reduzir, aprimorar ou
realizar. Geralmente você tem interesse em ver como as coisas são alteradas ou aprimoradas ao longo do tempo, de
uma iteração para outra, de um projeto para outro.
Exemplos:
-
Monitorar o progresso relativo ao plano
-
Aprimorar a satisfação do cliente
-
Aprimorar a produtividade
-
Aprimorar a previsibilidade
-
Aumentar a reutilização
Essas metas gerais de gerenciamento não são facilmente convertidas em métricas. Elas precisam ser convertidas em
submetas menores (ou metas de ação) que identificam ações que os membros do projeto precisam executar para
alcançar a meta. É necessário certificar-se de que as pessoas envolvidas compreendam os benefícios.
Exemplos
A meta para "aprimorar a satisfação do cliente" seria decomposta em:
-
Definir a satisfação do cliente
-
Medir a satisfação do cliente, em vários releases
-
Verificar se há aprimoramento da satisfação
A meta para "aprimorar a produtividade" seria decomposta em:
-
Medir esforço
-
Medir progresso
-
Calcular a produtividade em várias iterações ou projetos
-
Comparar os resultados
Por conseguinte, seria necessária a coleta de algumas métricas para algumas submetas (mas não todas).
Exemplo
"Medir a satisfação do cliente" pode ser derivada de
-
Relatório sintético do cliente (em que o cliente atribuiria notas para os diferentes aspectos).
-
Número e gravidade de chamadas para a hotline de suporte ao cliente.
Para obter informações adicionais, consulte AMI95].
Uma maneira útil de categorizar essas metas é por organização, projeto e necessidade técnica. Isso oferece uma
estrutura para o refinamento descrito anteriormente.
Uma organização precisa saber, e talvez aprimorar, seus custos por 'item', reduzir seus tempos de construção (prazo de
lançamento no mercado) e, ao mesmo tempo, fornecer um produto de qualidade conhecida (objetiva e subjetiva) e com
demandas de manutenção apropriadas. Uma organização pode precisar ocasionalmente (ou mesmo continuamente) aprimorar seu
desempenho para manter-se competitiva. Para reduzir seus riscos, uma organização precisa conhecer os níveis de
habilidade e de experiência de sua equipe e assegurar que ela possua os outros recursos e a capacidade para competir na
esfera escolhida. Uma organização deve ser capaz de introduzir uma nova tecnologia e determinar seu custo-benefício. A
tabela a seguir lista alguns exemplos dos tipos de métricas relevantes a essas necessidades para uma organização de
desenvolvimento de software.
|
Preocupaçã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
de parte definida de ciclo de vida, linguagem de programação, qualidade de equipe, etc.) por linha de
código, ponto de função ou caso de uso. Observe que essas métricas não são geralmente números simples -
elas dependem do tamanho do sistema a ser entregue e se o planejamento está compactado.
|
|
Tempo de Construção
|
Tempo decorrido por linha de código ou ponto de função. Observe que isso também depende do tamanho do
sistema. É possível, também, reduzir o planejamento por inclusão de equipe - mas apenas até um determinado
ponto. A capacidade de gerenciamento de uma organização determinará o limite exato.
|
|
Densidade de Defeitos no Produto Entregue
|
Defeitos (descobertos após a entrega) por linha de código ou ponto de função.
|
|
Qualidade Subjetiva
|
Facilidade de uso, facilidade de operação e aceitação do cliente. Embora sejam difusas, 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 de Habilidades, Perfil de Experiência
|
O grupo de Recursos Humanos provavelmente manteria algum tipo de banco de dados de habilidades e
experiências.
|
|
Recurso de Tecnologia
|
-
Ferramentas - uma organização deve conhecer aquelas de uso geral e a extensão de conhecimento
daquelas não utilizadas regularmente.
-
Maturidade do Processo - em que lugar a organização está classificada na escala SEI CMM, por
exemplo?
-
Recurso de Domínio - em quais domínios de aplicativo a organização é capaz de desempenhar?
|
|
Medidas de Aprimoramento do Processo
|
-
Tempo e esforço de execução do processo.
-
Taxas de defeitos, estatísticas de análise causal, taxas de correção, scrap e retrabalho.
|
Um projeto deve atender aos seguintes critérios antes da entrega:
-
recursos funcionais e não funcionais requeridos
-
várias restrições técnicas
-
restrições de orçamento e de planejamento
-
determinadas características de transição, operação e manutenção
O Coordenador de Projeto deve ser capaz de perceber se as metas estão sendo acompanhadas, expandidas na tabela a seguir
para dar uma idéia das considerações a serem feitas sobre as medidas do projeto:
|
Preocupação
|
Esforço e Orçamento do Projeto
-
Como está o acompanhamento do projeto sobre o esforço e custo em relação ao plano?
|
Planejamento do Projeto
-
O projeto está correspondendo a seus marcos?
|
Transição/Instalação
-
Os requisitos de esforço, custo e habilidades previstos são aceitáveis?
|
Operação
-
Os requisitos de esforço e habilidades previstos são suportáveis pelo cliente?
|
Manutenção/Suportabilidade
-
Os requisitos de esforço e habilidades previstos são aceitáveis para o cliente?
|
Requisitos Funcionais
-
Os requisitos são válidos e completos?
-
Os requisitos estão alocados para uma iteração?
-
Os requisitos estão sendo realizados de acordo com o plano?
|
Requisitos Não Funcionais
-
Desempenho
-
O sistema está atendendo aos requisitos de pronto atendimento, rendimento do processamento,
tempo de recuperação?
-
Capacidade
-
O sistema pode manipular o número necessário de usuários simultâneos? O Web site pode
manipular o número necessário de ocorrências por segundo? Existe armazenamento suficiente
para o número necessário de registros do cliente?
-
Fatores de Qualidade
-
Confiabilidade: com que freqüência são permitidos defeitos do sistema e o que constitui um
defeito do sistema?
-
Utilidade: o uso do sistema é fácil e satisfatório? Quanto tempo leva para aprender a
utilizá-lo e quais habilidades são necessárias?
-
Tolerância a falhas/resistência/recuperação/subsistência: o sistema poderá continuar em
funcionamento se ocorrerem defeitos? O sistema pode lidar com entrada inválida? O sistema é
capaz de recuperação automática após um defeito?
-
Requisitos de Engenharia de Especialidade
-
Segurança: o sistema pode ser desempenhado sem risco à vida ou propriedade (tangível e
intangível)?
-
Segurança/privacidade: o sistema protege os dados sigilosos contra acesso não autorizado? O
sistema está seguro contra acesso mal-intencionado?
-
Impacto ambiental: o sistema atende aos requisitos ambientais?
-
Outros Requisitos Reguladores ou Jurídicos
-
Restrições
-
Ambiente externo: o sistema tem capacidade para operação no ambiente prescrito?
-
Recursos, host, destino: o sistema atende a suas restrições de CPU, memória, idioma,
ambiente de hardware/software?
-
Uso do COTS (Commercial-Off-The-Shelf) ou outro software existente: o sistema atende às
restrições de reutilização?
-
Disponibilidade e habilidades da equipe: o sistema pode ser construído com o número e tipo
de equipe disponível?
-
Suporte/compatibilidade de interface: o sistema pode suportar o acesso requerido para/de
outros sistemas?
-
Reutilidade: quais provisões foram feitas para a reutilização do sistema?
-
Padrões estabelecidos: o sistema e o método de desenvolvimento estão em conformidade?
-
Outras restrições de design (arquiteturais, algorítmicas, por exemplo): o sistema
está utilizando o estilo arquitetural requerido? Os algoritmos prescritos estão sendo
utilizados?
|
Esta é uma extensa, porém não completa, lista de preocupações para o Coordenador de Projeto. Muitas delas necessitarão
da coleta e análise de métricas, outras também necessitarão do desenvolvimento de testes específicos (para derivar
medidas) para que seja possível responder às perguntas apresentadas.
Muitas das necessidades do projeto não terão medidas diretas e, mesmo para aquelas que tiverem, pode não ficar claro o
que deve ser feito ou alterado para aprimorá-las. Os atributos de qualidade de nível inferior podem ser utilizados para
construir a qualidade de vários atributos de qualidade de nível superior, como aqueles identificados no Padrão ISO 9126
(Características e Métricas de Qualidade de Software) e aqueles mencionados anteriormente em Necessidades do Projeto.
Estas medidas técnicas são de características e efeitos (estruturais e comportamentais) de engenharia (abrangendo o
processo e o produto), que contribuem para as necessidades de métricas no nível do projeto. Os atributos na tabela a
seguir foram utilizados para derivar um conjunto de métricas de amostra para os produtos de trabalho e o processo do
Rational Unified Process. Isso pode ser encontrado em Diretriz do Produto de
Trabalho: Métricas.
|
Qualidade
|
Atributos
|
|
Boa Qualidade de Requisitos
|
-
Volatilidade: freqüência de alteração, taxa de introdução de novos requisitos
-
Validade: estes são os requisitos corretos?
-
Integralidade: estão faltando requisitos?
-
Correção de expressão: os requisitos foram determinados corretamente?
-
Clareza: as descrições são compreensíveis e sem ambigüidade?
|
|
Boa Qualidade de Design
|
-
Acoplamento: qual a extensão das conexões entre os elementos do sistema?
-
Coesão: cada componente possui um único propósito bem definido?
-
Estado primitivo: os métodos ou operações de uma classe podem ser construídos a partir de outros
métodos ou operações da classe? Neste caso, eles não são primitivos (uma característica desejável).
-
Integralidade: o design realiza totalmente os requisitos?
-
Volatilidade: freqüência de alteração arquitetural.
|
|
Boa Qualidade de Implementação
|
-
Tamanho: qual a proximidade da implementação em relação ao tamanho mínimo (para resolver o
problema)? A implementação atenderá às restrições?
-
Complexidade: o código é algoritmicamente difícil ou complexo? É difícil compreender e modificá-lo?
-
Integralidade: a implementação realiza fielmente todo o design?
|
|
Boa Qualidade de Teste
|
-
Cobertura: o quanto é satisfatória a aplicação do teste do software? Todas as instruções são
executadas por um conjunto de testes? O teste aplica vários caminhos através do código?
-
Validade: os testes, propriamente ditos, são um reflexo correto dos requisitos?
|
|
Boa Qualidade de Processo (nível mais baixo)
|
-
Taxa de defeitos, causa do defeito: qual é a incidência de defeitos em uma tarefa e quais são as
causas?
-
Esforço e duração: qual duração e quanto esforço humano são requeridos por uma atividade?
-
Produtividade: por unidade de esforço humano, o que uma atividade produz?
-
Boa qualidade de produtos de trabalho: qual é o nível de defeitos nas saídas de uma tarefa?
|
|
Eficácia de Alteração de Processo/Ferramenta
|
(o mesmo que Boa Qualidade de Processo, mas a porcentagem é alterada no lugar de valores totais):
-
Taxa de defeitos, causa do defeito
-
Esforço e duração
-
Produtividade
-
Boa qualidade de produtos de trabalho
|
Para um tratamento detalhado dos conceitos de métricas, consulte [WHIT97].
Há dois tipos distintos de métricas:
-
Uma métrica é um atributo mensurável de uma entidade. Por exemplo, esforço do projeto é uma medida (ou seja,
métrica) de tamanho do projeto. Para calcular essa métrica, você precisaria somar todos os registros da planilha de
tempo durante o projeto.
-
Uma métrica primitiva é um item de dados brutos utilizado para calcular uma métrica. No exemplo anterior, os
registros da planilha de tempo são as métricas primitivas. Uma métrica primitiva é geralmente uma métrica que
existe em um banco de dados, mas que não é interpretada isoladamente.
Cada métrica é formada por uma ou mais métricas coletadas. Conseqüentemente, cada métrica primitiva precisa ser
claramente identificada e seu procedimento de coleta definido.
As métricas para suporte às metas de alteração ou realização são, muitas vezes, as "primeiras derivativas" no decorrer
do tempo (ou iterações ou projeto). Estamos interessados em uma tendência, não no valor absoluto. Para "aprimorar a
qualidade", é necessário verificar se o nível residual de defeitos conhecidos diminui ao longo do tempo.
Modelo para uma Métrica
|
Nome
|
Nome da métrica e quaisquer sinônimos conhecidos.
|
|
Definição
|
Os atributos das entidades medidas utilizando esta métrica, como a métrica é calculada e a partir de quais
métricas primitivas ela é calculada.
|
|
Metas
|
Lista de metas e perguntas relacionadas a esta métrica. Também algumas explicações do motivo da coleta da
métrica.
|
|
Procedimento de Análise
|
Como a métrica deve ser utilizada. Condições prévias para a interpretação da métrica (por exemplo,
intervalo válido de outras métricas). Valores ou tendências de destino. Modelos de técnicas de análise e
ferramentas a serem utilizadas. Premissas implícitas (por exemplo, do ambiente ou dos modelos).
Procedimentos de ajuste. Armazenamento.
|
|
Responsabilidades
|
Quem coletará e agregará os dados de medida, preparará os relatórios e analisará os dados.
|
Gabarito para uma Métrica Primitiva
|
Nome
|
Nome da métrica primitiva.
|
|
Definição
|
Descrição sem ambigüidade da métrica em termos do ambiente do projeto.
|
|
Procedimento de Coleta
|
Descrição do procedimento de coleta. Ferramenta e forma de coleta de dados a serem utilizadas. Pontos no
ciclo de vida quando os dados são coletados. Procedimento de verificação a ser utilizado. O lugar em que os
dados serão armazenados, o formato e a precisão.
|
|
Responsabilidades
|
Quem é responsável pela coleta dos dados. Quem é responsável por verificar os dados.
|
Existem duas tarefas:
-
Definir plano de medidas
-
Coletar medidas
A definição do plano de medidas é feita uma vez em cada 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 medidas pode ser inspecionado, como qualquer outra seção do plano de desenvolvimento de software, durante o
projeto.
A coleta de medidas é feita de modo repetitivo, pelo menos uma vez por iteração e às vezes com mais freqüência; por
exemplo, semanalmente em um iteração que se estende por muitos meses.
As métricas coletadas fazem parte do documento Avaliação de Status, a ser explorado ao avaliar o progresso e o
funcionamento do projeto. Elas também podem ser acumuladas para uso posterior em estimativas e tendências do projeto
por toda a organização.
Estimativa
O coordenador de projeto, em particular, se depara com a necessidade de planejar - designar recursos a tarefas com
orçamentos e planejamentos. O esforço e o planejamento são estimados a partir de uma avaliação do que deve ser
produzido, ou o inverso - existem recursos e um planejamento fixados e é necessária uma estimativa do que pode ser
produzido. A estimativa geralmente está relacionada ao cálculo de necessidades do recurso com base em outros fatores -
normalmente tamanho e produtividade - para propósitos de planejamento.
Previsão
A previsão é somente um pouco diferente da estimativa e, geralmente, é sobre o cálculo do valor futuro de algum fator
baseado no valor atual desse fator e outros fatores que exercem influência. Por exemplo, dada uma amostra de dados de
desempenho, é útil saber (prever) a partir dela como será o desempenho sistema sob carregamento total ou em uma
configuração restrita ou degradada do recurso. Os modelos de previsão de confiabilidade utilizam os dados de taxa de
defeitos para prever quando o sistema alcançará determinados níveis de confiabilidade. Após o planejamento de uma
atividade, o coordenador de projeto precisará dos dados para prever as datas de conclusão e o esforço para conclusão.
Avaliação
A avaliação é utilizada para estabelecer a posição atual para comparação com um limite, declaração ou identificação de
tendências ou para comparação entre alternativas ou como a base para estimativa ou previsão.
Para obter informações adicionais sobre métricas no gerenciamento de projeto, leia [ROY98].
|
