Gerência de Processos
Mestrado de Informática / UFPB
Francilene Procópio Garcia, D.Sc.
[email protected]
Métricas - Parte V
Você sempre obtenhe o que
cobra e acompanha
Por quê devemos medir?
Nós medimos primeiramente porque desejamos ter controle sobre o
projeto e, portanto, gerenciá-lo. Nós medimos para avaliar o quanto
próximo ou distante nós estamos dos objetivos delineados em algum
plano em termos de finalização, qualidade, conformidade com os
requisitos, etc.



As medições melhoram a capacidade de estimar em
novos projetos (esforço, custos, qualidade)
As medições indicam aspectos que devem ser
melhorados
As medições ajudam a compreender os efeitos das
mudanças ao longo da vida útil do software
Métricas devem ser úteis!

Coleta-se apenas o que pode ser útil para o alcance
de metas traçadas. Existem dois tipos de metas, em
geral:


Aprendizagem: ajudam a compreender melhor o processo
de desenvolvimento em uso. Por exemplo: avaliar a
qualidade do produto; obter dados para prever o esforço
com testes; monitorar mudanças nos requisitos.
Controle de mudanças: ajudam a entender como as
mudanças ou melhorias ocorrem ao longo do tempo,
iteração após iteração. Por exemplo: melhoria da satisfação
do cliente; melhoria da produtividade; aumento do reuso.
Como transformar metas em ações?

“Melhorar a satisfação do cliente” poderia ser
decomposta em:




definir o que é a satisfação do cliente\
medir tal satisfação em várias versões
verificar se a satisfação tem aumentado
“Melhorar produtividade” poderia ser decomposta em:




medir o esforço
medir o progresso do projeto
calcular a produtividade em várias iterações e/ou projetos
comparar os resultados
Por quê a empresa necessita das métricas?
Custos
Custo por LOC, custo por pontos de função, custo por use case.
Veja que não são números simples - dependem do tamanho do
sistema a ser produzido e da pressão do cronograma.
Tempo de
desenvolvimento
Tempo usado por LOC ou pontos de função. Também
dependente do tamanho. O cronogroma pode ser encurtado se
mais gente for incorporada. A capacidade de gestão deverá
influenciar no conhecimento de limites.
Defeitos (encontrados após entrega) por LOC ou pontos de
função.
Facilidade de uso, facilidade p/ operar, aceitação do cliente.
Densidade de
defeitos
Qualidade
subjetiva
Manutenção
Experiência
Custo por LOC ou por pontos de função no ano.
Alguma forma de medir a experiência deve constar no BD.
Tecnologia
Ferramentas, Processo, Domínio
Melhoria do
processo
Tempo de execução do processo; esforço; taxa de defeitos;
retrabalho.
O projeto também necessita de métricas

Um projeto típico deve ser entregue em sintonia com:





requisitos funcionais e não funcionais
algumas restrições
orçamento e tempo
transição para o cliente e condutas de manutenção
O projetista deve ser capaz de monitorar tais aspectos
(o projeto está alcançando os milestones? os requisitos
alocados numa iteração são válidos? etc)
Métricas típicas no projeto







Esforço e orçamento
Cronograma
Transição/Instalação
Operação
Manutenção
Requisitos funcionais
Requisitos não funcionais
Non-Functional Requirements
 Performance
 Is the system meeting requirements for responsiveness, throughput, recovery time?
 Capacity
 Can the system handle the required number of simultaneous users? Can the web site
handle the required number of hits per second? Is there sufficient storage for the
required number of customer records?
 Quality Factors
 Reliability - how often are system failures allowed, and what constitutes a system
failure?
 Usability - is the system easy and pleasant to use? How long does it take to learn how
to use it and what skills are required?
 Fault tolerance/ robustness/ resilience/ survivability - can the system continue to function
if failures occur? Can the system cope with bad input? Is the system capable of
automatic recovery after failure?
 Specialty Engineering Requirements
 Safety - can the system perform without risk to life or property (tangible and
intangible)?
 Security/ privacy - does the system protect sensitive data from unauthorized access? Is
the system secure from malicious access?
 Environmental impact - does the system meet environmental requirements?
 Other Regulatory or Legal Requirements
 Constraints
 External environment - is the system capable of operation in the prescribed
environment?
 Resources, host, target - does the system meet its CPU, memory, language,
hardware/ software environment, constraints?
 Use of commercial-off-the-shelf (COTS) or other existing software - is the system
meeting its reuse constraints?
 Staff availability and skills - can the system be built with the number and type of staff
available?
 Interface support/ compatibility - can the system support required access to and from
other systems?
 Reusability - what provisions are made for the system to be reusable?
 Imposed standards - are the system and the development method compliant?
Other design constraints (architectural, algorithmic, for example) - is the system using the
required architectural style? Are the prescribed algorithms being used?
Métricas devido às necessidades técnicas
Qualidade
Atributos
Requisitos
Volatilidade (frequência de mudanças requisitos)
Validade
Completude
Correticidade
Clareza
Acoplamento (intensidade de conexões)
Coesão (propósito claro)
Primitivismo (métodos ou classe podem ser construídos a partir de outros?)
Completude
Volatilidade (frequência mudança na arquitetura)
Tamanho
Complexidade
Completude
Cobertura
Validade
Taxa defeito
Productividade
Artefatos
Design
Implementação
Teste
Processo
Então, o que é uma métrica?

Existem duas categorias de métricas:



Metricas de processo - também conhecidas como métricas
para gestão - relacionadas ao processo em uso e usadas
para:
 ajudar nas estimativas de tamanho e esforço
 determinar se o projeto encontra-se no prazo
Métricas de produto - também conhecidas como métricas de
qualidade - medem a qualidade do produto
Essas duas categorias as vezes são conflitantes
entre si!
Métricas de processo vs. métricas de produto



Como distinguí-las? As taxas de defeito são parte do
produto - onde elas são encontradas - ou são parte do
processo - onde elas são criadas?
Regra geral : imagine sempre que as métricas de
produto medem sempre as funcionalidades ou
componentes do sistema
Regra geral : as duas sempre serão usadas
conjuntamente para avaliar o processo como um todo
Métricas OO: categorias

Em geral, encontram-se organizadas em quatro
categorias:




Tamanho do sistema: por exemplo, saber antecipadamente quantas
chamadas à funções ou o número de objetos pode ajudar na
obtenção de estimativas mais precisas
Tamanho de classes e métodos: medido de várias formas - classes e
métodos pequenos e simples são bem melhor
Acoplamento e herança: o número e tipo desses relacionamentos
indicam a interdependência entre classes. Relacionamentos simples
e claros são mais desejáveis
Classes e métodos internos: este tipo de métrica revela como as
classes complexas e seus métodos se encontram e como a
documentação interna se dá
Métricas OO: Tamanho do sistema


Em geral, na maioria dos sistemas OO, componentes tipo GUI
representam um volume significativo do desenvolvimento total
esperado.
Este tipo de métrica inclui:




Total de LOC. Todas as linhas de código executável no sistema, classes
ou métodos. Comparações entre sistemas similares são válidas
Total de chamadas à funções (TCF). O número de chamadas à
métodos e funções do sistema. Mede tamanho de forma mais
independente do estilo de codificação do que LOC
Número de classes (NC). Conta todas as classes no sistema, incluindo
as classes não visuais e classes GUI (controle de janelas, por exemplo)
Número de janelas (NJ). Conta o número de janelas visíveis no sistema
- indicando o tamanho da interface presente no sistema
Métricas OO: Tamanho de classes e métodos


Consideradas equivalentes a métricas de qualidade - pois, em
geral, classes grandes indicam abstrações mau concebidas
Este tipo de métrica inclui:



LOC e chamadas à função por classe/método. Tais métricas são
similares ao LOC, mas focam sobre classes e métodos individuais
Número de métodos por classe e métodos públicos por classe. O
número de métodos por classe indica o nível de funcionalidade
implementada numa classe. O número de métodos públicos indica a
exposição ao mundo externo e provê uma visão do tamanho da
classe e de sua complexidade de uso
Número de atributos por classe e número de instâncias do atributo
por classe. O número de atributos indica o volume de dados a ser
mantido numa classe. Os atributos podem ser instâncias de atributos
- instâncias únicas do objeto - com o mesmo valor para todos os
membros da classe
Métricas OO: Acoplamento e herança


Ajudam a medir a qualidade do modelo do objeto. Revelam o grau
de dependências existente entre objetos. O ideal seria a total
independência entre objetos - facilitando o reuso, por exemplo
Em geral, o número de dependências é tão grande que que
entender o comportamento do grupo inteiro é mais caro do que
reescrever os objetos. Algumas métricas utéis:




Class Fan-in. Medem o número de classes que dependem de um
dado objeto.
Class Fan-out. Medem o número de classes sobre as quais uma dada
classe depende. Deveria ser evitada, evitando crecimento de
dependências.
Nível de herança da classe. O nível de herança de uma classe
depende do número de ancestrais diretos.
Número de filhos por classe. Mede o número de descendentes diretos
de uma dada classe.
Métricas OO: Métrica Fan-in

Classe B

Classe A
Classe C

Classe E
Classe D
Cada seta indica a
dependência de uma
classe com outra.
Neste caso, todos os
objetos dependem da
classe E
Usando a técnica fan-in,
você pode reusar
qualquer classe em outro
projeto - apenas
incluindo a classe E
Métricas OO: Métrica Fan-out

Classe B
Classe A
Classe C


Classe E
Classe D
Usando esta técnica
você deve incluir muitos
objetos sempre que
desejar reusá-los
É mais dispendiosa a
manutenção
Reusar a classe E
também incluirá as
demais classes
Métricas OO: Classes e métodos internos

Métricas internas suportam várias medidas de qualidade tanto para
as classes quanto para os métodos. Podem ser usadas para
identificar as áreas onde uma ação corretiva deve ser aplicada.
Incluem:



Número de referências globais/compartilhadas por classe. Esta métrica
indica o número de referências a variáveis globais. Referências globais
tendem a quebrar a encapsulação einibir o reuso
Complexidade do método. A complexidade do método ou
complexidade ciclomática mede o número de caminhos diferentes da
execução do código. Muito alta indica código difícil manter/entender
Ausência de coesão entre métodos. Mede a extensão com a qual a
classe que referencia o método instancia o dado. Em geral, deseja-se
baixo acoplamento e alta coesão (objetos não podem ser deixados)
Métricas OO: Classes e métodos internos (cont.)



Indíce de especialização da classe. Este índice mede a extensão com
a qual subclasses apresentam o mesmo comportamento de seus
ancestrais. Um número alto indica que a abstração não está OK. É
melhor ter subclasses com métodos diferentes
Percentagem de métodos comentados. Mede a extensão de
documentação interna no código. Conta o número de blocos de
comentários separados - melhor do que o número de linhas de
comentários
Número de parâmetros por método. Esta métrica mede o número
médio de parâmetros envolvidos na chamada de um método. Um
número alto de parâmetros indica uma interface complexa e deve ser
evitado
Como as métricas são usadas?


Podem ser usadas em sistemas pequenos (200.000
LOC) até muitos grandes (centenas de milhares de
LOC)
O importante é saber como fazer uso dos números:
 guiar o desenvolvimento
 priorizar as revisões e inspeções
 rever padrões
Como as métricas são usadas? (cont.)



Métricas OO, em particular, podem ajudar:
 a estimar o tamanho do código e o esforço
necessário
 definir políticas de revisões e de desenvolvimento
 priorizar onde fazer uso do esforço nas revisões
 avaliar a qualidade global do sistema
Para tal, faça uso de ferramentas que ajudam na
coleta de métricas mais detalhadas
No mais, trate de fazer o melhor e o mais simples ...