Pular para o conteúdo principal

Medição de Software


Olá,
hoje nós vamos falar sobre medição de software e da experiência em fazê-la no sistema para a escola de surfe que estou desenvolvendo na faculdade juntamente com outros colegas. Os conceitos aqui apresentados, se baseam na apostila de medição de software.

Para começar, o que é medição de software ? Segundo Dumke, medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Sendo assim, é possível perceber a importância da análise estatística do desenvolvimento do seu software, pois com ela consegue-se obter informações relevantes, tais como: tamanho do projeto, custos de desenvolvimento, quantidade de defeitos e etc. No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance dos objetivos, à identificação de problemas e à tomada de decisões informadas. No contexto organizacional, a medição pode auxiliar na análise do desempenho dos processos e apoiar o estabelecimento de metas factíveis(isso é importante rs), bem como identificação de ações que visem melhorar a competitividade da organização.
Maravilha, não ? Mas as coisas não são tão fáceis assim, porque realizar a medição demanda esforço, sem contar nos custos envolvidos, como tempo.. essas coisas.
Podemos dividir o processo de medição em três atividades gerais: planejamento, execução e avaliação da medição.
Para realizar o planejamento da medição no trabalho, primeiro tivemos que pensar o que nós gostaríamos de medir. Antes de entrar nessa parte, o professor nos apresentou uma ferramenta chamada SonarQube que faz a análise contínua da qualidade do código. Ela possui algumas métricas, como: quantidade de bugs, vulnerabilidades e code smells. Haha, onde vamos usar isso, hein ? Exatamente, são elas que nós vamos analisar no processo de medição. Preciso nem comentar sobre a execução, né ? Que lindo, o Sonar faz isso para gente. Basta configurá-lo com o seu repositório no GitHub e pronto! Como configurar ? Vamos deixar esse assunto para outro post :)
Bom, já falamos sobre o planejamento e a execução da medição. Agora vamos falar sobre a parte mais importante: a avaliação!

Para nos auxiliar na avaliação dos resultados da medição, nós utilizamos ferramentas gráficas (quer que eu desenhe ? kkk fica bem melhor!), como gráficos de controle. Com eles nós conhecemos identificar com maior clareza variações e diferenciá-las dos ruídos, picos e etc, ao longo de um determinado período.
Existem vários tipos de gráficos de controle, e cada um possui uma melhor aplicabilidade a situações específicas. A forma como os dados serão plotados e como os limites de controle serão calculados, são definidos pelo tipo de gráfico. Cada tipo possui um conjunto de métodos quantitativos ou estatísticos associados.
Embora diferentes, eles possuem uma estrutura básica. Os limites central, superior e inferior são calculados a partir de um conjunto de valores coletados para a medida representada no gráfico, sendo que os limites superior e inferior ficam a uma distância de três desvios padrão em relação à linha central. Dá uma olhadinha no gráfico abaixo para ver como fica.

Estrutura base para gráficos de controle 
Como já foi dito, existem vários tipo de gráficos de controle, como: XBar, XmR, XMmR.. Qual que eu devo usar ? Depende do que você quer medir hihi.
Eu não vou me aprofundar nos gráficos e no que cada um faz,por que esse também é um assunto que caberia em outro post, vou partir logo para o que foi usado no trabalho.
Para escolher que gráfico usar, tivemos que voltar lá nas variáveis, entender o que nós queríamos saber delas e como fazer para obter essa informação. Nós queríamos medí-las várias vezes. Sendo assim, os gráficos XmR e XMmR eram os gráficos candidatos para essa tarefa. Qual a diferença dos dois ? No gráfico XmR, nós analisamos a variação média daqueles dados. No gráfico XMmR, nós analisamos ao invés da média, a mediana. Mas a pergunta continua, qual a diferença ? A média, estatisticamente falando, é uma medida sensível a outliers, ou seja, se no meu conjunto de dados eu tiver valores muito pequenos ou valores muito grandes, a média vai levar todo mundo pra baixo ou todo mundo para cima e isso não é interessante. Sendo assim, escolhemos usar  o gráfico da mediana, por ela ser uma medida mais equilibrada, capaz de nos dar uma informação mais próxima do real.

Exemplo de uma gráfico XMmR de quantidade de code smells por commit.

XMmR quantidade code smells X commit
Bom, isso é quase tudo pessoal! kkk
Tudo isso parece simples e realmente é, basta dedicar uma parte do tempo para essa atividade que os resultados serão recompensadores.

Até a próxima :)














Comentários

Postagens mais visitadas deste blog

TDD e BDD

Olá pessoal, Hoje nós falaremos sobre TDD e BDD! Logo que eu ouvi sobre eles gerou um confusão enorme na minha cabeça. O que é TDD e BDD ? TDD – Test-Driven Development (Desenvolvimento Orientado a Testes) é o Desenvolvimento de Software orientado a Testes. O processo de desenvolvimento do TDD seria: Escrever um teste, sem mesmo ter escrito o código real a ser testado (Imagine o que deseja testar). Executar os testes e acompanhar a falha (Pode ser um código falso que retorne o  erro) Escrevemos a funcionalidade do sistema que iremos testar. Testar novamente, agora para passar (Se não passou algo saiu errado, faça novamente o passo 3) Refatore sua funcionalidade e a escreva por completo (o teste também) (Refactor) Passe para o próxima estória ou caso de uso e inicie novo teste. Confesso que isso é bem estranho, principalmente os passos 1 e 2 rs, até porque se funcionasse sem código seria mais estranho ainda kkk. BDD – Behavior Driven Dev

Padrões GRASP

Olá pessoal! Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre   padrões GRASP . Vamos lá! Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução. Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião. 1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la. Qual o padrão que estamos utilizando ? O information expert! Os benefícios ao usar são: Encapsulamento mantido  Comportamento é bem mais distribu