As Métricas que Apresentaremos
Olá Pessoal! Tudo Bom?! 🙂
Iremos apresentar um “mapa” de diversas métricas para medição de software, no mais amplo possível de seu ciclo de vida de desenvolvimento. Abordaremos distintos cenários para distintas necessidades conforme a fase de desenvolvimento do software e o perfil de cada profissional envolvido. Exemplos práticos específicos também serão abordados em artigos relacionados a cada métrica.
Vamos lá! Tipos de Métricas
Apresentaremos uma visão geral dos tipos de métricas. Um projeto de desenvolvimento de software pode conter diversos tipos de artefatos mensuráveis (Lista de Requisitos, Casos de Uso, Modelo de Dados, Modelo UML, Linhas de Código, etc.), e também de acordo com o tipo de processo de desenvolvimento (RUP, Spice, Scrum, XP, etc.). Destacaremos alguns tipos de métricas, o objetivo de cada uma, e relacionaremos aos respectivos artefatos do processo de produção de software.
A lista abaixo relaciona os tipos mais significativos, que afetam drasticamente a utilização do resultado da métrica para estimativa de Custo, Prazo e Esforço.
1 – Métrica de Requisitos
2 – Métrica de Arquitetura
3 – Métrica de Projeto UML
4 – Métrica de Banco de Dados
5 – Métrica de Implementação
6 – Métrica de Teste
7 – Métrica de Performance
8 – Métrica de Implantação
9 – Métrica de Integração
10 – Métrica de Operação
11 – Métrica de Monitoramento
12 – Métrica de Marketing
Tipos de Métrica x Método de Medição
1 – Métrica de Requisitos
Medir o software do ponto de vista do usuário, levando em conta como será a interação do mesmo com o software e o que é esperado de cada interação. As regras de negócio devem ser especificadas, assim como regras de interface entre o software e o usuário. No final da contagem é mensurado o quanto que o usuário solicita de requisitos e/ou quanto o mesmo recebe.
Métodos de medição: Análise de Pontos de Função e NESMA.
2 – Métrica de Arquitetura
Medir a capacidade da arquitetura, em termos de quantidade de funcionalidades encapsuladas a mesma fornece para os projetistas, desenvolvedores e testadores.
Métodos de medição: Não existe métricas formais. A arquitetura pode ser analisada pela quantidade de componentes abstratos e interfaces de serviços não-funcionais que a mesma atende.
3 – Métrica de Projeto UML
Mede a quantidade de artefatos UML descrevem o software de forma horizontal e vertical. Consideramos horizontal a quantidade de tipos de artefatos, tais como Diagramas de Classe, Sequências, Componentes, Implantação, etc. Verticalmente a quantidade de elementos por diagrama, tal como Nós no Diagrama de Implantação, classes no Diagrama de Classe, etc.
Método de medição: Não existe uma métricas formais. O Projeto UML é documentado de forma quantitativa, e a empresa deve criar um guia formalizando as regras de documentação com a finalidade de restringir o escopo de esforço, controlar a qualidade e tornar a base histórica de contagem efetiva para fins de estimativa.
4 – Métrica de Banco de Dados
Mede as estruturas físicas e lógicas do banco de dados. Como o banco de dados está estruturado e as operações que são realizadas no mesmo devem ser mensuradas. É conveniente que até mesmo os tipos, periodicidades e tamanho de backup sejam mensurados e documentados.
Métodos de medição: Por padrão é de costume dos DBAs mensurar a quantidade de tabelas, quantidade de registros em sua carga inicial e fator de crescimento de registros em cada tabela. Os registros são mensurados considerando um fator quantitativo e também físico em bytes, com base na quantidade de bytes de cada registro. Colunas do tipo BLOB, CLOB, FILE, etc. devem ser mensuradas separadamente se orientando também nos requisitos de negócio e requisitos não-funcionais.
Por questões de gerenciamento é uma boa prática mensurar a arquitetura física do banco de dados, tal como Datafiles, Tablespaces, etc.
5 – Métrica de Implementação
Mede fisicamente o tamanho do código implementado. Esta medida pode ser o tamanho físico em quantidade de linhas de cada arquivo de código fonte, ou lógica utilizando a quantidade de comandos existem em cada linha de código fonte.
Método de medição: LOC (Line Of Code). Técnica utilizada para medir a quantidade de linhas de código. A técnica LOC possui duas variantes, SLOC (Sorce Line Of Code) e LLOC (Logical Line Of Code), que medem respectivamente a quantidade de linhas físicas e quantidade de comandos por linha de código conforme mencionado no parágrafo anterior.
6 – Métrica de Teste
Mede a quantidade de código que é coberto pelos testes. Existem diversos tipos de testes, Teste Unitário, Teste Funcional, Teste de Aceitação, etc. O mais importante é ter devidamente documentado e acordado a quantidade mínima de código que deve ser coberto pela técnica escolhida.
Método de medição: Code Coverage.
7 – Métrica de Performance
Com os atuais dispositivos de pequeno porte em relação aos computadores, tais como Tablets e Smartphones, a performance de execução da aplicação retornou a ser um fator crucial para o sucesso e fracasso de um software, podendo até mesmo não alcançar determinados usuários por conta de fatores também relacionados e capacidade de telecomunicação.
Previamente a produção do software, no momento em que o Arquiteto de Software estiver projetando o mesmo, deve-se documentar e estabelecer os requisitos mínimos e máximos de performance para o correto desenvolvimento da arquitetura de software e seleção de tecnologias e frameworks.
Método de medição: Mensurar em milissegundos a velocidade média que cada funcionalidade de negócio, que responde a cada ação do usuário nos tipos de dispositivos contemplados na arquitetura, estão de acordo o esperado.
Cabe ao Arquiteto de Software orientar ao Analista de Requisitos a projetar a realização do negócio com telas (protótipos) contendo barras de progresso, ou até mesmo operações assíncronas quando o processamento for inevitavelmente pesado.
8 – Métrica de Implantação
A complexidade e cada atividade envolvida no processo de implantação do software afeta de forma significativa o projeto.
Na etapa de implantação, principalmente primeira implantação, muitas vezes é necessário diversos perfis de profissional, bem como os mais capacitados da equipe para realizar tais atividades. Caso a implantação não seja mensurada o gestor de projeto poderá encontrar um planejamento “obscuro” onde a estimativa de Custo, Prazo e Esforço é baseada simplesmente no “feling” e susceptível a muitas falhas de planejamento, resultando em baixo lucro ou até mesmo prejuízo, juntamente com o constrangimento do cliente.
Método de medição: De acordo com a Base de Projetos formada pela empresa, deve-se obter o esforço médio de implantação com cada atividade da implantação, por exemplo, instalação de banco de dados, instalação de bibliotecas, configuração de usuários, etc.
9 – Métrica de Integração
Projetos de software possuem alto risco ao desenvolver integrações. O Arquiteto de Software consegue estimar tecnicamente o esforço para integrar com determinado protocolo, mas jamais conseguirá estimar a estabilidade, risco, complexidade causada por pouca ou nenhuma documentação existente. Para evitar que problemas de integração sejam incorporados ao desenvolvimento do software e causa raiz para baixa produtividade da equipe, deve-se tratá-lo isoladamente com a finalidade de identificar o real riso e produtividade do mesmo, por exemplo, integrar com a Receita Federal, com o SAP, ou determinado banco financeiro, etc.
Método de medição: Mensurar o esforço e manter a produtividade na base de projetos separadamente, por exemplo, a produtividade para integrar um software com uma rede social, um órgão público, etc. deve ser mantido separadamente do esforço para desenvolver as funcionalidades para o usuário final.
10 – Métrica de Operação
Mesmo com o software desenvolvido, implantado e integrado com sucesso nada adianta se não for possível operacionalizá-lo. Como o gestor conseguirá estimar tal operacionalização? A resposta é simples! Mensurar o nível de mudança do software, a depreciação das tecnologias requerendo atualizações e upgrades, a produtividade e perfis dos profissionais envolvidos nas soluções de incidentes e desenvolvimento de mudanças e melhorias, o indice de SLA acordado em todas as infraestruturas envolvidas e comparar tudo isso a base de projetos.
Método de medição: Reunir todas as atividades recorrentes, catalogar pelas criticidades, catalogar a produtividade de cada perfil da equipe em horas/criticidade. Assim poderá mensurar o prazo e custo médio para realizar determinada quantidade de atividades recorrentes com a equipe formada.
11 – Métrica de Monitoramento
“A pressão está tão alta que pode ocorrer um ataque cardíaco, ou tão baixa que pode ter uma parada cardíaca?”
Uma operação por mais mensurada que seja não conseguirá fornecer informações suficiente para que ações proativas sejam tomadas para que um software não tenham incidentes de alta gravidade e risco. Para que possamos atuar proativamente e de forma preventiva temos que observar como que todo o ambiente onde o software está implantado se comporta, e para isso temos que monitorá-lo a maior quantidade de elementos possíveis.
A quantidade de elementos a serem monitorados determinará o custo do monitoramento e sua eficiência.
“Mas qual quantidade e quais elementos a serem monitorados?”
Método de medição: Levantar todos os itens de monitoramento do ambiente implantado e integrado, por exemplo, processador, memória, rede, internet, temperatura, espaço de armazenamento, etc. de toda infraestrutura. A quantidade de elementos definirá a complexidade de alertas e itens para atenção. Deve-se ter cuidado para não selecionar itens em demasia, pois sempre que isso acontece resulta em e-mails e SMS ignorados pelos técnicos como o “erro conhecido” infelizmente.
12 – Métrica de Marketing
Tudo Pronto!!! 🙂 Seu produto de software desenvolvido, testado, implantado, integrado, em operação e monitorado. Mas será se ele terá sucesso mesmo?! Sei não viu!
“É o produto que foi definido? Custa o preço adequado? Está sendo ofertado para o público correto? Está sendo divulgado corretamente?”
Caso não consiga responder ou tenha uma resposta negativa para os questionamentos acima seu produto de software está fortemente comprometido. Deve-se obrigatoriamente questionar e monitorar estes questionamentos que formam o chamado “Os 4P do Marketing”. Produto, Preço, Praça e Promoção.
Método de Medição: O produto deve ser medido se foi desenvolvido tal como especificado. Pode-se utilizar a Análise de Pontos de Função. O preço deve levar em conta o preço dos concorrentes e o custo de desenvolvimento do mesmo de forma equilibrada. A Praça, ou meio onde se encontra os consumidores, deve realmente ter a necessidade em adquirir o produto de software desenvolvido. O software deve ser promovido ao público certo, levando em consideração cultura, gênero, economia, faixa etária e atributos similares.
As Métricas mencionadas acima juntas completam todo um ecossistema de medidas. Muitas dificuldades estão envolvidas para implantar tamanha quantidade de métricas, porém nos artigos publicados orientaremos a melhor prática e planejamento. Também forneceremos dicas de ferramentas e softwares para auxiliar no trabalho.
Lembre! Mensurar permite manter sob controle o conhecimento de tudo que ocorre em seu projeto de software!
Obrigado!
[ABTM id=380]