Como utilizar indicadores de qualidade no desenvolvimento de software

617 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
617
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Como utilizar indicadores de qualidade no desenvolvimento de software

  1. 1. Como utilizar indicadores de qualidade no desenvolvimento de software Vanessa Campos Publicado na iMasters em 11/09/2012 Teste e qualidade são duas máximas apresentadas com frequência em artigos, sala de aula, planejamento de projeto e ao longo do desenvolvimento de um software. E sempre levam a perguntas do tipo: quais os custos, as dificuldades de implementação e benefícios dos testes? Desenvolvimento ágil com qualidade e custo factível é possível? A experiência de desenvolvimento ágil fortemente baseado em SCRUM tem ajudado a transpor várias barreiras e a quebrar muitos dos diversos mitos referentes às métricas de qualidade. Os pontos de avaliação do processo e da equipe e a melhoria contínua que a metodologia ágil proporciona são pontos essenciais do processo utilizado para desenvolver software. Apresentaremos neste artigo algumas das soluções e mitos sobre a adoção dessa prática. Testar software é caro! Sim, testar é caro. Mas não testar é muito mais caro! E não, teste não é custo adicional do desenvolvimento. E de maneira alguma teste é algo que possa ser cortado ou reduzido. Quando todos entendem que teste faz parte do desenvolvimento, a própria equipe se reorganiza e garante que o teste não será negligenciado. É possível fazer isso usando-se um mix de TDD (Test-driven Design) e BDD (Behavior-driven Design) e vários níveis de testes ao longo do projeto (de teste unitário a teste de aceitação). O primeiro mito que pode ser vencido é o de que a taxa de cobertura de testes não é um número significativo. Realmente, se analisarmos somente a taxa de cobertura, isoladamente, ela não significa muito. Porém, quando são usados vários mecanismos de teste e se define muito bem o escopo da taxa de cobertura usando-se os plugins maven-cobertura-plugin e maven-surefire-plugin, é possível ter tranquilidade em afirmar que a cobertura de testes está alta ou baixa. Isso quando se considera na taxa de cobertura somente o código que trata do negócio do sistema. À primeira vista, o número pode não parecer muito significativo. Porém, ao longo do projeto, refatoramentos do código são necessários. Nesse ponto é que a equipe percebe a importância da taxa de cobertura estar alta e bem medida, pois o a essa altura o software já estará bem testado, e é possível garantir que todo o impacto causado pela mudança foi tratado.Passada a primeira barreira, é importante decidir ir um pouco além e adicionar mais métricas de qualidade. Dessa vez, pode-se optar por usar o CCN (Cyclomatic Complexity Number) e o número de bugs de código, usando-se a ferramenta Findbugs.O CCN é uma métrica de código desenvolvida por Thomas J. McCabe para indicar a complexidade do código. Segundo McCabe, um trecho de código deve ser avaliado sempre que o CCN exceder 10. Todo método cujo CCN excede 10 é candidato a refatoramento. E, com isso, pode-se quebrar outro mito do projeto: durante o desenvolvimento, não há tempo para melhorar o código. Lembre-se: é importante testar muito bem, medir a cobertura de testes constantemente e reavaliar esses números o tempo todo. Mas somente a lista de métodos candidatos não é suficiente. Por isso, deve-se criar um indicador para medir a qualidade do software. Isso pode ser feito comparando-se o número de métodos com CCN maior que dez com o
  2. 2. número total de métodos do projeto. Após coletar e avaliar esse indicador duas ou três vezes, é possível chegar a um valor médio que faz sentido para o projeto e trabalhar para que o indicador fique dentro da meta estabelecida. Seguindo nessa linha de melhoria contínua, é interessante adotar também o Findbugs e criar um indicador para ele, comparando o número de bugs com o número de linhas de código. O Findbugs proporciona uma análise diferente, pois encontra falhas, e não defeitos no sistema. Ou seja, nos indica potenciais futuros bugs da aplicação, além de mostrar à equipe melhores maneiras de desenvolver software, criando uma oportunidade de aprendizado dentro do projeto.Com esse mix de ferramentas e indicadores sendo avaliados constantemente, pode- se focar nos pontos críticos do sistema, introduzir uma cultura de avaliação e melhoria contínua do software, além de proporcionar a toda a equipe momentos de avaliação do código e uso de boas práticas de desenvolvimento. Usando essas métricas, fica mais seguro produzir o software de qualidade. A cobertura de testes traz essa segurança, aliada ao número de bugs do Findbugs sempre baixo, próximo de zero. O número de métodos refatorados devido ao CCN alto diminui ao longo do projeto e se começa a criar novos métodos já observando sua complexidade. O código se torna mais simples de ler, pois os métodos se tornam menos complexos. O Findbugs traz novo conhecimento, principalmente referente a boas práticas de desenvolvimento, movimentando o conhecimento dentro da equipe e motivando ao estudo mais saprofundado das ferramentas utilizadas no desenvolvimento. Para o cliente, todo esse movimento representa um número extremamente reduzido de defeitos nos testes de aceitação e a garantia de que a implementação de novos requisitos não trará impacto nos requisitos já entregues. Quem trabalha com entrega contínua de software sabe muito bem o quanto isso é importante. Leia o artigo na iMasters e deixe seu comentário: http://imasters.com.br/desenvolvimento/como-utilizar-indicadores-de-qualidade-no-desenvolvimento-de-software/ Entre em contato com a autora do artigo: Vanessa Campos fb.com/camposvoc @vanessaocampos

×