Aplicação de Métricas no
Subsistema Comu-Vig
O objetivo deste documento é demonstrar e quantificar a eficiência
do processo de desenvolvimento do Subsistema Comu-Vig e exibir o plano de
correção dos tópicos deficientes, no qual foram metrificados. A avaliação foi
feita através da ferramenta CASE Borland
Together Control Center.
As métricas aplicadas foram: CC - Cyclomatic Complexity, DOIH - Depth Of Inheritance
Hierarchy, NOCC - Number Of Child Classe, NOC -
Number Of Classes, CR - Comment Ratio.
Justificativa de uso das métricas sitadas
CC - Cyclomatic
Complexity : Esta métrica tem como função quantificar o
número de desvios (If, while, Case) de
um algoritmo. Esta métrica demonstra as
possibilidades de caminhos que o algoritmo fornece. Tendo essa visão se pode
fazer um analise de onde pode conter defeitos que não se demonstraram como
erro.
Exemplo:
if (x>0) {
x++;
} else {
x--;
}
CC = L - N + 2P = 4 - 4 +
2*1 = 2
DOIH - Depth Of
Inheritance Hierarchy: Esta métrica
contas o baixo nível de hierarquia de
herança de uma classe ou interface é declarada. Valores altos implicam que uma
classe está bastante especializada.
NOCC - Number Of Child
Classe: Contas o número de classes
que herdam de uma classe particular, demonstra o número de classes na árvore de
herança de uma classe particular. E interessante para se ter visão da
reusabilidade do software.
CR - Comment Ratio: Quantifica o número de comentários, um código bem
comentado facilita a interoperabilidade dos programadores.
NOC - Number Of
Classes: Conta o número de classes e a descriminação de
complexidade do código.
Aplicação das métricas no código
fonte
Foi encontrado defeitos no processo de
desenvolvimento em relação a métrica CR - Comment Ratio ( em azul no quadro acima
). Essa falha afeta a leitura do código por outro programador.
Plano para Correção dos Possíveis DEFeitos
|
Finalidade ·
Iniciar as ações corretivas apropriadas para
problemas e exceções que surgem no projeto |
|
Passos ·
Avaliar exceções e problemas ·
Determinar as ações corretivas apropriadas ·
Emitir Solicitações de Mudança e/ou Ordens de
Trabalho |
Avaliar Exceções e Problemas
O primeiro passo é
avaliar cada um dos problemas identificados na Avaliação de Status e na Lista
de Problemas. A maioria dos projetos realiza uma "Reunião de
Problemas" freqüente (geralmente semanal) com essa finalidade, com a
participação do gerente de projeto, do arquiteto de software e dos chefes de
equipe. Para cada problema, é necessário identificar a causa e o impacto
correspondente no projeto, bem como determinar quais são as opções para
resolvê-lo. Você também deverá determinar se a equipe do projeto tem autoridade
para implementar as possíveis soluções.
Determinar as Ações Corretivas Apropriadas
Para cada
problema/exceção, selecione a abordagem desejada para a resolução
correspondente e determine os passos necessários para implementá-la. Se essa
abordagem exigir uma mudança no Plano de Desenvolvimento de Software ou nos
requisitos ou design do produto, você precisará criar uma Solicitação de
Mudança e implementar a mudança após o Plano de Gerenciamento de Configuração
do projeto. Se a abordagem não alterar um dos planos que servem como baseline,
a solução poderá ser implementada pelo gerente de projeto através da emissão de
uma nova Ordem de Trabalho. Em qualquer um desses casos, se a solução escolhida
estiver além da autoridade da equipe do projeto, o problema deverá ser levado à
Autoridade para Revisão de Projetos de modo que seja resolvido. Por exemplo, se
o Gerente de Projeto determinou que, sem a ação corretiva, a iteração atual não
cumprirá a data de término planejada, a melhor ação é redefinir o escopo da iteração:
se isso impactar algo que será liberado para o cliente no final da iteração,
não deverá ser feito unilateralmente pela equipe do projeto.
Emitir Solicitações de Mudança e/ou Ordens de Trabalho
Após a definição
da ação corretiva para cada problema ou exceção e das aprovações necessárias, o
gerente de projeto documenta o trabalho envolvido e efetua Solicitações de
Mudança e/ou Ordens de Trabalho para iniciar o trabalho. Em geral, ele pode
retirar problemas da Lista de Problemas nessa etapa, pois o fechamento será
rastreado de outra forma.
|
Artefatos Informados:
|
Artefatos Resultantes:
|
Relatório Sintético
Atráves
desta listex 5 estamos implementando técnicas importante para expressar
Qualidade e quantificar o trabalho realizado.
Baseado-se
neste relatório serão criadas novas ideias que melhorarão cada vez mais o
software desenvolvido.